add 'importance' field to issues (BB-507)

Issue #248 resolved
Chris Rebert
created an issue

this would be equivalent to the severity and priority fields in Bugzilla, except combined into 1 field for simplicity.

Comments (88)

  1. Peter Hosey

    This is a terrible idea.

    For one thing, letting users set the priority of tickets does not work. Users often have an inflated opinion of the importance of fixing their problems, and such users will set their tickets as high priority; then the developers come along and find that it's really a minor problem that's relatively low on the totem pole. (I know this from experience on Adium, as our Trac used to let users set the priority; we would tell them not to, and admonish them when they did, because they almost always set it insensibly.)

    Moreover, severity and priority (as Trac calls them) are not the same thing. I think you're right that they are related, but I also think you have the wrong solution.

    Priority is a function of severity. If a bug is severe, then it's a high priority. If it's trivial, then it's low priority. Severity determines priority, so you can cut the latter.

    But severity is a function, also—of the type of bug. A bug that loses data is severe, but a text label two points out of place is trivial. Severity is also a derived result; you can cut that as well, and record the type of bug instead.

    A bug can be of multiple types. Think of some bug types:

    • Data loss
    • Security risk
    • Crasher
    • Feature doesn't work
    • Feature is slow
    • App start or quit is slow
    • Interface element out of place

    Suppose that that a remote attacker can trigger a bug that loses data and crashes the app. This is data loss, a security risk, and a crasher, all in one bug.

    So the bug types should be checkboxes, not a pop-up menu; “Severity” should be a derived property equal to the severity of the most severe type in the list (first three high, next two medium, last two low); and “Priority” shouldn't appear at all.

  2. Chris Rebert reporter

    Ok, so perhaps there should be a pref as to whether to include the field(s) on a tracker.

    Also no one ever said they had to be user-settable; they could just as easily (possibly also via pref) be settable only by the repo owner(s). The point is, there needs to be some way to mark one bug as a trivial spelling mistake and another as a major crasher and be able to tell this when looking at the issues list.

    IMHO, having "bug types" is even more complicated and will inevitably result in some bugs being shoehorned into a type and some users not understanding the types well enough and selecting the wrong one. I think that would be somewhat comparable to the willful user-distortion problem you experienced. However, the tagging feature of #251 would certainly allow you to have "bug types" on your repo, so I view that as orthogonal to this feature request.

    As for combining the 2 fields into one, the BB tracker seems to be trying for simplicity generally (cf #243), so that was my reasoning behind having just 1 field; the 2 seem to always be directly proportional and are thus redundant.

  3. Peter Hosey

    Also no one ever said they had to be user-settable; they could just as easily (possibly also via pref) be settable only by the repo owner(s).

    I can't see the point of having a pref for this, since there's no reason to let users set priority or severity. At best, you could argue that the repo owners should be able to override the priority and severity that come from a bug type, but I can't think of a good reason for them to do that.

    The point is, there needs to be some way to mark one bug as a trivial spelling mistake and another as a major crasher and be able to tell this when looking at the issues list.

    That's why I suggested allowing the user to set the type(s) of bug: Mark one bug as a spelling mistake, and the other as a crasher, and let the system infer their severity properties from that.

    IMHO, having "bug types" is even more complicated …

    One field is more complicated than three?

    I argue that only making the (bug author|developers) enter the bug type, and letting the system figure out the appropriate severity from that, *simplifies* the UI, not complicates it.

    and will inevitably result in some bugs being shoehorned into a type and some users not understanding the types well enough and selecting the wrong one.

    You're assuming that there will only be one bug type per bug. As I said, a bug can be in multiple types.

    I think users are less likely to select a wrong type or not select a right type than to inflate the priority of their bug. Especially if you word the bug types well enough.

    Extremely-novice users are likely to get this wrong, but you're only likely to have that happen when you have a lot of users, in which case you'll have other problems, such as fighting off duplicates with a stick. This, too, comes from my experience on Adium. The only real solution at this scale is having repo owners file the bugs on users' behalves.

    However, the tagging feature of #251 would certainly allow you to have "bug types" on your repo, so I view that as orthogonal to this feature request.

    Tagging, as commonly implemented, is too freeform: There is no suggestion of possible bug types. If you borrow the idea of Google Code Hosting's “Labels” editor, which provides a list of possible tags when you click on a tag field, then this would be a workable substitute for a dedicated bug-types field.

    However, if you roll bug types into tags, then you can't make severity a derived property, unless you make the system recognize special bug-type tags or have a preference elsewhere to assign severity to each tag (and the latter would increase UI complexity). I'm still not seeing a reason to make anyone set it themselves.

    As for combining the 2 fields into one, the BB tracker seems to be trying for simplicity generally (cf #243), so that was my reasoning behind having just 1 field; the 2 seem to always be directly proportional and are thus redundant.

    This is also my reasoning for having one bug-type field instead of two (p+s) or three (type + p+s) fields: One field is simpler than two or three.

  4. Chris Rebert reporter

    Also no one ever said they had to be user-settable; they could just as easily (possibly also via pref) be settable only by the repo owner(s).

    I can't see the point of having a pref for this, since there's no reason to let users set priority or severity. At best, you could argue that the repo owners should be able to override the priority and severity that come from a bug type, but I can't think of a good reason for them to do that.

    I'd say it depends on who your audience is and how much faith you have in your users. If your package is a library to be used by fellow programmers and you're trusting, I see now reason to not let the user set the importance.

    IMHO, having "bug types" is even more complicated …

    One field is more complicated than three?

    No, several "bug type" checkboxes is about as complicated as one "importance" level pull-down menu.

  5. Peter Hosey
    > I'd say it depends on who your audience is and how much faith you have in your users. If your package is a library to be used by fellow programmers and you're trusting, I see now reason to not let the user set the importance.
    

    I see no reason why they should, even if they are clueful enough to get the correct answer. Can you think of a critical UI-element-out-of-place (that isn't also a broken-feature), or a trivial crasher? I can't.

    My point is that severity is derivative, and the system should treat it as such.

    > >One field is more complicated than three?
    > 
    > No, several "bug type" checkboxes is about as complicated as one "importance" level pull-down menu.
    

    The bug-type field has other uses, though. One is that you could use it to narrow a search—for example, “crashers whose summary contains ‘download’”. So it makes sense to have it anyway, and once you do, it makes sense to strike the severity/priority/importance field and derive it from the bug type.

  6. craiv

    I find this is a very important feature for the tracker. As the tickets become a lot, we might have a triager who assigns priorities to new tickets. That will reduce the developer's "idle time" spent scanning through bugs to find the most "dangerous" ones.

    Trac way to implement both severity and priority might be confusing. We just need a way to sort bugs by relevance, which will depend only on internal policy.

    In my opinion, a drop-down menu under the "component" will be enough. The 5 standard priority levels (trivial, low, normal, high, critical) will work very well for the needs of most people.

  7. Anonymous

    craiv: Or, better yet, make it a derived property as I described in my earlier comments. Then you don't need anybody to set it, no matter how many tickets you have, because the system sets it for you according to the bug type(s).

  8. craiv

    I don't think linking a type to a priority will be good.

    A bug may need fixing in the future because it's not dangerous (for example, the "404" page fails to render properly if the URL includes two consecutive commas) but there may be a "proposal" which gets higher priority (for example, the need of a group of people for an RSS feed of something).

  9. Peter Hosey

    craiv: No, you've misunderstood (or didn't read) my statements. I didn't say the ticket type (bug vs. feature), I said the ''type of bug''. See my comments above, where I listed a bunch of examples.

    I guess you could have a user-selectable priority field for features, but for bugs, it should be a derived property.

  10. craiv

    Sorry, my bad. But my opinion remains the same: an human triager will do the best work than an user prompted to check some options. We may have to do with non-technical users, so letting them in some way prioritize the tasks for us is not the right way to arrange the tickets. If this fails, it will be bad for the operators (which trusted the system) to discover that a bad security hole was prioritized as "low" because the user did not flag the right thing (because he was pissed, because he did not understand the language very well, or because "somebody will do that for me").

    I can actually think of a "data loss" which can be low-prioritized. Think of an application which saves automatically on exit the file you are working on. The user doesn't hit "save" periodically. Clicks "exit" and the program exits with an error, because the file is being locked by another software. This is actually the user's fail, and can be fixed later than a "data loss" that occurrs every time an user presses [ctrl] + [v] inside the program.

    Basically that's the problem: I am reluctant to letting user prioritizing things for me. I prefer to do it myself or to get the job done by a person who knows the application. You can obviously have the opposite opinion, because you trust your users.

    But, in your proposal there's a very interesting point. The "security issue" flag can be used, this time by the user, to hide the issue. In this way you can hide security issues from the malicious users, and you can let the user eventually post dumps or error messages with personal information in it without worrying.

    I also agree with you about tagging: it is not the right way to prioritize tickets. But tags will grant the granular differentiation between issues that you are pointing out in comment #17.

  11. Peter Hosey

    We may have to do with non-technical users, so letting them in some way prioritize the tasks for us is not the right way to arrange the tickets.

    I never said anything about letting users set priority. In fact, I explicitly said that that does not work.

    You should read every ticket you get and make sure that its bug types are set correctly. If you do this, then the bug's priority is also set correctly.

    Plus, if your users are computer novices, you're probably better off filing tickets on their behalves. Otherwise, you'll end up with poorly-described tickets, incompletely-filed tickets, and duplicate tickets, and most of them won't even bother at all.

    I can actually think of a "data loss" which can be low-prioritized. Think of an application which saves automatically on exit the file you are working on. The user doesn't hit "save" periodically. Clicks "exit" and the program exits with an error, because the file is being locked by another software. This is actually the user's fail, and can be fixed later than a "data loss" that occurrs every time an user presses [ctrl] + [v] inside the program.

    They're both data loss, though, and I argue that they should both be high priority. Sure, fix the eat-data-on-paste bug first, but you don't need to express priority at that granularity.

    The fix for the save-on-quit-fails bug would be to inform the user that the file is locked, and then remain open. If the application must quit (because the OS is going to gun it one way or another; e.g., at shutdown), then it should save the data to an auto-save file and restore it on next launch.

    This is not purely a user fail; an application should never eat data unless (1) the user specifically asked it to or (2) the data loss is unavoidable (e.g., above scenario plus full disk).

  12. Martin Geisler

    A priority field is simply a way to manually sort the bugs based on their priority. Currently one can "Bump!" an issue to bring it to the top -- a priority field would just be a more fine grained way to sort things.

    For a closed bug tracker this would be a nice and fairly standard feature. For a public bug tracker it might be good to allow only developers to change the priorities.

  13. Chris Rebert reporter

    Bitbucket (or at least its issuetracker) seems to adhere mostly to the KISS school of design. In keeping with that, and heavily agreeing with Martin, I'd like to see with a single, manually-set pulldown field and an option to let the public be able to set it or not.

    Now if we could just one of the actual implementors to comment on what their thoughts are...

  14. Peter Hosey

    Martin Geisler: I'm not seeing the point of allowing anyone to set a different priority than what one could infer from the bug type(s). If the bug type is specified accurately, then what is the point of changing the priority?

    Note that if you want to put something off to a later release, you could just change its milestone.

  15. Martin Geisler

    Peter: I imagine having a handful of bug types and a handful of milestones. So it would still be nice to be able to order things within a given bug type. Nothing fancy or special -- I just want to be able to say that this crash bug is higher priority than this other crash bug.

  16. Jesper Noehr

    I've just wontfix'ed #251, and I'll comment a bit here:

    While I appreciate both sides of this conversation, I think one side in particular makes more sense for the BB tracker than the other:

    1. I like the idea of "bug types", but:

    • You need to specify very exact scenarios for it to be useful in the first place (more work for the repo admins also)
    • There's a lot more triaging involved (which does add granularity, but I don't think we want to take it that far -- if we did, tagging would've been added)
    • You're basically rolling component+importance into one field

    2. Importance / severity / priority:

    • We can have the classic 5 step, which indicate a sequence of priorities (1-5, easily sortable)
    • It's easy to understand for the end user
    • While it's a concern that users might think their issue is way more important than anything else, they may either report it as "critical" or later change it to that, but as you proposed earlier, we can either a) make a setting for whether allowing users to specify priority, or b) have a default priority (triage?) and not present the user with a list of options when reporting it.

    Peter, I know you've spent a lot of time on the Adium tracker, and that you have a lot of stories from the trenches. I think the solution you propose makes a lot of sense for that project too, but I'm not convinced that it would work well for the majority of projects we host here. I can think up about 75 "bug types" for BB alone, and I can't even imagine how we'd present those in a UI.

    Anyway. These are my personal thoughts on the matter, and they're in no way more important than any of yours. Please let this discussion continue, and I hope eventually we'll reach an agreement.

  17. Peter Hosey
    • You need to specify very exact scenarios for it to be useful in the first place (more work for the repo admins also)

    I'm not sure what you mean. The bug description?

    • There's a lot more triaging involved (which does add granularity, but I don't think we want to take it that far -- if we did, tagging would've been added)

    I'm not sure what you mean here, either.

    • You're basically rolling component+importance into one field

    Wait, component? No, that's got nothing at all to do with the bug type. Nobody is suggesting “crasher in issuetracker”, “crasher in api”, etc. as bug types—just “crasher”. Component is completely separate.

    While it's a concern that users might think their issue is way more important than anything else, they may either report it as "critical" or later change it to that, but as you proposed earlier, we can either a) make a setting for whether allowing users to specify priority, or b) have a default priority (triage?) and not present the user with a list of options when reporting it.

    I still don't see the point of allowing users to set priority at all. Isn't that the developers' decision?

    Severity, maybe, but you're relying on the user to know how severe their problem is. If the users are very technically-minded (e.g., programmers), then they probably will. If they aren't, then they probably won't.

    Bitbucket certainly has a highly technically-minded user base now, but if developers of a popular end-user application told their users to file bugs on Bitbucket, most of those users will either leave the severity at the default, underestimate it (some users are self-deprecating), or overestimate it. And then the project developers have to fix the severity, along with anything else the user filled in wrong.

    At this point, you could argue that a project like that shouldn't make its users file their own bug reports. That leaves the bug-tracker for the technically-minded users, if not the developers only. But can't those same people simply check the right bug-type boxes?

    I can think up about 75 "bug types" for BB alone, and I can't even imagine how we'd present those in a UI.

    If most of those are only relevant to certain components, perhaps you could conditionally show them based on the currently-selected component.

    I'm having a hard time imagining that many, though. Can you name some of the more BB-specific types? It's possible that you're being too specific; remember that these are checkboxes I'm proposing, not radio buttons, so most bug types should be quite general.

    Some BB-specific types I'm thinking of:

    • Wiki/ticket mark-up conversion error (wiki and issuetracker components only)
    • Mercurial-integration problem (for bugs in Bitbucket's use of the underlying Mercurial API and extensions)
    • Push/pull failure
    • Proxy problem
    • Authentication problem
    • HTTP
    • HTTPS
    • SSH
    • Browser-specific (to be combined with crasher and UI element out of place)

    Those are in addition to the general types I named above, of course.

    One type you wouldn't need is “Web-page rendering error”. That would be the same as “UI element out of place” (or “UI element missing”—that could be another of the default set of types). You could have types for “invalid HTML” and “invalid CSS”, though, referring to violations of those specifications; most of those would probably also be UI elements missing or out of place.

  18. wikihardware

    This would be good for #573 =P.

    However, I think 1-10 is a relatively big range; how about a rank from 5 to 1 tagged from "lowest" to "highest", and some color coding for the rows?, this is the way Assembla and Redmine manage it.

  19. Jonathan Wight

    We use bitbucket at smallsociety.com to host repositories for client development. We had originally hope to use bitbucket as a nice, simple one stop shop for projects - but the lack of a priority field means we're forced to investigate other issue tracking systems.

    This is a shame - there's a lot to be said for the amazing integration bitbucket provides.

  20. Dan Kamins

    This is a must have!

    I didn't read this whole comment thread, but there needs to be SOME way to prioritize bugs.

    Right now I'm hacking the "Version" field to be like "1-Vital", "2-Soon", "3-Maybe", etc. That's just no good.

  21. Adon Metcalfe

    Yeah were in the same boat, though for now I've just been adding '(1)', '(2)' etc to the titles of bugs to manage priorities, which is easy now our project is private, but I can see it being an issue down the track when we go public.

  22. andysk NA

    Bump! Even if we just had a 'tag' (delicious style) that you could add and then search for, it would be a useful feature. For now, I just add a comment with a unique word (such as phigh, pmedium, plow) and we can search for that later.

  23. andysk NA

    Thanks Chris, I wasn't aware of that and I'm glad to have that information. I'm still voting for some way to specify priority. For our purposes, just Low/Medium/High would be great and simple, but I'm sure others will have different preferences.

  24. Jason Harris

    I find this lack of a priority or severity or whatever a real killer. I like bitbucket! Its strange bitbucket is the first place I have come across where the issue tracker doesn't have this feature...

    I have been looking around at Mantis, or maybe putting up a Redmine or Trac server on my website just so I can get around this issue... But I am really reluctant to split hosting the project and the issue tracking...

    I guess I could change all of the titles of every incoming bug to reflect a severity. Eg if someone submits

    • I can't click XYZ button

    I could change this to

    • P3: I can't click XYZ button

    But thats pretty gross, and users could submit a bug then trick me and bump their own priorities, etc...

    Thanks, Jason

  25. Anonymous

    So what happened 17 months ago?

    We are a paid customer and really need priority. Importantly it provides a way to sort. In theory each developer should sort by priority things assigned to them and then work on the top items.

    I have been using the milestone field, but as we near release of the project I actually need to use the milestone field for milestones. (And I had to give them numeric prefixes to force a sort order.)

  26. nbouton

    Bump. Need some kind of priority/importance flag per-issue (preferably something controlled by the project owner).

    Honestly I'm not sure how anyone can function without it. I'm investigating a number of hosted issue tracking solutions and this one would be perfect except for the lack of some kind of prioritization flag.

  27. franklinharper

    I just signed up and created my first bug. I noticed immediately that there wasn't a way to set a priority. Then I searched for a solution, and found this thread. The requests have been flooding in for 2 years, and nothing has been done. That's a deal-breaker for me.

  28. oldays

    This is an inexplicable omission.. Why have responsible, reported by, type, version then? Users could just type those in as part of the name. Right?

  29. Rufus Pollock

    Is there any ETA on this? Without this feature any number of tickets > 10 becomes almost impossible to manage in a sensible way. We've just signed up as paying user of BB but w/o this feature we will have to seriously re-think this ...

  30. Case Builders

    This is a killer feature we're also missing.

    This was proposed two years ago and still not implemented. The reason that it's taken so long for something relatively simple to get implemented seems to be that the perfect has been allowed to become the enemy of the good.

    I understand Peter Hosey's concern, but to be honest this is a problem related to the size and nature of his userbase. If you have a technical project (like a compiler or library) its users are generally well-equipped to make a judgement call on how critical an issue is. If it's wrong, the project owner can simply reset the priority and people probably won't change it back.

    In our our case (a paying customer with private projects & private ticket tracking), this is not even a concern - all priority is decided by the project managers.

    In open source projects, there might be some use to distinguish between priority and severity; something can be a severe bug which crops up only occasionally and hence does not have to be immediately fixed, or it can be a small but extremely annoying bug which someone needs fixed ASAP because his users don't accept it.

    For now, I propose implementing the simplest thing that could possibly work: a simple 3- or 5-value "priority" field, optionally with a setting on the project admin page where you can choose who is allowed to set priority - the reporter or project administrators. If this doesn't work for projects like Adium, this could be iteratively improved. At least the smaller, technical and private projects (quite a large - and some of them paying! chunk of the bitbucket userbase) would have something that works for them.

  31. Peter Hosey

    casebuilders:

    The reason that it's taken so long for something relatively simple to get implemented seems to be that the perfect has been allowed to become the enemy of the good.

    That implies that they've actually been working on it and have gotten bogged down in perfectionism. Have you seen or heard of any work being done on this feature?

    I understand Peter Hosey's concern, but to be honest this is a problem related to the size and nature of his userbase.

    How big of a problem it is, is related to the size and nature of one's user base. It is a problem for every project that exposes a priority field for users to change.

    If you have a technical project (like a compiler or library) its users are generally well-equipped to make a judgement call on how critical an issue is.

    Not if they're not involved with the project. Remember, your users often have a different idea of how high a priority something is (should be) than you do.

    If you enable users to change the priority field, users *will* change it. The only solution is to make it only writable by those with write access to the repository—or make it derived, as I described above.

    If it's wrong, the project owner can simply reset the priority …

    I.e., this makes work for the project's maintainers.

    … and people probably won't change it back.

    I can tell you from experience that this is not true. On Adium, we got into edit wars with users over the priority field. Telling them not to touch that is (was) not a solution. The only solution is (was) to put it out of their reach.

    In our our case (a paying customer with private projects & private ticket tracking), this is not even a concern - all priority is decided by the project managers.

    So it is on Adium, as well. Is there a project anywhere that does differently? It seems to me that putting the priority field directly in the hands of users would result in *every* ticket having the highest priority.


    Coming back to this ticket two years after my first comment on it, I was surprised that you said “I understand Peter Hosey's concern”, since I thought I supported this feature. Then I re-read my old comments, and saw that I had clearly not.

    Making it a derived property is certainly a good idea, but I can see how it would be a lot of work for Bitbucket's staff, especially since the list of bug types should be project-editable (what makes sense for a Mac app may not make sense for a CMS, for example). I think that it's worth it, that it would even set Bitbucket ahead of other bug-trackers on this score, but I can see how Bitbucket might disagree.

    I'm OK with a priority field as long as it's only editable by those who have write access to the repository.

    For now, I propose implementing the simplest thing that could possibly work: a simple 3- or 5-value "priority" field, optionally with a setting on the project admin page where you can choose who is allowed to set priority - the reporter or project administrators.

    I'm on board with that. I would add “only” before project administrators.

  32. Case Builders

    > The reason that it's taken so long for something relatively simple to get implemented seems to be that the perfect has been allowed to become the enemy of the good.

    That implies that they've actually been working on it and have gotten bogged down in perfectionism. Have you seen or heard of any work being done on this feature?

    I see a lot of discussion, which suggests that's the reason it's being held up.

    > If you have a technical project (like a compiler or library) its users are generally well-equipped to make a judgement call on how critical an issue is.

    Not if they're not involved with the project. Remember, your users often have a different idea of how high a priority something is (should be) than you do.

    Sometimes having an idea how important something is for your users defines your priority as well. At least, as long as keeping users happy is a primary concern.

    To prevent editing wars, maybe the users should be allowed to tweak the priority at will, and as soon as an admin changes it, it stays locked to that value and only other admins can change it. That way the user can define the desired/initial priority and once the ticket is accepted, the admin can define the "true" priority within the project at large.

    > In our our case (a paying customer with private projects & private ticket tracking), this is not even a concern - all priority is decided by the project managers.

    So it is on Adium, as well. Is there a project anywhere that does differently? It seems to me that putting the priority field directly in the hands of users would result in *every* ticket having the highest priority.

    Right. I was a bit confused when I said that. Our project managers are also the ones filing tickets. On the other hand, we can give them admin rights, so it doesn't matter much.

  33. Peter Hosey

    Sometimes having an idea how important something is for your users defines your priority as well.

    Give users a priority control, and most of them will set it to “high”. It's that simple. Rare is the user who will evaluate their own bugs and requests objectively. The user setting the priority control to “high” tells you nothing.

    Far better to leave the priority control out—for users, that is—and have them write a case for why their issue is important in its body text and/or in comments. If they want to express how important it is, that's the best way for them to do it.

    At least, as long as keeping users happy is a primary concern.

    Niiiice.

    Users' ideas of their own issues' priority has nothing to do with the project's drive to keep users happy. In any project with finite time and resources, you can't do everything, so you have to prioritize. Somebody's ticket is going to get done first, which means somebody's ticket is going to get done last.

    Whenever the maintainers' priority for the issue is lower than the user's priority, the user is not going to be happy.

    To prevent editing wars, maybe the users should be allowed to tweak the priority at will, and as soon as an admin changes it, it stays locked to that value and only other admins can change it.

    This seems unnecessarily complex. What's the benefit to users? What's the benefit to maintainers?

    Again, remember that:

    1. Most users will set it to “high”, rendering that value meaningless;
    2. Those tickets that are not coincidentally already set to the correct value by the user will have to be changed by an admin.
    3. Furthermore, controls that are visible one moment and gone or disabled the next confuse users.

    That way the user can define the desired/initial priority and once the ticket is accepted, the admin can define the "true" priority within the project at large.

    That sounds like the made work that I mentioned in comment #74.

    The central problem with letting the user set the priority—ever, at all—is that most of the time, they'll set it to a value you'll disagree with. There is no value to a control that maintainers need to change more often than leave alone. It wastes the user's time and effort to set it, and the maintainers' patience and time to change it.

    You may ask: How is a maintainer changing it different from a maintainer setting it initially? The answer: When the user has set it to “high”, and the maintainer changes it, the user is likely to post an angry comment asking why the priority was changed, why the maintainers don't want to fix this issue [as soon as the user would like], and (sarcastically but more rightly than they know) why the priority control is even exposed to users if the maintainers are just going to change it.

    It should be either derived—and therefore read-only by definition—or writable only by the project's writers. There is no benefit to letting anybody else change it.

  34. Case Builders

    At this point I don't even care about user-settable priorities anymore. I'd be happy if something is implemented so we can keep track of priority in our in-house projects.

    Having it settable-by-admin-only is fine by me.

  35. Andrew Hughes

    Nice commentary, and for the record - as the owner of a company who uses and pays for all our employees to be committing to numerous private repos here on BB - I'm in total agreement with the less-is-more crowd. Give users with write access and above the ability to change issue priority. Have a simple 5 stage indicator. Done and done.

    The thing is, when will we figure out that no one who has the juice to solve this problem is actually still watching or caring about this thread? Aren't we preaching to the choir anymore?

  36. Dean Moses

    I've got more than a hundred issues and I'm going bonkers. Several times a day I look at the system to find the top couple of things that are most important to address, and EVERY TIME I have to wade through 90 bugs of lesser importance.

    It's just. Not. Sustainable.

    Please, Bitbucket, give us the ability to enable a priority field. Doesn't have to be on by default. Doesn't have to be editable by the world. Doesn't have to show up on the submission screen, but the option to do so would be very welcome.

  37. Pyjeon Software

    I agree, just started using bitbucket and it's somewhat frustrating not being able to set priority for the bugs despite it being such a basic feature. I agree with some of the earlier comments that we don't really need 2 fields (severity + priority), a single field is good enough. If a bug is severe enough, its priority is probably going to be high anyway, and if priority is low, the devs probably won't bother looking at severity either.

    p.s. If we had a priority field, this issue would get the priority it deserves :P

  38. jask

    Is there any ETA on this? I'm with Rufus: without this feature any number of tickets > 10 becomes almost impossible to manage in a sensible way.

    How about a simple field, only editable by users with write access, with the ability to search for and sort by, so anyone cold type in whatever he likes.

    Make it as simple as possibly, but: please, get this done. We have only about a dozen of open issues at a time, anyway it is absolutely frustrating wading through all of them over and over again to figure what has to be done next.

  39. Log in to comment