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

[Arthur Ryman <ryman@xxxxxxxxxx>]

David,

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
intranet: http://labweb.torolab.ibm.com/DRY6/

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

01/03/2005 01:33 PM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	[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. 

Thanks, 

= = = = = = = = = 
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".

= = = = = =