I'm new to github, and am looking for advice on how to manage issues. I'm used to having priority and other ordering options but see that none exist.
How do others manages issues during the lifecycle of a bug/feature?
Thanks in advance.
locked by Thomas Owens♦ May 7 at 13:25
This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.
closed as not constructive by Yannis♦ Apr 16 '13 at 20:59
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
In addition to the tagging solutions suggested above, we have
An issue must first be assigned to the correct person, but if that person is unable to work on the issue until some other issue is finished, the issue is marked as
Similarly if a task is blocking someone else from working on something, it should be marked as
I found it a little tricky to figure out how to list items assigned to a particular person;
The solution is to click on the 'search' icon (with no search criteria typed in) and on the results page there is a drop-down on the left.
I use huboard.com to represent github issues in a Kanban board way, and then sort them by dragging and dropping within huboard. It works pretty well if you're only interested in visualizing the priority, and knowing what to work next.
It actually stores the priority within the issue itself, as an HTML comment:
The GitHub issue tracker is quite flexible. There is indeed no priority, nor ordering. It revolves around three major pillars: Assignments, labels and milestones.
Eventually, thanks to the sidebar, you can "filter" the list of issues to help you manage it.
A full blog post "Issues 2.0" on this subject will give you a more detailed view of the features.
You could define different groups of labels like issue types, issue priorities, issue statuses, version tags, and maybe more. In order to be able to see instantly to which group a label belongs to you could use a naming convention like
Using such a naming convention should make managing Github issues much easier and helps others to "understand" issues much faster. Note that you can also assign colors to labels which can add even more to readability (I would use a specific color for each label group). But because you still have to assign/unassign those labels to/from issues manually you might want to keep the overall list of groups/labels small.
According to the scheme suggested above you might define groups and corresponding labels as follows.
'issue type' group
'issue priority' group
'issue status' group
(These labels describe an issue's state in a defined workflow.)
'issue information' group
'version tag' group
I go for two kinds of labels in GH issues - the first relating to type of issue, and the second relating to priority:
Question/discussion may not be necessary, if you use the Wiki well. But I like it because it allows me to direct a question or an idea at a particular person.
Then there are three really simple priority labels:
Example of how we use labels on github to manage our projects
Category Labels (could also use all caps to visually separate)
We consider everything to have normal priority and don't really see a need for "low". So that only leaves one label to mark things that need immediate attention.
We keep all documentation in a wiki which includes how-to's, architecture, infrastructure, case studies, planning, and requirements.
Pull-Requests are for code reviews and feature discussion if it is part of a branch
With some creative use of the filtering we can find whatever work we need to do for the day. "Task+URGENT" or "Bug+URGENT" always review issues tagged as "need feedback" and leave a comment even if you don't have anything to add. Of course this works with our team of five but probably not much more than that.