bugzilla enhancement request policy (was: Onwards!)
stimming at tuhh.de
Thu Dec 30 05:41:35 EST 2010
Am Donnerstag, 30. Dezember 2010 schrieb Yawar Amin:
> On 2010-12-28, at 16:44, Christian Stimming wrote:
> >>> […]
> > I think bugzilla leaves it up to the project to define what the semantics
> > of such an enhancement request is. (That's different from a bug, which
> > either is a bug or it's not in bugzilla.)
> > That's an open question: What should we answer to enhancement request
> > that nobody of us wants to implement in the near future?
> Can we have a convention or a policy among devs that any time one of us
> creates a new bug report, we have to attach a patch to it either
> immediately or within a very short period of time (say, a day)? The idea
> is to make the bug list more actionable, instead of a big wish list.
> So in this scenario, if a patch is not attached within 24 hours, someone
> (the assignee) would close it as WONTFIX.
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
I think using the priority field is sufficient for that, isn't it? We didn't
use it for now, but we can now start using priority=low more aggressively for
enhancement requests that won't be worked on immediately. That means, all
enhancement requests with priority=normal should indeed get worked on in the
near future; all others with priority=low may very well get worked on never,
but are kept in case someone with new resources or new developers want to work
in some area and should check on existing ideas.
More information about the gnucash-devel