Merge "New communication tools proposal"
This commit is contained in:
Zuul
Gerrit Code Review
commit
82cc8d9624
|
|
@ -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/
|
||||
|
|
@ -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
|
||||
|
|
@ -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/
|
||||
Loading…
Reference in New Issue