internal communication | aligning info across communication channels

[Joseph P. De Veaugh-Geiss]

This is a follow up to an issue I brought up in the Akademy presentation 
on internal communication: aligning information across communication 
channels.

tl;dr If you are an admin of a communication channel or an active 
contributor to a project, make sure information about communication 
channels for your team are aligned across channels. If they are not, 
please update information in all relevant places (website, wiki, mailing 
list or Matrix room description, etc.).

The goal: to make it as easy as possible for new contributors to know 
where to contact teams and get started!

_Problem_

Depending on your entry point, new contributors may find different 
information about where/how to communicate with teams.

In the Akademy presentation I used examples from local community groups, 
but it applies to other teams as well.

When information is not aligned across communication channels, 
on-ramping paths will be inconsistent, fragmentation can occur, and 
there is a general lack of discoverability across channels of communication.

We can change this.

_Proposal_

Provide consistent information across communication channels for your 
team/group. I see two basic ways to go about this (or a combination of 
the two):

  (1) *Centralized Info*: Provide a link to one central place (the 
project website, a wiki page, etc.) where the various communication 
channels for your team/group are listed, and a brief description of each 
channel; see below for more. This link can then be included at all 
relevant communication channels (e.g., wiki, Matrix room description, 
mailing list description, Discuss, etc.).

  (2) *Decentralized Info*: At each channel provide a list of /all other 
communication channels/ for your team/group (Matrix room description, 
mailing list description, Discuss, etc.), and a brief description of 
each channel; see below for more. This way, regardless of where a 
contributor starts, information about the other communication channels 
will always be immediately available.

_Information To Include In The Description_

The information to include in the description includes:

  * Communication channels relevant for the team/group (website, wiki 
page, mailing list, Matrix/IRC room, GitLab repo, Bugzilla, blog, etc.)
  * Links to the above channels
  * Short description of what the channel is used for (announcements, 
long-form discussion, live chat, etc.)
  * What contributors can expect there (low or high traffic, end user 
support, developer discussions, etc.)

_Defining The Channel's Scope_

You may not be able to tell by looking at me, but I really like things 
to be orderly :)

I know there is a lot of overlap in how various communication channels 
are used, but I suggest defining a clear scope for each channel and 
communicating that explicitly in the description. For example (general 
idea):

  * Mailing list (low traffic): for long-form discussions and 
announcements -- primarly for internal communication (for live chat, 
please use Matrix/IRC; for user support, use Discuss)
  * Matrix room (high traffic): for quick developer questions, short 
discussions, development suggestions -- primarly for internal 
communication (for longer discussions or announcements, please use the 
mailing list; for user support, use Discuss)
  * Discuss: for end user support and announcements -- primarly for 
external communication (for internal communication, please use the 
mailing list or Matrix room)
  * Bugzilla: for bug reports; make sure to read 
https://community.kde.org/Get_Involved/Issue_Reporting for issue 
reporting guidelines
  * Etc.

Again, I know many communication channels are not used categorically for 
one thing or another, so adapt this suggestion as you see fit. 
Nevertheless, I imagine there are benefits when new contributors have 
clear information about the scope of a communication channel, and it may 
save some time and energy for teams when new contributors land in the 
right place right away.

I will follow up on this late September to see how things look across 
the various teams. If you have any questions or comments, want some 
support for this, or simply disagree with my proposal, please feel free 
to write to me or respond to the list.

Note: I will be away from the computer for most of the first half of 
September. If you write me in this time, I will definitely get back to 
you asap after 18 September.

Cheers,
Joseph

-- 
Joseph P. De Veaugh-Geiss
KDE Internal Communications & KDE Eco Community Manager
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Matrix: @joseph:kde.org

Generally available Monday-Thursday from 10-16h CET/CEST. Outside of 
these times it may take a little longer for me to respond.

KDE Eco: Building Energy-Efficient Free Software!
Website: https://eco.kde.org
Mastodon: @be4foss at floss.social