Governance

making decisions together

Learning Objectives

• Describe two ways informal decision-making fails as projects grow.
• Apply Martha's Rules to a concrete proposal.
• Write a one-paragraph governance statement for your project.
• Establish authorship and credit policies before a conflict makes them necessary.

Before

The simulator now had four regular contributors outside the lab. In October, two of them—Carlos from a university in Brazil and Fatima from a government agency in Morocco—independently submitted pull requests that fixed the same bug in the climate data parser. Both fixes worked, but the approaches were very different. Jess read both, thought Carlos's was cleaner, and merged it. Fatima's PR sat open for a week before Jess closed it with a brief comment: "Duplicate of #147, which has been merged."

Fatima stopped contributing. Jess only found out two months later, when Carlos mentioned it. Fatima had assumed that a closed pull request without explanation meant that her contributions weren't wanted. Nobody had written down how decisions about competing implementations were made, so from the outside there was no way to tell the difference between "Jess chose Carlos's approach after careful consideration" and "Jess chose Carlos's approach because she knows him better."

Governance Statement

Every project, no matter how small, needs written answers to three questions:

1. Who gets a vote on what?
2. How are decisions recorded and communicated to people who weren't in the room?
3. How does someone raise a concern if they don't have a seat at the table?

Martha's Rules [Minahan1986] is a lightweight decision process that answers all three (and scales better than Robert's Rules for small teams):

• Proposals are filed at least 24 hours before a meeting.
• A proposal is at most one page: a summary, a concrete proposal, some discussion of pros and cons, and alternatives.
• Members cast a sense vote: support, neutral, or oppose.
• If everyone supports or is neutral, the motion passes.
• If there is opposition, the group gets 10 minutes of moderated discussion followed by a binary vote in which everyone must support or oppose. No one is allowed to be neutral in this vote, because the proposal is either going to be adopted or not.
• Decisions go in a public decision log.

What makes it work is that proposals must be written and specific before discussion starts. Most governance fights Jess had experienced, including the one she'd just caused with Fatima, happened because someone acted without warning and the affected parties had no structured way to respond.

Writing governance feels premature until you need it. The moment you need it, it is too late to write it calmly. The Fatima incident took a minutes to create and two months to discover. Writing down how competing pull requests are handled would have taken twenty minutes.

Meetings as Governance

Good meetings are a governance tool. An agenda with time allocations sent in advance, a rotating facilitator, a designated note-taker, and a public decision log all serve the same function as a governance document: they make the project's behavior visible and predictable to people who weren't in the room. Brief status updates in the format "what I did, what I'll do, what's blocking me" keep meetings focused on problems rather than updates.

After

After the Fatima incident, Jess wrote a one-page governance document. The hardest question to answer is the first one: who gets a vote. Jess realized she didn't have an answer because she'd never thought of the project as having an "outside". She had been treating it as a small group of people who trusted her to make all the decisions. It had quietly become something larger, and the governance hadn't kept up.

Credit

Ren wrote 40% of the early code for the simulator before graduating and taking a job at a genomics company. A year later, Jess started drafting the software paper. She emailed Ren to say she was planning to include him in the acknowledgments. He replied that he expected to be a co-author. Tahia, who had rewritten most of what Ren had originally built, expected first authorship. Nobody had discussed authorship when they joined the project because it had felt premature.

Three questions that get confused:

1. Who wrote the code? git log can answer that, but doesn't record reviews and other contributions. A CONTRIBUTORS.md file can record that, but only if it is kept up to date.
2. Who deserves credit for the software as a research contribution? Zenodo and CITATION.cff can track this, but again, someone has to decide.
3. Who is an author on the paper about the software? This is what people argue about, and unfortunately there is no formula.

As a manager, you should do two things before conflict happens:

1. Write down in CONTRIBUTING.md what kinds of contributions qualify someone for authorship on papers about the software. Do this before anyone asks.
2. Keep a CONTRIBUTORS.md file or something similar up to date so that people's contributions don't disappear from the record.

The Ren and Tahia authorship conflict took three months to resolve, cost Jess significant goodwill with both of them, and ended with an authorship order that neither found fully satisfying. Afterward, Jess wrote two sentences for the CONTRIBUTING.md: one defining what kinds of contributions qualify for authorship, and one describing how someone who believes they've been omitted can raise the issue. Both sentences were harder to write than she expected because they required being specific about things she had been comfortable leaving vague.