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

[David M Williams <david_williams@xxxxxxxxxx>]

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

= = = = = =