People around the project.
WHY IT MATTERS
Adoption and contribution depend on whether participation is worthwhile.
WHAT ATTRACTS PARTICIPATION
The software solving a real problem Documentation that makes it usable Responsiveness Contributions being accepted A welcoming tone
WHAT DETERS IT
Unanswered issues Contributions ignored or rejected without explanation Hostile or dismissive responses Unclear direction Decisions made without explanation
WHY TONE MATTERS PRACTICALLY
Technical communities are small and reputation spreads.
WHAT TO ESTABLISH
Expected conduct, stated.
WHAT TO ADDRESS
Behaviour that drives people away.
WHY
A few hostile participants can end a community.
WHAT TO ESTABLISH ABOUT DECISIONS
Who makes them and on what basis.
WHY
Unclear authority produces repeated argument.
WHAT TO COMMUNICATE
Direction and priorities.
WHY
Contributors work on what they believe will be accepted.
WHAT TO RECOGNISE
Contributions, visibly.
WHY
Recognition is most of what contributors receive.
WHAT TO ESTABLISH
A route for questions separate from issue reporting.
WHY
Questions in issue trackers obscure actual defects.
WHAT TO PROVIDE
Documentation that answers the common questions.
WHY
It reduces the support burden that otherwise consumes maintainers.
WHAT TO ESTABLISH ABOUT COMMERCIAL INVOLVEMENT
Transparency about the company's role.
WHY
Undisclosed commercial direction of a community project causes resentment when discovered.
WHAT TO AVOID
Treating contributors as unpaid staff.