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