Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Release and target fields are now in Bugzilla


Looks fine. However, I'd like us to be more explicit about where contributors can help, i.e. we shouldn't rely on people to troll for tasks by reading Bugzilla. (Maybe we could generate a summary from Bugzilla?)

This sounds like a Community topic. Lawrence, could you think about how we can set up a "Help Wanted" page like that on other sites (e.g. SourceForge).

Arthur Ryman,
Rational Desktop Tools Development

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-admin@xxxxxxxxxxx

01/03/2005 01:33 PM

Please respond to

[wtp-dev] Release and target fields are now in Bugzilla

I've had the webmaster add some concrete release and target values to our bugzilla

schema. They are named similar to how other projects name theirs ... "1.0" for the release,
"1.0 M3", "1.0 M4", etc. for the targets.  I'd like to suggest the following text be added to
our "practices" document to describe how these fields are to be used. I am
not trying to invent anything new or complicated here .... but just trying to mimic how
I think other projects use the fields. So ... if I've gotten anything wrong, or anyone has
any suggestions for improvements to this description, please post reply to this mailing list for
review and discussion.


= = = = = = = = =
Only when someone is actively assigned to work on a bug and its done or

near certain to be in a particular milestone is it marked with "Mx" target.

That is, the Milestone target not used for long term planning, but short

term picture of the way things are.

If something can not be done for the next milestone, but is still hoped to

be in Release 1, is should just be left unassigned until its actually being

worked on and near certain to be in a particular milestone. This is simply
to avoid implicitly "over promising" anything that someone may misinterpret
as firm commitment.

Any enhancement or bug that is a good idea, but can't be contained by core

teams in next planned release, should be marked as "resolved, later". Bugs

marked this way are still "open game" for any community contributor to help with, if

such an activity can be coordinated.

Any enhancement or bug that is fairly sure will never be done or fixed

should be marked "resolved, won't fix" ... just to be honest about it, and

allow any protests or appeals to be written by original submitter or

community. Usually "won't fix" denotes the suggestion or 'fix' is not

technically possible, or not a good idea, for some reason -- not just that

"there's not enough time or people right now", since "time and people" depends on

whole community, not just one team.

This scheme should allow us to fairly easily query "things fixed since the

last milestone", or, eventually, "since last release".

= = = = = =

Back to the top