[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Platform UI triage process
|
+1. We do it exactly the same in Text and JDT land with one exception:
instead of introducing a new group account/owner (
platform-ui-triaged@xxxxxxxxxxx) which is not well known in the community
we use the ASSIGNED state of the inbox to reflect this and our goal is to
have an empty inbox when it comes to NEW, REOPENED and UNCONFIRMED bugs.
Triaged bugs are ASSIGNED to the inbox.
Dani
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Boris Bokowski <Boris_Bokowski@xxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|platform-ui-dev@xxxxxxxxxxx |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Kevin McGuire <Kevin_McGuire@xxxxxxxxxx> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|24.02.2009 04:16 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[platform-ui-dev] Platform UI triage process |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
