Difference between revisions of "Platform UI/Bug Triage Change 2009"

(New page: This page explains how Platform UI and IDE changed their bug triage process in February 2009 and why. == Problem == In the old Platform UI bug triage process, all bugs were assigned to c...)

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.

+

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 its 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 will instead use the QA Contact field, which was unused in the past. So instead of assigning the bug to the component owner, we instead make them the QA Contact. Triaged bugs are assigned to a group user like platform-ui-triaged@eclipse.org until they are assigned to a real owner, with the intent of fixing them. 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.

To manage the "watching" of bugs task, we will instead use the QA Contact field, which was unused in the past. So instead of assigning the bug to the component owner, we instead make them the QA Contact. Triaged bugs are assigned to a group user like platform-ui-triaged@eclipse.org until they are assigned to a real owner, with the intent of fixing them. 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.

+

+

See the [[Platform UI/Bug Triage|Platform UI Bug Triage]] wiki page for a detailed description of the new process.

== Advantages ==

== Advantages ==

Line 22:

Line 24:

# 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.

# 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.

+

# Identification of opportunity: It provides an easier way for the community to identify places where they can get involved. Bugs without an owner are de facto "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.

# 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.

Line 28:

Line 30:

We are starting to use the new bug triage process as of February 26, 2009. To avoid large amounts of Bugzilla spam, we will move existing bugs to platform-ui-triaged@eclipse.org over time, starting with those who are still assigned to former members of the team. When moving bugs to platform-ui-triaged@eclipse.org, we should make sure that they are accurately classified as bugs vs. enhancement requests.

We are starting to use the new bug triage process as of February 26, 2009. To avoid large amounts of Bugzilla spam, we will move existing bugs to platform-ui-triaged@eclipse.org over time, starting with those who are still assigned to former members of the team. When moving bugs to platform-ui-triaged@eclipse.org, we should make sure that they are accurately classified as bugs vs. enhancement requests.

+

+

== How to contact us ==

+

+

Please comment on the bug, someone will get back to you on the bug. If there is no response within a few days, please ping again on the bug. If this does not work, ask on the newsgroup (eclipse.platform) or use our mailing list platform-ui-dev@eclipse.org.

Latest revision as of 12:11, 2 March 2009

This page explains how Platform UI and IDE changed their bug triage process in February 2009 and why.

Contents

Problem

In the old Platform UI bug triage process, all bugs were 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.

However, this process incorrectly provided 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 made it look like "everything is being taken care of".

Additional tricks like adding the "helpwanted" keyword or changing the priority were 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 recognized 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 its 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 will instead use the QA Contact field, which was unused in the past. So instead of assigning the bug to the component owner, we instead make them the QA Contact. Triaged bugs are assigned to a group user like platform-ui-triaged@eclipse.org until they are assigned to a real owner, with the intent of fixing them. 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

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 de facto "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.

Transition Period

We are starting to use the new bug triage process as of February 26, 2009. To avoid large amounts of Bugzilla spam, we will move existing bugs to platform-ui-triaged@eclipse.org over time, starting with those who are still assigned to former members of the team. When moving bugs to platform-ui-triaged@eclipse.org, we should make sure that they are accurately classified as bugs vs. enhancement requests.

How to contact us

Please comment on the bug, someone will get back to you on the bug. If there is no response within a few days, please ping again on the bug. If this does not work, ask on the newsgroup (eclipse.platform) or use our mailing list platform-ui-dev@eclipse.org.