bugzilla enhancement request policy (was: Onwards!)

[John Ralls]

On Dec 30, 2010, at 2:41 AM, Christian Stimming wrote:

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

Yes, priority would be helpful as would target. Doing so means that we need to be more assiduous in assigning those fields when we review bugs and enhancements. Same for severity on bugs... some users like to set it rather higher than is really justified.

Regards,
John Ralls