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 > > _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
