Community: common goal, mutually engaged, shared resource

Rule 1: Be welcoming

  • make a good first impression, make a proactive effort to foster positive feelings
  • offering assistance in finding ways to make an initial contribution
  • directing the newcomer to project members who have a similar background or skill set
  • pointing the newcomer to essential project resources (e.g., the contribution guidelines)
  • clearly identify work items they can start with
  • tag bugs or issues as “suitable for newcomers” and ask established members not to fix them

Rule 2: Help potential contributors evaluate if the project is a good fit

  • LibreOffice, e.g., provides a way for developers to filter available tasks by required skills and difficulty
  • “basic Python skills” means very different things to different people

Rule 3: Make governance explicit

  • “The Cathedral and the Bazaar”: an egalitarian world in which everyone could contribute equally to open projects
    • reality: authority lies with those willing to shout loudest and longest
    • the realities of how power arises, becomes concentrated, and used to perpetuate itself
    • Freeman’s influential essay “The Tyranny of Structurelessness” (1972)
    • The solution is to make a project’s governance explicit so that people know who makes which decisions
  • consensus-building: Martha’s Rules (at bottom)
  • decide on the rules well in advance of contentious issues emerging

Rule 4: Keep knowledge up to date and findable

  • make sure that all necessary information is both accessible and findable
    • use wikis, files in GitHub, shared Google Docs, old tweets or Slack messages, and email archives
    • Signaling the absence or staleness of material can save newcomers time
  • provide “how to contribute” guidelines: GitHub’s recommendation for placing such information in a

Rule 5: Have and enforce a code of conduct

  • make norms about acceptable behavior explicit
    • ensure that everyone will find the environment healthy and welcoming
    • sends a clear signal that the community actually has standards
  • A code of conduct is only useful if there is a clear reporting mechanism

Rule 6: Develop forms of legitimate peripheral participation

  • legitimate peripheral participation (LPP)
    • Newcomers become members of a community by participating in simple, low-risk tasks
    • newcomers become acquainted with the community’s tasks, vocabulary, and governance so that they can ease into the project
  • encourage newcomers to submit issues to a repository when they notice a bug
  • have newcomers help with documentation, particularly with translation and localization
  • mark some issues as suitable for newcomers.

Rule 7: Make it easy for newcomers to get started

  • going from “I want to help” to “I’m able to help” to “I’m helping”
  • Any complexity or confusion at this point is therefore a significant barrier to participation

Rule 8: Use opportunities for in-person interaction—With care

  • face-to-face vs remote communication: each form has benefits and drawbacks
    • In-person interaction is valuable for uninterrupted, synchronous dialog
    • benefit from engaging newcomers in in-person interaction from time to time
  • potential contributors might shy away from the project if they are introverted

Rule 9: Acknowledge all contributions

  • gratitude and recognition are the most powerful tools community builders have
  • every project should adopt and publicize guidelines describing what constitutes a contribution, how contributions will be acknowledged, and how they will be used

Rule 10: Follow up on both success and failure

  • Helping newcomers find the next problem they might want to work on or pointing them at the next thing they might enjoy reading
  • encouraging them to help the next wave of newcomers is both a good way to recognize what they have learned
    • Mentoring programs
  • projects should also try to follow up on their failures
    • Why did potential contributors not become community members?
    • Did they realize that the project wasn’t a good fit (in which case, the overview may need an overhaul)?
    • Was it too difficult to find a starting point or to get set up to start work (in which case information may need to be consolidated, tagged, filled in, or updated)?
    • Or did they feel uncomfortable or undervalued (in which case the community may need to have a more difficult conversation)?

Martha’s rules

  • Anyone may put forward a proposal up to 24 hours before a meeting. Proposals must include a one-line summary, a brief description, any required background information, and a discussion of pros and cons (including alternatives).
  • Once a person has sponsored a proposal, they are responsible for it; the group may not discuss or vote on the issue unless the sponsor is present.
  • After the sponsor presents the proposal, a “sense” vote is taken prior to any discussion in which people indicate whether they like the proposal, can live with it, or are uncomfortable with it.
  • If all or most of the group likes or can live with the proposal, it moves to a formal vote with no further discussion.
  • If most of the group is uncomfortable with the proposal, it is postponed for further rework by the sponsor.
  • If some members are uncomfortable, they can briefly state their objections. After 10 minutes of moderated discussion, the facilitator calls for a yes-or-no vote on adoption. If a majority vote “yes”, the proposal is implemented. Otherwise, the proposal is returned to the sponsor for further work.

Bibliographic data

   title = "Ten simple rules for helping newcomers become contributors to open projects",
   author = "Dan Sholler and Igor Steinmacher and Denae Ford and Mara Averick and Mike Hoye and Greg Wilson",
   journal = "PLoS Comput Biol",
   volume = "15",
   number = "9",
   month = "Sep",
   year = "2019",
   doi = "",
   url = "",