From 19c136b11a06179dac13e56b532ae88862bbbf65 Mon Sep 17 00:00:00 2001 From: Jean-Philippe Evrard Date: Fri, 10 Apr 2020 09:57:32 +0200 Subject: [PATCH] New communication tools proposal Change-Id: I96c9b8a09cf3267b4eb173f6168d688269e5a3fc --- doc/source/ideas/pylon/asynchronous-comms.rst | 74 +++++++++++++++++++ doc/source/ideas/pylon/index.rst | 33 +++++++++ ...nchronous-and-pseudo-synchronous-comms.rst | 60 +++++++++++++++ 3 files changed, 167 insertions(+) create mode 100644 doc/source/ideas/pylon/asynchronous-comms.rst create mode 100644 doc/source/ideas/pylon/index.rst create mode 100644 doc/source/ideas/pylon/synchronous-and-pseudo-synchronous-comms.rst diff --git a/doc/source/ideas/pylon/asynchronous-comms.rst b/doc/source/ideas/pylon/asynchronous-comms.rst new file mode 100644 index 0000000..2dc6d3e --- /dev/null +++ b/doc/source/ideas/pylon/asynchronous-comms.rst @@ -0,0 +1,74 @@ +Asynchronous communications +=========================== + +Before explaining what tools can be good for OpenStack, we should clarify +what asynchronous communications mean, and explain the problem with the +current status-quo. + +Definition +---------- + +The *asynchronous* communications are the communications happening between +community members which don't trigger an expectation of an immediate +("instant") answer from other community members. + +The current mechanisms for asynchronous communications are for example our +code review system, ask.openstack.org, or our mailing lists. + +The problem +----------- + +While our code review system brings an easy way to track comments on any +code and find history of discussions and decisions, a code review system is +not a good fit for non-code conversations. + +For that we rely on mailing lists. The current mailing list implementation has +a poor user interface, preventing efficient search for example. + +Next to this, a mailing list is only an email service. It will not provide +any other tool that our community could need and use in asynchronous +communications. An example is a poll system for a topic: It often happen +that we run informal polls in OpenStack governance entities (like projects), +yet the only way to record those polls is to rely on either an external +service, or to rely on an IRC bot (and need to fallback to a synchronous +meeting). + +We should move to a more modern tool for asynchronous communications, +as it would offer new features, be more attractive to interact, and +look more modern to accomodate new contributors. + +The proposal +------------ + +I propose to move our mailing lists to `Discourse`_, like Mozilla. + +`Discourse`_ has lots of benefits: a better search, indexing, and +interaction with communication tools. This would allow to refer to synchronous +communications inside the asynchronous tool. For example, we could +have conversations with `matrix`_ inside `Discourse`_. +(https://www.discourse.org/plugins/chat-integration.html) + +Next to this, we could generate more granular data on the engagement on certain +topics, compared to the mailing lists, as it is already part of Discourse. + +Fun note: This would also allow us to remove this "ideas" framework +git repository. + +Downsides +--------- + +Discourse if far less attractive for "email only" workflows. +While it is possible to simply "Reply via email", and mark all the conversations +as read when they are sent through email, creating a new topic is a little +bit harder, as a user cannot simply send to the generic address. Instead, +the writer should find the unique email for a new topic. +See also Mozilla's `new Discourse topic via email procedure`_. + +A change in the tooling could lead to a split in the community, +for people not wanting to change. There is of course an +`xkcd for that`_. + +.. _new Discourse topic via email procedure: https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279#create-topics-via-email +.. _xkcd for that: https://xkcd.com/1782/ +.. _Discourse: https://www.discourse.org/ +.. _matrix: https://matrix.org/ diff --git a/doc/source/ideas/pylon/index.rst b/doc/source/ideas/pylon/index.rst new file mode 100644 index 0000000..8cc7d81 --- /dev/null +++ b/doc/source/ideas/pylon/index.rst @@ -0,0 +1,33 @@ +Project Pylon: Update our communication tooling +=============================================== + +Introduction +------------ + +Our community is relying on efficient, working, communication mecanisms. +Currently, the OpenDev team provides us with mailing lists, IRC tools, and +video conferencing. + +However, those communication mechanisms might appear "unattractive" +by younger contributors. The idea to change these tools with a more +modern "toolkit" has been floated in the past. However, this didn't result +in a change, and it is hard to find a record of the reasons why the +conversations ended up with a status quo. We therefore don't know what +was proposed, and what were the rejections reasons. + +We should instead keep these conversations in an easy to browse format, +and the ideas repository is most likely the best place for that (until +we change the tooling). + +I compared what other communities have been doing to record communications, +and I think we are closer in mindsets to the "Mozilla" model than the +"Kubernetes" model for example. This is taken into account in the proposed +solution. You can find more details about the proposed solution in the +next. + +Index +----- + +.. toctree:: + synchronous-and-pseudo-synchronous-comms.rst + asynchronous-comms.rst diff --git a/doc/source/ideas/pylon/synchronous-and-pseudo-synchronous-comms.rst b/doc/source/ideas/pylon/synchronous-and-pseudo-synchronous-comms.rst new file mode 100644 index 0000000..0ffd4d1 --- /dev/null +++ b/doc/source/ideas/pylon/synchronous-and-pseudo-synchronous-comms.rst @@ -0,0 +1,60 @@ +Synchronous and pseudo-synchronous communications +================================================= + +Before explaining what tools can be good for OpenStack, we should clarify +what (pseudo-)synchronous communications mean, and explain the problem with the +current status-quo. + +Definition +---------- + +The *synchronous* and *pseudo-synchronous* communications are the +happening between our community members, for which people +expect a relatively quick answer. The relative notion +depends on the context. For example, on a idle IRC channel, one might not +be expected to answer instantly, while instant present is expected during +synchronous IRC meetings or video conferences. + +The current mechanisms for (pseudo-)synchronous communications are for +example is OpenDev's meetpad service and our freenode IRC channels. + +The problem +----------- + +With the community being more distributed, it is probably easier to deal +with the distribution by relying on more asynchronous tools. +Yet, our processes and asynchronous tools limitations make us use more +synchronous communications, which limits the scalability of the community. +Some people will always feel left alone in the current ways. + +Next to this, IRC seems alien to the "new generation of developers", which +prefer *Slack* or *Matrix*: Those record conversations when you are +disconnected for example. + +The proposal +------------ + +I propose to move our IRC communication by moving to `matrix`_ (and optionally +a front-end/web client, like *Element*). + +I believe using it would increase attractiveness of our synchronous +communications. Additionally, this could integrate well with a more +modern asynchronous tooling like `Discourse`_. + +Mozilla has also chosen `matrix`_. + +People using IRC could easily adopt matrix, as a IRC bridge exists. + +For new joiners, a web interface would be a welcomed change, +as communication can be done from the browser, like *Slack*. + +Downsides +--------- + +This is a disruptive change, like for the asynchronous communications. +This could lead to a split in the community, for people not wanting to change. +https://xkcd.com/1782/ + + +.. _matrix: https://matrix.org/ +.. _Discourse: https://www.discourse.org/