Managing your backlog with GitHub Issues
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.
