---
author: Jono Bacon
category: 观点
comments_data:
- date: '2017-06-22 17:55:45'
  message: 国内社区的发展不如国外。
  postip: 14.130.112.10
  username: 小刀弯弯 [Firefox 31.0|GNU/Linux]
- date: '2017-06-22 18:19:14'
  message: 主要是用户群体少？
  postip: 223.149.244.64
  username: GHLandy [Chrome 59.0|GNU/Linux]
count:
  commentnum: 2
  favtimes: 0
  likes: 0
  sharetimes: 0
  viewnum: 2974
date: '2017-06-22 10:17:01'
editorchoice: false
excerpt: 开源项目的首要挑战是找出最佳的贡献者协作方式
fromurl: https://opensource.com/article/17/5/much-ado-about-communication
id: 8627
islctt: true
largepic: /images/p/201706/22/101703gt8juoeudnto3uuo.png
permalink: /article-8627-1.html
pic: /images/p/201706/22/101703gt8juoeudnto3uuo.png.thumb.jpg
related: []
reviewer: ''
selector: ''
summary: 开源项目的首要挑战是找出最佳的贡献者协作方式
tags:
- 开源
- 沟通
thumb: false
title: 关于开源项目如何选择沟通渠道的思考
titlepic: true
translator: geekpi
updated: '2017-06-22 10:17:01'
---


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


![Much ado about communication](/images/p/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/) 荣誉推出