Re: [platform-ui-dev] Platform UI triage process

["Prakash G.R." <grprakash@xxxxxxxxx>]

+1.

I too felt that the current triage could be improved (but didn't know
how). This looks like a much better solution.

 - Prakash

“People are meant to be loved and things are meant to be used.
But unfortunately, people are being used and things are being loved”


2009/2/24 Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>:
> Apologies for the long email, but we have put this off for too long and it
> is high time to fix how we triage bugs.
>
> The "busy committer" summary is: We would like to move bugs that nobody is
> planning to work on to a group account ("platform-ui-triaged@xxxxxxxxxxx").
> To ensure that each bug has someone who is responsible for "watching" it, we
> would like to use the "QA Contact" field which is currently unused.
>
> === Problem ===
>
> 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.
>
> 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@xxxxxxxxxxx. 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:
>
> 1) 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.
>
> 2) 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.
>
> 3) 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: 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@xxxxxxxxxxx (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 committer 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.
>
> 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.
>
> Boris and Kevin
>
> P.S. A copy of the main part of this email is at
> http://wiki.eclipse.org/Platform_UI/Bug_Triage - to be cleaned up and
> enriched with links etc. when we have consensus.
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>