[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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