Build a Community
Overview
Teaching: 5 min
Exercises: 10 minQuestions
How can I turn a project into a community?
Objectives
Identify the two biggest barriers to contribution in open source projects.
Explain how to choose the primary medium of discussion for a project.
Describe common communication pitfalls in open projects.
- Clearly identify members of core team
- Who is a primary part of the project and what rights does that give them
- What do they need to get out of the project and when (e.g., completion of thesis or contract)
- Review annually (at least)
- Treat every user as a potential contributor
- Makes it more likely that others will use your software
- Increases the odds of survival for your work when funding runs out or you move on
- More likely to impact traditional academic metrics (i.e., citations)
- Be clear about what peripheral participation means
- Make it clear that you respect research confidentiality and define what that actually means
- E.g., have explicit agreements about data availability, publication embargoes, etc.
- Even (or especially) if the project is “all open, all the time”
- Be explicit about when and how software changes will be integrated so that people have reasonable expectations
- Make it clear that you respect research confidentiality and define what that actually means
- Steinmacher identified two main barriers to contribution in open projects
- How easy is it to get set up?
- How friendly was reception of first contribution?
- Every project should include a contributor code of conduct
- And every project leader should think about what it’s like to be in a vulnerable group
- Use Contributor Covenant by default
- Make the process for complaint, appeal, and adjudication very clear
- And make the first point of contact very clear as well
- Needs:
- Incident response plan (i.e., who does what when an incident occurs)
- Widespread promotion (people have to know it exists and where to find it)
- Most important next step is to manage communication
- Small projects converge on one channel (i.e., issues, mailing list, Slack)
- “Someone mailed me your tweet about the Slack discussion so I filed a GitHub issue about updating the Google Doc. Wait, why are you crying?”
- Strongly prefer email for general discussion: ubiquitous, threaded, and asynchronous
- But only if publicly archived
- Point-to-point email makes key information unfindable and fosters cliques
- And discussion threads on issues for specific topics (to avoid overwhelming general channel)
- Small projects converge on one channel (i.e., issues, mailing list, Slack)
- Use video conferencing and in-person meetings to build community, not to share information
- People can read faster than you can talk
- Avoid common communication pitfalls
- Don’t post without a purpose
- Don’t rehash previous discussion
- Summarize in blog posts or web pages and point people at those
- Avoid bikeshedding
- “The smaller the problem, the longer the debate”
- Throttle discussion
- One post per person per topic per day
- Recurse Center’s social rules
- No feigning surprise
- No “well, actually”
- No back-seat driving
- No subtle -isms
- Be clear when the group is deciding and when it is merely advising
- Distinguish between inquiry and delegation
- “Could you please look at X?” is ambiguous
- Distinguish between inquiry and delegation
- Share management tasks as well as technical tasks
- Make it clear what has been delegated
- Follow up on everything you delegate
- Be clear about what “done” looks like
Code of Conduct
Add the Contributor Covenant or some similar code of conduct to your project. (Do not create one of your own.) What is the process for complaint, appeal, and adjudication?
Channels
- What is your project’s primary communication channel?
- Why and how was it chosen?
- What discussion(s) take place in other channels?
- Why?
- How easy or hard is it for a newcomer to find where things are being discussed?
Key Points
The two biggest factors affecting participation in open projects are ease of setup and warmth of response to first contribution.
Specify a contributor code of conduct for your project.
Use one primary channel for communication.
Avoid common communication pitfalls.