Project Management with Github

August 12, 2013 • #project_management • 2 notes •

So, if you were ever curious how I kept all this stuff straight…Here’s a picture of our Github Issues tracker’s open issues.

Yes, each atomic task we do is an issue. It is assigned to people. We can track progress, post discussions, and log all of this. It’s a bit of a pain to get used to but once you do it’s really quite handy.

When we finish them we mark them as completed.

As you can see we also track the closed ones. This is so we can see what is done. We also get notifications of any issue we watch being closed or commented on. Really a cool way to track stuff.

[EDIT] About the color coding. Each label has its own color. Astute observers may have noticed that most of them have 2 labels on them. This is because I try to color it by type of work and by which submodule of the robot it’s on. (Note this is submodule in the sense of part of the robot NOT in the git submodule sense). Here’s a picture of all the different labels.

You can, of course, add new ones or change the names. These are just what I used.

I also use Milestones to mark deadlines or goals. Sometimes I admit I push a little hard though.

Basically, this is how I assign everyone their tasking, interact with them, and track their progress. Because everything is color coded I can see if one subteam is falling behind and perform triage as needed. This process seems to be working well, some of the students actually like being able to go online and see what is assigned to them to do for the day/week (depending on task). And I like being able to not be asked constantly what they should do next. It DOES require quite a bit of upfront organization on my part but I find the ability to know that at least one group of students on the team will be self driven is worth that cost. Now to get the rest of the team on this sort of system. Actually, I might go make a Kanban rack and hang it on the wall.

I also investigated using other tools such as Pivotal Tracker and Trello. In the end I went with Github’s Issues system because it was integrated and simple. Not that there is anything wrong with those systems (I use both for other things) but they weren’t a good fit for this problem space.

  1. cadandcookies reblogged this from aschreiber and added:
    Might need to forward this to our programming team…
  2. aschreiber posted this