开源礼仪指南

开源软件正在蓬勃发展。大型公司正在构建基于开放协作的软件，享受社区广泛采用的诸多好处。免费和开源软件凭借其将来自世界各地的人们聚集在一起并根据兴趣结合他们的努力和技能的能力而令人惊叹。

也就是说，由于我们来自不同的背景，因此值得花点时间反思我们如何一起工作。你在与他人合作时表现出的方式有时会影响你的工作是否会被合并、是否有人会处理你的问题，或者在某些情况下，你将来可能被阻止参与代码库的原因。这篇文章旨在尽可能地指导人们如何使这些沟通顺利进行。以下列出了开源中的礼仪要点，以帮助你在社区中度过更愉快的时光并为使其变得更好而做出贡献。

针对维护者

• 使用“需要帮助”或“新手友好”等标签来指导人们解决他们可以参与的问题，如果他们刚接触该项目。
• 在运行基准测试时，向框架/库等的作者展示你将要运行的基准测试代码，然后再运行它。允许他们提交 PR（可以设置截止日期）。这样，当你的基准测试运行时，你就知道他们已经批准了你的基准测试，并且它尽可能地公平。这还可以解决诸如对开发环境而不是生产环境进行基准测试或一些用户错误之类的问题。
• 当你请求某人提供帮助或将问题标记为需要帮助，并且有人提交了 PR 时，如果你决定不合并，请写一个评论解释你关闭它的原因。否则，这会不尊重他们的时间，因为他们是在响应你的号召。我甚至会说，在你关闭或合并任何 PR 时，评论一下原因或表示感谢会更好。
• 不要关闭来自活跃贡献者的 PR 并自己重新实现相同的功能。就是…不要这样做。
• 如果在一个问题上发生了人身攻击的争吵，尽快将其限制在核心维护者范围内。锁定该问题，并在必要时执行行为准则。
• 制定行为准则并使其存在清晰可见。你可以考虑使用 贡献者公约 行为准则。GitHub 现在还提供了一些基本模板，方便集成行为准则。

针对用户

• 在询问新功能或提交错误报告之前，感谢项目通常会受到赞赏。
• 在打开问题时，如果可能，请使用在线代码编辑器（如 CodePen 或 CodeSandbox）创建一个小型、隔离、简单的错误重现，如果不行，请使用 GitHub 仓库。此过程可能会帮助你发现潜在的问题（或意识到这不是项目的问题）。它也将使维护者更容易帮助你解决问题。
• 在打开问题时，请提出解决问题的方案。花几分钟时间进行一些挖掘。这篇博文 提供了一些深入了解源代码的建议。如果你不确定，请说明你不知道该怎么做。
• 在打开问题时，如果你无法自己解决，请说明这一点。预期是你解决你提出的问题。如果其他人解决了，那就是他们给你的礼物（在这种情况下，你应该表达适当的感激之情）。
• 不要提交诸如“这个项目还有人维护吗？”之类的问题。这样的评论是对他们投入时间的侮辱，它暗示着仅仅因为他们需要休息、正在处理其他事情、父亲去世或有了孩子或其他无数的人为原因而没有随时随地响应代码请求，项目就不再有效了。询问未来是否有路线图，或者根据过去的提交记录判断维护是否足够，这完全是可以的。对免费为你创造东西的人咄咄逼人是不对的。
• 如果有人出于尊重拒绝了你的 PR，因为虽然代码有效，但这不是他们希望项目发展方向，请不要继续在 PR 上发表评论。此时，如果你强烈需要该功能，最好是 fork 项目。
• 当你希望向你并非核心贡献者的项目提交一个非常大的 PR 时，最好通过问题询问你希望采取的方向是否有意义。这也意味着你的 PR 更可能被合并，因为你已经提前告知他们并传达了计划。更好的是，将其分解成更小的 PR，以便一次不必理解太多内容。
• 避免认为理所应当。项目的维护者并不欠你任何东西。当你开始使用该项目时，你就有了帮助维护它的责任。如果你不喜欢项目的维护方式，请在提供建议和提供帮助以改善这种情况时保持尊重。如果你强烈认为这不是你个人会采取的方向，你可以随时 fork 项目自己进行开发。
• 在项目上做任何事情之前，请熟悉贡献者指南，这些指南通常位于仓库根目录下的 CONTRIBUTING.md 文件中。如果不存在，请提交问题询问你是否可以帮助创建它。

最终想法

这些技巧的首要主题是礼貌、尊重和友善。开源对我们行业的价值是不可估量的。我们可以通过遵循一些简单的礼仪规则，让它成为每个人都更好的地方。请记住，项目的维护者通常是在业余时间进行维护。此外，不要忘记项目的使用者有时是软件世界的新手。在沟通和合作时，我们应该牢记这一点。通过这样做，我们可以使开源社区变得更好。