开源礼仪

思考您为何要贡献于 OSP

在您开始为开源项目贡献之前，问问自己为什么要这样做。如果这个问题的答案是“我想找点事做”，那也很好，但更好的原因可能包括：

• 我想提升我的技能。
• 我一直在使用这个工具，发现了一个 bug，或者我想让它变得更好。
• 我想帮助其他人更成功地使用这个工具。
• 我想帮助其他人更成功地为项目做出贡献。
• 我想为我的大学课程公开展示我的技能，或者提高我获得工作的机会。

这些原因中有一些是出于个人目的，这没关系！拥有清晰的贡献原因将使您更有效率，也更容易与社区合作。

保持礼貌，保持友善，避免煽动性或冒犯性语言

我们可以将这一点缩写为“保持友善”。这是我们给任何开始贡献开源的人的首要建议。对项目中的其他贡献者保持友善，这将使这里成为一个更愉快、更高效的地方。

• 如果有人帮助了您，请感谢他们。
• 在适当的时候祝贺别人，比如他们成功合并了一个拉取请求 (pull request)，或者修复了一个棘手的 bug。
• 始终以尊重的态度回应，即使您觉得问题的答案很明显，或者有人在重复同样的事情。
• 尝试以支持的方式帮助人们做得更好。例如，说“这是错的”或“答案在这里”不如说“这样可以，但我认为如果这样做会更好，这里有一篇博客文章供您参考更多想法”或者“您可以在这里找到答案；也可以看看这个链接，了解更多常见问题的答案”。

贡献者之所以在这里，是因为他们想对项目产生积极影响。除此之外，不要做任何假设，例如：

• 对项目及其构建所用技术的了解程度
• 性别、性取向、年龄、所讲语言、地点、政治观点、宗教或其他个人属性
• 开源项目经验
• 自信程度
• 期望
• 幽默感

您应该让您写的内容保持在主题之内，并避免争议性话题，如宗教或政治。避免使用脏话或潜在的冒犯性语言。这些很少能改善沟通，反而会使他人更难参与。

即使您不同意某人或不喜欢他们做出的决定，也要保持支持和尊重。请注意，任何好的 OSP 都会制定规则来保护其贡献者，使其在贡献过程中不会感到不适。这通常可以在 GitHub 的 CODE_OF_CONDUCT.md 文件中找到（例如，请参阅 mdn/content CODE_OF_CONDUCT）。

MDN 的仓库遵循广泛的 Mozilla 社区参与指南 (CPG)。在 MDN Web Docs 仓库中，通常轻微冒犯性的行为（例如，持续跑题/捣乱，或不礼貌）将首先受到警告，然后是最后警告，接着是暂时或永久封禁。更严重的品行问题，如仇恨言论或威胁其他贡献者，将不被容忍，并很可能导致立即封禁。

如果您收到任何让您感到不适的内容，您应始终使用行为准则中提供的机制进行举报。

选择有效的贡献

思考您想在项目上做什么。例如，我们在 贡献者任务看板 上列出了大量问题，按不同任务类型进行了分类。您也可以通过打开 拉取请求 来修复您在阅读 MDN 文章时遇到的问题。

MDN 的许多工作围绕着编写文档和代码示例，但也有其他贡献方式。这可能包括帮助分类收到的问题、修复拼写错误、纠正语法以使页面更容易理解，或者指导那些试图进行修复的人。每一次修复都有用，无论大小，我们都不会拒绝。不过，请尽量确保您的修复是有效的。我们建议避免以下类型的贡献：

• 更新代码风格、文本语言或测试框架，仅仅因为您更喜欢它。
• 将页面从美式英语改为英式英语。
• 在原始标点符号正确的情况下添加或删除标点符号。

在许多情况下，OSP 的事物之所以如此，是有原因的。您应该阅读它们可能提供的风格指南，如果您不确定某件事是否有效，请务必先询问！

阅读手册

好的 OSP 总是会提供易于获取的贡献者文档。在 GitHub 项目中，它通常位于仓库的 CONTRIBUTING.md 文件中，有时也在项目的 README.md 文件中。作为一个文档项目，MDN 内容本身有一个 README 和一套不错的网站贡献者文档（请参阅 社区资源）。

不要害怕寻求帮助，但在提问之前，请务必先尝试自己找到答案。这样，您就可以积累对项目的知识，变得更加独立，并且不会给其他贡献者带来不必要的负担。如果某个解释很难找到或描述得不好，可以提交一个 issue，或者创建一个拉取请求来尝试自己修复它。

找出哪里可以提问

找出提问的最佳地点。好的 OSP 总是会在其文档中明确说明（请参阅 联系我们）。如果您想问一般性问题，请务必利用这些渠道。不要为每个问题都提交 GitHub issue，因为这会给项目增加噪音（请参阅下一节）。

创造进展，而非噪音

仔细考虑您在项目中的沟通方式 — 确保它是有效的，并且不会让其他贡献者的工作更困难。提交拉取请求来修复 bug 是很好的，但请确保它们是有效的或易于审查的。提交 issue 和参与其他对话都可以，但您的 issue 和评论是否切题，或者是否在制造噪音？

一般来说，请

• 每个 issue 讨论一个主题 — 这样可以轻松地使 issue 保持专注和高效。
• 每个 PR 修复一个问题 — 这对您来说可能稍微费力一些，但审查单个清晰的修复要容易得多。
• 如果您有有用的观点或可以回答别人的问题，请参与其他讨论串。
• 如果您不确定某件事是否有效，或者有一个简单的问题，请使用聊天室或论坛等其他方式提问。
• 先阅读手册，尝试自己回答问题，然后再提问。

请勿

• 试图一次讨论多个主题，或发表离题评论，使 issue 变得复杂。
• 试图将多个修复合并到一个拉取请求中。这会大大增加审查难度，并引起怀疑（有些人可能会认为您试图在有效更改中隐藏恶意代码）。
• 打开大量 issue 来提问模糊的问题。
• 在没有先尝试自己解决问题的情况下提问。

OSP 是民主的（几乎）

OSP 相当民主 — 许多决策会进行投票，并且您在很大程度上可以自由地以您想要的方式贡献，只要您不阻碍任何人贡献。

然而，有些事情将主要由一小群核心贡献者决定。您可以自由地对任何决定提出反对意见，但有时版主会做出与您的意见相悖的决定。您需要尊重并接受这些决定。

了解任何项目的版主是有益的，这样您就知道向谁寻求帮助最好，例如在拉取请求或 issue 讨论串中。

保持耐心，保持及时

请记住，许多在 OSP 工作的人是在业余时间无偿工作的，而且所有在 OSP 工作的人通常都很忙。如果您正在等待诸如拉取请求审查或问题答案之类的事情，请保持耐心。

等待几天，然后礼貌地提醒某人，询问他们是否有时间查看，这是合理的。如果他们碰巧太忙，最好再等一周，然后再尝试跟进。

要求快速回复等事情是**不**合理或不礼貌的。

如果有人在等您为他们做某事，您也应该受到同样的礼遇，但同时，请尽量尽快回复。如果您实在抽不出时间，请告知他们，并请求维护者帮助您找到其他人来完成这项任务。

另见

• 如何为开源项目做贡献
• freeCodeCamp 的更通用的“如何为开源项目做贡献”列表
• 开始为开源项目做贡献
• Google 工程实践文档 (google.github.io/eng-practices)