[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-dev] Re: [platform-ui-dev] Correct usage of bug priorities
|
I agree with the comments below, and suggest it may be worth modifying the
enter_bug template to clarify the field definitions. IMHO the template in
use by the Bugzilla system itself is a good example (
http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla ) Ok, well
maybe the STOP sign is a bit over the top!
> 5. Nobody other than the bug owner should ever modify the priority
field.
If people are not playing nicely, this can trivially be enforced through
minor modifications to Bugzilla as described here (
http://www.bugzilla.org/docs/html/cust-change-permissions.html )
Regards,
Tim
Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx
06/05/2004 01:51
Please respond to
eclipse-dev
To
eclipse-dev@xxxxxxxxxxx
cc
Subject
[eclipse-dev] Re: [platform-ui-dev] Correct usage of bug priorities
Here here!
The Eclipse team greatly appreciates the time and effort that the
community puts into tracking down and reporting bugs. We would not be
where we are today without that input. We also appreciate that our users
have come to depend on Eclipse for important parts of their lives (whether
it be work or fun or both).
However, as we approach the end of the 3.0 cycle the team needs to be able
to identify and focus on the critical issues. As Stefan points out,
overstating bug severity is a major (no pun intended) inhibitor in that
process. Once a bug has been analyzed, the *Eclipse Team* assigns a
priority given the other problems and our workloads. Please do NOT change
priority of a bug. This is how we manage our work.
I would also ask that you followup on your bugs. If you found more
information, were asked for more information, found that it was
user/configuration error, etc etc. letting us know can save alot of time
that can then be spent improving other areas.
Finally, don't be afraid of marking a report as an Enhancement. This does
not mean it gets ignored. There are many polish items and minor
annoyances which take little time to address and we appreciate knowing
about them. These can add substantially to the quality of the end result.
Thanks
Jeff
Stefan Xenos/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
05/05/2004 08:25 PM
Please respond to
platform-ui-dev
To
platform-ui-dev@xxxxxxxxxxx
cc
Subject
[platform-ui-dev] Correct usage of bug priorities
I'd like to direct everyone's attention to the following URL:
https://bugs.eclipse.org/bugs/bug_status.html#bug_severity
Currently, too many bugs are being misclassified with a severity of
"major" or higher. This noise is starting to make it hard to locate the
really urgent bugs, and some real biggies are sometimes going unnoticed.
I would like to suggest the following guidelines:
1. If classifying a bug as "blocker", the bug must indicate what it blocks
(ie: which product, feature, or Eclipse milestone is being delayed until
the bug is resolved)
2. In order to be classified as "critical", a bug must cause Eclipse to
crash, delete user data, or report a memory leak which is severe enough to
cause Eclipse to become unusable.
3. To be classified as "major", there must be some important piece of
functionality that is unusable (with no workaround). The existence of a
workaround means that the bug cannot be major.
4. All cosmetic problems are "trivial", no matter how ugly.
5. Nobody other than the bug owner should ever modify the priority field.
6. If someone has removed themself from the CC list or the Assigned To
field, they don't want to be there.
7. Don't be rude
I believe we need some sort of minimal policing of the bugzilla system in
order to reduce its abuse. The guidelines above should probably be
displayed every time a new bug is entered along with a warning like:
"Failure to follow these rules will result in deletion of your bugzilla
account". The threat of repercussions would probably be enough to
eliminate most of the abuse, even if no accounts were ever deleted.
- Stefan