Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Yannis Rizos 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.

add comment

7 Answers

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
share|improve this answer
1  
But this does not solve sorting, does it? –  Pavel S. Nov 5 '12 at 14:12
3  
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 Rizos Apr 16 '13 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 '13 at 21:58
add 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.

  • 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.

share|improve this answer
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 '12 at 3:33
1  
@djf as in Johnny Dee's answer, you can use labels to assign priority. –  David Brown Jan 29 '12 at 2:27
add comment

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.

share|improve this answer
add comment

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} -->

share|improve this answer
    
+1 Thanks! This is a great service and actually answers the question. This should really be higher up. –  KyleMit Mar 6 at 15:11
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

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