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
  • Nadia Eghbal's template: nayafia/contributing-template/

• Changelog (e.g. Dolphin's progress reports)
• Frequently asked questions
• Release notes
• Pull request/issue templates

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

servo/highfive

• 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
• Shepherd changes that don't meet the bar
• Explain why changes are not desirable
• Say thank you

• Just/easy/simple
• Please ask questions
• Does that make sense?
• You/your -> we/our

• 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

• Positive 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

• How To Improve The Bus Factor In Your Open Source Project - Sumana Harihareswara
• Teaching People to Fish - Denise (Dreamwidth)

• Josh Matthews
• Engagement Whip at Mozilla
• @lastontheboat


• Slides:
  http://joshmatthews.net/oscon16/