[RFC] Bugzilla "Feature" Severity

Thu Jul 19 13:34:56 UTC 2012

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

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120719/da87daa4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120719/da87daa4/attachment.sig>