mahuja 12 Posted March 6, 2007 Someone put me in the developer group, so I now have the power to improve descriptions, mark as acknowledged, and so on. But we're in a sorry shape when it comes to guidelines. Here's how I'm currently working... 1. Fix bad summaries 03-06-07 12:17 MaHuJa Summary Editor => Editor - Opfor group "air/transport" is blufor 2. Mark relationships 03-06-07 12:17 MaHuJa Relationship added duplicate of 0002077 3. If I can objectively call it a bug, and have personally verified it (reproduced), i set it acknowledged. There was a case where I agreed with the change, but where it was a subjective opinion. I didn't change that. This means BIS can, if they don't care to wade through the 'rest' of the reports, get right at real bugs... (Well, there aren't *that* many bad reports...) But there is something up for discussion: What do I do when I have a duplicate, do I close ("resolved") the duplicate, or what? (In addition to resolution=duplicate) There is a small problem in that most places show only one of them. (Though I guess "is duplicate of" would suffice to tell that it being "resolved" doesn't matter) But if we 'resolve' it, information unique to that other bug (attachments, notes, etc) would easily be overlooked. Share this post Link to post Share on other sites
mahuja 12 Posted March 6, 2007 I've seen some disagreement on the version field as well. Is this supposed to be the earliest time it was observed (...uuhh.. occasionally they date back to OFP! or the latest? ("This still needs fixing! It wasn't fixed by accident or this issue just not updated!") Share this post Link to post Share on other sites
boecko 0 Posted March 6, 2007 I've seen some disagreement on the version field as well.Is this supposed to be the earliest time it was observed (...uuhh.. occasionally they date back to OFP! or the latest? ("This still needs fixing! It wasn't fixed by accident or this issue just not updated!") It's the version in which the bug was reported. That means, if the bug isn't marked as resolved, the issue is still there in the next versions 1.03,1.04 ,etc. BTW: I gave you the rights after reading your sandbox Share this post Link to post Share on other sites
raedor 8 Posted March 6, 2007 As a first step you should be moved in a more appropiate group as I'm pretty sure that you're not a developer. Your suggestions are looking good, it is especially required that the summaries and descriptions are spot-on. Duplicates should be closed. Share this post Link to post Share on other sites
boecko 0 Posted March 6, 2007 As a first step you should be moved in a more appropiate group as I'm pretty sure that you're not a developer. About the appropiate group.. It's just a name. Look at the differences  between UPDATER and DEVELOPER here. http://bugs.armed-assault.net/adm_permissions_report.php not much IMHO. Essential is, that the THRESHOLD for getting mail when new bugs are submitted is DEV. So people, who like to contribute (e.g. cleaning up things), can react more quickly. That's why I gave him this permission. Share this post Link to post Share on other sites
INNOCENT&CLUELESS 0 Posted March 6, 2007 Quote[/b] ]3. If I can objectively call it a bug, and have personally verified it (reproduced), i set it acknowledged.There was a case where I agreed with the change, but where it was a subjective opinion. I didn't change that. There I see a problem, maybe I am wrong. I suggested to use CONFIRMED as statement after NEW to express to the reporter that his TT is accepted and not rejected nor set to FEEDBACK. But there is also ACKNOWLEDGED, which could mean both acknowledging the NEW TT or acknowledging the fix. To make it crystal clear I suggest to rename CONFIRMED to VERIFIED if it should be used to express that the fix is successfully re-tested. And the used status should be locked in the ticket flow so that no abuse by mistake would be possible. Somaybe NEW-(FEEDBACK)-ACKNOWLEDGED-(FEEDBACK)-ASSIGNED-(FEEDBACK)-RESOLVED-CONFIRMED/VERIFIED-CLOSED I forgot to mention another thing: It would be correct in my opinion if the reporter is obliged to close a TT mainly. Devs should not be worry about TT which are RESOLVED, but not in VERIFIED or CLOSED, that`s the duty of the community to verify the offered fix and the reporter to CLOSE if he is happy with the fix. Only in case the reporter does not react in time, the managers and the admin should CLOSE a TT. I did this wrong already. Share this post Link to post Share on other sites
boecko 0 Posted March 6, 2007 CONFIRMED and VERIFIED is basically the same, so there is no need to change that. This might be interesting for choosing the right status: <a href="http://mantisbt.org/manual/manual.page.descriptions.system.management.pages.manage.configuration.workflow.transitions .php" target="_blank">http://mantisbt.org/manual....ons.php</a> Quote[/b] ]We use 'acknowledged' to confirm that a new issues has been reviewed and that it is indeed a bug and that it contains enough information to be reproduced/analysed. However, at this time we will not start work on it. Once we start a new release and the issue needs to be addressed (in this release), its status will change to 'confirmed'. Once an issue gets assigned to a developer, he is expected to work on it ASAP. So we will never have developers that have hundreds of issues assigned to them. Share this post Link to post Share on other sites
boecko 0 Posted March 9, 2007 Feel free to complete this page: http://community.bistudio.com/wiki/BTS_Guidelines Share this post Link to post Share on other sites
raedor 8 Posted March 9, 2007 We could also look for some addicted BTS managers as we had for the biki buglist. Share this post Link to post Share on other sites
raedor 8 Posted March 11, 2007 Speaking of priorities... could someone add a filter which only shows bugs with priority >= high && resolution = open? Share this post Link to post Share on other sites
boecko 0 Posted March 11, 2007 done it's called 'open bugs with high prio' rss-feed: http://bugs.armed-assault.net/issues_...._id=261 Share this post Link to post Share on other sites
