开源礼仪

在你开始为开源项目做贡献之前，问问自己为什么要这样做。如果答案仅仅是“我闲着无聊，想找点有意义的事情做”，也没关系，但你可能可以更深入地思考一下。

更好的理由可能包括：

• 我经常使用这个工具，并且发现了一个 bug/想帮助改进它。
• 我想帮助其他人更成功地使用该工具。
• 我想帮助其他人更成功地为该项目做贡献。
• 我想提高自己的技能。
• 我想作为我大学课程的一部分公开展示我的技能。
• 我想公开展示我的技能，以提高我获得工作的几率。

其中一些理由是自私的，这没关系——如果你花时间免费工作在一个项目上，那么期望从中获得一些东西是合理的。此外，拥有明确的贡献理由将使你更容易决定首先要做什么。

你在项目中的存在应该是有成效的，并且不应该阻止其他人也这样做。

我们可以将其缩写为“友善”。这是我们对任何开始开源贡献的人的首要建议。

对项目中的其他贡献者友善，这将使项目变得更快乐、更高效。这包括：

• 如果有人帮助了你，要感谢他们。
• 在适当的时候祝贺他人（例如，如果他们提交了他们第一个拉取请求，或者修复了一个特别困难的 bug）。
• 始终尊重地回复他人，即使你认为他们问题的答案很明显，或者他们一直在重复自己。
• 尝试以支持的方式帮助他人下次做得更好，例如在拉取请求审查期间或当你回答他们的问题时。说“这是错误的”或“答案在这里”远不如说“这没问题，但我认为如果你尝试这样做会更好，这里有一篇博客文章可以提供更多想法”或“你可以在此处找到答案；还可以查看此链接以获取更多常见答案”。

你和其他的贡献者（或应该）在这里是因为他们想对项目做出积极的贡献，但除此之外，你不能对他们有任何假设。这包括他们的：

• 对项目和用于构建它的技术的了解
• 性别、性取向、年龄、语言、居住地、政治观点、宗教或其他个人属性
• 参与开源项目的经验
• 自信心
• 期望
• 幽默感

因此，你应该尽可能地保持你所写的内容与主题相关，远离潜在的争议性脱轨话题，如宗教或政治，即使你不同意某人的观点，或者不喜欢他们做出的决定，也要保持支持和尊重。

此外，你应该避免使用任何脏话/冒犯性语言，即使它不是针对任何特定的人。参与不需要这些，而且有些人对此非常敏感。

请注意，任何优秀的 OSP 都会制定规则来保护其贡献者免受在贡献过程中感到不舒服的影响。这通常以 GitHub 上的 CODE_OF_CONDUCT.md 文件的形式出现。

例如，MDN 的存储库受范围广泛的 Mozilla 社区参与指南 管辖。通常，MDN Web 文档存储库中轻微的冒犯性行为（例如持续偏离主题/破坏性行为或粗鲁行为）通常会首先得到存储库警告，然后是最终警告，然后是临时或永久禁止。更严重的行为问题，如仇恨言论或对其他贡献者的威胁，将不容忍，并可能导致立即禁止。

如果你收到任何让你感到不舒服的东西，你应该始终使用行为准则中提供的机制进行报告。

考虑一下你想在项目中做什么。例如，我们在 贡献者任务看板 上列出了大量的已提交问题，并按各种任务类型进行了分类。

你也可以通过打开 拉取请求 来修复你在阅读 MDN 文章时遇到的问题。

MDN 上的大量工作围绕着编写文档和代码示例，但还有其他贡献方式：

• 帮助分类收到的问题。
• 帮助修复错别字。
• 帮助改进语法并使页面更容易理解。
• 帮助指导那些试图进行修复的人。

每个修复都是有用的，无论它多么小，我们都不会拒绝任何修复。然而，请尽量确保你的修复是有成效的。我们建议避免以下类型的贡献：

• 仅仅因为“你更喜欢这种风格”而更新代码样式。
• 仅仅因为“你更喜欢这种风格”而更新语言风格。
• 将页面从美式英语更改为英式英语。
• 在没有真正错误的情况下添加或删除大量标点符号。
• 因为你更喜欢它而将我们使用的测试框架更改为其他框架。

在许多情况下，OSP 上的事情之所以是现在这样是有原因的。如果他们有风格指南，你应该阅读它们，如果对某件事是否有成效有疑问，请务必先询问！

优秀的 OSP 总是会提供贡献者文档。在 GitHub 项目中，它通常位于存储库的 CONTRIBUTING.md 文件中，或者有时位于项目的 README.md 文件中。作为一个文档项目，MDN 内容有一个 README 以及网站本身提供的一套不错的贡献者文档（请参阅 为 MDN Web 文档做出贡献）。

不要害怕寻求帮助，但在提问之前，**始终**尝试先找到问题的答案。这样，你就可以积累对项目的了解，变得更加独立，并且不会给其他贡献者带来不必要的负担。

当然，文档并不总是完美的。如果难以找到说明或说明不太清楚，请提交问题或创建拉取请求来尝试自己修复它。

始终找到提问的最佳位置。优秀的 OSP 总是会在其文档中明确说明这一点（请参阅 联系我们）。如果你想问一些常规问题，请始终使用这些渠道。不要只是为每个问题在 GitHub 上提交一个问题，因为这会给项目增加噪音（请参阅下面的“注重实质性贡献，而非制造噪音”）。

仔细思考你在项目中处理沟通的方式——确保它有用，并且不会让其他贡献者的工作变得更困难。提交修复 bug 的 pull request 很好，但它们真的有用且易于审查吗？提交 issue 和参与其他对话也很好，但你的 issue 和评论是否主题明确，还是仅仅增加了噪音？

作为规则，请

• 每个 issue 讨论一个主题——这很容易让 issue 保持专注和高效。
• 每个 PR 修复一个 issue——这对你来说可能稍微多做了一些工作，但审查单个清晰的修复要容易得多。
• 如果你有有用的观点或可以回答别人的问题，请参与其他讨论。
• 如果你不确定某件事是否有用或有一个简单的问题，请使用其他机制（如聊天室或论坛）提问。
• 在提问之前，先阅读手册，尝试自己解答问题。

请勿

• 通过尝试一次讨论多个主题或发表跑题评论来使 issue 复杂化。
• 尝试将多个修复塞进一个 pull request 中。这会让审查变得非常困难，并引发怀疑（有些人可能会认为你试图在有效的更改中隐藏一些恶意代码）。
• 打开大量 issue 来询问含糊不清的问题。
• 在没有尝试自己解决问题之前就提问。

开源项目 (OSPs) 非常民主——许多决定都是投票产生的，并且你基本上可以自由地按照你想要的方式做出贡献，只要你不妨碍其他人做出贡献。

但是，有些事情将在很大程度上由一小部分核心贡献者决定。你可以自由地对任何决定提出异议，但有时主持人会做出与你的意见相悖的决定。你需要尊重并接受这些决定。

了解项目的任何主持人很有用，这样你就知道向谁寻求帮助，例如在 pull request 或 issue 讨论中。

请记住，许多参与开源项目的人都是利用业余时间，无偿进行的，并且所有参与开源项目的人通常都很忙。如果你正在等待某些事情，例如 pull request 的审查或问题的答案，请耐心等待。

等待几天然后礼貌地提醒某人是否已经抽出时间查看它是合理的。如果他们恰好太忙，最好再等一周，然后尝试再次联系他们。

开始要求某些东西，比如快速回复，是不合理的。

如果有人在等待你为他们做某事，你应该给予同样的礼貌，但同时，尽量尽快回复。如果你真的没有时间，请让他们知道，并请维护人员帮你找到其他人来完成这项任务。

• 如何为开源项目做出贡献
• 更通用的 freeCodeCamp“如何为开源项目做出贡献”列表
• 开始为开源项目做出贡献