很多事不是坚持了

开源项目面临的首要挑战之一是如何在贡献者之间进行交流。 有很多选项：论坛，聊天频道，问题，邮件列表，请求请求等。 我们如何选择哪种才是正确的媒介，如何正确选择呢？

可悲的是，很多时候，项目都回避做出有条理的决定，而是选择“以上所有”。 这导致了一个分散的社区：一些人坐在Slack / Mattermost / IRC中，一些人使用论坛，一些人使用邮件列表，一些人生活在问题中，很少人阅读全部内容。

在我组织中，这是一个常见的问题。 我们选择这些渠道中的哪一个以及用于哪个目的？ 另外，什么时候可以对其中一个人说不？

这就是我要在这里深入探讨的。

结构化和非结构化

我的脑袋里有一个花生大小的小脑袋。 因此，我倾向于将问题分解为较小的部分，以便更好地理解它们。 同样，我倾向于将方案中的不同选项分解为较小的主题，以更好地理解其目的。 我也通过通讯渠道采用这种方法。

我相信有两种广泛的沟通渠道：结构化和非结构化。

结构化渠道在每个单独的通信单元中都有非常具体的重点。 这里的一个例子是GitHub / GitLab / Jira问题。 问题是与错误或功能相关的非常具体的信息。 在最初的问题发布之后进行的讨论通常非常集中于该特定主题并找到结果（例如错误修正或功能的最终计划）。 然后通常将结果反映在状态（例如“已修复”，“ WONTFIX”或“无效”）中。 这意味着您可以了解通信的开始和结束而无需阅读中间的内容。

同样，拉/合并请求是结构化的。 他们专注于特定类型的贡献（通常是代码）。 在最初的请求/合并请求之后，讨论的焦点非常集中在一个结果上：将形式上的贡献合并到更广泛的代码库中。

这里的另一个示例是StackOverflow / AskBot样式的问答环节。 这些帖子以问题开头，然后进行编辑和回复，以提供对问题的简洁答案。

对于这些结构化机制中的每一个，通常与结构之间几乎没有偏差。 您永远不会看到有人问别人在问题，请求请求或问答主题中他们的孩子/猫/狗/家人的状况如何。 偏离主题在社会上是不可接受的，这是结构化媒体的力量的一部分：它专注并且（通常）高效。

相反的非结构化媒体包括聊天频道和论坛。 在这些环境中，通常会有一个主题（例如频道或子论坛的主题），但是对话与特定结果或结论的联系要少得多，并且本质上通常可以更笼统。 例如，在开发人员邮件列表中，您将获得包括一般性问题，有关新功能的想法，体系结构挑战以及与社区本身的运营相关的讨论的混合讨论。 在进行这些讨论时，参与者必须保持对话的重点，主题和富有成效。 可以想象，情况通常并非如此，而这类讨论可能会偏离有效的结果。

录音的影响

除了结构化和非结构化通信之间的细微差别外，记录内容和如何搜索它的影响也起着很大的作用。

通常，记录所有结构化通道。 人们引用了旧的错误，而StackOverflow的问题又一次又一次地被重用。 您可以搜索某些内容，即使有很多讨论，问题，请求请求或问题通常也会进行更新以反映最终结论。

这是要点的一部分：我们希望能够快速，轻松地挖掘出旧问题/问题/拉动请求/等，链接到它们并引用它们。 这里的关键组成部分是我们将这些内容转换为可参考的材料，可用于教育人们并了解以前的知识。 随着社区的发展，我们的结构化交流成为知识的主体，可以从过去的经验教训中汲取教训。

非结构化的交流会更加模糊。 一方面，论坛通常很简单且有效地进行搜索，但是它们当然充满了非结构化的对话，因此，您要查找的内容可能会隐藏在讨论中。 例如，许多社区都使用论坛作为支持工具。 尽管这是一个功能强大的平台，但问题在于，对问题的答案可能是讨论中的响应16或响应340。 随着我们受到越来越多的信息资源（以及诸如Twitter之类的小片段）的轰炸，我们变得越来越不耐烦地阅读大量的材料，这对于非结构化的媒体可能会造成问题。

一个特别有趣的案例是实时聊天。 从历史上看，IRC多年来为实时聊天铺平了道路，对于大多数IRC用户而言，几乎没有（如果有的话）记录这些讨论的想法。 当然，有些项目（例如Ubuntu）记录了IRC日志，但这通常不是有用的资源。 正如我的朋友杰夫·阿特伍德（Jeff Atwood）一次对我说的那样：“如果您必须搜索聊天内容，那么您已经迷路了。”

尽管IRC的录制受到限制，但Slack和Mattermost更好。 对话已存档，但重点通常仍然存在：您为什么要在大型对话中进行搜索以找到某人提出的观点？ 其他渠道对于参考先前的讨论要好得多。

但这确实创造了一个有趣的机会。 聊天比其他所有媒体展现出的一贯优势是人性化。 结构化的渠道，甚至论坛和邮件列表之类的非结构化渠道，也很少鼓励现成的社交讨论。 聊天。 聊天是您问的地方：“您周末过得怎么样？” “你看到比赛了吗？” 和“下周要去见约，塞普图拉和Pro吗？” （好的，也许最后一个就是我。）

因此，尽管实时讨论在我们之前的协作中可能不太有效，但它确实为塑造人际关系提供了至关重要的粘合剂。

选择你的毒药

那么，回到开源社区的原始问题：我们从中选择哪些？

虽然这个答案因项目而异，但我倾向于从两个层面来思考。

首先，通常应该优先安排结构化通信。 这是完成切实工作的地方：在bug /问题，请求请求，支持Q＆A讨论等方面。如果资源紧张，则将精力集中在这些渠道上：您可以更轻松地在时间投入之间划出一条虚线那里的钱和社区的生产性产出。

其次，如果您热衷于建立一个更广泛的社区，专注于工程，宣传，翻译，文档等等，那么请探讨引入非结构化渠道是否有意义。 社区不仅仅是完成工作，还在于建立关系和友谊，在我们的工作中互相支持，以及帮助人们在社区中成长和繁荣。 在这种情况下，非结构化通信是一个有用的工具。

当然，我只是在这里划掉一个大话题的表面，但是我希望这在如何评估和选择交流渠道的价值方面提供了一些清晰度。 请记住，这里少了更多：不要试图推迟决定并提供以上所有内容； 您会得到一个零散的社区，就像空荡荡的餐厅一样诱人。

愿力量与您同在，并确保让我知道您的生活。 我总是可以通过我的和与我 。

翻译自:

很多事不是坚持了