Asynchronous communication for open source projects

This is a suggestion for organising asynchronous communication 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: openness, inclusivity, and transparency, translates when it comes to communication 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 future 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 communication.

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 pull request. We encourage present and future contributors to inquiry by opening an issue if they have any questions.

A repository is the agora for maintainers, contributors and users. 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:

  • there is an issue that conveys what they have to say; if so they should carry on the conversation in that issue;
  • one or multiple issues that are related to what they have to say, but do not convey the full message, they should open a new issue, and carry on the conversation referencing past related issues;
  • their issue was dealt with in the past and is now closed.

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. If an issue is a duplicate, or related to some other conversation, contributors will close it and reference the relevant issue. Do your own research; be considerate of other contributors’ time and attention.

Opening an issue to start a conversation can seem daunting. It should not be. It is expected that contributors write so others can join the conversation. All conversations should take place on the repository for the sake of openness, inclusivity, and transparency.

The repository as an asynchronous communication platform:

  • allows for the pace of a conversation to be adequate so all contributors have a chance to join;
  • allows necessary time for contributors to think and reflect before starting, or joining a conversation;
  • allows contributors with different schedules, obligations, or in different time zones, enough time to join a conversation;
  • allows contributors to join any conversations about the development of the product;
  • allows contributors to create thoughtful conversations that can be seamlessly transferred to a Wiki, a Help page, or Documentation;
  • allows contributors to find their way throughout past conversations since conversations are structured and organised by subjects;
  • prevents collaboration overload (that is for contributors to spend less time organising” and more time contributing to documentation, code, translations, design, bug reporting, etc);
  • allows for necessary time and space to produce higher quality conversations.

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:

  • contributors have different schedules, obligations, and live in various time zones;
  • conversations taking place outside the project’s repository arbitrary seclude other contributors;
  • conversations taking place outside the project’s repository might be concurrent and risk conflicting at some point.

Sometimes synchronous, or instant message (IM), communication 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

Other read on asynchronous communication:
  • How to foster an asynchronous communication culture (coming soon — sign up for the newsletter or follow RSS feed to be notified).
Up next git - remote: Invalid username or password. fatal: Authentication failed for [remote’s URL] twtxt
Latest posts Update: added EtherCal (web-based spreadsheet), Etherpad (web-based word processor), Framadate (polls), Drop (file transfer) to list.romainaubert.com Mac Terminal commands to prevent Mac from sleeping Mac Terminal command-line interface (CLI) cheatsheet A roadmap to reclaiming my attention, relationships, intimacy and privacy Bypass cookie banners by toggling “reader view” in your browser Book review - alone together: why we expect more from technology and less from each other - by sherry turkle Update: added 2 Android OS, 2 phones, a search engine, a map app, 2 blog CMS, and a tool to delete Tweets to list.romainaubert.com Should people negotiate financial income from the use of their personal data? Peer-to-peer/decentralized network architectures and information commons as an alternative to a centralized internet Yelp is screwing over restaurants by replacing their phone numbers on listings and routing customers’ calls thru a referral marketing business. how to ditch Facebook, Twitter, Google News, Instagram, and LinkedIn — and still follow news, people and organizations you like Tour of Queyras (GR58), 140 km, 7,000m elevation, 7 days Facebook’s “privacy notifications” and “co creation strategies” to protect people’s privacy Privacy-friendly and open source alternatives to Google’s products Privacy 101: simple steps to protect your privacy online Bongo 9. twtxt Asynchronous communication for open source projects git - remote: Invalid username or password. fatal: Authentication failed for [remote’s URL] product development resources 10 Days in Silence: Vipassana Meditation Book review - un peuple de promeneur - alexandre romanès Book review - journey under the midnight sun (白夜行, byakuyakō) - keigo higashino Book review - how to fail at everything and still win big - scott adams Book review - the remains of the day - kazuo ishiguro Book review - man’s search for meaning - viktor e. frankl Book review - cosmos - michel onfray We don’t care about personas “Building a more private web” by Google — comment on Reddit Replacing Facebook with newsletters Now