Optimizing Open Source Projects for Contribution

• As a maintainer...
• As a contributor...

• Who's the audience?
• What could someone else do?
• What would you like them to do?
• How much help will you provide?

• What is expected of me?
• What can I work on?
• How do I get help?
• How do I share my work?

Help the target audience:

• find the project
• get involved quickly
• have a positive experience

• Prioritize useful information
• Reduce friction
• Make expectations clear
• Respond appropriately
• Follow through

• How do I use it?
• How do I change it?
• Where can I get support?
• README

• Roadmap
  • What currently exists
  • What doesn't exist
  • What will never exist
• CONTRIBUTING.md
  • Recommended workflow
  • Requirements for accepting changes

• Release notes
• Changelog (e.g. Dolphin's progress reports)
• Frequently asked questions
• Quickstart guide

The goal is to avoid an information overload.

Conversely, we must also provide just enough to enable success.

Choose something to work on from our issue tracker.

- every project maintainer

Tag related pieces of work.

• area of code
• symptom
• platform
• required skill

Tag issues that are appropriate for newcomers and non-core contributors.

Ensure issues contain enough information to start contributing immediately.

• clear steps to reproduce
• filenames, class names, function names
• links to documentation
• testing expectations

Make it easy to tell if an issue is claimed.

Triage old issues. Is it still:

• Valid? Reproducible?
• In progress?
• Good for a newcomer?

• Prioritize useful information
• Reduce friction
• Make expectations clear
• Respond appropriately
• Follow through

• following instructions that don't work
• making a choice without understanding the options
• unbounded waiting for someone else
• requiring new skills
• differences from past experience
• performing useless work

• automate as much as possible
• standardize technology

versus
./mach bootstrap

• Prioritize useful information
• Reduce friction
• Make expectations clear
• Respond appropriately
• Follow through

• What are contributors supposed to know?
• How long should it take to get feedback?
• How difficult is a task?
• Is there a deadline?
• What behaviour is apppropriate?

• Prioritize useful information
• Reduce friction
• Make expectations clear
• Respond appropriately
• Follow through

• Minimize time to feedback
• Changes that don't meet the bar
• Changes that are not desirable
• Language hacks
• Say thank you

• Prioritize useful information
• Reduce friction
• Make expectations clear
• Respond appropriately
• Follow through

• Recognition of contribution
• Suggest next task
• Every contributor is a potential maintainer

Help the target audience:

• find the project
• get involved quickly
• have a positive experience

• Feedback cycle
• Tools for publicizing work
• Communities of potential contributors
• Making the right pitch

• Feedback cycle
• Tools for publicizing work
• Communities of potential contributors
• Making the right pitch

• Josh Matthews
• Engagement Whip
• @lastontheboat
• Slides: http://joshmatthews.net/fsoss15/