unarchive 704874 reopen 704874 thanks Hi Russ,
Russ Allbery wrote:
Daniel Pocock<dan...@pocock.com.au> writes: > On 07/04/13 03:48, Filipus Klutiero wrote: >> The ITS currently assigns each ticket a severity. This is very useful >> for users, for example by letting them check the worst problems of a >> package without having to read its entire ticket list. >> Severity is also useful for developers as a means of prioritizing >> tickets - for example, if a developer wants to debug LibreOffice, he'd >> better start looking at critical, grave and serious tickets rather than > This all comes back to asking the questions > - what are the goals of the project? > - if releasing is a goal, and quality is a factor, how can the bug > tracking best enable quality releases? > Then you come to questions like: what is the metric for quality? Also, I think you have the question of "what tools do the people who are doing the work need?" Priority is a work management tool for developers (as opposed to severity, which is a combination of reporter impact and informed triage). My past experience with other bug tracking systems like JIRA is that priority is noise unless people want to actually use it. If developers want to use it, it's already possible (albeit somewhat awkward) to create a priority system, or any other classification system, using usertags. Thus, if I were a BTS developer (which I'm not), I'd not bother to implement this unless some of the large teams in Debian that have bug workflow issues would find it useful, since the functionality is already possible today and it's not clear whether most people would like it or just find it distracting. For example, I don't want priorities on any of the bugs in my packages for the same reason that I don't use the confirmed tag: it's additional metadata that I don't need and that I therefore find confusing, and if I'm not careful it triggers my need to categorize things and I waste a bunch of time filling out the metadata even though it's not useful and no one cares about it.
Hehe, I must admit I can relate to that :-) I do not specifically agree about the confirmed tag though, which I find quite useful. But it's true that a small change to a ticket can require a considerable time, although devscripts helps a lot. The interface chosen will be important. Note that I didn't say I would bother implementing this if I were a debbugs developer. I intentionally filed this against bugs.debian.org, not debbugs. Addressing this issue in debbugs would require considerable efforts. This ticket is not necessarily a recommendation to make that effort for debbugs, it's also a reminder to take this issue into account if we look for a new ITS engine. Hopefully, a new ITS engine would allow ticket manipulations to be done efficiently. But if a developer finds severity to be the optimal level of prioritization, he should also be allowed to hide the investment or priority field and avoid distraction. I agree that priorization is less necessary in small packages, but only in a limited sense. If a developer has many packages with few tickets, he still has to prioritize many tickets in the end. And prioritization is still very useful whatever the number of tickets. Tens of the "RC bugs" in jessie are in fact mere requests for enhancement which were reported with non-wishlist severity because developers know wishlist tickets are not prioritized properly and prefer to inflate severity to important or even serious when a non-bug issue blocks a prioritary change. For example, few of the packages mentioned in http://info.comodo.priv.at/blog/rc_bugs_2013_21.html are big. The first one had 1 upload and has 1 ticket... releases would just be even more difficult if we avoided hacks in the current situation. The case of ITS abuse I remember best involves someone acting as the unique maintainer of the affected package. Prioritization is not just important for maintainers, it's also important for Gregor and other developers "specialized" in filling in the gaps. I haven't touched JIRA in a long time, but according to https://confluence.atlassian.com/display/JIRA/Defining+%27Priority%27+Field+Values "Priority" is how JIRA calls importance. What noise were you referring to? I wasn't sure what cost (or priority) should default to when I opened this. I now think Unknown should be the default, but Unknown should be considered as the average (or median) cost when sorting by priority. I don't see why something non-essential would be confusing. I don't need the patch tag, but I don't find it confusing. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b54e6c.9070...@gmail.com
