This is the fourth blog post in a series about open source project governance, so you should consider pausing and reading the other posts about why governance is important, defining governance, and pathways to leadership before reading this one.

Defining your governance / decision-making processes along with pathways to leadership are key to creating an intentional culture for your project that encourages participation and contributions from others. Having a scope, vision, and values (sometimes called a charter) for your project can help people understand what is / is not in scope for your project to encourage people to work on contributions that are most likely to be accepted and avoid wasting time on contributions that aren’t aligned with the project. This also helps to avoid issues and misunderstandings later by helping align the expectations of all community members. By setting expectations and clearly documenting them, you set the stage for creating a healthy and sustainable project over time.

However, just documenting your governance process and setting expectations in writing isn’t enough. You should also be role modeling good behavior and helping others understand what behavior is appropriate within your project. It’s important to remember that tolerating bad behavior unwittingly sets the expectation that this behavior is acceptable in your project, which can drive new contributors away, so addressing concerns promptly before they can get out of control or become a crisis helps set an intentional culture and improve sustainability of your project. A code of conduct is a good starting point for these conversations, but it’s also important to think about how you plan to approach code of conduct issues and how things like remediation and education can be a first step to help people meet the expectations of your projects, instead of taking an enforcement first approach. 

Unfortunately, some projects eventually run into issues that can’t be resolved via remediation or education, and in these cases, it may be necessary to remove someone from your project. Your governance documents should have a provision for involuntarily removing someone from your project, even if that person is in a top leadership position. I watched a project struggle with bad behavior for months while waiting for a steering committee member’s term to end because they didn’t have a process for removing that person. We always hope that we never need to use the process to remove someone, but you’ll be glad that you put it in place now if you ever need it in the future.

Having your ducks in a row with robust governance documentation that incorporates your code of conduct, charter (or similar statement of mission, scope, and values), and includes clear processes for dealing with conflict can help make your project more sustainable over time. 

Resources:

• Good Governance Practices for Healthy Open Source Projects (video)
• The Open Source Way Guidebook section on governance.
• Codes of Conduct and Remediation talk by Aeva Black (video)
• Creating Charters, Mission, Scope and Values for CNCF Projects
• Donnie Berkolz on how Assholes are Ruining your Project (video)
• CNCF guides, resources, and templates for governance 

Photo by Mike’s Birds on Flickr