管理对新手友好的开源社区的 3 个步骤

图片来自

Opensource.com

当有人刚开始为开源做贡献时，最好的起点通常是对新手友好的错误和问题。但在他们做到这一点之前，他们必须能够找到这些类型的问题。作为开源项目的成员，你可以做很多事情来帮助新手找到贡献的方式。

考虑到这一点，AnitaB.org 开源社区优先考虑让我们的社区对新手友好。我们采取了一些措施来确保我们对不同经验水平的贡献者以及不仅与编码相关的不同类型的贡献都具有包容性。

我最近在 AnitaB.org 社区的 Upstream 2021（Tidelift 的活动，也是维护者周的开幕活动，旨在庆祝开源维护者）上介绍了我们在社区方面所做的一些工作。我讨论了我们的策略主要分为三个部分：

我们如何沟通
项目和问题
开源计划

我们如何沟通

透明度是开源的重要组成部分，我们将透明度原则应用于我们的沟通方式。实际上，这意味着我们所有的社区会议都是公开进行的，这会影响我们设置 Zulip 聊天的方式以及我们提供文档的方式。

开放会议

任何人都可以加入我们的会议并讨论与我们社区相关的主题。他们可以参与讨论或只是倾听。这些在我们的社区日历中对所有人可见。我们通常只在这些通话中使用音频，我们发现这可以让人们更自在地参与其中。

我们主持以项目为中心的会议和一些与类别相关的会议，来自不同领域的人们可以在这里讨论同一个项目并帮助改进我们的流程。有时，我们会举办“问我任何问题”会议，任何人都可以来提问与开源相关的任何问题。

我们会将所有会议的笔记记录在共享文档中，并在我们的 Zulip 中分享摘要和文档链接。

我们的 Zulip 聊天

开源 Zulip 聊天平台是我们主要的社区沟通渠道，尽管我们也使用 Github 上问题和拉取请求上的评论部分。一般来说，我们禁用了私信，以确保我们尽可能透明。对于此规则，我们只有少数例外，我们在那里为处理我们运行的程序的后勤工作的管理员提供私人流。我们发现这种方法更受欢迎，而且它还使我们能够更清楚地了解公共聊天中的行为违规行为。

我们在 Zulip 聊天中分享所有会议摘要，包括讨论的要点、行动项目和文档。这个过程听起来可能是一个显而易见的要求，但我惊讶地发现有多少开源项目没有提供笔记，以便那些没有参加的人可以随时了解情况。

在 Zulip 上，我们讨论项目路线图，回答社区的问题和疑问，并积极**宣传人们可以贡献的方式以及他们可以贡献的地方。** 有时我们会庆祝贡献者的胜利——无论是突出他们测试、审查的第一个 PR，还是我们志愿者的出色工作。

文档

我们尝试保留**有关我们流程的公开文档**，例如常见问题解答，以便社区成员可以按照自己的节奏和时间了解社区。这旨在让他们在联系我们之前了解我们的工作方式和我们所做的工作类型。

项目和问题

关于我们的项目和问题管理，我们鼓励多种贡献方式，专门为初学者创建问题，并尽量简化项目的设置。

多种贡献方式

我们努力创建**需要不同贡献的问题**，例如文档、测试、设计和推广。这是为了让任何人都能够贡献，无论他们的经验水平和兴趣领域如何。它有助于社区参与，我们发现它可以让成员逐步参与并为一些低成本但有价值的任务做出贡献。

我们推广的贡献类型有

复杂度各异的编码任务。
质量保证任务——贡献者可以在其中测试我们的应用程序或拉取请求并报告错误。
成员可以参与讨论的设计会议。此外，还有机会创建模型并重新设计我们应用程序的某些部分，并探索用户体验改进。
推广任务，我们主要在 Zulip 上推广，我们建议他们撰写关于他们的开源经验和贡献的 Medium 出版物博客。
文档任务，可以包括一般的社区文档或我们项目在 Docusaurus 上的文档。

仅限初学者的问题

我们将一些**问题标记为“仅限初学者”**。这些是为尚未向问题存储库贡献的人提供的。标记问题还可以让我们在贡献者涌入时（例如，在Google Summer of Code (GSoC)期间）为开始开源之旅的人提供工作。

有时这些可能是“唾手可得的果实”，可以让他们熟悉贡献和提交拉取请求的过程。

简单的项目设置

我们也很关心为我们的项目提供**对新手友好的设置**。我们注意到，最活跃的项目通常是最容易设置的项目。我们知道，为不熟悉的项目做出贡献可能需要大量的努力，并且会影响或破坏贡献的体验。

我们尝试提供有关如何在多个操作系统上运行我们的项目的说明。过去，我们有一些项目有单独的在 Unix 环境中运行的说明，我们注意到贡献者在 Windows 上运行这些项目时遇到困难。从那时起，我们进行了改进，以避免贡献者在我们的 Zulip 上寻求帮助时产生混淆。

我们一直在根据贡献者的经验改进我们最活跃的项目之一 mentorship-backend 的 README。该项目中初学者的一个难题是设置与配置电子邮件帐户相关的部分环境变量，以启用后端功能来发送电子邮件。但是，由于此功能对于本地开发并不重要，因此默认情况下，我们将电子邮件设置设置为可选，以便将电子邮件打印到终端而不是发送给用户。这种方法仍然使贡献者可以看到电子邮件。与此更改类似，我们将 SQLite 数据库设置为本地开发的默认数据库，以避免为 Postgres 数据库进行额外的设置，即使我们在部署的版本中使用它。

我们注意到，一些贡献者很难为我们的一个项目 bridge-in-tech-backend 做出贡献，该项目的设置复杂且包含的步骤比 mentorship-backend 多得多。自从我们在我们的开源程序之一中注意到这一点以来，我们一直在探索改进其结构。

对于我们的大多数项目，我们还提供应用程序的实时或捆绑版本，以便贡献者可以在不设置的情况下测试项目。这有助于我们为对开发设置不感兴趣或不熟悉的贡献者提供一种方法来尝试我们应用程序的最新版本，并通过报告发现的任何错误来做出贡献。我们在我们的质量保证指南中提供了指向这些已部署应用程序的链接。

开源计划

我们在社区中组织两个主要项目：开源黑客马拉松（为期一个月的项目）和开源大使（为期六个月的项目）。

开源黑客马拉松 (OSH)

在该项目中，我们创建了多个贡献类别的问题——文档、编码、推广、测试和设计（类似于 Google Code-in 竞赛）。参与者可以为每个类别至少贡献一次并获得数字证书。一个问题可能包括多个类别，并且不需要合并拉取请求即可使他们的贡献有效。

我们为该项目选择了一些项目，然后导师集思广益并为参与者创建问题。当项目开始时，参与者可以声明问题并开始贡献。导师会支持和审查他们的贡献。

这种方法鼓励了贡献的多样性，并欢迎任何人（无论他们的编码能力如何）在友好且安全的fail-safe环境中做出贡献。

开源大使

在该项目中，我们从社区中选择大使，理想情况下，他们将涵盖我们旨在推广的每个贡献类别。到目前为止，我们已经运行了两次该项目。

该项目旨在让成员在帮助管理项目和计划方面不断成长，方法是回复来自社区的问题，协助贡献者参与进来，并倡导他们分配的类别。

在我们运行的第一个项目中，我们接受了所有申请者。我们评估了成员的兴趣所在，并为想要贡献但最初不习惯采取这一步的人提供了一个结构。

对于我们社群来说，这个版本非常有启发性。由于我们有经验丰富的开源贡献者和经验不足的开源贡献者以及社区成员，因此需要管理员进行大量管理。一些大使充满信心，积极主动地领导各项工作，而另一些大使则需要更多支持。在我们的第二个项目中，我们决定缩小规模。我们只接受已经熟悉社区、可以领导倡议和项目并帮助我们培训经验不足的人的贡献者。

第二个项目形成了一个积极的反馈循环。最初作为初学者参与我们第一个项目的大使，在从项目经验中学习后，逐渐能够自如地领导工作。

这种方法的改变使管理员能够更加专注于支持大使团队，帮助他们传播我们的使命，继续使社区对初学者友好，并指导更多人做出贡献。