I am very excited about the recent relaunch of Github Issues. It adds useful keyboard shortcuts, support for milestones, assignees and email-replies. In comparison to the previous system, which was one of Github’s weakest parts, it feels like a huge improvement. Also the UI got cleaned up and feels more stable. However, I am sad to see that it lost one of its best features. Priorities.
Priorities – the traditional Way
Once you start to collect & manage tasks it soon becomes a necessity to manage priorities. Most issue tracking systems support graded priorities. Usually it is possible to customize the number of grades and how they are named but let’s look at some popular default configurations:
- Redmine: ‘Low’, ‘Normal’, ‘High’, ‘Urgent’ and ‘Immediate’
- Trac: ‘trivial’, ‘minor’, ‘major’, ‘critical’ and ‘blocker’
- FogBugz even offers seven grades of priority
If you think this is overkill I would agree with you but it used to be much worse. Earlier issue tracking systems also had a concept of severities. You can read about why FogBugz decided to omit them in an interesting StackExchange answer.
Using labels you can easily emulate graded priorities but unfortunately this is as good as it gets. Priorities add noise. Tickets start to cry ‘I am important’ and ‘Look at me, I am urgent! Do me first!’. Ultimately every ticket by definition is somewhat important or relevant to what you do. Otherwise it wouldn’t be a ticket in the first place, right? It gets worse with systems like redmine that visualize priorities in shades of red.
Priorities – the Github Way (in version 1.0)
The previous version of Github Issues had a great solution for this common problem. It used to be a list of tasks ordered by priority. If something is important it moves to the top. This is a simple but very powerful concept to keep noise down to a minimum. In fact we liked it so much that we adopted it as one of Blossom’s key features.
Apparently voting and ordering were used by an ‘incredible small number’ of users. I believe that instead of removing these features another way would have been to emphasize them. I am a huge fan of Github and hope that they will reevaluate their decision. It wasn’t wrong to provide ordering for issues in the first place. It was brilliant.