[RFC] Bugzilla "Feature" Severity

[Allen Winter]

Jeroen,

This issue is popping-up again.
Any update?


On Thursday 19 July 2012 02:34:56 PM Jeroen van Meeuwen wrote:
> On Thursday, July 12, 2012 07:15:10 PM Allen Winter wrote:
> > Howdy,
> > 
> > Wondering if we should add a new bugzilla severity type called "Feature".
> > 
> 
> Hi Allen,
> 
> sorry for responding to this thread only now, but your sysadmin request ended 
> up on my plate.
> 
> First of all, let me state that - in my opinion - severity alltogether is the 
> wrong field to use for what is in fact a ticket type (bug, task, enhancement). 
> I'm not about to make any changes but I'll certainly have this placed 
> somewhere prominently among the series of "thoughts and recommendations" 
> articles I'm currently writing.
> 
> I also wanted to say that while I'm now engaging in this discussion, if you 
> need your request to be implemented right-away and it can't wait for our 
> exchange of thoughts to be exchanged, please let me know - I can just 
> implement the request and we can review where we stand after we're done 
> exchanging thoughts.
> 
> > This is something a product owner can add to a bugzilla issue.  Users should
> > not be able to set this. When users request new features -- we call those
> > "wishes".  This new type will be for features that the development teams
> > plan to implement according to milestones.
> > 
> > The idea is we could  query on this severity type when auto-generating
> > feature plans.
> > 
> 
> I'm working out plans implementing this exact same thing as well, with help of 
> mediawiki extensions for the display of Bugzilla query results ;-)
> 
> > A small technicality: we need to be able to close (or monitor) bugzilla for
> > new features of the current milestone at the appropriate freeze time. i.e
> > at the 4.10 soft freeze we can't permit any new 4.10 features being added
> > to bugzilla.  No sure how we can enforce this.
> > 
> > We would do away with the wiki-based feature plans currently on techbase:
> > replacing with a bugzilla query.
> > 
> 
> Yes, +1.
> 
> > For example, the query for all wishes planned for 4.10 are:
> > https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&target_milestone=4.10
> > 
> > but I am proposing:
> > https://bugs.kde.org/buglist.cgi?bug_severity=feature&target_milestone=4.10
> > 
> 
> Let's view this from a different perspective as well - wishlist items (that 
> are not accepted by the development team / developer of a particular product 
> or component) can have the wishlist item remain against a milestone 'future' 
> endlessly, noted that not every product today uses such milestones (properly).
> 
> I personally think it's also not all too unacceptable to close off wishlist 
> items the development team isn't considering working on. The message to 
> accompany such closing off such wishlist item would be the polite, politically 
> correct and motivating equivalent version of "Step up or shut up".
> 
> Wishlist items that are accepted are mapped to a milestone that developers are 
> actually working on achieving - which would subsequently, automatically, put 
> such feature on the roadmap / feature plan.
> 
> I think the addition of a new severity is therefor surplus overhead, 
> especially since it doesn't allow for some of the features you requested, 
> including the requirement to restrict access to setting the severity.
> 
> There's several other ways of making sure no new features are being put on the 
> roadmap for 4.10 (or other $x milestone "in freeze"), but with not all of them 
> necessarily being equally feasible / good ideas in my personal opinion;
> 
> - flags
> 
> Bugzilla allows for enforceable access restrictions to requesting and 
> accepting/declining requests through flags. This requires someone or a team of 
> people to be on the receiving end of the notification when such a flag is 
> requested, though, and also requires someone or a team of people to be allowed 
> to accept such flags.
> 
> Effectively, I suspect everyone who's a member of editbugs will require / want 
> such permissions, or alternatively, the release team will be overloaded having 
> to respond to each ticket being requested inclusion into the queue for.
> 
> IMHO, this is the lesser of ideas.
> 
> - tracker bugs
> 
> Changes to the dependency chain of a tracker bug would automatically notify 
> the assignee / CC list of tracker bugs. The genious aspect of tracker bugs is 
> everyone in editbugs can make the changes in order to repair the desired 
> state, whether it be the release team, the assignee, the development team, 
> quality assurance, bugsquad, you name it. The tracker bugs allow for a 
> dependency tree, can be aliased (given a name in addition to a number) for 
> easy reference, and can be queried really easily (such as with a mediawiki 
> extension).
> 
> IMHO, this is the best of ideas.
> 
> - watchers
> 
> People could be watching all relevant tickets - but this is like drinking from 
> a firehose (see the volume of the bugs-dist mailing list).
> 
> IMHO, while possible, not a very good idea at all.
> 
> Thank you in advance,
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> 
>