GitHub: Issues 2.0 a Big Improvement, Short of Visionary
Since I was gassing about how awful the issues were (actually, I think just saying they weren‘t even worthy of that name), I figured I would blog about my discovery this morning that there is a new version on GitHub, which is much better. You can actually assign issues to people, and comments can be made. There are still no priorities, or categories. Basically, put it in there, assign it, discuss, then close it. You can indicate what milestone you are planning to fix it for.
The system can make links to from/to issues/commits.
What would be better?
After looking through this stuff, it made me glad for some of the process decisions we have made in the last 6 months. One was:
Favor stories over incidents we are not using QA on our latest round of projects, subscribing to the school of ‘developers should actually just fix their stuff.‘ This sounds like I am blaming developers, but I‘m not. Kanban makes you realize that the usual SDLC is kind of a farce: things are pushed along and called done that should never pass any amount of muster, and then transferred over to a whole other process. And managing one process is already like trying to keep your head above the event horizon in a black hole, managing two is madness. Actually, what often happens is people like to get things into the issues stage because it‘s more particular and predictable: there‘s too much anxiety when the only view of the future is stories (for most, I think points relieves that).
In this approach, what we do is we mark stories in In Development (on the Kanban) as Ready to Pull, then someone on the team has to pull them over into testing and see if they work (debating using forks and pull requests on github, but right now we are just using topic branches in the main repo). Once it has been tested, it‘s marked Ready to Pull and the Customer tries it. If issues are found in either of these stages, the story is pushed back into In Development. Sometimes, we find issues that really indicate that the story did not adequately describe the whole space. Then we add another story. Anyway, this has been working pretty well.
One other thought here: we often have to do some research before doing stories, and that could be thought of as an issue. Issues in the Scrum sense are just things that are unresolved, or in Rummy terms known unknowns. For instance, I want to highlight text in a PDF that someone found through a search (show the term as highlighted). Do I need to find a viewer? Which candidates are there? Good thing to discuss.
The next logical thing for GitHub is a Kanban. Unfortunately, Rally bought AgileZen before they could, but a good team should be able to produce such a board in a few weeks. Seriously. The key thing is make it very lightweight and nimble.