This is a suggestion for organising asynchronous communications for open source projects.
I first drafted a modified version of this blog post as a contribution to an open source project. The aim of this contribution was to suggest how values of the project: openess, inclusiveness, and transparency, translate when it come to communications amongst present and future contributors and maintainers.
We would like people to feel that they can join the conversation whenever they want and contribute at their own pace. In that aspect, the role of contributors should be to make sure that present and futur contributors can do so. Contributors should convey the ethos by keeping the project open, inclusive, transparent. That is by making sure all contributors have access to all communications.
We believe that the time and effort people contribute to an open source project should remain under their control. Contributing to an open source project should not become a burden for a contributor. Contributors should not feel pressured to work; that is coding, reporting bugs, translating, documenting, joining or monitoring conversation or even responding to a message synchronously. Contributors can join at their own will, contribute at their own pace. Contributors are responsible to assess the relevance and the scope of their contributions before opening a PR. We encourage present and future contributors to inquiry to the community by opening an issue if they have any questions.
The repository is the agora of the community. If one feels like they have something to say, a comment, a feedback, an idea, a suggestion, a feature request, a bug report; they should do so in an issue. Issues are the place for those conversations; we believe that it is best to open issue when in doubts, than not to.
Before one opens an issue they should search through open and closed issues to check if:
All conversations should be deemed a space on the repository. It is best to open an issue, comment and have a say, rather than not to. If an issue is a duplicate, or related to some other conversation, the community will close it and reference the relevant issue. Do your own research; be considerate of other contributors’s time and attention.
Opening an issue to start a conversation can seem daunting. It should not be. The community expects contributors to write so other contributors can join the conversation. The community would like all conversations to take place on the repository because we believe in being open, inclusive and transparent.
The repository’s issues system should be the agora of the community because we believe that a public asynchronous communication platform:
As the founder of Doist puts it, “asynchronous communication is when you send a message without expecting an immediate response”.
I would also add that asynchronous communication tools tend to organise conversations by subjects (e.g. “Fix update button”) rather than topics (e.g. “#bugs.”) With asynchronous tools such as a repository’s issue system or a forum, conversations are organised by subject. Conversations organised by subjects are separated from one another; once they are terminated they can be closed, and archived, and don’t clutter the issue/forum board where all active conversations live. With synchronous tools such as Slack, conversation are organised by topic. Conversations all live on the timeline of a same topic and can’t be closed or archived. In asynchronous tools tags are a substitute for synchronous tools’s topics.
Contributors might find it easier to navigate conversations by subjects and tags, rather than topics and conversational timelines.
Conversations outside a project’s repository — if a contributor decide to contact a contributor outside of the project’s repository, they should be considerate:
Sometimes synchronous, or instant message (IM), communications can help. E.g. when working in pairs, code reviews, mentoring, dealing with emergency, etc. If one happens to do so they should make necessary effort to document the “off repo” conversation in an issue. That said:
“Synchronous communication should be the exception, not the rule.”– Amir Salihefendic, founder and CEO of Doist