Creating contributor pathways with the Handbook and Github
cross-posted on Greenpeace International’s Planet 4 publication
For the last couple of months, we’ve been working on getting the Planet 4 project tightened up so that open source contributors can find the project and easily find ways to get involved. Unlike most open source projects, this project isn’t about software in and of itself. A big issue for Planet 4 is that people are contributing to something that they aren’t likely to deploy in production themselves. Therefore, what they’re doing is very selfless and not ‘scratching their own itch’.
I have spoken often about the fact that non-profit organisations often need to stretch their resources, especially when it comes to technology. I believe that contributing to Greenpeace open source projects is a way to use technical skills to help this network of organizations respond to the climate emergency.
“We’re often working with limited resources, especially when it comes to technical capability.”
Matt Browner-Hamlin
The more the Planet 4 team can systematize work in an open, accessible and transparent way, the more the team will be able to focus on community building and engaging people.
Earlier this month Luca wrote about how P4 aims to enable people power through the Planet 4 Community Strategy. Last week Doug from We Are Open Co-op, published a long read detailing how to create an Architecture of Participation for your open source project. In this post, I want to talk about how these two things come together to make Planet 4 a more open project.
What the Architecture of Participation (AoP) is
The term ‘architecture of participation’ comes from a 2004 article by Tim O’Reilly in which he stated:
“I’ve come to use the term “the architecture of participation” to describe the nature of systems that are designed for user contribution. Larry Lessig’s book, Code and Other Laws of Cyberspace, which he characterizes as an extended meditation on Mitch Kapor’s maxim, “architecture is politics”, made the case that we need to pay attention to the architecture of systems if we want to understand their effects.”
We Are Open Co-op member Doug Belshaw has written a guide to building an architecture of participation which included the above steps
As we started to look into how one might get involved with the project, we found that over the years Planet 4 has grown quite organically. It makes sense, we’ve been busy building the software and rolling it out to 80% of National and Regional Greenpeace offices! Now that we’ve finished the roll out, we want to refocus on continuous improvement, including the experience for contributors.
Our AoP document places the reasons people contribute to open source and the different Planet 4 sub-communities (aka tracks) side by side. We wanted to make sure that the documentation and processes we use on the project is accessible to existing community members, who are mostly Greenpeace staff and close friends. We also want to ensure that as P4 grows potential contributors from the world of open source it wouldn’t get caught up or blocked by internal processes. That’s what the AoP is: a way to make sure the various communities (including the open source one) get the easiest, consistent and holistic way to interact with the project.
Tightening up for people to find their way more easily
We created personas to represent the different community tracks, and made sure the wants and needs of those personas included open source insights. All this is to make sure that ALL our personas had clear, explicit pathways into the project.
As we have been looking at the Planet 4 community, we’ve realized that we could implement small changes for big impact. Using the Community strategy to keep us focused on *actual* community needs, we mapped out how different community members access and use our documentation and processes. We then started making some tweaks to various handbook pages (including the Contribute page and the Community page), and found that we need a more user-friendly way of interacting with community members and their ideas. In addition to setting up community calls and slack channels, as detailed in the Community strategy, we decided to go all in on our Planet 4 Github Repository.
Planet 4 on Github
When we started the P4 project, we had to use JIRA as our issue and commenting system. That served us fine, but an inability to make the project public means P4 can’t accept random or short-term contributions easily. Since the world of open source projects exists on Github, we knew we needed to show our Github Repository some love.
We’re slowly but surely moving all sorts of tickets that are suitable for contribution to Github. We’ve started filing tickets for ourselves and our teammates in Github. This is a more transparent way of organizing our work and we hope it helps community members from within and outside the Greenpeace network to see how they can get involved.
Visual organizing
We’ve created a labeling system that uses the community tracks to help us organize tickets. Using Coolors, a color system is helping us distinguish between types of tickets at a glance. Each track matches a monochromatic color scale:
- Development is using green 🍏
- Design is using blues 💙
- Data is using purple 😈
- Programme is using grey 🐀
- Council is using orange 🍊
We’re also using pink for communication and documentation tasks 🐙 and will likely extend that palette for project management tasks. Finally, yellow marks how easy or difficult something is 🌻, as well as if it is part of the change backlog. Using this system makes it easy for us to see where collaboration needs to happen, and it will help different community members quickly see where we need the most help.
Socializing our methods
We now need to start using Github and helping others do the same. As we start to open up our processes, we are beginning to file tickets that help others communicate with us around bits of work. For example, we’ve filed a ticket asking National and Regional Offices to add a link from their installation of Planet 4 to our Github repository. Adding the Github icon to the Planet 4 footers would help connect potential contributors with the project. We want to know whether or not members of the Council are willing to complete this task, so the team goes through this process*:
- Step 1: We file the ticket and describe the issue
- Step 2: We label the ticket with the community track
- Step 3: The community track lead checks for new tickets when planning their biweekly or monthly community calls
- Step 4: The community goes through the tickets and if they’re willing, community members volunteer to pick things up. If no one volunteers, the ticket stays unassigned until either a team member or a contributor has time for it.
- Step 5: If someone volunteers for a task, community track leads can gently nudge progress and try to form connections between community members who should be collaborating.
We encourage community members to both check the repo and also file new tickets. This will help us manage what everyone is working on, and create a higher transparency between all NROs, the open community and the team.
What’s next?
We are continuing to implement a number of changes to our architectures of participation, in the effort to make things easier and more transparent. Next steps are to rework the handbook landing page (and by consequence, all onboarding documentation) to reflect the user flows we created and to begin the process of socializing our new community repository. Using analytics and polls on the Handbook, we will be deprecating information, processes and methods that no longer fit the project or help contributors, staff and activists understand the changes.