### Managing Research Software Projects # Governance
Evil begins when you begin to treat people as things.
--- Terry Pratchett --- # What problems are we trying to solve? - Opaque decision making - "Apparently we have rules…" - The tyranny of structurelessness - "It's not what you know, it's who you know." - A low lottery factor - "They left and now no one knows how to do this." - Low productivity - "Oh no: not another meeting…" --- # Martha's Rules ## Putting forward a proposal - 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) --- # Martha's Rules ## Establishing a quorum - A quorum is established if half or more of voting members are present - …which means there must be: - A written rule about how to become a member - A written 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. --- # Martha's Rules ## Sense vote - The sponsor has 5 minutes to present the proposal - Members cast a *sense vote*: support, neutral, or oppose - If everyone supports or is neutral, pass immediately - If a majority is opposed or neutral, send proposal back to sponsor for further work --- # Martha's Rules ## Discussion and final vote - If a minority of members oppose, set a timer for 10 minutes of moderated discussion - Then call a final binary vote - 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 --- # Roles and responsibilities - 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…" --- # Roles and responsibilities | Role | Task | | ---- | ---- | | admin | merge PRs | | admin | assign issues | | contributor | publish blog posts | | contributor | file issues | | Person | Roles | | ---- | ---- | | ghopper | admin | | kjohnson | admin, contributor | | aturing | contributor | | bwk | contributor | --- # How to run a meeting ## Before - Decide if there actually needs to be one - If the only purpose is to share information, the answer is "no" - Write and circulate an agenda with timings - "Our open issues on GitHub" is not an agenda - Put the most important or contentious things first - 20 minutes on coffee club and 5 minutes on budget is probably not the right balance --- # How to run a meeting ## During - Pick a moderator - They always pick the next person to speak - When they want to make point, be clear that they're speaking as themselves as not as the moderator - Require politeness - No interruptions, no rudeness, no rambling - Devices down - Unless required for accessibility --- # How to run a meeting ## During - Take notes - Of the meeting as a whole - While others speak so that you can ask good questions - Keep a backlog - Stops conversation going off track - Helps with time management --- # How to run a meeting ## After - Circulate the minutes - Email + a wiki page or a file in version control - Be clear where discussion should go - File or update action items - GitHub issue tracker is a good place ---
1. What decisions has your project made recently? 1. Who made them? 1. Where are they recorded? ---
Roles and responsibilities
1. List a dozen things people do to keep your project going in Column A. 1. List people who contribute to the project in Column B. 1. Draw lines to connect them. What roles can you identify?