Re: [wtp-dev] Proposal to propose Hot Bugs

[Arthur Ryman <ryman@xxxxxxxxxx>]

David,

Interesting proposal for the process.
We do need to refine it as we get more experience with it. I introduced
the use of the wtp-dev list to make the process fully open and transparent.
Using bugzilla also satisfies those goals.

FYI, Jeffrey and I have been planning
some upgrades to the Adopters section of the Web site which would include
a section for each adopter where they could describe their products without
divulging any confidential plans.

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

David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

01/27/2006 04:14 PM

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

To	<wtp-dev@xxxxxxxxxxx>
cc
Subject	[wtp-dev] Proposal to propose Hot Bugs

I know our 1.0.1 time for considering changes for Hot Bug list is nearing
an end. (I think we decided Sunday 1/29,  at last status meeting?).

But, its such a good idea, I wanted to make a few suggestions to improve
and document this process -- while they are still fresh in my mind. 

        First, let's take it off mailing list. I don't
think "general" readers of mailing list are that interested,
and info is available elsewhere if we do following: 
                - requester add
a request to the bugzilla, use the exact phrase: "Hot Bug Request"
in the comment, so searches would 'hit' 
                - requester would
add Jeffrey Liu to CC list (so he'd be more likely to see quickly)
                - if Jeffrey agrees
request is appropriate "hot bug request", Jeffrey would add [Hot
Bug] to abstract (so easy to query the currently accepted list). 
                - (and Jeffrey,
I propose, would make sure it was actually "assigned" to a person,
not an inbox, for quicker status/response). 

        Further, maybe this is obvious to others, but
to make it explicit and easier to track, as part of the request, I propose
the requester first be required to provide: 
                - what/how they
are adopting extending WTP (e.g. product, another Eclipse Project, another
open source project, etc. ... nothing confidential!, just some documentation)
                - give some rationale
or justification for why they consider it a "blocking adoption"
bug for their use of WTP (we don't want to be picky ... we want to be responsive
.. 
                    
   but, honestly, we should be able to document why its so important
that is justifies putting off fixing other important things -- its not
like we are sitting on our hands :). 
                - explain why its
"hot" for the particular release requested (again, nothing confidential,
but "needed for important demo", or reference to their own clients
bug (if open source) from their users, 
                    
   or perhaps simply stating that "current WPT maintenance/release
plans are not timely for their case?). 


Other suggestions/improvements welcome, and I'll leave to Jeffrey to pursue
and document on web, etc., but ... in the interest of "constant improvement",
thought I'd write these ideas to improve this adopter-friendly process.

Again, no rush, since we're ending this for 1.0.1 soon, but ... then I
figure it will "startup" for 1.0.x (if any) and 1.5 ... and,
we might even want to *consider* allowing requests for milestones, 
since, if we were truly blocking an adopter from moving to one of
our Milestones (and they really needed to move to that milestone), we'd
want to know about it in advance, if possible. 

Thanks for reading. _______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev