bugzilla enhancement request policy

[Christian Stimming]

Am Donnerstag, 30. Dezember 2010 schrieb Derek Atkins:
> Christian Stimming <stimming at tuhh.de> writes:
> > 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.
> 
> Perhaps we can make better use of the wiki to maintain "wishlist"
> feature requests.  So that bugzilla is really for actual bugs/defects or
> active feature development?

We have at least one page in the wiki containing "wishlist" items. The issue 
is that those wiki pages become unmaintainable very quickly. Subsequently, 
developers tend not to look at it anymore at all (because it's so clumsy to 
read), so in effect the text recorded there is worthless.

No, bugzilla is the right database structure not only for bugs but also for 
enhancement requests. We should only make use of more clear signals to 
distinguish our bug list from the mere enhancement ideas.

Christian