Guidelines? [Archive] - Bohemia Interactive Forums

View Full Version : Guidelines?

MaHuJa

Mar 6 2007, 11:03

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.

MaHuJa

Mar 6 2007, 11:54

boecko

Mar 6 2007, 12:12

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&#33http://forums.bistudio.com/oldsmileys/wink_o.gif 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 (http://community.bistudio.com/wiki/MaHuJa%27s_Sandbox) http://forums.bistudio.com/oldsmileys/wink_o.gif

raedor

Mar 6 2007, 12:14

As a first step you should be moved in a more appropiate group as I'm pretty sure that you're not a developer. http://forums.bistudio.com/oldsmileys/wink_o.gif

Your suggestions are looking good, it is especially required that the summaries and descriptions are spot-on.

Duplicates should be closed.

boecko

Mar 6 2007, 12:58

As a first step you should be moved in a more appropiate group as I'm pretty sure that you're not a developer. http://forums.bistudio.com/oldsmileys/wink_o.gif

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.

raedor

Mar 6 2007, 13:03

Well okay... http://forums.bistudio.com/oldsmileys/wink_o.gif

INNOCENT&CLUELESS

Mar 6 2007, 13:59

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.

boecko

Mar 6 2007, 14:45

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.

boecko

Mar 9 2007, 16:57

Feel free to complete this page:
http://community.bistudio.com/wiki/BTS_Guidelines

raedor

Mar 9 2007, 17:18

We could also look for some addicted BTS managers as we had for the biki buglist.

raedor

Mar 11 2007, 00:02

Speaking of priorities... could someone add a filter which only shows bugs with priority >= high && resolution = open?

boecko

Mar 11 2007, 02:16

done

it's called 'open bugs with high prio'
rss-feed:
http://bugs.armed-assault.net/issues_...._id=261 (http://bugs.armed-assault.net/issues_rss.php?project_id=1&filter_id=261)

raedor

Mar 11 2007, 19:13

Thanks! http://forums.bistudio.com/oldsmileys/smile_o.gif