bugzilla enhancement request policy: Mostly with priority=normal/low, some closed as WONTFIX

[Christian Stimming]

Am Donnerstag, 30. Dezember 2010 schrieb John Ralls:
> >>> That's an open question: What should we answer to enhancement request
> >>> that nobody of us wants to implement in the near future?
> >> 
> > This would be one possibility, but on the other hand there is also some
> > benefit to have a place to file ideas that came to mind even though a
> > developer won't do them immediately. I think it is sufficient if we agree
> > on some signalling that clearly identifies enhancement requests that we
> > won't do immediately but still think it's a good idea and it should be
> > recorded for later.

I thought about this some more and I have some more proposals (and already did 
some action). We have almost 500 open enhancement requests, many of them open 
for many years. I think it is pointless to have such a large list which 
doesn't get implemented anyway. Eventually, this will make us just ignore that 
list (because it's so large), rendering its content useless. To get out of 
this uselessness, I decided we should indeed use the bugzilla list of 
enhancement requests to already make some decisions. Namely, we should be bold 
enough to sometimes indeed refuse propose enhancement requests which we don't 
want to do, not in the near future with the current developers and their 
current priorities. This doesn't concern many of those items, only a minority. 
The others which seem valid enough to be worked on sometime in the near future 
can of course be kept there. Maybe with priority=low or also with 
priority=normal, which is already some signal about its priority. But my point 
is that we should be confident enough of ourselves to also speak out clearly 
if an enhancement request will have a priority less than low - that it just 
will not be worked on by us and not now.

This idea appeared so appealing to me that I've already went through most of 
our ~500 enhancement requests and closed ~100 of them with the following text 
and resolution=WONTFIX, also on http://wiki.gnucash.org/wiki/Bugzilla (see 
https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html for the closed 
items):

> Thank you for taking the time to explain your enhancement request.
> 
> The described enhancement is a good proposal and would be an advantage for
> the software. However, as a volunteer-driven project with limited
> resources, the GnuCash developers have their own priorities about the
> features which are most likely being worked on in the near future. In that
> sense, the current GnuCash developers decided not to work on your proposed
> feature in the next 4-6 months. In case you would like to have this
> feature implemented in any case, you have the following option: 1. Start
> to program in gnucash yourself - see
> http://wiki.gnucash.org/wiki/Development . 2. Convince someone who is not
> yet part of the GnuCash team to join the team and implement your feature.
> 3. Pay some of the GnuCash developers to implement your feature - ask on
> the mailing list gnucash-devel at gnucash.org in that case. Thank you very
> much.
> 
> Feel free to file other bugs or enhancement requests that you find, though.

Some reporters were asking to get more explanation on what this means, and to 
reiterate my thoughts from above, I wrote:

> My point is that gnucash's 1000 items in bugzilla are an unusable large
> collection of items. We would like to reduce this to an item list which is
> still usable and helpful. Part of reducing the bugzilla items is to clearly
> say "no" to enhancement requests that we won't do (in the near future and
> with the current developers and their current priorities). This is what
> you've been seeing here.
> 
> I did close this issue for exactly this reason: status=RESOLVED,
> resolution=WONTFIX. Bugzilla's definition for WONTFIX mentions only bugs,
> not enhancement requests, but I took the freedom to stretch its meaning
> according to what I've written in the comment.
> 
> Other possibilities here are to mark enhancement requests as priority=low
> if we won't do them right now but might do them in the near future. The
> item above wasn't on that list; instead, it clearly will not be done even
> in the further future (by the current developers/priorities/blablabla,
> that is). I decided we should indeed make a decision for items which are
> not on our list for the foreseeable future. Many other items still are on
> this list, though.

I think it boils down to the question whether we are really able to make 
decisions about what's in and what's not. And yes, we are able to make such 
decisions. We welcome each and every contribution, but we do know when to say 
yes and when to say no to further proposals. To some requests, this results in 
a clear WONTFIX answer, but for most requests, we will continue to accept them 
and include them in our further plans.

Conclusion: I think it's reasonable to also close *some* enhancement requests 
as WONTFIX. The majority will just be kept, either with priority=normal or 
priority=low, but some can also outright be closed.

Regards,

Christian