The Virtues of Reply All

One of my biggest pet peeves is coming into a meeting somewhere or talking casually with co-workers and realizing that a decision was made on a project that I was involved with and I didn't know about it.

I will say right up front that 99% of this peeve are my own hang-ups: a combination of a lot of FOMO and more than a little frustration at myself for not keeping up with my own e-mail deluge. Most of the time, it turns out, the decision was made out in the open in an e-mail thread or chat session and I just didn't see it.

Plus, I just need to loosen up a little.

Within a community, this kind of thing happens all of the time, and it's to be expected. No one person, after all, can and should be expected to keep track of everything that happens on an open source software project that involves more than, well, one person. That's kind of the whole point of community: taking on tasks collectively that no one person could do on their own.

Imagine, though, communications about an open source project that don't take place out in the open, where people can't have a say in what's going on or even come back to it later and review the communications after the fact.

It's not hard to imagine, because even in Red Hat, it's something we struggle with all of the time.

It is very easy to fall into a private conversation, and there doesn't have to be anything sinister about it. I am very guilty of this, too. There will be an e-mail thread on a project mailing list and I will click "Reply" instead of "Reply All" to talk to one or two people on the thread. Now I have started a side conversation, and the rest of the list cannot read what we are discussing.

There probably wasn't a sinister reason for this. Perhaps I was talking to the someone with graphic artist skills about a small change to the project logo and didn't want to bother the entire project (via the mailing list) with my question. Or I knew one person would have the answer to the question I had. Regardless of the reason, these kinds of side conversations, especially when they start gaining a life of their own, can be detrimental to the transparency of a community.

It should be noted that you don't have to include every single person in your project in every conversation. Topics can and should be siloed to the people who are interested in ad can contribute to that topic. The very existence of a "user" mailing list versus a "dev" mailing list is one simple example of such topic siloes. So, too, are any committees' conversations, where executive action is encouraged by discussions across smaller groups of people. (Though committee mailing lists should at least be viewable, even if they are moderated for non-list members.)

Closed conversations are particularly quick to occur when companies are involved in projects, because employees may tend to talk to each other privately before including the rest of the project roster.

This issue is pertinent to more than just mailing lists; online chats and real-world meetings can be mishandled in this manner as well. Methods that I use to try to stop this bad habit include:

• Trying to start all conversations in a public list and keeping them there
• Examining all messages for the inclusion of personal information that I don't want made public.
• Encouraging others to move private conversations to an open forum.
• Conduct face-to-face meetings with access to some sort of online conferencing system so "outside" community members can also participate.

Your efforts won't be 100% effective right off the bat. But if they can help make your community a little more transparent, then the efforts will be well worth it.

Image by Max Pixel, under CC0 Public Domain license.