Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by DanielQuinlan:
http://wiki.apache.org/spamassassin/UsingBugzilla
The comment on the change is:
add triage procedure
------------------------------------------------------------------------------
The general practise is to open a bug when some task needs to be done, even if there is no "bug" involved. The idea is to provide a "thread" of discussion and a place to track development.
Also does Bugzilla offer a more persistent way of storing things, ie. stuff like patches and votes are less likely to get lost on the mailinglist.
+
+ == Bug Triage ==
+
+ Here is how you handle bug triage:
+
+ * mark duplicated bugs as duplicate
+ * try to confirm bugs
+ * ask users for additional information as needed (sooner is better if you want a response)
+ * set the severity (how bad does it affect things, is it an enhancement request, etc.)
+ * close bugs already fixed (when possible, this is mostly done by developers, but sometimes it's obvious or easy to tell)
+
+ That leaves priority and milestone setting...
+
+ Priority doesn't really get used much and is in theory set by the
+ assignee, so let's ignore it.
+
+ We do use the milestones a lot. Developers are always going to tweak
+ those, but I think we could come up with a procedure to allow those to
+ be set fairly accurately in a first pass triage. Something like:
+
+ {{{
+ if (bug)
+ set severity appropriately if needed
+ if (bug affecting current svn head)
+ assign to next release off of svn head
+ elsif (bug affecting current stable release)
+ if (bug affects both svn head and current stable)
+ # I'm still not entirely happy with how we handle this case...
+ assign to next release off of svn head, make note in bug
+ else
+ assign to next stable release
+
+ else
+ set severity to "enhancement"
+ if (pie-in-the-sky)
+ assign to "Future"
+ else
+ assign to next major release
+ }}}
== When Taking Bugs... ==
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by DanielQuinlan:
http://wiki.apache.org/spamassassin/UsingBugzilla
The comment on the change is:
add triage procedure
------------------------------------------------------------------------------
The general practise is to open a bug when some task needs to be done, even if there is no "bug" involved. The idea is to provide a "thread" of discussion and a place to track development.
Also does Bugzilla offer a more persistent way of storing things, ie. stuff like patches and votes are less likely to get lost on the mailinglist.
+
+ == Bug Triage ==
+
+ Here is how you handle bug triage:
+
+ * mark duplicated bugs as duplicate
+ * try to confirm bugs
+ * ask users for additional information as needed (sooner is better if you want a response)
+ * set the severity (how bad does it affect things, is it an enhancement request, etc.)
+ * close bugs already fixed (when possible, this is mostly done by developers, but sometimes it's obvious or easy to tell)
+
+ That leaves priority and milestone setting...
+
+ Priority doesn't really get used much and is in theory set by the
+ assignee, so let's ignore it.
+
+ We do use the milestones a lot. Developers are always going to tweak
+ those, but I think we could come up with a procedure to allow those to
+ be set fairly accurately in a first pass triage. Something like:
+
+ {{{
+ if (bug)
+ set severity appropriately if needed
+ if (bug affecting current svn head)
+ assign to next release off of svn head
+ elsif (bug affecting current stable release)
+ if (bug affects both svn head and current stable)
+ # I'm still not entirely happy with how we handle this case...
+ assign to next release off of svn head, make note in bug
+ else
+ assign to next stable release
+
+ else
+ set severity to "enhancement"
+ if (pie-in-the-sky)
+ assign to "Future"
+ else
+ assign to next major release
+ }}}
== When Taking Bugs... ==