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).
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
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"
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
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
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".
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'
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
last milestone", or, eventually, "since last release".