[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Platform UI triage process
|
What about a name like
platform-ui-helpwanted-inbox ?
Also, I forgot to ask in the original proposal whether we are going to do the same for platform-ide?
susan
![Inactive hide details for Boris Bokowski <bokowski@xxxxxxxxx>]()
Boris Bokowski <bokowski@xxxxxxxxx>
![]()
| ![]()
| ![]()
To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc:
Subject: Re: [platform-ui-dev] Platform UI triage process |
We hit a snag - it is not easy to just get arbitrary bugzilla accounts
at eclipse.org. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=265985 for the
discussion.
Would assigning to nobody@xxxxxxxxxxx be an option? Personally, I
think this would send too strong a message.
Would platform-ui-triaged-inbox be an option? Personally, I think this
would be misleading because one of the goals was to have an account
that is not perceived as an inbox.
Any help (ideas, comments, here or on bug 265985) would be appreciated.
Boris.
On Tue, Feb 24, 2009 at 12:04 PM, Boris Bokowski <bokowski@xxxxxxxxx> wrote:
> Sounds like we have a consensus. (Yay! Next topic: formatter
> options... just kidding :-)
>
> I have filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=265985 to
> get the new bugzilla account created.
>
> On today's call, we said that moving bugs from existing owners to
> platform-ui-triaged should happen over time rather than as one fell
> swoop. I will add a button to the Greasemonkey script for the purpose
> of moving a bug to platform-ui-triaged. The script will add a one-line
> comment to the bug, with a pointer to a wiki page explaining the
> changes. Based on this one-line comment, people should be able to
> filter out unwanted bug emails.
>
> Boris
>
> 2009/2/24 John Arthorne <John_Arthorne@xxxxxxxxxx>:
>>
>> +1, I think this proposal makes sense and is worth a shot. In Platform
>> Runtime/Resources we use the ASSIGNED to inbox technique, but I agree with
>> the sheer volume of bugzilla traffic on UI that a dummy triaged owner makes
>> sense. That allows people to watch only new bugs, or all triaged bugs if
>> they dare. Component owners will need to double-check their bugzilla
>> settings to ensure they are notified on bug changes when they are the QA
>> contact.
>>
>> John
>>
>>
>>
>> Boris Bokowski/Ottawa/IBM@IBMCA
>> Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
>>
>> 02/23/2009 10:15 PM
>>
>> Please respond to
>> "Eclipse Platform UI component developers list."
>> <platform-ui-dev@xxxxxxxxxxx>
>> To
>> platform-ui-dev@xxxxxxxxxxx
>> cc
>> Kevin McGuire/Ottawa/IBM@IBMCA
>> 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
>>
>>
>> _______________________________________________
>> platform-ui-dev mailing list
>> platform-ui-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>
>>
>
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
