Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 171 posts at DZone. You can read more from them at their website. View Full User Profile

GitHub: Issues 2.0 a Big Improvement, Short of Visionary

04.18.2011
| 4841 views |
  • submit to reddit

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.

 

From http://www.jroller.com/robwilliams/entry/github_issues_2_0_a

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Efosa Oyegun replied on Wed, 2011/11/16 - 8:44pm

I completely agree with your last assessment on GitHub building a Kanban system.

I was a little dismayed to find out Agilezen had been acquired and I'm not sure how commited the Rally is to improving the product.

On another note, are you using a software solution for your current Kanban system or working off note cards? I've been trying to nail down a good web app for the job. Current cadidates are PivotalTracker and AgileZen.

Thoughts?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.