Governance

Managing Research Software Projects

Greg Wilson

2026

Learning Objectives

  • Describe two ways informal decision-making fails as projects grow.
  • Describe Martha’s Rules and explain when they are appropriate.

Why Informal Governance Fails

  • Informal groups always have power structures, just invisible and unaccountable.
  • About 80% of GitHub projects are hero projects.
    • 5% or fewer of contributors account for 95% of interactions.
  • Decisions should not be made by the loudest voices.
  • Transparency attracts and keeps contributors.

A Governance Statement

  • Every project needs written answers to three questions.
    1. Who gets a vote on what?
    2. How are decisions recorded and communicated?
    3. How does someone without a vote raise a concern?
  • Research projects must also decide authorship order and release approval.

Martha’s Rules

  • Proposals are filed at least 24 hours before a meeting.
  • A proposal is at most one page: summary, proposal, pros and cons, alternatives.
  • Members cast a sense vote: support, neutral, or oppose.
  • If everyone supports or is neutral, the motion passes.
  • Opposition triggers 10 minutes of discussion followed by a binary vote.
  • Decisions go in a public decision log.

Meetings as Governance

  • Agendas with time allocations sent in advance.
  • A rotating facilitator and a designated note-taker.
  • A public decision log makes behavior visible and predictable.
  • Status updates in “progress, plans, problems” format.
  • Managers provide context and priorities.

Externals and Escalation

  • Say how external contributors can make proposals or escalate concerns.
  • Say when someone who has submitted pull requests can vote.
  • Omitting this is equivalent to “maintainers decide and contributors live with it”.
  • Spell out the appeal process, or say clearly that there isn’t one.

Credit

  • Three questions get confused:
    1. Who wrote the code?
    2. Who gets credit for the software?
    3. Who is an author on the paper?
  • git log records code but not reviews and other contributions.

As a Manager

  • Write down what qualifies someone for authorship before anyone asks.
  • Keep a CONTRIBUTORS.md file up to date.

What about AI?

  • LLM summaries can surface points of disagreement before a meeting
  • LLM-drafted position statements look equally authoritative regardless of evidence
  • LLM governance documents can omit the operational detail that makes them useful

Authorship Policy (7 min)

Write two sentences for the “Authorship” section of your CONTRIBUTING.md:

  • Sentence 1: what kinds of contributions qualify someone for authorship on a paper about the software. Be specific: not “substantial contribution” but something that could be assessed independently after the fact.
  • Sentence 2: how someone who believes they have been omitted can raise the issue.

Stress Test (8 min)

Work in groups of three. One person reads their governance statement aloud. The other two play roles:

  1. A confused newcomer who wants to contribute but has never interacted with the project. Ask one question the statement doesn’t answer.
  2. A disgruntled long-term contributor who disagrees with a recent decision. Ask one question about how they could have raised that disagreement.