开源项目面临的首要挑战之一是如何在贡献者之间进行沟通。 有大量的选项：论坛、聊天频道、问题、邮件列表、拉取请求等等。 我们如何选择正确的媒介，以及如何正确地使用它？
可悲的是，而且太常见了，项目往往避开做出有纪律的决策，而是选择“以上所有”。 这导致社区的分裂：有些人待在 Slack/Mattermost/IRC 中，有些人使用论坛，有些人使用邮件列表，有些人住在问题跟踪系统中，而很少有人阅读所有这些渠道。
这是我在与 我正在合作构建其内部和外部社区 的组织中看到的常见问题。 我们应该选择哪些渠道，以及用于哪些目的？ 此外，什么时候可以对其中一个渠道说不？
这就是我想要在这里深入探讨的内容。
结构化和非结构化
我的脑袋里有一个花生大小的微型大脑。 因此，我倾向于将问题分解成更小的部分，以便更好地理解它们。 同样，我倾向于将场景中的不同选项分解成更小的主题部分，以便更好地理解其目的。 我也对沟通渠道采取这种方法。
我认为沟通渠道可以分为两大类：结构化和非结构化。
结构化渠道在每个独立的沟通单元中都有非常具体的重点。 这里的一个例子是 GitHub/GitLab/Jira 问题。 问题是非常具体的信息，与错误或功能相关。 初始问题帖子之后级联的讨论通常非常关注该特定主题，并寻找结果（例如错误修复或功能的最终计划）。 然后，结果通常反映在状态中（例如“已修复”、“不会修复”或“无效”）。 这意味着您可以理解沟通的开始和结束，而无需阅读中间的部分。
同样，拉取/合并请求也是结构化的。 它们专注于特定类型（通常是代码）的贡献。 在初始拉取/合并请求之后，讨论非常关注一个结果：使贡献物成形，以便合并到更广泛的代码库中。
这里的另一个例子是 StackOverflow/AskBot 风格的问答帖子。 这些帖子以问题开始，然后进行编辑和回复，以便为问题提供简洁的答案。
对于这些结构化机制中的每一个，通常很少偏离结构。 您永远不会看到人们在问题、拉取请求或问答主题中询问其他人他们的孩子/猫/狗/家人怎么样。 偏离主题在社交上是不可接受的，这是结构化媒介力量的一部分：它专注于（通常）高效。
相反，非结构化媒体包括聊天频道和论坛。 在这些环境中，通常有一个主题（例如频道或子论坛的主题），但对话与特定结果或结论的关联性要小得多，并且通常本质上更通用。 例如，在开发者邮件列表中，您会看到各种讨论，包括一般性问题、新功能的想法、架构挑战以及与社区自身运营相关的讨论。 对于所有这些讨论，参与者都必须保持对话的重点、主题和富有成效。 正如您可以想象的那样，情况往往并非如此，这些类型的讨论可能会偏离富有成效的结果。
记录的影响
除了结构化和非结构化沟通之间的细微差异之外，记录的内容以及如何搜索它也起着重要作用。
通常，所有结构化渠道都会被记录下来。 人们引用旧错误，StackOverflow 中的问题被一遍又一遍地重复使用。 您可以搜索某些内容，即使有很多讨论，问题、拉取请求或问题通常也会更新以反映最终结论。
这是重点的一部分：我们希望能够快速轻松地挖掘出旧的问题/问题/拉取请求等，链接到它们并引用它们。 这里的关键组成部分是我们将此内容转换为可参考的材料，可用于教育和告知人们以前的知识。 随着我们社区的成长，我们的结构化沟通变成了一个知识语料库，可以从过去的经验中为未来提供信息。
对于非结构化沟通，情况变得更加模糊。 一方面，论坛通常简单有效且易于搜索，但它们当然充满了非结构化对话，因此您要查找的内容可能被埋藏在讨论中。 例如，许多社区使用论坛作为支持工具。 虽然这是一个非常称职的平台，但问题是问题的答案可能是讨论中的第 16 个回复或第 340 个回复。 随着我们受到越来越多的信息来源（以及更小的片段，例如 Twitter）的轰炸，我们变得越来越不耐烦阅读大量材料，这对于非结构化媒介来说可能是个问题。
一个特别有趣的案例是实时聊天。 从历史上看，IRC 多年来为实时聊天铺平了道路，对于大多数 IRC 用户来说，很少（如果有的话）有记录这些讨论的概念。 当然，一些项目（例如 Ubuntu）记录 IRC 日志，但这通常不是有用的资源。 正如我的朋友 Jeff Atwood 曾经对我说过：“如果你必须在聊天中搜索某些东西，那么你已经输了。”
虽然 IRC 在记录方面受到限制，但 Slack 和 Mattermost 更好。 对话被存档，但观点仍然通常成立：你为什么要搜索大量的对话来找到某人提出的观点？ 其他渠道更适合引用以前的讨论。
但这确实创造了一个有趣的机会。 聊天在所有其他媒体中表现出的一致优势是它的人性化程度。 结构化渠道，甚至非结构化渠道（如论坛和邮件列表）也很少鼓励即兴的社交讨论。 聊天可以。 聊天是您可以问：“你的周末怎么样？”、“你看比赛了吗？”以及“你下周要去看 Testament、Sepultura 和 Prong 吗？”的地方（好吧，也许最后一个只有我）。
因此，虽然实时讨论在我们的先前协作语料库中可能不太有效，但它确实为塑造关系提供了重要的粘合剂。
选择你的毒药
那么，回到我们最初针对开源社区的问题：我们应该选择哪些？
虽然这个答案会因项目而异，但我倾向于从两个层面来考虑这个问题。
首先，您通常应该优先考虑结构化沟通。 这是完成实际工作的地方：在错误/问题、拉取请求、支持问答讨论等中。 如果您的资源紧张，请将精力集中在这些渠道上：您可以更轻松地在时间和金钱的投入与社区的生产性产出之间划出虚线。
其次，如果您热衷于建立一个可以专注于工程、宣传、翻译、文档等更广泛的社区，请探索引入非结构化渠道是否有意义。 社区不仅仅是完成工作，还包括建立关系和友谊，在我们的工作中互相支持，以及帮助人们在我们的社区中成长和蓬勃发展。 非结构化沟通在这方面是一个有用的工具。
当然，我在这里仅仅触及了一个大话题的表面，但我希望这能为如何评估和选择沟通渠道的价值提供一点清晰度。 请记住，少即是多：不要试图推迟决定并提供以上所有渠道； 您将得到一个支离破碎的社区，它就像一家空荡荡的餐厅一样不吸引人。
愿原力与你同在，并务必让我知道你的进展。 我始终可以通过我的 网站 和 jono@jonobacon.com 与我联系。
评论已关闭。