Make governance explicit

[gvwilson]

Be clear about who has the authority to decide what (e.g., who has the right to merge or reject PRs) so that newcomers know whether the person who's talking to them is a decision-maker or not, and if not, who to appeal to.

• cf. Freeman's "The Tyranny of Structurelessness"

[dsholler]

In this section, we might provide some examples of how projects make governance explicit (and commentary on the benefits/drawbacks of different approaches). Roadmaps, text on the project website, or a separate governance repo all come to mind. The recent "vote" for governance mechanisms for Python would be a good case to reference as well.

[gvwilson]

Raymond's "The Cathedral and the Bazaar" was one of the most influential documents in the history of open source. It described an egalitarian world in which everyone could contribute equally to the greater good, but as Bezroukov pointed out in "A Second Look at the Cathedral and the Bazaar", that description ignored the realities of how power arises, becomes concentrated in a few hands, and is then used to perpetuate itself. Bezroukov's criticism drew on Freeman's influential 1970 essay "The Tyranny of Structurelessness", which explained how an apparent lack of structure in organizations "...too often disguised an informal, unacknowledged and unaccountable leadership that was all the more pernicious because its very existence was denied."

Two decades later, we can see how unequal and unwelcoming the supposedly egalitarian "bazaar" of open source can be if authority lies with those willing to shout loudest and longest. Making a project's governance explicit is therefore essential to making that project inviting and welcoming to newcomers with diverse backgrounds. The most basic way to do this is to adopt something like the Contributor Covenant, which lays out groundrules for interpersonal interaction within the project. At the opposite end, large, well-established projects that incorporate as non-profits are required to promulgate bylaws, such as those for the Python Software Foundation.

What lies between these two extremes is less well documented, but the "Social and Political Infrastructure" chapter of Fogel's Producing Open Source Software is a good place to start. It describes two models:

• A benevolent dictator (who might better be called a "community-approved arbitrator") has final say, but their principal responsibility is to manage conversation to achieve consensus.
• When consensus cannot be achieved, organizations may hold a vote. Organizations should decide who is and isn't eligible to vote well in advance of the emergence of issues requiring votes, since tempers may already been running hot by the time this point is reached. In the Carpentries, for example, anyone who satisfies any of the conditions below is eligible to run for a seat on the Executive Council and to vote in those elections:
  • everyone who has completed instructor certification in the preceding year;
  • everyone who has completed certification in the last two years and taught at least one workshop;
  • everyone who has been certified for more than two years and has taught at least twice in that time; and
  • anyone who has made a significant contribution to lesson development, infrastructure, or other activities as determined by the Executive Council.

No organization wants to become mired in red tape of its own making, but equally, no one has ever said, "I wish we had waited longer before making our rules explicit." Should any reader wish to make a significant non-coding contribution to open source, a series of three or four successively more elaborate models for governance, each annotated to explain when and why the extra complexity should be added, would be extremely valuable.

• Raymond: http://www.catb.org/esr/writings/cathedral-bazaar/
• Bezroukov: https://firstmonday.org/article/view/708/618
• Freeman: https://www.jofreeman.com/joreen/tyranny.htm
• Contributor Covenant: https://www.contributor-covenant.org/
• Python Software Foundation Bylaws: https://www.python.org/psf/bylaws/
• Producing Open Source Software: https://producingoss.com/en/producingoss.html
• Carpentries Governance: https://docs.carpentries.org/topic_folders/governance/index.html

This rule brought to you by Annie Lennox's version of "Train in Vain".

[dsholler]

Starting a thread here about Python's recent change in governance as a generative example to draw out in this section. This page has most of the info we'll need, but there are also some commentaries and blog posts out there that I'll try and sort through: https://discuss.python.org/t/python-governance-vote-december-2018-results/546

[gvwilson]

Incorporated into rules.tex in 97f6773.