关于开源项目如何选择沟通渠道的思考
开源 沟通

> 
> 开源项目的首要挑战是找出最佳的贡献者协作方式
> 
> 
> 


![Much ado about communication](/data/attachment/album/201706/22/101703gt8juoeudnto3uuo.png "Much ado about communication")


开源项目要面对的首要挑战之一是如何在贡献者之间沟通。这里有很多的选择：论坛、聊天频道、<ruby> 工单 <rp>  （ </rp> <rt>  issue </rt> <rp>  ） </rp></ruby>、邮件列表、<ruby> 拉取请求 <rp>  （ </rp> <rt>  pull request </rt> <rp>  ） </rp></ruby>等等。我们该选择哪个合适的来使用，我们又该如何做呢？


令人遗憾的是，项目本身往往不愿做出约束性的决定，而是选择“上述所有”。这就导致了一个支离破碎的社区：有些人使用 Slack/Mattermost/IRC，而有些人使用论坛，有些使用邮件列表，有些则存在于工单之中，很少有人能够读到所有这些途径的内容。


在我[帮助其建立内外部社区](http://www.jonobaconconsulting.com/)的组织中，这是一个常见的问题。我们会选择哪个渠道，以及出于什么目的？另外，何时可以对它们之一说不呢？


这就是我想在此处深度探讨的。


### 结构化和非结构化


我并不是个聪明人。因此，我倾向于将问题分成小的部分，这样我可以更好地理解它们。类似地，我倾向于将一个情景中各种选择拆解成更小的部分，来更好地理解它们的目的。我在沟通渠道的选择上也使用这种方法。


我认为有两大沟通渠道的分类：结构化和非结构化。


结构化渠道在每个单独的沟通单元中都有非常具体的重点。例子如：GitHub / GitLab /Jira 的<ruby> 工单 <rp>  （ </rp> <rt>  issue </rt> <rp>  ） </rp></ruby>。一个工单是与 bug 或功能有关的一个非常具体的信息。在初始的工单帖子发布之后引发的系列讨论中，通常非常集中在该特定话题上，并会有一个结果（比如 bugfix 或者一个功能的最终计划）。结果通常都反映在状态（例如 “FIXED”、“WONTFIX” 或 “INVALID”）中。这意味着你可以了解沟通的始末，而无需阅读中间的内容。


类似的，拉取/合并请求也是结构化的。它们集中在特定类型（通常是代码）的贡献上。在最初的拉取/合并请求后，讨论会非常集中在一个结果上：让贡献符合要求，且合并入代码库中。


另一个例子是 StackOverflow/AskBot 这类的问答帖子。这些帖子以一个问题开始，接着被编辑以及回复来提供对这个问题的精确答案。


通过这些结构化机制，通常几乎不会偏离其本来结构。你不会在工单、拉取请求或问答话题上看到有人问别人他们的孩子/猫/狗/家人在做什么。偏离话题在社区是不可接受的，这是结构化媒体的力量的一部分：它是集中和（通常）高效的。


反之，非结构化媒体包括聊天频道和论坛。在这些环境中，通常会有一个主题（例如频道或分论坛的主题），但是其中的会话与特定结果或结论的关系要小得多，而且通常情况下可能会更普遍。例如，在开发者邮件列表中，你会看到一系列讨论，包括一般问题、新功能的想法、架构争论以及与社区自身运营相关的讨论。每一个讨论都希望让参与者保持对话的焦点、主题和工作效率。但你可以想象，情况往往不是这样的, 这种讨论可能会偏离一个富有成效的结果。


### 记录的影响


除了结构化和非结构化沟通的微妙不同外，所记录的内容以及它们如何搜索的所带来的影响也很重要。


典型的，所有的结构化渠道都是记录的。人们可以参考以前的 bug，来自 StackOverflow 的问题可以被反复地重新利用。你可以搜索一些东西，即使有很多讨论、常见问题、拉取请求或者提问，都会被更新以反映最终结论。


这是一个重点：我们希望能够快速、轻松地挖掘旧问题/提问/拉取请求等，并链接到它们、引用它们。这里的一个关键部分是我们把这个内容转换成可以引用的材料，从而可以用来教育和告知人们以前的知识。随着社区的发展，我们的结构化沟通成为一种知识库，可以通过以往的经验来告知未来。


而非结构化沟通变得越来越糟。一方面，论坛的搜索通常都简单高效，但是它们当然充满了非结构化的对话，所以你正在寻找的东西可能被埋在讨论之中。例如，许多社区使用论坛作为支持工具。虽然这是一个更强大的平台，但是问题在于，一个问题的答案可能是在 16 楼或者 340 楼中有回复。随着越来越多的信息来源（比如 Twitter）的轰炸，我们越来越不耐烦地阅读大量的材料，这对于非结构化媒体来说可能是一个问题。


一个有趣的特定案例是实时聊天。历史上，很多年来，IRC 为实时聊天铺平了道路，对于大多数 IRC 用户而言很少有（如果有的话）记录这些讨论的念头。的确，一些项目（比如 Ubuntu）记录了 IRC 日志，但是这通常不是有用的资源。如我的伙伴 Atwood 有一次跟我说的：“如果你不得不在聊天中搜索一些东西时，你已经输了。”


虽然 IRC 在记录上有所不足，而 Slack 和 Mattermost 会好点。交流会被归档，但是问题仍旧存在：你为什么会想在海量的聊天信息中找出一个人提出的观点呢？其他的渠道能更好地引用先前的讨论。


不过，这的确创造了一个有趣的机会。聊天相比其他媒体有个一贯的好处是能体现这是个怎样的人。结构化的渠道，甚至非结构化的渠道，如论坛和邮件列表，很少鼓励闲聊。但聊天是的，聊天时你会问：“你周末怎么样？”、 “你见过这个游戏吗？”还有“你下周会看 Testament，Sepultura 和 Prong 吗？” （好吧，也许问最后一个问题的只有我。）


因此，虽然实时聊天相比前面的那些方式也许更低效一些，但是它的确增进了人们的关系。


### 你想喝点什么


因此，回到我们最初的对于开源社区的提问：我们要选择哪个？


虽然这个答案对于不同的项目会不同，但我想在两个层面思考。


首先，你通常应该优先考虑结构化沟通。这是完成有形工作的地方：问题/工单、拉取请求、问答讨论等等。如果你资源有限，那么专注在这些渠道上，你可以用较少的时间和金钱支出，获得社区的高效产出。


再者，如果你热衷于建立一个可以专注于工程、宣传、翻译、文档等方面的更广泛的社区，那么探究是否引入非结构化渠道就有意义了。 社区不仅仅是为了完成工作，也是为了建立关系和友谊，在工作中相互支持，帮助人们在社区中发展壮大。非结构化通信是一个有用的工具。


当然，我只是在一个大的话题上浅谈辄止。 不过我希望在如何评估和选择沟通渠道的价值方面，为大家提供了一些辨析。记住，少即是多：不要被拥有所有的渠道的妄想而诱惑，否则你会得到一个支离破碎社区，就像一个空荡荡的餐厅一样。


愿原力与你同在，请让我知道你进行的如何。你可以通过我的[网站](http://www.jonobacon.com/)和邮箱 [jono@jonobacon.com](mailto:jono@jonobacon.com) 联系到我。


（题图： Opensource.com）




---


作者简介：


Jono Bacon 是一名领先的社区管理者、演讲者、作者和播客。他是 Jono Bacon Consulting 的创始人，提供社区策略/执行、开发者工作流程和其他服务。他以前曾担任 GitHub、Canonical、XPRIZE、OpenAdvantage 的社区总监，并为很多组织曾经提供建议和咨询。




---


via: <https://opensource.com/article/17/5/much-ado-about-communication>


作者：[Jono Bacon](https://opensource.com/users/jonobacon) 译者：[geekpi](https://github.com/geekpi) 校对：[jasminepeng](https://github.com/jasminepeng)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
One of the first challenges an open source project faces is how to communicate among contributors. There are a plethora of options: forums, chat channels, issues, mailing lists, pull requests, and more. How do we choose which is the right medium to use and how do we do it right?

Sadly and all too often, projects shy away from making a disciplined decision and instead opt for "all of the above." This results in a fragmented community: Some people sit in Slack/Mattermost/IRC, some use the forum, some use mailing lists, some live in issues, and few read all of them.

This is a common issue I see in organizations I'm [working with to build their internal and external communities](http://www.jonobaconconsulting.com). Which of these channels do we choose and for which purposes? Also, when is it OK to say no to one of them?

This is what I want to dig into here.

## Structured and unstructured

I have a tiny, peanut-sized brain in my head. Because of this, I tend to break problems down into smaller pieces so I can better understand them. Likewise, I tend to break different options in a scenario down into smaller thematic pieces to better understand their purpose. I take this approach with communication channels too.

I believe there are two broad categories of communication channels: structured and unstructured.

Structured channels have a very specific focus in each individual unit of communication. An example here is a GitHub/GitLab/Jira issue. An issue is a very specific piece of information that relates to a bug or feature. The discussion that cascades after the initial issue post is typically very focused on that specific topic and finding an outcome (such as a bugfix or a final plan for a feature). The outcome is then typically reflected in a status (e.g. "FIXED," "WONTFIX," or "INVALID"). This means you can understand the beginning and end of the communication without reading the pieces in between.

Likewise, pull/merge requests are structured. They are focused on a specific type (typically code) of contribution. After the initial pull/merge request, the discussion is very focused on an outcome: getting the contribution in shape to merge into the wider codebase.

Another example here is a StackOverflow/AskBot style Q&A post. These posts start with a question and are then edited and responded to in order to provide a concise answer to the question.

With each of these structured mechanisms there usually is little deviation from the structure. You never see people asking others how their kids/cats/dogs/family are doing in an issue, pull request, or Q&A topic. It is socially unacceptable to veer off topic, and that is part of the power of a structured medium: It is focused and (usually) efficient.

The inverse, unstructured media, include chat channels and forums. In these environments there is typically a theme (such as the topic of a channel or sub-forum), but conversations are much less tied to a specific outcome or conclusion and can often be more general in nature. As an example, in a developer mailing list you will get a mix of discussions including general questions, ideas for new features, architectural challenges, and discussions that relate to the operational running of the community itself. With each of these discussions it is imperative on the participants to keep the conversation focused, on topic, and productive. As you can imagine, this is often not the case, and these kinds of discussions can veer away from a productive outcome.

## The impact of recording

Aside from the subtle differences between structured and unstructured communication, the impact of what is recorded and how it can be searched plays a large role too.

Typically, all structured channels are recorded. People reference old bugs, questions from StackOverflow are reused over and over again. You can search for something, and even if there is lots of discussion, the issue, pull request, or question is usually updated to reflect the ultimate conclusion.

This is part of the point: We want to be able to quickly and easily dig up old issues/questions/pull requests/etc., link to them, and reference them. A key component here is that we convert this content into referenceable material that can be used to educate and inform people about previous knowledge. As our community grows, our structured communication becomes a corpus of knowledge that can inform the future from lessons in the past.

This gets murkier with unstructured communication. On one hand, forums are generally simple and effective to search, but they are of course filled with unstructured conversation, so the thing you are looking for might be buried inside a discussion. As an example, many communities use a forum as a support tool. While this is a more than capable platform, the problem is that the answer to a question may be response #16 or response #340 in a discussion. As we are bombarded with more and more sources of information (and in smaller pieces, such as Twitter), we have become increasingly impatient to reading through large swaths of material, and this can be problematic with an unstructured medium.

A particularly interesting case is real-time chat. Historically, IRC has paved the way for real-time chat for many years, and for most IRC users there was little (if any) notion of recording those discussions. Sure, some projects (such as Ubuntu) record IRC logs, but this is generally not a useful resource. As my pal Jeff Atwood said to me once: "If you have to search chat for something, you have already lost."

While IRC is limited in recording, Slack and Mattermost are better. Conversations are archived, but the point still typically stands: Why would you want to search through large bodies of conversation to find a point that someone made? Other channels are far better for referencing previous discussions.

This does create an interesting opportunity though. One consistent benefit that chat exhibits over all other media is how human it is. Structured channels, and even unstructured channels such as forums and mailing lists, rarely encourage off-the-cuff social discussion. Chat does. Chat is where you ask: "How was your weekend?" "Did you see the game?" and "Are you going to see Testament, Sepultura, and Prong next week?" (OK, maybe the last one is just me.)

So, while real-time discussion may be less effective in our corpus of previous collaboration, it does provide a vital glue in shaping relationships.

## Choose your poison

So, back to our original question for open source communities: Which of these do we pick?

While this answer will vary from project to project, I tend to think of this on two levels.

First, you should generally prioritize structured communication. This is where tangible work gets done: in bugs/issues, pull requests, in support Q&A discussions, etc. If you are tight on resources, focus your efforts on these channels: You can more easily draw a dotted line between the investment of time and money there and productive output in the community.

Second, if you are passionate about building a broader community that can focus on engineering, advocacy, translations, documentation, and more, explore whether bringing in unstructured channels makes sense. Community is not just about getting stuff done, it is also about building relationships and friendships, providing support to each other in our work, and helping people grow and flourish in our communities. Unstructured communication is a helpful tool in this.

Of course, I am merely scratching the surface of a large topic here, but I hope this provides a little clarity in how to assess and choose the value of communication channels. Remember, less is more here: Don't be tempted to defer the decision and provide all of the above; you will get a fragmented community that's just about as inviting as an empty restaurant.

May the force be with you, and be sure to let me know how you get on. I am always available through my [website](http://www.jonobacon.com) and at [jono@jonobacon.com](mailto:jono@jonobacon.com).

## Comments are closed.