bugzilla enhancement request policy (was: Onwards!)

[Christian Stimming]

Am Donnerstag, 30. Dezember 2010 schrieb Yawar Amin:
> Hi,
> 
> 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 
later.

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.

Regards,

Christian