On 28 March 2011 17:28, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> > * Uncategorized (default) > > * Feature request: for adding something new. > > * Bug report: for when an existing thing is broken or not behaving as > > expected. > > * Optimisation: for when an existing thing is not broken but could be > > made better, faster, stronger. > > * Other: none of the above. > > I would suggest two modifications to this: > > First, I would call "Feature Request" -> "New Feature" to remove any > suggestion that just by opening a ticket, it will magically be > implemented by the feature ponies. > +1, that's even clearer. > Second, this ontology doesn't do the one type of filtering that we > need for release management -- identifying bugs that are release > blocking. This means that either the 'bug report' category needs to be > expanded into: > * Bug > * Bug causing data loss > * Regression > * Bug with new feature > > Or we need to add a separate boolean flag for "release blocker". > > We used keywords for the 1.3 release, and I think that proved a > helpful resource; I think it's worth promoting these to full UI > elements. > I think there will rarely be many blockers at any given time, so I'd rather keep all bugs under "Bug" to keep the dropdown box succinct, and introduce a new "Release blocker" flag which will be enough to get people's attention. Whether it's a regression, bug in new feature, etc. can then easily be guessed by reading the ticket comment thread. Julien -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
