3 步管理初学者友好的开源社区

图片来源

Opensource.com

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

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

最近，我在 Tidelift 活动 Upstream 2021 上介绍了我们在 AnitaB.org 社区所做的一些社区工作，该活动开启了维护者周，这是一个为期一周的开源维护者庆祝活动。我讨论了我们的战略主要分为三个部分：

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

我们如何沟通

透明度是开源的重要组成部分，我们将透明度原则应用于我们的沟通方式。实际上，这意味着我们所有的社区会议都是公开进行的，这影响了我们如何设置 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 竞赛）。参与者可以做出贡献，并因至少为每个类别贡献一次而获得数字证书。一个问题可能包括多个类别，并且拉取请求不需要合并才能使他们的贡献有效。

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

这种方法鼓励贡献的多样性，并欢迎任何人，无论他们的编码能力如何，都在友好且万无一失的环境中做出贡献。

开源大使

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

该项目旨在让成员成长，通过回答社区的问题、协助贡献者参与以及倡导他们分配的类别来帮助管理项目和倡议。

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

对于我们社区来说，这个版本非常有启发意义。它需要管理员进行大量管理，因为我们混合了经验丰富和经验不足的开源贡献者和社区成员。一些大使有信心站出来领导倡议，而另一些大使则需要更多支持。对于我们的第二个项目，我们决定缩小倡议的规模。我们只接受已经熟悉社区并且可以领导倡议和项目并帮助我们培训经验不足的人员的贡献者。

第二个项目变成了一个积极的反馈循环。从新手开始，为我们运行的第一个项目做出贡献的大使，在从该项目的经验中学习后，变得可以自信地进行领导。

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