Skip to main content
Jump to: navigation, search

Difference between revisions of "Platform UI/Bug Triage"

Line 3: Line 3:
 
* [http://www.eclipse.org/eclipse/platform-ui/greasemonkey/ Greasemonkey script]
 
* [http://www.eclipse.org/eclipse/platform-ui/greasemonkey/ Greasemonkey script]
 
* [http://www.eclipse.org/eclipse/platform-ui/componentAreas.php Component Areas]
 
* [http://www.eclipse.org/eclipse/platform-ui/componentAreas.php Component Areas]
 +
* [[Platform_UI/Bug_Triage_Change_2009|Why we changed our bug triage process]]
  
−
== Problem ==
+
==The New Bug Triage Process in Detail==
  
−
In the current Platform UI bug triaging process, bugs are assigned to component owners.  The primary role of the component owner is to watch over the activity in those bugs, ensuring that no critical bugs are left unnoticed and that comments are addressed.  Second to that is to attempt to fix some of the bugs.  This assigning of bugs is effected through the changing of the "owner" field of the bug.
+
This is how our bug triage process looks like:
−
 
+
−
However, this process incorrectly provides the impression that all bugs are being worked on because they have owners.  This often isn't the case, since the reality is that there are more bugs per component owner than the owner will ever have time to fix.  It makes it look like "everything is being taken care of".
+
−
 
+
−
Additional tricks like adding the "helpwanted" keyword or changing the priority are then required, but these aren't always or consistently applied, so become an unreliable reflection of the need/desire for community participation.
+
−
 
+
−
Finally, while being the owner of a component area is a fairly "big" job, watching over bugs and helping with their further triaging isn't, and we recognize that there are opportunities for the community to participate at a lower granularity than component owner.
+
−
 
+
−
== Proposal ==
+
−
 
+
−
We believe that it would be clearer, and more helpful to the community, if the assigning of a bug meant what it should mean, which is that the person "owns" the outcome of the bug and is going to fix it.  When and only when a committer decides they are going to fix a bug should it's owner field be set to them.  Bugs without owners are, by definition then, bugs not being worked on.
+
−
 
+
−
To manage the "watching" of bugs task, we propose instead to use the QA Contact field, which presently is unused. Where today we'd assign the bug to the component owner, we'd instead make them the QA Contact.  Triaged bugs would initially be assigned to a group user like platform-ui-triaged@eclipse.org.  The QA Contact could be the component owner, or could be any other platform UI committer who is willing to lend a hand.  They would keep up on the comment thread and ensure that critical bugs are brought to the attention of someone who can fix it.
+
−
 
+
−
== Advantages ==
+
−
 
+
−
We believe there are several advantages to this small change:
+
−
 
+
−
# Clarity of status: It provides a more truthful reflection of bug activity. It now becomes easier to tell which bugs are actually being worked on, since they are the ones with owners.
+
−
# Identification of opportunity: It provides an easier way for the community to identify places where they can get involved.  Bugs without an owner are defacto "help wanted" bugs.  Additionally, committers who want to help but can't commit to owning a component can become QA Contacts for some set of bugs.
+
−
# Effectiveness: Finally, we believe this will help component owners focus on fixing the most important bugs, which after all, is the greatest benefit to the community.
+
−
 
+
−
==The Process in Detail==
+
−
 
+
−
This is how the bug process would look like as a result:
+
  
 
Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.
 
Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.
Line 49: Line 26:
 
* Respond on the bug if necessary.
 
* Respond on the bug if necessary.
 
* Adjust prioritization if necessary.
 
* Adjust prioritization if necessary.
−
 
−
Questions and comments are of course welcome. Unless we find a flaw in the proposed process, or come up with a better idea, we should be able to use the new process next week. We suggest that we start using this new process on all incoming bugs, and move over existing bugs over time. For existing bugs, we should start with those that are currently "owned" by former members of the team (Kim, Tod, Karice...). As part of the moving over, we should classify bugs correctly as actual bugs vs. enhancement requests.
 
−
 
−
TODO: Clean up page after we have consensus. Add links to bugzilla queries, component areas, and greasemonkey script.
 

Revision as of 15:56, 26 February 2009

Helpful links

The New Bug Triage Process in Detail

This is how our bug triage process looks like:

Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.

Incoming bugs: To do triage, we use the Greasemonkey script (with buttons for all component areas). Clicking on a button will

  • Prefix the bug description with [ComponentArea].
  • Set the "QA contact" field to the person responsible for watching bugs in the identified component.
  • Assign the bug to platform-ui-triaged@eclipse.org (separate account from platform-ui-inbox).

As part of the triage, we need to make sure that the bug contains enough information, and that the "severity" is set to a value that makes sense. Enhancement request need to be marked as such, and the same is true for blocker/critical bugs.

When a person is assigned as the QA contact for a bug:

  • Double-check that there is enough information in the bug, and that the severity is accurate.
  • If it is a blocker or critical bug (e.g. loss of data, crash), it needs to be fixed as soon as possible. If you are not able to fix the bug yourself, assign it to someone else who is.
  • If it is a regression, it needs to be fixed during the current development cycle, or potentially in a maintenance stream as well. Schedule the bug accordingly, or assign it to someone else who has time to work on it.
  • For all other bugs, try to stay "on top" of the bugs you are watching in the sense that you can produce a rough prioritization of the bugs in a component area. Something like: "if we had the time to fix these ten bugs, our code would be in much better shape".

When a new comment is made on a bug you are watching:

  • Respond on the bug if necessary.
  • Adjust prioritization if necessary.
Retrieved from "http://wiki.eclipse.org/index.php?title=Platform_UI/Bug_Triage&oldid=141763"

Back to the top