When GitHub rolled out its simple but powerful Issue Tracker, I finally realized that GitHub was the only thing I needed to manage my open source projects: I didn't need to use LightHouse or RubyForge anymore, because GitHub's issues were more than enough for me.

If you have a project hosted on GitHub yourself, you already know what you can do with GitHub issues; you can:

• Open them
• Sort them
• Tag them
• Prioritize them
• Vote them
• Search them
• Close them
• ...

But the important thing is that GitHub issues are very snappy, simple and FAST.

Like with to do list, I don't think you need 12,789 fields for your bugs and features, possibility to add attachments, folders or subfolders: you need something that doesn't get in your way. At least that's the way I see it, and GitHub issues are perfect for the job, and for managing your entire project backlog.

Of course, like all things, you must use them properly, following some kind of logic. Here's my take on that.

First and foremost, sort out your labels. Having labels like Parser, Compiler, Feature, Bug, High, Low didn't seem organized to me, so I decided to minimize what I used tags for. Three things:

• Project Releases
• Bug/Feature distinction
• Severity/Effort

Let's take for example the Github Issues for my Glyph project. Here are my labels:

• The first labels are used for releases. white-ish colored ones are past releases, the yellow one is the current (next) release planned, the blue one is a generic future release, 0.x.x.
• Then there's the big black REJECTED label for rejected bugs and features. I use this instead of a release label.
• Then there are three different degrees of feature tags, in green, and then another 3 different degrees of bugs, in red.

That's pretty much it. When used properly, issues look like this:

You don't have to be a rocket science to figure out what tags are for, even if you didn't read the description above.

As you can see, issues are sorted manually by release and then by effort/severity.

That's pretty much it. A simple set of convention for a simple tool.

Now, let's get to the real point of this post: Please, GitHub, fix closed issues! (Pun not intended) 

1. You can't filter closed tags:

2. Closed tags cannot be sorted manually. They are sorted -- sadly -- just by creation date:

3. You can't search closed issues: You can, actually! I just discovered it right now:

Despite these two minor quirks, GitHub issues are close to perfection. If you don't use them yet, you definitely should!

P.S.: And if you don't like GitHub's web interface, there's always this awesome cappuccino-powered app.