cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Date Thu, 09 Oct 2003 10:26:52 GMT
Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
> ...And we also create a process in the following way:
> - the wiki feature request page is scanned from time to time (the mails
>   help there)
> - A new entry is evaluated (perhaps the feature doesn't make sense or
>  is a bug or is a really cool thing etc.) and if accepted added
>   to our planning document.
> So the planning document in our docs contains the approved list of 
> feature
> requests....

See what you mean, but this could also be a list of pointers to 
bugzilla.

IMHO if we start to use bugzilla more seriously, we will need a 
slightly more precise categorization of issues:
-actual bugs with different severity levels (can do)
-patches ([PATCH] header is a hack but more or less workable)
-feature requests
-release-related stuff (if we want to use bugzilla dependencies to 
prepare releases)
-more?

Meaning that we shouldn't count just "open issues" anymore, rather 
"open bugs", "open feature requests", "open patches" etc.
On Monday we were focused on "total open issues" which is wrong IMHO.

I think this is easier to do in bugzilla where everything is dynamic.

This might need adding more possible values to the "severity" field, 
dunno off the top of my head how easy it is to do. Otherwise we can use 
title headers like [RELEASE] [REQUEST] etc.

For feature requests, my suggestion would be to do so:
-Let them come in bugzilla
-Evaluate them often, and close the ones which seem too far away with 
resolution=LATER
-Explain all this on a wiki page, with links to bugzilla queries to 
show what's current

This would help give more importance to bugzilla for planning/progress 
monitoring stuff, which I think is good.
And in this way we avoid the need to synchronize lists or move stuff 
between bugzilla and the wiki.

> ...I'm planning to "reactivate" our planning documentation in the docs 
> section
> so that it show more information anyway...

Could be good if we're able to keep promises made there. I don't know 
if it is realistic.

-Bertrand

Mime
View raw message