当有人刚开始为开源做贡献时，最好从对新手友好的故障和议题开始。但在他们修复故障之前，他们必须要能够找到这类问题。作为一个开源项目的成员，你可以做很多事情来帮助新手找到为项目贡献的方式。
鉴于此，AnitaB.org 开源社区 优先考虑让我们的社区做到对新手友好。我们提倡包容性，确保不同经验和水平的贡献者都可以参与进来，并且他们的贡献不止限于跟编程有关。
我最近在 Upstream 2021，即 Tidelift 活动中介绍了我们在 AnitaB.org 上所做的一些社区工作，该活动启动了“维护者周”，这是一个为期一周的开源维护者庆祝活动。在活动中我讨论了我们策略的三个主要部分：
- 我们如何沟通
- 项目和议题
- 开源项目
我们如何沟通
透明度是开源的重要组成部分，我们将透明度原则应用于我们的沟通方式。实际上，这意味着我们所有的社区会议都是公开进行的，并且影响我们设置 Zulip 聊天的方式以及我们提供文档的方式。
开放会议
任何人都可以加入我们的会议，并讨论与我们社区相关的话题。他们可以参与讨论或者旁听。会议相关信息在我们的社区日历中都可以找到。在这些通话中我们通常只使用语音聊天，我们发现这可以让人们在参与时感觉更自在。
我们举办以项目为中心的会议和一些分类的会议。会议上，来自不同领域的人们可以讨论同一个项目并帮助改进我们的流程。偶尔，我们会有“自由提问Ask Me Anything（AMA）”会议，任何人都可以来问任何与开源相关的问题。
所有会议我们都会在共享文档中进行记录，并在 我们的 Zulip 中共享摘要和文档链接。
我们的 Zulip 聊天
开源 Zulip 聊天平台是我们的主要社区交流渠道，虽然我们也在 Github 的评论区讨论议题和拉取请求Pull Request（PR）。一般来说，我们禁用了私人消息以确保我们尽可能透明。对于这条规则，我们只有少数例外，那些私人聊天是管理员在处理我们运行程序的后勤工作所用的。我们发现这种方法更受欢迎，它还使我们能够更清楚公共聊天中的违规行为。
我们在 Zulip 聊天室分享所有会议摘要，包括讨论的要点、行动项目和文档。这些听起来好像是些显而易见的要求，但我一直惊讶于很多开源项目并不提供会议笔记，所以 Zulip 可以让那些没有参加会议的人也随时了解情况。
在 Zulip上，我们讨论项目路线图，回答社区的问题和疑问，并积极促进人们通过不同的方式方法和在不同的场景下做出自己的贡献。有时我们为贡献者的成就而庆祝 —— 无论是为了突出他们测试或者审查的第一个拉取请求，还是强调我们志愿者所做的出色工作。
文档
我们尽量保持关于我们流程的开放文档，例如常见问题解答，以便这些社区成员可以按照自己的节奏和时间了解社区。这是为了让他们在联系我们之前了解我们的工作方式以及我们从事的工作类型。
项目和议题
关于我们的项目和议题管理，我们鼓励通过多种方式做出贡献，我们为新手专门创建特定的议题，并尝试让项目的设置变得简单。
多种贡献的方式
我们努力创建需要不同贡献的问题，例如文档、测试、设计和外展。这是为了让任何人 —— 无关他们的经验水平和兴趣领域 —— 都能做出贡献。这样能够帮助社区参与进来，而且我们发现它使成员能够从一些省力但有价值的任务开始一步步做出贡献。
我们提倡的贡献类型有：
- 不同复杂性的编程任务。
- 质量保证任务 —— 贡献者可以测试我们的应用程序或拉取请求并报告错误。
- 社区成员可以参与讨论的设计会议。此外，创建模型和重新设计我们应用程序某些部分的机会，并探索改进用户体验。
- 外展任务，我们主要在 Zulip 上推广，我们建议在我们的 Medium 出版物上发表博客，介绍他们的开源经验和他们的贡献。
- 文档任务，可以包括一般社区文档或我们在 Docusaurus 上的项目文档。
仅限新手的问题
我们将一些议题标记为“仅限新手”。这些问题适用于尚未为议题存储库做出贡献的人。为议题做标签还使我们能够让人们在贡献者大量涌入时开始他们的开源之旅，例如，在 谷歌编程之夏（GSoC） 申请期间。
有时，这些可能是“唾手可得的果实”，可以让他们熟悉作出贡献和提交拉取请求的过程。
简单的项目设置
我们也很在意为我们的项目提供新手友好的安装设置。我们注意到最活跃的项目通常是最容易设置的。我们知道，为你不熟悉的项目做出贡献可能需要付出很多努力并且关乎贡献体验的成败。
我们尝试提供有关如何在多个操作系统上运行我们项目的说明。在过去，我们有一些项目有单独的说明，可以在 Unix 环境下运行，我们注意到贡献者在 Windows 上运行这些项目有些困难。自那以后我们不断进行改进，以避免贡献者在 Zulip 上寻求帮助时出现混乱。
我们根据贡献者的经验，一直在改进我们最活跃的项目之一 mentorship-backend 的自述文件。新手在这个项目中遇到的困难之一是设置与配置电子邮件帐户相关的部分环境变量，以使后台功能能够发送电子邮件。但是，由于此功能对于本地开发并不重要，因此默认情况下，我们将电子邮件设置设为可选，以便将电子邮件打印到终端，而不是发送给用户。这种方法仍然使贡献者可以看到这些电子邮件。与此更改类似，我们将 SQLite 数据库 作为本地开发的默认设置，以避免对 Postgres 数据库进行额外设置，虽然我们在部署版本中会使用到 Postgres。
我们注意到，一些贡献者在为我们的 bridge-in-tech-backend 项目做出贡献时觉得很困难，该项目的设置很复杂，并且包含的步骤比 mentorship-backend 多得多。自从我们在一个开源项目中注意到这一点以来，我们一直在探索如何改进其结构。
对于我们的大多数项目，我们还提供应用程序的实时体验版本或打包版本，以便贡献者无需设置即可测试项目。这有助于我们为那些对开发设置不感兴趣或不熟悉的贡献者提供一种方式，来尝试我们应用程序的最新版本，并通过报告发现的任何错误来做出贡献。我们在 质量保证指南 中放了这些应用程序的链接。
开源计划
我们在社区中组织了两个主要计划：开源黑客（OSH）（一个为期一个月的项目）和 Open Source Ambassadors（一个为期六个月的项目）。
开源黑客（OSH）
在此计划中，我们在多个类别的贡献中创建议题 —— 文档、编码、外展、测试和设计（类似于 谷歌的 Code-in 竞赛）。 参与者可以为每个类别至少贡献一次并获得电子证书。一个议题可能包含多个类别，并且无需合并拉取请求也能使贡献有效。
我们为这个计划选取几个项目，请导师们集思广益为参与者创造议题。项目开始后参与者可以认领议题并开始作出贡献。导师们会支持帮助并审查他们的贡献。
这种方法鼓励贡献的多样性，并欢迎任何人，无论他们的编码能力如何，都可以在友好和不怕出错的环境中做出贡献。
开源大使
在此计划中，我们从社区中选择大使，理想情况下他们将涵盖我们旨在促进的每一类贡献。至今该计划已启动了两次。
该计划旨在让成员通过回答社区的议题、协助贡献者参与并为他们指定的类别宣传来帮助管理项目和计划。
第一个计划举行时我们接受了所有的申请者。我们评估了社区成员的兴趣所在，并为那些想要做出贡献但最初不敢踏出第一步的人提供了一个体系。
第一个计划的举办给了我们很多启发。因为我们的活动中既有经验丰富的开源贡献者和社区成员，也有初来乍到缺乏经验的新手，因此项目的执行要求管理员进行大量的管理工作。一些社区大使信心十足准备好进一步采取新措施，而其他大使则需要更多支持。到了第二个，我们决定缩减该计划，只接受那些已经熟悉社区、可以领导倡议和项目并帮助我们培训新人的贡献者。
第二个计划中形成了正反馈循环。那些在第一个计划中还是新手的大使们，通过为上一个项目做出贡献并且从项目经验中学习之后能够做到轻松带领项目。
这种方法的改变使管理员能够更加专注于支持大使团队，帮助他们传播我们的使命，并继续让我们的社区对新手友好，并指导更多人做出贡献。
总结
这些计划帮助我们提高了对开源贡献和回馈的不同方式的认识。通过它们，我们发现志愿者通过管理项目和举办公开会议来提供帮助，这有助于管理社区并为我们的贡献者提供指导。
尽管我们得到了贡献者的良好反响，并帮助人们做出了他们的第一个贡献，但我们仍有很大的改进空间。我们将继续改进我们项目的设置和贡献指南，以改善贡献者的体验。我们还将继续专注于确保我们的组织始终拥有并推动不同类别的问题，促进包容性，以便任何有意愿做出贡献的人都能出自己的一份力。
