Daniel Pocock <[email protected]> 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. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
