### Managing Research Software Projects # Leadership
There isn't a way things should be. There's just what happens, and what we do.
--- Terry Pratchett --- # What problems are we trying to solve? - Scheduling - "What are we going to deliver when?" - Visibility - "No one knows we could help them" - Sustainability - "It's getting pretty lonely around here…" --- # Product manager vs. project manager - The *product* manager manages the feature list - What can't we do? - What hurts? - The *project* manager manages the schedule - Who is doing what? - When do we cut it and do something smaller? - You are probably doing both… --- # Prioritization - Sticky notes on a whiteboard - Lots of discussion
--- # Prioritization - Guarantee some successes - Be optimistic, but be prepared to adjust - Be willing to ignore some things
As project lead
- Manage discussion of priorities and required effort - Tag issues as `current` - Update regularly as work progresses - Decide when to defer work in progress - "A schedule's purpose is to tell us how far behind we are and what to do about it" --- # Communication - "Someone just mailed me your tweet about the Slack thread so I filed a GitHub issue about updating the Google Doc that keeps track of our wikis." - Most projects converge on a single channel - Mail or Slack, Google Docs or a wiki - Pick one for immediate topics, one for archiving - *Make them searchable* --- # Communication pitfalls - Use real-time to build community, not share information - Throttle discussion - "One message per person per topic per day" - Makes room for people who need more time to think - Don't re-argue points endlessly - Archive decisions and point to them - No disparagement or feigned surprise - "Maybe next time you could think before you type?" - "Gosh, I thought *everyone* knew X…" --- # Get the word out - Blog regularly - Papers are supposed to sound objective - Blog posts should be excited and opinionated - Your site generator can handle the mechanics - Make things findable - Tag early, tag often - Make things accessible - Describe your images ---
As project lead
- Ask contributors to make space for others to speak - Blog (or ask others to) - Bring newcomers on board --- # Pathways to contribution - Tag some issues as good first issue - Go through first review in more detail or by video - Provide runnable examples in docs - And ask newcomers to update them - Show newcomers how to write good bug reports - Reproducible examples (reprexes) --- # At the end of the day - Recognize contributions - Add names to `CONTRIBUTING` and `CITATION` - Thank people publicly - Especially when they move on - Designate your own successor - Who can also run things temporarily when you're on holiday, ill, or busy ---
1. How do newcomers make their first contribution to your project? 1. What are project members working on right now that they really ought to set aside in favor of something else? 1. What do you do for the project that no one else knows how to do?