Home → Suggestions →

Priority on tickets

• Edit

johan.sombekke

20 Apr, 2009 10:02 PM

Hi Rick,

I picked up a suggestion you did in February on the topic of ticket priority. I know you dislike it, but now you've implemented the field and the sort option (sort:priority-ticket and sort:priority-milestone) which is great! I'd suggest you document it (I had to search all through the forum to find out) and please add the visual indicator for priority for both the ticket list view and tickets per milestone view. Cannot be that hard :-) Like others have said: your suggestion is classy! And of course, please add a change of priority to the changesets. Thanks a lot!

[...] At any rate, I threw up a real quick priority interface on paid plans. To see it, you have to enable it in the account settings. The ticket list doesn't show it... I'm considering a little 3-phase badge... empty circle for low, grey circle for medium, and colored circle for high.

Also, right now priority is not tracked between ticket updates. This is still just a quick experiment so I didn't run the long migration to add the priority column to the ticket comments.

Kind regards, Johan

1. 1 Posted by Rick on 22 Apr, 2009 04:27 AM

   

   I'll document the search options, but I don't know how permanent this change will be. It still doesn't seem that useful for us. But, we try to keep our iterations short, and our ticket lists small and sortable.

   • Edit

2. 2 Posted by System on 22 Apr, 2009 04:28 AM

   

   A Lighthouse ticket was created for this discussion

   • Edit

3. 3 Posted by johan.sombekke on 22 Apr, 2009 11:39 AM

   

   Thanks! For the matter of the implementation of priorities: I don't want to discuss usefullness here (I understand your point of view with regard to the weighing of priorities). Nevertheless, I feel you should either implement a 'working solution' or dispose it. The 'working' part consists of a visual feedback and (less important) changeset. Now I can set priority, but it's not visualised in the ticket list and thus rather useless.

   The on/off switch enables projectmanagers to chose themselves the way they want to work. Let them (the market) decide. I noted that the CSV export includes priorities if these are set, great!

   I hope you can implement these changes.

   • Edit

4. 4 Posted by Rick on 23 Apr, 2009 12:50 AM

   

   I agree. We had a client that was more comfortable using priorities with dropdowns (vs the default drag/drop reordering), which is why we enabled this on a trial basis. We'll probably be analyzing usage of the participating accounts and emailing the owners to get a sense of how they're using them. Approximately 7% of the eligible accounts even have the feature turned on.

   At any rate, the priority and sort options have been documented. Priority bulk editing has also been documented in its FAQ.

   It's not deployed yet, but I threw in some initial bubble icons (see the screenshots).

   • ticket_list_priority.jpeg 7.11 KB
   • milestone_tickets_priority.jpeg 6.63 KB
   • Edit

5. 5 Posted by johan.sombekke on 23 Apr, 2009 06:40 AM

   

   Thanks, looks fine to me!

   For the colours; light grey = low, black = neutral and green = high? Or is green = neutral and black = high? You might consider picking another colour for 'high' (something orange / yellow / red, ...). Or like you suggested before something like:

   • open circle (low)
     
   • open circle with dot (neutral)
   • filled circle (high)

   These could all be in the same colour range to prevent the 'rainbow' effect.

   • Edit

6. 6 Posted by Rick on 23 Apr, 2009 07:44 AM

   

   Yea, I actually ripped the icons from Tender. I tried playing around in Pixelmater and had issues getting something decent. I mainly wanted to see how it'd look in the layout.

   • Edit

7. 7 Posted by johan.sombekke on 23 Apr, 2009 07:49 AM

   

   Rick, I got an idea for the discussion wether or not having priorities foor tickets. A priority can be defined as a 'attention mark'. So, in this respect it would be possible to:

   • sort tickets per milestone with drag-and -drop
   • mark a ticket as requiring attention

   As a projectmanager I understand your point about weighing priorities. If you rank them this way, it is unclear whether a 'normal' ticket for milestone A (to be delivered next week) is less or more important than a 'high' ticket for milestone B, set for next month. Thus, ranking is done on the basis of milestones, the sequence (or importance) is done by drag-and drop within a milestone. Yet, I'd like to know if a ticket requires special attention. This can be done with the 'attention mark'. And if someone wants to use this as a 'priority flag', then let them do so.

   The attention marks could be labeled as stated above, maybe you should not give a meaning to the symbol, but just let the symbol explain itself:

   • open circle
   • open circle with dot
   • filled circle

   I'm curious how you feel about combining both ways in this approach.

   • Edit

8. 8 Posted by Rick on 23 Apr, 2009 08:05 AM

   

   Yes, we tend to do this with a @high tag. Obviously, having the grey/green bubbles is a much stronger visual indicator of importance, but it's essentially the same thing. We just happen to file these @high tickets from a special search bin into the current sprint's milestone and bump lower priority tickets to the next one.

   I started the 'experimental priority' support as a low-risk way to try it out. Maybe a sticky flag as you suggested is all that's needed? Or maybe some people really need that priority dropdown to make them feel comfortable?

   • Edit

9. 9 Posted by johan.sombekke on 23 Apr, 2009 05:08 PM

   

   For me a sticky flag would do (a ticket requires my 'special' attention or not). And of course the possibility to view (filter) a list of all tickets with this 'attention mark'. But a priority 'flag' is also OK and I'll mark issues this way. With this solution you can also satisfy your currently 7% using the priority flag (and that number may grow, because with the current situation people who really want a priority flag will most probably not choose Lighthouse as there issue tracking system).

   When I think of a one-time solution that fits all, I think I would opt for:

   • the concept of an attention mark or visual tag, visualised by symbols (the circles for example). The meaning can then be user-defined (verbal definition not necessarily supported in Lighthouse): it can be used as a sticky flag, a priority mark, a complexity mark, a dependency mark, ...; in any case a mark that requires visualisation.
   • a combination of the possibility to rank tickets within a milestone and at the same time this 'attention mark' for a ticket (the current setting is one OR the other, but the sticky flag can be combined with the drag-and-drop ranking within a milestone).
   • the possibilty to sort or filter on this mark (this is already implemented).
   • you could think of the possibilty to have people define themselves this visual tag; in project settings you could show a list of icons; the admin can define a label for each of the icons (no label = not in use / not shown) and sort these icons. Further also a label for this visual tag can be set (priority, attention, urgency, complexity, or whatever....) This label is only shown in the ticket details, not in the ticket list (lay-out, of course the icons are shown in the ticket list).

   With regard to your question: In development projects it is usual to bump low-prio things to the next milestone / release. With other projects, like I do myself, it is not possible to simply move tickets to another milestone. In many European countries (like Belgium, the Netherlands and the UK) we use Prince 2 project methodology. In a Prince 2 project one defines workpackages which deliver certain products. A product + a due date = a milestone. For each product are actions (tickets) defined that are needed to deliver the product. As these products (milestones) differ it is not possible to simply move actions (tickets) forward to another milestone. This explains why you are asked for things like priorities and a due date for a ticket. Well, as soon as you introduce dates for tickets, things can become pretty complex, but a visual mark... ;-)

   Anyway, the decision is up to you! I'm just trying to help and improve an already wonderful product (because it's so easy to use, with a clear interface and not cluttered with dozens of functions one will never use or get used to).

   • Edit

10. 10 Posted by andres on 01 Jun, 2009 04:15 PM

    

    ticket priority sorting would be a very useful feature, a must I'd say, it was frustrating subscribing to the service and finding that you can't sort tickets by priority

    • Edit

11. 11 Posted by Rick on 02 Jun, 2009 01:29 AM

    

    Andres: please see the section on sorting at the bottom of our searching FAQ article.

    • Edit

12. 12 Posted by andres on 02 Jun, 2009 03:24 PM

    

    yes, I have seen that, but there's nothing as sorting absolute
    priorities,
    even under different milestones, (like absolute_position)
    a little like having a scrum approach built in as well,

    • smime.p7s 5.38 KB
    • Edit

13. 13 Posted by Rick on 02 Jun, 2009 04:03 PM

    

    What do you mean by sorting absolute priorities? Do you mean High/Medium/Low? Just use 1/2/3 for the sorting, it's all the same.

    • Edit

14. 14 Posted by andres on 02 Jun, 2009 04:29 PM

    

    sorry about the lack of proper explanation on "absolute priority "
    what I meant, is a ticket priority independent of the milestone scope,

    like if I do order:ticket-priority
    I still get them sorted by milestone, ticket

    in the current interface you can arrange ticket priority by milestone,
    but you can not give a ticket a priority higher than the one of the
    ticket on the following milestone

    it implies yet another position attribute, (like absolute_position)
    different from the one in the scope of the milestone,

    this also allows prioritizing tickets that don't belong to a milestone
    and a "prioritize" button on the ticket view (not just in the
    milestone.tickets)

    • smime.p7s 5.38 KB
    • Edit

15. 15 Posted by Rick on 02 Jun, 2009 04:33 PM

    

    Try using sort:ticket-priority as shown in the docs. If this doesn't work, let me know what project it is and I'll take a look.

    • Edit

16. 16 Posted by franklin on 15 Jun, 2009 05:46 PM

    

    i'm of the same mindset as andres. right now, it doesn't seem like you can prioritize one ticket over the other if they are not in the same milestone or if they are not part of a milestone.

    it would be nice to have the "Prioritize" button on the ticket page as well so that you can change relative rankings outside of the milestone bucket.

    • Edit

17. 17 Posted by Rick on 15 Jun, 2009 06:17 PM

    

    You need a paid account to enable the "traditional" global priority feature in your account settings.

    • Edit

18. Rick closed this discussion on 15 Jun, 2009 06:17 PM.