49
votes

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.

1
  • 1
    By the answers it doesn't seem to be overly opinion based -- the first two are pretty much covering the same details (with a third a few more answers down that also covers those same details -- a few tips and tricks post -- and a post for a third party service which might add more of the missing features). -- Seems like it's a great fit for SO's Q&A format, it's not opinion based at all, just "where is feature X", and people answered. -- I hope this question gets re-opened so that someone can get answerer credit.
    – BrainSlugs83
    Apr 16, 2015 at 9:05

6 Answers 6

Reset to default
52
votes

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 <label-group>:<label-name>.

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

  • type:bug
  • type:feature
  • type:idea
  • type:invalid
  • type:support
  • type:task

'issue priority' group

  • prio:low
  • prio:normal
  • prio:high

'issue status' group

(These labels describe an issue's state in a defined workflow.)

  • status:confirmed
  • status:deferred
  • status:fix-committed
  • status:in-progress
  • status:incomplete
  • status:rejected
  • status:resolved

'issue information' group

  • info:feedback-needed
  • info:help-needed
  • info:progress-25
  • info:progress-50
  • info:progress-75

'version tag' group

  • ver:1.x
  • ver:1.1
4
  • 2
    But this does not solve sorting, does it?
    – Pavel S.
    Nov 5, 2012 at 14:12
  • 4
    Hi, just noticed your MSO question. The question was automatically deleted because it was a rejected migration. However the original copy on Stack Overflow had also been deleted, so no copy of the question or its answers remained. I don't see any reason to not have at least one copy of it around, even closed, so I un-deleted this one. Next time you have a Programmers specific issue you would like to discuss, please bring it up on Meta Programmers, I only happened to see your MSO question by accident.
    – yannis
    Apr 16, 2013 at 21:04
  • @YannisRizos: You are absolutely great (+1). Thanks a lot for your fast response, for undeleting it, and also for your clarifications :)
    – Jonny Dee
    Apr 16, 2013 at 21:58
  • I would just like to add that having info:progress-X is excessive. I would agree with a info:in-progess but to quantify the progress is a bit of a stretch. I have had a few issues that I thought I was 90% done and then I saw something and I knew I was only about 50% done. Now to have this on github would just be a waste of time in my opinion.
    – AntonioCS
    Mar 16, 2015 at 10:15
22
votes

The GitHub issue tracker is quite flexible. There is indeed no priority, nor ordering. It revolves around three major pillars: Assignments, labels and milestones.

  • You can "tag" issues with labels you create (in a similar way than Gmail labels). For instance: "bug", "feature-request", "todo", "question", ... One issue can be tagged with different labels.

  • You can "package" several issues into a milestone. A milestone is made of a title (a version number for instance) and an optional delivery date.

  • Each issue can be assigned to a collaborator (contributor or organization member) of the repository. You can even summon a collaborator in a comment using a @ followed by its GitHub login.

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.

2
  • 1
    Very helpful, thank you. It does seem as if I will have to unlearn my 'old' way of managing issues. Do you just give up on the notion of prioritization? Normally I'd review a bug list, assign priorities which would then be assigned to developers. How do I modify my thinking as a manager? It feels as if I will have to spend more time reviewing issues I've already reviewed and bumped down in prio. Suggestions or perhaps a pointer to examples will be appreciated.
    – djf
    Jan 13, 2012 at 3:33
  • 1
    @djf as in Johnny Dee's answer, you can use labels to assign priority.
    – David Brown
    Jan 29, 2012 at 2:27
8
votes

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:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->
1
  • I now use waffle.io for this purpose. It's a little nicer.
    – joseph.hainline
    Apr 16, 2015 at 17:21
5
votes

Example of how we use labels on github to manage our projects

Category Labels (could also use all caps to visually separate)

  • Task
  • Bug
  • Feature
  • Discussion

Priority Label

  • URGENT

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.

Status Labels

  • reviewed (assignee has read it)
  • queued (assignee will work on it soon)
  • work in progress (assignee is working on it now)
  • invalid (if bug it's not reproducible)
  • need feedback (bat signal to get people to read and comment or provide help)

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.

1
vote

I go for two kinds of labels in GH issues - the first relating to type of issue, and the second relating to priority:

  • bug
  • feature - (new stuff)
  • enhancement - (making existing stuff better)
  • question/discusstion - (discussing stuff)

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:

  • now
  • soon
  • later

Easy, right?

1
vote

In addition to the tagging solutions suggested above, we have blocking and blocked as labels.

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 blocked. And the other issue is referenced using a hash tag.

Similarly if a task is blocking someone else from working on something, it should be marked as blocking with a reference to the other issue.

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.