在上一篇文章中，我们介绍了描述当前社区的指标，以及一些可能导致这些指标的原因。在这篇文章中，我将阐述我关于如何解决这些问题的观点。

(如果您更喜欢以视频形式观看，可以观看Ansible 社区峰会上的录制视频，其中我详细介绍了其中许多要点)

社区作为“邻里”

让我从一个比喻开始，试图说明我认为我们社区中缺少什么。对于许多人来说，“社区”一词会让人联想到一个地方——也许是一个村庄或小镇——它致力于改善人们居住的地方。这通常看起来像这样（至少在我居住的英国是这样：P）

大多数居民都会同意改善社区是值得做的——但他们可能并不都认同如何改善。这通常没有问题，因为人们可以专注于自己的领域（您可能负责组织维护道路等；我将为新的运动场筹集资金），因此我们可以为整个社区完成很多事情。任务非常明确，只有在存在做某事的机会成本时才会重要。
很明显（无论如何，在大多数国家/地区），房子内部发生的事情在很大程度上是他们自己的事情。只要他们没有播放过大的音乐或纵火烧邻居的围栏，一切都好。没有人希望在那种程度上进行监管（而且在很大程度上也无法实现）。
但是，如果一户人家开始对周围的人产生影响，那么就会有一些方法来制裁这些人（法律手段，是的，还有通常更有效的社会契约），并将他们重新纳入正轨。
同样，虽然有时整个区域会同时规划，但开发通常更有机性，因为人们购买土地并在其上建造房屋。中央计划者并非必需（但有时存在）。
他们将拥有与感兴趣的居民沟通的方式——至关重要的是，即使是那些目前可能不活跃的人。在过去，这将是镇上的公告板或类似的东西（实际上，在我的村庄里仍然如此），但今天它也可能是消息聊天室或社交网站群组。
将有一种方法可以讨论社区感兴趣的事情——问题、即将举行的活动、地方政府选举等。通常，这是一个镇政厅或类似的场所，在那里定期举行会议。

这个比喻实际上对我们也很适用。如果我们将每个项目和工作组视为“房屋”，形成一个“邻里”，即整个 Ansible 社区，那么一些结论自然而然地就会出现。

首先，我们有一个使命，虽然现在可能是完善它的好时机，但我们普遍同意自动化是我们的目标。其次，“房屋”（项目）确实在很大程度上是独立的，例如 DevTools 不会告诉 AWX 如何运行他们的“房屋”。事实上，大多数项目都相处得很好。

有趣的是项目之间的沟通（如果可以这样说，房屋之间）。目前，在我看来，完全按照自己的方式行事所产生的“社会成本”并不特别高，这导致了各种各样的行为。这在房子/项目内部是可以的，但当它导致整个邻里出现困难时就不行了。

关于缺乏中央计划者，这很好——但所有村庄都需要电力、水、连接等。这通常是监管机构的工作，值得探讨这种区别，可能在以后的文章中。

但是，正是最后两点对这篇文章至关重要，因为它们直接关系到我认为我们今天可以改进 Ansible 社区的两种方式——因为“公告板”是一个网站，而“镇政厅”是一个论坛。

网站、品牌和过载

让我们从我们邻里的“公告板”开始。正如我们已经指出的，没有一个单一的联络点可以了解今天 Ansible 正在发生的事情。我们没有办法让社区撰写关于有趣的事情的文章，或者宣布新的项目等。我们有ansible-announce，但邮件列表的流量并不多。我们有 Bullhorn，但它有多广为人知呢？

实际上，问题的一部分在于“Ansible”一词意味着很多东西，“ansible.com”无法满足所有这些需求。它可能意味着

我们编写剧本的语言
提供该语言的基本软件包
包含集合的完整软件包
更广泛的社区/项目
Red Hat 产品

最后两个是最大的问题。今天，ansible.com 是 Red Hat 的产品网站——这不是批评，而是一个事实。但是，因此，这些页面是产品页面，博客是产品博客，依此类推。简单地将其开放给社区进行编辑是不对的，因为它不是我们正在谈论的同一个 Ansible。

解决此问题的唯一方法是将含义分开。有人可能会争辩说“Ansible”一词属于社区，而该产品应该迁移到另一个网站。这并没有错，但商业系统发展缓慢，我相信我们需要更快地解决这个问题。对于新社区成员缺乏关注点以及现有成员缺乏发言权，正在损害我们。

上游项目通常有自己的名称和网络存在。因此，我建议我们创建一个新的短文本（1-3 个单词）来减少过载。我们可以对此进行讨论，但“Ansible 社区”目前似乎是一个不错的占位符。然后，我们使用它来查看可能的新 DNS 域名（例如，ansible.community 可供我们使用），然后我们可以查看设置新网站。我已经获得了 Red Hat 内部对此的批准，因此一旦社区批准，我们就可以立即开始。

在功能方面，至少从一开始，我看到了一个相当标准的设置——GitHub 仓库、静态网站生成器、为贡献者途径、活动、通信等准备的相应页面。显然还有一个博客部分。这一切都很简单，而且是标准做法，我们只需要去做。

当然，让网站公开并开放协作对于改进我上次描述的那些原则至关重要。此外，我无法预见我们将对此有哪些用例。显而易见的事情是创建一个新的工作组来监督构建它，这也会在我的提案中。

总结

社区的新短文本（以减少“Ansible”的过载）
托管社区项目的新 DNS 属性
新网站
新工作组

论坛、碎片化和文化

现在进入更长、更棘手的部分。我非常清楚，并非每个人都喜欢论坛，所以让我做一件罕见的事情，并使用人身攻击。我真的相信这会奏效——事实上，我已经为多个其他社区做过这件事，并且它确实奏效了。如果您对此感到不确定，请给它一个机会。

迄今为止，在所有这些帖子中、在我内部的讨论中、与社区的讨论中、我看到的所有地方，最大的主题都是碎片化。我们今天看到的大部分内容至少部分归因于我们没有一个共同的地方来弄清楚事情，或者让新人提出问题。我们需要解决这个问题。

为了清楚起见，我建议使用Discourse 作为软件，因为它是我见过的迄今为止最好的实现。我无法指出任何“杀手级功能”来说明原因——它只是充满了数百个提高生活质量的功能，即使在使用 5 年以上后，它仍然让我感到惊讶。我认为它被Python、Fedora、Mozilla、Ubuntu、Nextcloud、Pulp、LetsEncypt、Sailfish……等等使用并非偶然。它已成为异步讨论的事实标准。

与其尝试列出功能，我将概述 Discourse 可以帮助解决的一些问题（这并不详尽），然后我会解决我认为将会出现的一些批评。

新一代用户，以及现有用户

近 2 年前，我主张在我们的社区中包含 Matrix（数据显示这对我们的聊天空间来说是一件好事）。我这样做的理由是，我们需要接触下一代用户和贡献者。这个问题不仅仅存在于聊天中。

从轶事上讲，我听到过诸如“如果我想注册邮件列表，我不知道如何注册”、“邮件列表是时事通讯”、“注册意味着网络，我如何通过网络注册邮件列表？”等等评论。我们需要在他们今天所处的位置与他们会面。Discourse 支持基本的电子邮件注册，但也支持通过 GitHub、Google、Facebook、Discord、Twitter 和其他 SSO 系统登录——至少我们会提供 GitHub。

现有用户也不会被遗忘，因为您可以通过邮件与 Discourse 进行交互——除了更新您的地址簿以用于启动新主题的电子邮件外，几乎没有变化。

满足支持需求

我们已经看到向 StackOverflow (SO) 等地方迁移以寻求支持问题。我们知道 #users:ansible.com (#ansible) 房间很繁忙。有一个非官方的 Discord 拥有许多用户，以及多个其他 Slack 实例。帮助人们的需求并不少。

但是，正如 SO 所示，有时长篇幅的较慢回复比聊天室更有用。聊天室取决于正确的人在线，并且问题通常并不紧急（粘贴板也较少成为问题）。我认为缺乏一个通用的社区网站/DNS 阻止了我们之前创建此功能，因此人们去了他们可以去的地方（例如 SO）。

我们可以更好地帮助我们的用户，并在其周围构建一个专门的支持社区。使用 Solved 插件可以为我们提供类似于 SO 的行为，但在我们可以集成和指向社区和项目的其他部分的地方。适当使用标签/组可以真正帮助吸引合适的人参与，而不会压倒个人。

所有社区部分都需要支持之类的东西。今天，帮助其他用户的知识渊博的人分散在太多地方，这会稀释这些知识。我很想看到一个自我支持的用户社区，并且我看到确实有这样一群人（a）在其他项目的论坛中，以及（b）在我们自己的聊天室、SO 和其他地方，这给了我希望。

成为以异步为先

同步会议会排除一些声音 - 既因为时区差异，也因为一些话少的成员可能不太愿意开口。还有英语作为第二语言的人可能会遇到困难，这既是因为语速可能太快难以跟上，也因为在使用翻译系统时聊天功能可能难以使用。异步优先意味着我们可以获得尽可能好的讨论，但代价是速度 - 我认为这是一个值得的权衡，因为我们本来就不倾向于快速行动，而且如果我们想要充分利用集体智慧（例如，有些人可能正在度假！），可能也不应该快速行动。

我们之前提到过一个领域是跨项目讨论，我认为论坛可以极大地促进这一点。拥有一个讨论架构、未来计划、解决问题方法等的地方是必要的，但这里真正闪光的是能够通过真正跨越整个社区范围的组和标签（不像 GitHub 上那样）来包含合适的人。

我与一些内部人员进行了交谈，他们对将更多内部架构讨论上移到公开平台表示支持。这将是一个完美的起点，而不是再创建一个没人能找到的 GitHub 仓库。

可发现性和归档

邮件列表存在许多问题，但这里我将重点关注两个。首先，它们设置了较高的门槛 - 用户通常不会订阅开发者列表，即使他们可能对某个特定的技术讨论有有效的意见。这是一个直接的损失（参见上一篇文章中的集体智慧）。其次，很难让人们订阅新的列表，也很难在以后停用它们。

这转化为工作组的一个特殊问题。启动一个新的工作组成本很高，因为人们不知道要订阅，然后当工作组完成时，你就会有一个旧的列表闲置在那里。

将其与论坛进行对比。新的类别是免费的，并且可以重新组织（并且 URL 不会失效）。因此，创建 #working-groups/website 基本上是免费的，并且对所有拥有论坛帐户的人（无需重新注册）立即可见，之后可以移动到

working-groups/inactive/website。事实上，如果它将来再次活跃

，它可以被移回。当然，新的类别也可以被赋予传入的电子邮件地址，以充当电子邮件列表。更容易维护，并且参与度更高。

类别还可以有自己的规则，例如使用点赞或标记为已解决，允许每个子社区根据需要行事，同时保持整体的一致性。

项目记录

现在，在我的磁盘上有一个来自 ansible-project 的 75k 封电子邮件的存档。我能够从 Google Groups 中获取这些邮件的唯一原因是我有个人联系 - Google Takeout 坏了（参见 https://support.google.com/groups/thread/181378162?hl=en ，该问题尚未得到答复）。Google 一再证明 Groups 缺乏维护（例如，看看搜索中反复出现的问题，这些问题已经持续数年了，有些问题仍然存在），我担心如果/当 Google 决定停止使用它时，我们会丢失我们历史的存档。这非常非常非常接近于供应商锁定。

类似地，我们使用 Zodbot 进行聊天会议。虽然我希望看到更多这样的内容转向异步（见上文）；但目前，它还在进行，并且日志会发送到 fedoraproject.org（尽管之后通常会复制到 GitHub）。同样，我们不拥有它，虽然我比 Google 更信任 Fedora，但这仍然不是理想的选择。

所有这些都可以导入到 Discourse，我们还可以导入其他内容，例如会议记录和 GitHub 讨论。就像我之前在 Matrix 中论证的那样，我们应该拥有自己的项目，拥有新的 DNS 为我们提供了这样的机会。我希望在 5 年后，我能够在我们社区的网站上阅读这些类型的讨论。

此外，诸如更好的搜索、标签、写作时“类似帖子”建议等功能也使人们更容易使用该记录。但这些功能都依赖于内容，因此如果我们将我们的内容整合在一起，效果会更好。

组

组在 Discourse 中拥有巨大的力量，体现在两个层面。公共组可以在帖子中被 @提及，该组中的成员会收到通知。组也可以对新加入者开放，或仅限邀请，因此对于基于兴趣的组（例如 @edge），我们可以允许任何人添加自己并获得通知 - 但我们可以限制对其他人的访问（例如 @core）并确保合适的人员在其中。

这缓解了倦怠/围攻问题，在这种问题中，乐于助人的人回答了用户的问题，然后开始被越来越多的人直接寻求帮助。通过标记一个组，他们可以收到通知，同时我们避免在帖子中点名，从而避免倦怠。对于流量较大的用户，加入合适的组并订阅合适的标签应该可以将流量控制在必要的范围内（并且更容易从 GitHub 流量洪流中过滤掉，因为它是一个不同的域名）。

信任与权力下放

Discourse 具有几个功能，可以提高我们在无需社区团队付出太多努力的情况下扩展的能力，这直接体现了权力下放的目标。

信任等级是自动的（大部分），几乎任何操作都可以与之关联。例如，为了防止垃圾邮件，用户必须达到 1 级（大约需要 10 分钟）才能使用电子邮件回复主题。但这远不止于此，例如，你可以创建一个包含所有社区活动（会议、公开演示、会议）的日历类别，并且任何信任等级为 2 级及以上的人员都可以自由创建活动，无需设置门槛。这对我们有很多应用。

最后，私人群体可以用来权力下放。一个组可以有一个传入的电子邮件地址，绕过上面列出的垃圾邮件过滤器。这意味着你可以使用一个组来，比如，注册托管或社交媒体，并且该组的成员将拥有重置密码等的权限。甚至隐私、安全和行为准则也可以放在这里，并且组的成员资格可以根据需要更新。同样，组可以用来实现基础设施支持的民主化等等。

可访问性

我认为这里有很多小的胜利。首先是缺点 - 确实，邮件列表天生就对屏幕阅读器友好，因为它们是纯文本，而网络界面可能不那么友好。但是，你可以通过邮件与 Discourse 进行交互，我相信网络视图的屏幕阅读器兼容性现在已经很好了（我不使用，但如果有人使用，请在 meta.discourse.org 上测试，因为它是最新的，并告诉我）。

从好的方面来说，它有完整的键盘操作支持，我们可以更容易地更好地支持其他语言（每个类别一个？就像上面讨论的那样，它们很容易创建），我们可以编写修改 CSS/主题，并且我们将提供一个有效的访问内容的集中位置 - 虽然邮件列表可能与屏幕阅读器一起工作，但 GitHub 能做到吗？ansible.com 能做到吗？尝试找到合适的参与场所呢？

因为我不需要可访问性，所以我不知道还需要什么，但我乐于学习，请告诉我。

集成/插件

现代论坛软件是基于网络的，这意味着它可以更容易地与其他服务集成。链接到 GitHub、Webhook 集成、单点登录、为博客提供评论（是的，你可以在 Bullhorn 上发表评论），这个列表还在继续。例如，我们可以通过它管理活动的注册，或整合会议议程。我也在探索 Discourse 和 Matrix 之间的 Webhook。

插件也是一个重要功能，并且通常可以按类别启用。我一开始就会使用的一些流行功能是标记解决方案、事件和日历，以及可能对问题和翻译进行点赞。有关更多想法，请参见 https://meta.discourse.org/c/plugin/22。

关于论坛的担忧

我知道论坛不是每个人的最爱，我预计会有一些担忧。许多担忧都是有效的，并且是我认为值得权衡的一部分，而另一些我可以反驳，所以让我们来看看。

我喜欢现状

我不能否认这会带来一些变化 - 我只能希望我的数据和论点已经说服了你，它值得付出努力，我们必须做出改变。

我永远不会告诉人们使用什么工具（在 Matrix 中我也没有），并且我们会尽力与现有的工作流程兼容（上次是 IRC 桥接，这次是 Discourse 支持电子邮件工作流程）。但我们也必须问一下什么对整个社区是正确的，即使这意味着我们中的一些人需要做出一些改变。

论坛很老旧

它们确实存在了一段时间，我不怪任何 10 年前使用过论坛而留下阴影的人 - 我也有过。但在 Discourse 网站上花点时间，我希望你会感到惊讶。这么多项目使用它并非偶然。

论坛难以维护

维护确实是一个真正的担忧，体现在两个方面。

首先，代码/服务器需要存在并保持更新 - 但在这里我们可以利用社区团队有一些预算的事实。就像我们为 Matrix 的 Matrix 服务器提供资金一样，我们可以为论坛提供资金。为另一个开源公司的项目付费感觉也很好，我们应该互相支持。

更重要的是，我们需要主持人来运营它。一开始，这将必然是由构建它的人员（即 Red Hat Ansible 社区团队）来完成，但我们将寻求从社区中培养这群人。这些人已经在聊天、SO 等方面做了很多好工作 - 但对这些努力的认可/奖励很难获得，我认为这可以使它变得更容易。

我们应该标准化 GitHub

这有点像 XKCD 标准，不是吗？我同意 GitHub 对于讨论来说并不是一个糟糕的地方 - 肯定比邮件列表好。但是，我想从几个方面来反驳这一点。

首先，碎片化在 GitHub 上最严重（470 多个仓库，而且还在增加）。我们是否选择一个仓库并以某种方式将其视为特殊？如果我们这样做，它是否拥有足够丰富的工具来应对项目的规模？我们上次尝试时并没有成功 - 我们不得不在 2020 年将所有内容从 ansible/ansible 中移出。

我们可能也不希望在那个假设的特殊仓库中进行用户支持 - 将 GitHub Issues 用于实际问题并在专门的地方提供支持似乎是值得的。如果社区的大部分用户将在那里获得支持，难道我们不应该更多地利用它吗？

GitHub 也不支持跨组织的 @组，因此，除非我们想要承担很多额外工作（复制组），否则以这种方式让合适的人参与讨论将变得更加困难。

总的来说，Discourse 周围的工具对于讨论、支持和组来说更好 - 而且它是我们的。如果需要，我们可以开发插件来提供其他功能 - 对于按服务付费的平台来说，这永远不可能。

这是另一个检查的地方

我无法缓解这种情况，这是事实。但是，我预计通知垃圾邮件的总量应该会减少（除非你选择订阅所有内容，当然）。Discourse 可以通过网络、移动设备或电子邮件使用，并且您可以设置复杂的过滤器级别以获取所需的内容。此外，它来自我们自己的域名，并带有不错的标头，因此您也可以通过这种方式进行过滤。哦，您还可以设置工作时间，这样它就不会在不合适的时间向您发送垃圾邮件 - 很方便！

邮件列表/GitHub讨论/其他异步位置会发生什么情况

目前还没有。我不会粉饰太平——如果目标是减少碎片化，那么它们将需要得到处理（存档和导入，这在 Discourse 中完全有可能）。该时间表可以在我们前进的过程中设定，社区的每个部分都可以根据自己的舒适程度快速移动。但是，我希望看到社区中的大部分成员很快采用这种方式——我正在寻找志愿者 :)

总结

社区的新论坛
承载项目范围内的讨论
承载支持问题
其他异步讨论场所将逐步迁移

现在怎么办？

文字很多，所以让我快速回顾一下

指标不好
我们存在可能导致这种情况的结构性问题
我们需要解决我们的碎片化和缺乏共同声音的问题
我们应该使用新的网站和论坛来做到这一点

希望我已经说服了你，我们需要拥有自己的虚拟空间，在其中设置新事物，并尽快让尽可能多的社区成员迁移到它。但也许你有一些问题？当然，你会有，群众有智慧。

因此，伴随这些帖子将在 GitHub 中发布两个讨论主题（因为我们还没有论坛！）。它们是

请去告诉我你的想法！我故意没有在这里包含推出计划（请放心，草案已经存在），因为这已经够长了。一旦我们达成目标，我们可以在我们的工作组中制定出这些计划。

评论区见！