你的开源社区是否为贡献者进行了优化？

Josh Matthews 是 Mozilla 的平台开发人员。他是一位程序员，编写 Rust 代码，并积极参与 Firefox 的开发。他的开发经验使他喜欢指导开源项目中的新贡献者。

Josh 将在 OSCON 2016 上就优化您的项目以促进贡献这一主题发表演讲，并慷慨地同意接受采访。

您的背景是什么？是什么让您对开源感到兴奋？

我最早的编程经验发生在可以查看底层并了解所有内容如何组合在一起的环境中。同样，我加入的第一个邮件列表也充满了喜欢分享代码并互相帮助进行协作学习的人。当我意识到我不仅可以从开源软件中学习，还可以修改它并与他人分享我的更改时，我就被迷住了。对我来说，与他人合作的前景一直比简单的创造行为更具吸引力。

Mozilla 社区的哪些方面吸引了您的参与？

就我而言，那是一篇来自 Mozilla 开发人员的博客文章，描述了一个低优先级、高影响、极其艰巨的项目，该项目可以从更多人手中受益。这是 2009 年将 Firefox 拆分为多个进程的初步工作！我可以贡献的具体而实在的东西，加上获得入门帮助的承诺，让我想要尝试一下。

您如何确保您的开源项目不会被忽视？社交媒体在宣传方面有多重要？

我对第一个问题的简短回答是“营销”。社交媒体的存在可以成为宣传时效性或特定受众的信息，或实现围绕项目为中心的低接触沟通和技术支持的有用工具。为了避免被忽视，项目需要找到他们的目标受众在哪里，弄清楚他们为什么要关心这个项目，并（得体地）广播该消息。此外，项目需要有效地沟通他们如何随着时间推移而变化，以便现有用户和潜在新用户都可以一目了然地看到当前状态和未来目标是否与他们的需求相符。

人们不为开源项目做贡献的一些障碍（真实的或感知的）是什么？

我不认为“真实的”或“感知的”障碍之间存在差异，因为它们最终都会阻止潜在的贡献者这样做。感知的障碍通常是双方期望不匹配或不明确的结果——如果一个项目没有很好的文档，其问题跟踪器是未经整理的和/或充满了术语，并且维护者仅在被直接提及才回应，所有这些都可能被挣扎的新手视为他们不属于那里的迹象，即使这不是预期的结果。

话虽如此，一些最大的障碍源于贡献者犯错误的机会。每次流程的某个部分不明确且没有明确的获得帮助方式时，贡献者在遇到问题时就更容易放弃并离开。我经常听到人们在尝试对项目进行首次贡献时感到害怕和脆弱。我们应该在设计文档和工具时考虑到他们，因为每个人都会从结果中受益。

对于试图在开源项目中发展社区和参与度的人，您有什么建议？

确定哪些类型的人会想要参与您的项目，以及为什么。尽可能让他们轻松参与。

1. 确定适当的参与方式（例如，定期整理可用的工作清单）。
2. 投资于消除痛点的自动化（例如，样式检查器和开发环境设置）。
3. 使用允许最大灵活性的通信媒介。将项目仅限于 IRC 可能会因时区和社会限制而排除大量人群。
4. 大声、热情、频繁地认可参与。

只有在这一点上，真正开始积极鼓励更广泛的受众参与才有意义。这些是首次成功贡献的基础，而首次成功贡献是重复贡献者的先决条件。

一个人如何开始为 Mozilla 做贡献？

找到感兴趣领域的一种简单方法是访问 WhatCanIDoForMozilla.org，该网站根据所需的技能突出显示团队和子项目。从那里，您将被链接到有关如何为每个您感兴趣的项目做出贡献的具体说明。我们在我们的错误跟踪器中提供了经过整理的任务列表供您处理，每个任务都与一位导师相关联。还有专门标记为面向新手的任务，这些任务是直接且独立的。最后，我们有一个名为 #introduction 的 IRC 频道，其中充满了来自世界各地的人们，他们喜欢回答问题，无论是来自首次开源贡献者还是经验丰富的资深人士。

Rust 社区的参与度如何？您如何鼓励参与？Mozilla 目前最迫切的需求是什么？

Rust 社区的兴奋和活力让我震惊！每天都有新的库发布，并且有一种充满活力和积极的文化，以快速、尊重、积极的方式回答问题为荣。每次我最终在公共场合提出问题时，这种回应真的让我感到温暖！

至于鼓励参与，团队已经投入了大量的思考和努力来创建工具，使编写 Rust 代码并与他人分享变得容易。此外，语言开发过程从 0.1 版本之前就完全开放，但用于发展它的公共 RFC 流程是对鼓励贡献原则的伟大演示——它采用了一个许多人关心的临时流程，定义了参与其中的规则以及参与的形式，并且自那以后一直持续应用。因此，在不到 2 年的时间里，已经提交了超过 1,500 个 RFC！

当谈到 Mozilla 最迫切的需求时，它们出奇地简单明了。我们需要更多 Web 开发人员针对 Firefox 的预发布版本测试网站并报告他们遇到的错误，因为这有助于我们在继续发展 Web 平台时捕获向后兼容性方面的重大回归。此外，我们需要帮助分类已经提交的错误——那些可以花时间尝试重现问题、梳理出问题发生的条件并帮助创建精简测试用例的人对项目来说是巨大的福音。