We’ve been listening to community input (thanks everyone!!) on how to make our process of working through the governance refactor more open and easier to engage with. A while back we’d posted a list (What questions does a new governance model have to answer?) of the main questions we’re using to organize our thinking, but as evidenced by the lack of response to that post, a giant pile of complex questions in one shot isn’t very conducive to useful conversation
So we’d like to try a different approach: we’ve broken down those questions into 5 broad categories, and we’d like to make a small post each week, alongside with our meeting minutes, that includes just a few tightly related questions for input/feedback, and that includes our own summary of where things currently stand on that area in the project. Note that our summaries are fairly informal and in the interest of not stalling, we’re drafting them together in our weekly calls (that are open to all!) and posting them here right away. That means we may miss important points, other long-standing members of the project may disagree, etc. That’s OK: we want to move forward, open each week a reasonably scoped conversation, and invite all to participate.
If we follow this schedule, through the next 5 weeks we’ll be able to go through all 16 organizing questions. This will both help us organize our own thoughts and gather community feedback, which along with other mechanisms we are using (such as in-depth interviews with some community experts from other projects) will help us assemble initial materials for a draft.
We hope this helps everyone feel more included and welcome to participate, and we continue to listen for ways in which we can make progress while engaging all. The first few questions are listed below, roughly categorized as “community engagement”. Below is a summary of our status and thoughts on these. Next week we’ll continue with a different topic.
We would love your input, and we would especially love to hear your thoughts about successes and failures you’ve seen in other organizations in these areas. In your experience, what works and what does not in these areas of a project?
The notes here are the collecting thoughts of the people on this week’s call and we haven’t attempted to consolidate, summarize, or unify the thoughts. This is to encourage exploration, so having a diversity of thoughts and experiences is helpful.
Governance Refactor Editors in Chief, Brian and Fernando
Community Engagement Questions
How do we make governance transparent to the community?
- Currently, governance documents are public documents on GitHub, and governance changes are discussed and approved on public GitHub issues.
- The steering council mailing list is somewhat of a black box to others. At times we have attempted to regularly summarize the sort and number of discussions happening on the steering council list for the community, but we haven’t maintained these updates. In general, there are far fewer steering council discussions that most people imagine, and mostly mundane things like notifying the council of public blog posts or public governance issue votes, every now and then a trademark issue, etc.
- We want to significantly improve our mechanisms for community engagement and open communication. For example, we’ve discussed often switching away from a private mailing list for the Steering Council, but inertia and lack of time/resources kept things as they are. The recent use of Discourse has helped in that front, as more and more governance-related conversations now happen there instead of on the steering council mailing list.
How do we include and protect minority voices in governance decisions?
- We currently have a code of conduct that strives to set the standard for an inclusive discussion. We have an email account for reporting incidents, and we nominally have a several people checking that email box and bringing things to the steering council as needed. However, we don’t have a formal regular reporting mechanism for the code of conduct committee to report to the steering council regardless of CoC requests.
- The current steering council has some diversity, but could use a lot more diversity of people and viewpoints.
- Most decisions in the project are not made by voting, but through consensus, which in some cases can be more inclusive than pure majority voting.
How do we actively prevent implicit power dynamics or availability of resources from bubbling up and overtaking official governance?
- Most technical decisions on repos and orgs are made by the informal consensus of the contributors who are involved in that area of the project. These decisions include:
- Code review, security, and testing procedures
- Collaborators on a project
- Release decisions and timelines
- We have over 100 GitHub repos across ~6 Github orgs. These orgs and repos mostly self-govern through consensus. While this works locally, it makes cross org/repo work and communication challenging.
- We don’t have explicit mechanism for addressing implicit power dynamics or preventing a group with high availability of resources from overtaking official governance.
- Some of the most influential and powerful people in the project don’t have formal, commensurate roles.
- We appoint people to the steering council, not reserved seats for organizations. This ensures that we have personal trust and vetting of individual people and their vision of the project, rather than outsourcing our trust and vetting to an organization.
- We have a very high bar for consensus for governance document changes (80% quorum, ⅔ approval) - this implicitly helps prevent a small group taking over the governance. In practice, sometimes this bar is relaxed, with the understanding that if there is an issue, we can revert the relevant changes.
How do we manage gridlock and inertia so governance does not impede progress?
- Re “tyranny of resources” and gridlock/inertia: we don’t have great mechanisms to address either of these, but we’ve recognized them to become more pressing issues as the project grows larger, more complex and with more disparate stakeholders who differ greatly in needs, interests and resources. These issues don’t manifest themselves as much in smaller open source projects and can be perhaps ignored for a while, but are now key drivers of our future thinking about governance.
- Gridlock: We are often gridlocked, in that steering council proposals stall without active discussion. This has particularly become an issue as the steering council has grown larger. We have a very vague notion of “consensus” for decisions, but often we have just a few steering council members participating. We also don’t really have a formal procedure for calling for a vote, and any steering council member can put a decision before the group without any sort of vetting. Sometimes we overcome the gridlock by phrasing questions as “we’d like to do X, please comment if you object”, and if there are at least a few votes in favor with no objections over a few days, we assume there is consensus. We are also inconsistent about what gets brought before the steering council - for example sometimes giving someone commit rights is brought before the council, but often it is not and is just done as a decision between a few subproject maintainers. Basically, if one person feels it is important to get council approval, it goes before the council. But others may feel the same thing does not require council approval, and will just proceed.
Again, we would love your input, and we would especially love to hear your thoughts about successes and failures you’ve seen in other organizations in these areas. In your experience, what works and what does not?