Re: [wtp-dev] Re-Inventing Hot List

[Jeffrey Liu <jeffliu@xxxxxxxxxx>]

Let me try to recap..... I believe the
concern raised by Konstantin is that developers need a consistent way to
treat "normal" bugs and hot bugs.

I second Naci's idea to prefix hot bugs
with [hotbug] to denote a bug that is required by our adopters.
This allows us to generate a live query that can used in our weekly status
meeting. As David suggested in the last status meeting, we can use Status_Whiteboard
field to indicate which release the adopter wants this bug to be fix in
(ex. 1.0.1, 1.0.2 or 1.5).

I think adopters should continue to
submit hot bugs via the wtp-dev mailing list. Once a hot bug is submitted,
I will:

1. Prefix the abstract with [hotbug]
2. Change he Status_Whiteboard
field to indicate the correct release
3. Change the priority to at least P2
4. Add myself to the CC list

Note that the above process does not
require us to set the target milestone of the bug. In our weekly status
meeting, we will review all open hot bugs. For hot bugs that do not have
a target milestone set, the originator (or delegate) and the owner of the
bug should discuss whether this bug is release-defining or not. When an
agreement is reached (assuming it's release-defining), we will set the
target milestone and that's golden, meaning we are committed to fix this
bug in that release. We will not declare a release until all targeted hot
bugs are fixed. If it's not release-defining, then we will remove the [hotbug]
prefix, etc or defer it to the next release. In cases where an agreement
cannot  be reached, PMC members will have a vote on whether a bug
is release-defining or not.

Feel free to beat on this proposal.
Thanks.

Jeffrey Liu
IBM Rational Software - Performance Analyst
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/R8V/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920
jeffliu@xxxxxxxxxx

Arthur Ryman/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

02/22/2006 10:13 AM

Please respond to
"General discussion of project-wide or architectural issues."

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	Re: [wtp-dev] Re-Inventing Hot List

Kosta, 

Thx for the suggestions. Let's take a step back for a minute and review
why we have a Hot Bug process. 

WTP has two main goals: 

        1) Provide tools for Web application developers.
        2) Provide a platform for tool developers.

Both of these are very important for the success of WTP. The Hot Bug process
is aimed at goal #2. 

There are many more application developers than tool developers so the
bugs that are important to tools developers can easily get lost in the
large bugzilla backlog. To put things in perspective,  there have
been a total of 6700 bugs opened for WTP to date, but only 200 of them
are Hot Bugs. That's around 3% of the total. 

We need to treat tool vendors, aka adopters, differently. WTP is the first
Eclipse project, AFAIK, to treat adopters specially. The current process
needs to be refined over time. I'm sure we don't have it right yet.

However, I don't think we should rely on severity since I'd like us to
use severity correctly. Sometimes an adopter problem does not meet the
criteria for Blocking or Critical but is still very important. A Major
problem could be enough for an adopter to not use WTP. The meaning of Major
is that some major function is unusable. That major function might be exactly
what the adopter needs. 

This means we need to use another field. Priority is orthogonal to severity.
Priority is our way of saying what we are going to work on. If we mark
a bug as P1 then it is release-defining, i.e. we should delay the release
if a P1 function is broken. That translates into how we allocate our resources.
We need to plan our work so that we fix all the P1s first, then the P2s,
etc. 

To make this more concrete, suppose there was a bug in our HTML editor
that caused Eclipse to crash whenever the HTML editor opened a document
that contained a URL that was longer that 1,000,000 characters. That would
be a Critical bug because it caused a crash, but I would assign it a very
low priority because it is a very extreme edge case and would never affect
a user. 

In contrast, suppose our server tools listed a server adapter for IMB WebSphere.
I'd immediately open a Hot Bug to get that corrected. From my point of
view that would be a P1, but the severity would be trivial.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

02/21/2006 09:36 PM

Please respond to
"General discussion of project-wide or architectural issues."

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	[wtp-dev] Re-Inventing Hot List

I’d like to start the conversation about how we can improve the Adopter
Hot List process going forward. Here is a proposal to get us started. Feel
free to poke holes in it... 
  
This proposal places more emphasis on the severity field and establishes
a strict release exit criteria for high severity issues. A triage committee
(composed of PMC members or their designated replacements) would be established
in order to resolve disagreements over the severity and other issues.

• In order to exit a release all S1 (Blocking Severity) and S2 (Critical Severity) bugs targeted to that release have to be resolved. Additionally, there should not be any untargeted/uninvestigated S1/S2 bugs. The triage committee can push bugs of lower severity that are targeted to that release to the next release if there isn’t sufficient time remaining in order to resolve them.
• All S1/S2 bugs will be reviewed at the weekly status meetings. The severity as set by the originator can be challenged. The triage committee will arbitrate and have the power to assign a lower severity if necessary.
• Anyone can submit a bug of a lower priority to the weekly status meeting agenda in order to get the status or to request a targeting decision.
• A bug is only targeted to a particular release when a dev has made a commitment to work on it for that release.
• Once a bug is targeted, that setting cannot be changed without the approval of the originator or the triage committee. This applies to all bugs regardless of the severity.

I believe that if the above process is implemented and abided by than we
no longer need the Adopter Hot List. Thoughts? 
  
- Konstantin

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev