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)
• 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 CONTRIBUTING.md

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

@article{
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 = "https://doi.org/10.1371/journal.pcbi.1007296",
url = "https://journals.plos.org/ploscompbiol/article?id=10.1371%2Fjournal.pcbi.1007296",
}