Civic tech product management on Github
How is civic tech project management different from any other kind of project management/coordination? After all we also have deadlines, specific budgets (usually), external contributors (sometimes) and wide audiences we want to reach — so what’s different?
The main difference is that we develop projects in an open / transparent way. Creating transparency projects in a non-transparent way would be somewhat hypocritical. Some say it’s a compromise we have to make due to our limited resources, but I believe that structured and transparent management is the key to using the resources we have in the best possible way.
The question is how to effectively manage a project focusing on building a technology product using a transparent process. Building a technology product includes gathering requirements, planning the work, designing features, building and user-testing prototypes, configuring production (target) server, writing user and technical documentation. How to manage all these processes which may involve different people from your team, as well as external contractors?
My short answer is: do it on Github. It is a common place for open source projects to be developed and your project’s code will probably land there in the end — so why not use it from the start? Github is a repository of projects and task management services, but it’s focused on open collaboration on projects making it a perfect solution for civic tech. This article is intended for people who have managed projects before but haven’t tried Github yet.
As a first instinct, you may ask why Github and not Trello or Asana? Because we’re creating civic tech products which means developing and sharing code and Github is the place for code. Even if you just need a simple site with static content, putting it on Github will let you easily collaborate on the content with others. You can even use Github Pages to create sites without the need to learn HTML. Coordinating Code for Poland, I’ve seen projects use many different tools but, in the end, most teams decide to use a pair of tools: a code repository + management tool(Github) and a chat application (Slack or Gitter). Start using Github for tech projects and soon you will switch to it for managing non-tech ones too.
In this article I’ll explain Github basics and guide you through using it for managing the creation of civic tech products. It’s not that hard!
P.S. Do you know that Github itself isn’t open source? Check the recently created Gitlab if that bothers you on principle.
Github basics
Github was created with developers in mind and that can be seen in the percentage of screen layout dedicated to them. If you’re not a programmer, don’t be overwhelmed by that, just head to the Issues section. Issues are the core of product management on Github. If you feel comfortable with them, that’s enough.
Issues
Issues are forum-thread-like discussions used for managing aspects of your product and communicating with the outside world.
Each issue is identified by title and a unique identifier assigned to it. Issues on a public repository can be authored by anyone on Github and so they serve as a communication channel with the open source community. The most common examples of issues created by people you may not know are: bug report (something don’t work as expected), new feature requests, or a questions asking for clarifications. Normally, as a product manager, you will author most of the issues. You can then assign them to specific people from your team, which means it’s their job to resolve the task (at least partly).
Long list of issues can be a bit overwhelming. That’s why there are at least two methods to structure them: labels and milestones. Milestones allow to group issues together and optionally add a deadline for finishing them all. They can be beneficial if you have many somewhat independent sub-projects, but I haven’t seen them used a lot.
Much more helpful, in my opinion, are the labels. They are quite flexible — you can create as many as you want and assign several of them to one issue. More importantly, by assigning colors to them you can clearly distinguish different tasks in the otherwise grayish Github layout.
What kinds of labels should you create? That’s entirely up to you. I tend to create issues for:
- skillset: coding, design, documentation, communications, translation, research;
- external collaborators’ common reports: bug, feature request, question;
- decision on implementation: for future consideration, invalid, duplicate, wontfix (authors are not planning to include the proposed changes anytime soon).
Issues are the core of product management on Github. If you feel comfortable with them, that’s enough.
Agile concepts for advanced users
For those who don’t know it, agile software development is an approach which focuses on having a working product very early. It has the advantage of showing clients how product features will look before finishing the whole product. It’s also cheaper to make changes on the go when requirements change (as they always do). For example, instead of developing “national and cities’ budget visualization tool with citizen feedback” and showing the result after several months of work, let’s develop just the national budget visualization in the simplest form and comment on a working prototype after two weeks.
Experience tells me that there is no need (or rather no resources) for managing agile concepts in most civic tech projects. Anyway, if you’re missing advanced agile product management concepts like backlog, estimates, scrum boards, epics, burndown charts then install ZenHub.io. It will seamlessly integrate with Github providing all these features.
How to start using Github in your project?
So you’ve never used Github for managing your product, but would like to start? Follow these four steps to move your product management to Github.
Bring everyone to Github
If you will be coordinating with your designers on Trello, with communication managers on Hangouts, with your boss on weekly meetups, with your finance manager over the telephone and with the coding team only on Github — the project will be a mess. Try to bring as many people on a common platform as possible.
Do the Github workshop
Under the hood, Github and Gitlab use the Git, a code versioning software which tracks changes made by different people. While progressive IT companies have switched to Git (and Github for public products) quite some time ago, I still meet developers who are not using code versioning software or haven’t tried Github. If this is the case for the developers, what about other professions? That is why it’s crucial for everyone involved in the project to do the workshop/training to understand basic Github concepts such as: repositories, issues and (optionally) forking.
Is there a better way than trying it live? For the training, I’d recommend working on a common and easy topic, for example: collaborating on a cookbook. A product template (ie. octo-recipes) and a structure for the training (see one below) will help you organize the training.
Proposed workshop structure :
- Creating content
- fork the repo to add your own recipes
- intro to the markdown format - Feedback
- look for other people’s recipes/forks
- ask a question on other people’s recipes, mention others for help
- discuss and incorporate feedback - Collaborate
- propose changes back to the original repository — pull requests
- everyone merge with expanded cookbook
Break the project down into tasks
On your own time you should break down the whole project into smaller tasks (Github issues) that can be assigned to specific people and that shouldn’t take more than a week to finish. If you’re not sure of some details, leave them as question-labeled issues to come back to later.
After you have structured the project’s tasks, you should meet with the whole team and discuss your results. Is everything clear at this stage? Who should take which issue? Is an issue too complex (ie. more than one week to finish) and should be broken down into smaller ones? Which issues should be developed first and which can be left for later (these shouldn’t be discussed in detail)?
Execute
When your whole team is on the same page with the project, you can start executing the work. Try to keep project-related discussion on relevant issues, it’s going to be easier to find it later.
You can organize weekly stand-up meetings (“a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short.” — Wikipedia) to wrap up last week’s work and discuss any challenges. P.S. This way you can almost say that you are using agile software development.
Value in open development
Sometimes people say “Our code is too dirty to share,” or “we don’t have any data to share.” Fears of openness exist not only in government but also in the NGO sector. Alexey Sidorenko in his PDF UA talk “Sharing Is Caring: Share Your Data And Code” illustrates this barrier with lovely gifs and says “Be brave!”, there is big value in opening code and data and you will learn a lot along the way. P.S. Skip to 3m44s.
I strongly join him in this call to action. There are new civic tech solutions created to address the problems that already has some solutions. Often this is a huge waste of time and money. Share your code and data, prepare it for reuse by others, but also reuse others’ solutions, coordinate with others on what you are working on. This way, we will all have more resources to focus on the real deal — social change — for which technology is just a tool.
What’s next?
If you need more help using Github head to Github Help -> Managing your work on Github and/or write about your doubts in comments below.
Now, start using Github for your next project and let me know how it goes. Do you have good or bad experiences from past projects? I’d be glad if you sent your feedback!
Good luck with your project!
Originally published at transparencee.org.
