We’re in the process of developing some standard tools and procedures to apply to public projects that the Network engages in. Right now, that focus is on specifically adopting a standard set of tools for the National Action Teams, but the hope is to maintain some consistency across teams to also apply to project with the new (yet to be established) Communities of Practice as well.
One option I’m exploring right now is project management tools for public projects. At OpenMaine, we default to using GitHub to actually manage tasks, open issues, and store documentation. I know a few Brigades have custom tools for managing projects. (see this great related post on Project Frameworks/Guidelines/Checklists/etc)
Does anyone have thoughts/opinions/considerations on using GitHub for managing tasks on a project like the National Action Teams?
A beneficial side effect I could envision is that we may find replicable uses for project templates developed here. For instance, a National Action Team could develop a project roadmap, project plan, or even have really strong documentation guidelines that could then be replicated by Brigades and other groups.
The new (still beta) projects experience on GitHub is a world apart from the previous issues/projects mix:
Much more approaching the sophistication of something like Jira. Whatever tool is used though, I think the most important thing to hold constant is the principal of building in the open. A lot of folks love Jira because it’s what they’re used to in their day jobs, but an open source project where all the planning is locked away in a closed system isn’t open at all.
So far I have found GitHub to be the least awful product management tool I have used, and its integrations into the code lifecycle make linking code output/work easier as a software engineer.
As @chris points out GitHub seems to be investing in a more comprehensive tool for project management which will make its system a bit more usable for non-software projects as well as software projects.
Some advantages to GitHub include:
Discoverability: if someone discovers a brigade project it is now that far, click-wise or conceptually, to find the related project documentation.
Familiarity: most folks that work in tech or software already have some sort of familiarity with GitHub, so the only people that need to learn and onboard to the tool tend to be non-software engineers. Other tools like Asana, JIRA, etc. are less widely used and thus will likely require training by and of more people.
Durability: the popularity of GitHub and its backing by Microsoft means it is not likely to disappear or have the rug pulled out from under us anytime soon versus a tool that might be provided by a smaller company or organization.
Overall I think its a great idea, and in my experience regardless of the tool chosen, the tool is not typically the barrier or challenge to adoption or project management.
We have found our stakeholder and us at C4S have that common ground. Every thing is in one place without the need for another approach. GitHub is comparable to Trello in the sense that you can divide tasks is 3 columns… Such as Goals, PR, and PR Resolved. All documents live in GitHub as well, this makes the task of keeping everyone up to speed on the state of our project at any given time easy and accessible.
Soren:
tools like ZenHub that layer over GitHub have been really helpful for intermeshing code tasks and non-code project tasks in some of the organizations I’ve worked with/for.
Some key themes arising around the need for learning:
GH projects is particularly great for code-based projects because you can turn cards in the project board into issues on the repo and vice versa. It’s nice to be able to travel seamlessly between those two paradigms of thinking about tasks and collaboration. (I say code-based but I guess I really mean anything in a repo.)
Pulling out this particularly resonant thought from @Yeti-A
Thanks for posting this Em. This is one area we’re looking into for our Brigade. I see the project cycle as connective tissue, with inter related activities to provide a technical solution. It could involve more than one method and tool. Github is reay helpful in tracking code-based activities, creating issues for follow-up, providing a summary of progress and project snapshots. However it can also limit what we input, perceive and translate as knowledge (including our understanding of the solutions) into the project process.
It would be great to have a well rounded process that inputs diverse skill sets and encourages thought leadership and participation from our communities, volunteers and partners. Ideally, the project scope and milestone encourage and engage a diverse pool of perspectives, expertise, lived experiences, and partnerships.
I would say that building a thoughtful approach to the project life cycle that is intuitive, accessible, with solid technical grounding that is also practical in achieving outcomes would be the ideal state. Github is definately one way but not sure if it’s the only way.