[RFC] Bugzilla "Feature" Severity

[Allen Winter]

> On Thursday, July 19, 2012 02:34:56 PM Jeroen van Meeuwen wrote:
> 

Joroen,

You've obviously thought much more about these issues than I have.
I'm sure you know a lot more about bugzilla than I do.

There is no rush.

I can make the KDE SC 4.10 Feature Plan in the wiki as we have always done.

I'm ok with waiting to do things the "right way".   just as long as we agree that we don't
want to wait forever.



> 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 r
> equests 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
> 
> -- 
> Systems Architect, Kolab Systems AG
> 
> e: vanmeeuwen at kolabsys.com
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
> 
> pgp: 9342 BF08
> 
>