Skip to main content

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

Back to the top