当你开始向开源项目做贡献时，反思一下为什么要做这些贡献。你的回答很有可能就是“我太无聊了，想找点有工作量的事情消磨时间”，这没什么问题，但其实还可以更深一步。
下面这些理由可能会更好：
- 我总是使用这个工具，并且找到了一个错误，或想要帮助解决它。
- 我想帮助其他人更加顺利地使用这个工具。
- 我想帮助其他人更加顺利地向项目做贡献。
- 我想提升个人技能水平。
- 我想公开展示我在大学课程中学习到的技能。
- 我想公开展示我的技能，以便增加找到工作的机会。
有些理由是“自私自利”的——这都没什么问题。如果在花费了一些时间在免费的项目上，期待有所收获才是正道。另外，有了这些明确的贡献理由可以让你更加轻松地决定首先从什么起步。
你在项目中的存在应该是具有成效的，且不应该阻止其他具有成效的工作。
总而言之，就是”善待他人“。这是我们为任何开始做开源项目贡献的人提出的第一条建议。
善待项目中的其他贡献者，可以营造出和谐而富有成效的氛围。这包含：
- 感谢那些帮助过你的人。
- 在适当的时候向人们表示祝贺（例如：他们完成了第一个拉取请求（pull request），或修复了一个难度极高的 bug）。
- 始终以尊重的态度回应他人，即使你感觉到这些问题的回答是明显的，或者询问人在重复自己的工作。
- 试着帮助人们下次更好地工作，例如：在拉取请求审查及回答问题时，说”这是错的“或”这是所需的答案“远不如说”这样做没问题，但我觉得如果你尝试像这样做会更好，这里有一篇博文阐述了更多的想法“或”你可以在这里找到答案，也可以查看这个链接，了解更多常见问题的答案“来得有用。
你和其他贡献者在这里（或者说，应该在这里）是因为他们想为项目做出积极得贡献，但除此之外，你不能对他们作任何假设，这包括他们的：
- 对项目的了解和构建项目用到的技术
- 性别、性取向、年龄、语言、所在地、政治观点、宗教信仰或其他个人属性
- 参与开源项目的经验
- 信任
- 期待
- 幽默感
因此，你需要尽可能保证你所写的内容符合主题，远离具有潜在争议的题材，如宗教或政治。即使你不同意某人的观点，或不喜欢他们所做的决定，也要保持支持和尊重的态度。
并且，你要克制住任何脏话及冒犯性的语言，即使它没有明确地指向任何人。参与时不需要这样，且一些人会对此相当敏感。
需要注意的是，任何一个好的开源项目都会有相应的规则来保护它的贡献者，以避免他们在贡献时感到不自在。这在 GitHub 中往往以 CODE_OF_CONDUCT.md 文件的形式给出。
例如，MDN 的代码库受影响广泛的 Mozilla 社区参与准则的管理。通常在 MDN Web 文档库中轻微的攻击性行为（比如持续不合主题的讨论或破坏性行为，或举止粗鲁）会收到一次 repo 内的警告，然后是最后一次警告，最后就是临时或永久的封禁。更加严重的行为问题，如仇恨言论、对其他贡献成员的威胁，将不受容忍，且可能立即遭受封禁处理。
如果你收到任何令你不舒服的内容，总是可以使用行为准则（code of conduct）中提及的机制进行举报。
想清楚你在项目中要做什么。比如，我们会有一个在贡献者任务面板上记录的一些议题（issue）列表，根据任务的种类分开显示。
你也可以通过创建拉取请求来修复在阅读 MDN 文章时一眼扫到的问题。
MDN 上的很多工作围绕于文档及示例代码的编写，不过，通过这些方式也可以作出贡献：
- 对议题分流进行分类。
- 修正错别字。
- 改善语法，让页面内容更加易于理解。
- 指导人们如何进行修复。
每个修复都是有用的，无论多么琐碎，我们都不会拒绝。尽管如此，尽量确保你的修复工作是有成效的。我们不建议做这些种类的贡献：
- 出于自己的喜爱更新代码样式。
- 出于自己的喜爱更新语言样式。
- 将页面中的美式英语修改为英式英语。
- 在没有任何问题的情况下，添加或移除一批标点符号。
- 出于自己的偏好修改我们正在使用的测试框架。
在许多情况下，开源项目中存在的事情是有原因的。如果它有风格指南，你应该阅读；如果对某件事情是否有效有疑问，一定要先问清楚！
好的开源项目总会让贡献者文档随时可供查阅。对于 GitHub 项目，内容往往存在于仓库的 CONTRIBUTING.md 文件中，或者项目的 README.md 文件中。作为文档类项目，MDN content 有一个 README 文件和一整套对于网站本身的贡献者文档（请参阅为 MDN Web 文档做贡献）。
不要害怕寻求帮助，但总是尝试在提问之前，先自己寻找答案。这样可以让自己独立积累对项目的知识，而且不会给其他贡献者带来不必要的负担。
当然，文档并不总是完美的，如果某项解释很难查找，或者描述得不够出色，请提出 issue，或者创建拉取请求来尝试自己去修复它。
要始终弄清楚哪里是问问题的最佳地点。好的开源项目总会在它们的文档中明确指定这一点（请查看取得联系一节）。如果你想问一些普遍意义上的问题，请使用这些频道。不是所有问题都适合使用 GitHub issue，不合适的 issue 会使项目变得杂乱（请查看下述“要取得进展，不要捣乱”章节）。
仔细思考你在项目中沟通的方式，确保它是有用的，且不会使其他贡献者的工作更加困难。提交拉取请求来修复 bug 是好事，但它们真的有用，且方便审查吗？提出 issue 和加入其他对话是好的，但你的 issue 和评论是符合主题的，还是只是徒增杂乱？
通常情况下，要：
- 在每个议题（issue）中仅讨论一个主题，这样可以让议题集中且有效。
- 在每个拉取请求（PR）中仅修复一个议题（issue）：对你来说，这可能要多花点功夫，但审查一个明确的修复方案要容易得多。
- 如果你有一个有用的观点，或能回答别人的问题，请向其他主题投稿。
- 如果你不确定某样东西是否有用或有一个简单的问题，可以使用其他机制，如聊天室或论坛来提问。
- 在提出问题之前，先阅读手册，尝试自己回答这个问题。
不要：
- 试图同时讨论多个话题，或发表离题的评论，使问题复杂化。
- 把多个修正塞入一个拉取请求（pull request）中，这使得审查难度增加，并引起怀疑（有些人可能试图在有效的更改中隐藏一些恶意代码）。
- 开启很多个议题（issue），问一些含糊不清的问题。
- 在询问之前不尝试自己解决问题。
开源项目是相当民主的，很多决定是投票得出的，而且只要你不妨碍其他人的贡献，可以自由地做出任何想要的贡献。
然而，有些事情将主要由一小群核心贡献者决定。你可以自由地提出反对任何决定的理由，但有时核心贡献者会做出与你的意见相反的决定，你需要尊重并接受这些决定。
了解项目中的核心贡献者是很有用的，这样你就可以知道在诸如拉取请求（pull request）或提出的议题（issue threads）中应该向谁寻求帮助。
记住，很多人在用他们的业余时间运营于开源项目中，没有收入，且一般工作在开源项目的人都非常繁忙。如果你在等待拉取请求审查（pull request review）或问题的解答，请耐心一点。
合理的做法是等待几天，然后礼貌地与某人取得联系，询问他们是否有时间去看它。如果他们碰巧太忙，最好再等一个星期，然后再尝试跟进他们。
在一开始就苛求一些东西，如快速回复，是不合理的。
如果有人在等你为他做什么，你也应该得到同样的礼遇，但同时要尽量及时回应。如果你真的找不到时间，让他们知道，并要求维护者帮助你找到其他人来完成这个任务。
