Governance & Decision Making

Building effective structures for open projects

Lars Schöbitz

Global Health Engineering, ETH Zurich

July 15, 2025

Session Roadmap (70 min)

• Introduction & Context (~10 min)
• Governance Models (~15 min) - Including Martha’s Rules
• Activity 1 (5 min) - Project Assessment
• Roles & Code of Conduct (~10 min)
• Meeting Management (~15 min) - 10 rules for better meetings

This is our afternoon session on governance - More in-depth than morning session - Focus on practical tools and frameworks - Multiple activities to apply concepts

Introduction

⏱️ START: 0:00 | DURATION: 10 minutes | END: 0:10 - Welcome to afternoon governance session - More detailed than morning overview

Attribution

These slides are reproduced from github.con/gvwilson/codebender “Copyright (c) Greg Wilson”. The original content is licensed under http://creativecommons.org/licenses/by/4.0/.

Starting point

A 10X engineer is one who can bring together ten other engineers and emerge with a shared understanding and rough consensus of the problem being solved and work that needs to be done.

— Lorin Hochstein

In this house we call them “project managers”.

— Greg Wilson

Research software (because that is what we create)

• Software is created and run to answer a question
• Papers, theses, and other reports are the product
• The software is “just” a tool
• Shades into projects that produce software for other researchers to use

You

• Degree(s) in some research domain
• Little or no formal training in software development
• In a team of 1–12 people
• Timelines of weeks to months

XKCD Dependency cartoon

Me

• Don’t remember much statistics…
• …but I have programmed a bit in R,
• …I’ve managed a few software projects,
• …and I’ve been lucky enough to hang out with some very smart people

Where we’ve been, where we’re going

Then	Now	Next
Dropbox	Git repository	Branching workflow
“Just do it”	Slack / mailing list	Martha’s Rules
Interactive analysis	A big pile of scripts	Build tools / CI
Word / Google Docs	Notebooks / LaTeX	Site builder
“It doesn’t crash”	“Are there any NAs?”	Assertions / unit tests
“Um, hi?”	README + LICENSE	CONTRIBUTING + CoC

Acknowledgments

• Original workshop: Daniel Standage and Greg Wilson
• Producing Open Source Software: Karl Fogel
• Research Software Engineering with Python: Damien Irving, Kate Hertweck, Luke Johnston, Joel Ostblom, Charlotte Wickham, and Greg Wilson

Cover of ‘Research Software Engineering with Python’

Activity: Project Assessment (5 minutes)

In our shared Google Doc, Section: “Governance Assessment”

Reflect on your current project:

1. Who uses your software / your work?
2. How do they find it?
3. Who decides what will happen next?
4. How is that communicated?
5. Who can make what kinds of changes?
6. What happens automatically?
7. How are newcomers brought on board?

⏱️ START: 0:20 | DURATION: 5 minutes | END: 0:25 - Give participants 4 minutes to write - 1 minute for quick sharing - This sets the context for why governance matters

Governance

⏱️ START: 0:10 | DURATION: 15 minutes | END: 0:25 - Deep dive into governance models - Focus on Martha’s Rules as practical framework

What problems are we trying to solve?

• Low productivity
  • “Oh no: not another meeting…”
• Opaque decision making
  • “Did we decide that?”
  • “It’s not what you know, it’s who you know.”

The good news

• You don’t have to invent this yourself
• Learn from others who’ve solved these problems
• https://www.askamanager.org/ - Great resource for management advice

Example insights: - “Consensus doesn’t mean everyone agrees - it means everyone can live with the decision” - “Document decisions immediately, or they didn’t happen”

Ask a Manager logo

Governance models

• https://communityrule.info/ describes lots of options
• Benevolent dictator (often the project founder)
  • Common in young projects
  • Brittle (founder can move on)
  • Usually leads to emergence of unofficial (i.e., unaccountable) leaders
• Elected representation
  • Explicit rules for suffrage
• Consensus-based
  • If most people agree on most things most of the time

“Hero” programmers

• Brooks advocated a chief programmer model in the 1970s (Brooks 1995)
  • Disparaged since then
• But 80% of projects on GitHub are hero projects (Majumder et al. 2019)
  • 5% or less of people responsible for 95% or more of interactions
  • “Heroes” commit far fewer bugs than other contributors
• Despite terminology, not a bad model for research projects
  • (Petre and Wilson 2014) found that people without domain knowledge couldn’t review scientific code effectively

Martha’s Rules

• This is our recommended governance framework
• Simple enough to implement immediately
• Clear enough to avoid ambiguity

• Anyone can put forward a proposal by filing it at least 24 hours before a scheduled meeting
  • One-line summary
  • Background information
  • Concrete proposal
  • Pros and cons
  • Alternatives
• At most two pages
  • Preferably shorter

Establishing a quorum

• A quorum is established if half or more of voting members are present
• Which means there must be:
  • A rule about how to become a member
  • A rule about when and how someone stops being a member
• The meeting may not discuss or vote on a proposal unless its sponsor (or their delegate) is present.

Presenting a proposal

• The sponsor has 5 minutes to present the proposal
• Members cast a sense vote: support, neutral, or oppose
  • If everyone supports or is neutral, go immediately to a binary vote with no further discussion
  • If a majority is opposed or neutral, send proposal back to sponsor for further work
• If a minority of members oppose, set a timer for 10 minutes of moderated discussion
• Then call a final binary vote in which everyone must support or oppose (no neutral votes allowed)
• If a majority support, the proposal is accepted
  • Otherwise, it is returned to the sponsor for further work

Activity: Decision Making (5 minutes)

In our shared Google Doc, Section: “Decision Making”

1. What decisions has your project made recently?
2. Who made them?
3. Where are they recorded?

⏱️ START: 0:30 | DURATION: 5 minutes | END: 0:35 - This helps identify gaps in decision documentation

Roles and responsibilities

People & Their Roles

Person	Roles
ghopper	admin
kjohnson	admin, commit
aturing	commit
bwk	commit

Roles & Their Tasks

Role	Tasks
admin	merge PRs, assign issues
commit	publish posts, file issues

Benefits:

• Gives you a list of what actually needs to be done
  • It’s always longer than you first expect
• Tells everyone who to go to for what
  • Particularly when their first choice is on holiday
• Helps with succession planning
  • “We don’t have anyone who does that any more…”

Activity: Roles & Responsibilities (5 minutes)

In our shared Google Doc, Section: “Roles Matrix”

Column A: Tasks List things people do to keep your project going

Column B: People List contributors to the project

Then: Draw connections - what patterns emerge?

⏱️ START: 0:40 | DURATION: 5 minutes | END: 0:45 - Reveals informal structures and gaps

Code of Conduct

• Diverse communities need explicit norms
  • “I didn’t realize someone would find that offensive”
  • Which is sometimes used dishonestly…
• Adopt a Code of Conduct (e.g., Python’s)
  • Its mere existence is a strong signal about the kind of community you are
• Don’t write one yourself
  • You won’t think of all the edge cases
  • Using someone else’s makes misunderstandings less likely
• Use the Contributor Covenant

Code of Conduct (continued)

• A Code of Conduct is only useful if it is enforced
  • And if there is a clear reporting mechanism that community members trust
• Be explicit about enforcement mechanisms and consequences
• Designate an independent third party to handle complaints
  • Trade off with another project lead
  • Do the background reading (Aurora and Gardiner 2019)

Meetings

⏱️ START: 0:40 | DURATION: 15 minutes | END: 0:55 - 10 practical rules for better meetings - Each rule gets about 1.5 minutes

• On par with interruptions for “things people wish they could have less of”
• Unlike interruptions, can be done well
• As with governance, having rules is the first and biggest step toward efficiency

1. Does there actually need to be a meeting?

• To inform? Only if you are expecting questions
• To consult? Only if people get a vote
  • Otherwise it’s just informing with pretense
• To discuss and make decisions? Yes
  • But only in small groups
  • Or with well-defined procedural rules
• To brainstorm or collaborate?
  • That’s a very different kind of meeting

2. Create an agenda

• If you don’t care enough to make a list, you don’t need a meeting
• Include timings
• Prioritize
• Plan to end early
  • “The most fundamental unit of time is the bladder”

3. Have clear rules for making decisions

• “The Tyranny of Structurelessness” (Freeman 1972)
• If you need Robert’s Rules, you need training

4. Put someone in charge

• The moderator should not do most of the talking
  • Any more than the conductor plays most of the notes
• Call on specific people in order
• Allow them one point at a time
• Keep a backlog

5. Require politeness

• All the other rules are special cases of this…
• No technology during in-person meeting
  • Except for assistive technology or family need
  • “Please put your devices in politeness mode”
• No interruptions
  • Except by moderator
• No rambling
• You do have a Code of Conduct, right?

6. Record minutes

• So people who weren’t there know what happened
• So people who were there agree what happened
• So people can be held accountable at later meetings

7. Manage “that guy”

NOAA categorization of disruptive behavior types

• The moderator’s other job…
• Three stickies
• Interruption bingo
• https://coast.noaa.gov/ddb/

8. Be an active participant

• Decline invitations
  • If you agree to abide by what the meeting decides
• Read the agenda and material before the meeting
• Take your own notes
• Use participants’ names
• Pause before speaking
• Put down your hand

9. Life online

• No mixed-mode meetings
  • All in person or all online
• Do not record the meeting without willing consent
• Review meeting protocol at the start if necessary
• Take minutes in a shared document
• Raise hands digitally
  • /hand in the chat is good
  • /hand another budget item is better

10. Seek truth, not victory

• No social dominance displays
  • “Well actually…”
• Don’t raise points you don’t actually believe in
  • The devil doesn’t need more advocates
• Don’t make excuses for your questions or opinions
  • “This is probably stupid, but…”

Recommended reading

• (Brookfield and Preskill 2016) has a lot of good ideas for managing discussion
• Producing Open Source Software by Karl Fogel
• The Tyranny of Structurelessness by Jo Freeman

Key Takeaways

• Governance is not bureaucracy - it’s clarity
• Start with Martha’s Rules for decision making
• Document roles and responsibilities explicitly
• Make meetings count with clear structure
• Code of Conduct is non-negotiable

• Wrap up with actionable items
• Encourage participants to implement one governance improvement

Activity: Governance Structure (5 minutes)

In our shared Google Doc, Section: “Governance Rules”

1. Who gets a vote in your group?
2. How are new people added to that pool?
3. When and how do people lose their votes?
4. Where do people find out what has been decided?
5. How can non-voters raise issues?

⏱️ START: 1:05 | DURATION: 5 minutes | END: 1:10 - Often reveals informal or unclear processes - Wrap up with key takeaways - This final activity brings everything together

References

Aurora, Valerie, and Mary Gardiner. 2019. How to Respond to Code of Conduct Reports. Version 1.1. Frame Shift Consulting LLC.

Brookfield, Stephen D., and Stephen Preskill. 2016. The Discussion Book: 50 Great Ways to Get People Talking. Jossey-Bass.

Brooks, Frederick P., Jr. 1995. The Mythical Man-Month: Essays on Software Engineering. Anniversary edition. Addison-Wesley Professional.

Freeman, Jo. 1972. “The Tyranny of Structurelessness.” The Second Wave 2 (1).

Majumder, Suvodeep, Joymallya Chakraborty, Amritanshu Agrawal, and Tim Menzies. 2019. “Why Software Projects Need Heroes: Lessons Learned from 1100+ Projects.” Arxiv.org abs/1904.09954.

Petre, Marian, and Greg Wilson. 2014. “Code Review for and by Scientists.” In Proc.second Workshop on Sustainable Software for Science: Practice and Experience. https://doi.org/arXiv:1407.5648.