开源软件正在蓬勃发展。大型企业正在依赖于开源协作构建，并享受着主流社区所引入的诸多益处。自由而开源的软件是令人惊叹的，是因为它汇集来自世界各地的诸多人，并按照他们的兴趣将其成就和技能结合起来的这种能力。
这就是说，因为我们来自不同的背景，所以值得花点时间思考下我们如何一起工作。你在与他人合作时进行自我引导的方式有时会影响你的工作是否合并，某人是否已经在处理你的问题，或者是在某些情况下会影响你在未来可能被阻止参与某个代码库的缘由。这篇文章是为了尽可能地引导人们如何使这些沟通顺利进行。这里有一个开源的礼仪列表，以帮助你在社区中度过更愉快的时光，并为建立一个更好的地方做出贡献。
对于维护者
使用“需要帮助”或“初学者友好”这样的标签来引导项目的新人们去尝试处理那些他们可以解决的issue。 运行基准测试情况下，在运行基准测试之前向框架/库/etc的作者展示您将要运行的代码。允许他们进行PR（给出一个截止日期是可以的）。这样，当你的基准测试运行时，你知道他们得到了你的认可，并且尽可能的公平。这也解决了诸如基准开发引起的而不是生产环境或者一些用户错误引起的问题。 当你向某人寻求帮助或给一个问题贴上“帮助”的标签，或者是“PR”时，如果你决定不合并的话，请写一点评论来解释你为什么要关闭它。不合并是对他们的时间的不尊重，因为他们在遵循你的行动号召。我甚至会说，对你关闭或合并的任何PR，给出来解释为什么或者说谢谢你的评论都是很好的。 不要关闭一个积极贡献者的PR，自己尝试去重新实现同样的事情。只是……别这样做。 如果在一个涉及到个人问题的issue上爆发了一场争论，那么尽快将其关闭给核心维护人员。锁定issue，并确保在必要时强制执行行为准则。 制定一套行为准则并明确其存在。你可能会考虑参与者契约的行为准则。GitHub现在还提供了与一些简单行为准的模板。
对于使用者
在要求增加新功能或提交bug之前，对项目表示感谢，这通常是非常感谢的。 在开一个新issue时，如果可能的话，使用在线代码编辑器（如codepen或codesandbox）创建一个小的、隔离的、简单的问题的复制版，如果没有的话，可以使用GitHub库。这个过程可以帮助您发现潜在的问题（或者意识到这不是项目的问题）。它还将使维护人员更容易帮助您解决问题。 当开一个issue时，请提出一个解决问题的方法。花几分钟做一点挖掘。这篇博客文章对如何深入了解源代码有一些建议。如果你不确定，解释一下你不知道该怎么做。 当开一个issue时，如果你不能自己解决这个问题，请解释一下。期望是你解决了你提出的问题。如果别人这样做了，那是他们给你的礼物（所以你应该在这种情况下表达适当的感激）。 不要开诸如“这样的东西还能维持下去？”之类的issue。这样的评论是对作者所花费时间的侮辱，它读起来好像项目是不再有效，因为他们需要休息，或者在做别的工作，或者他们的爸爸死了，或者他们生了个孩子，或者任何其他无数人为的不能继续写代码原因。询问是否有未来的路线图，或者根据过去的承诺来决定它的维护是否足够满足你的要求是完全可以的。对那些为你免费创造一些东西的人来说，消极的攻击他们是非常不好的。
如果有人很有礼貌地拒绝了PR，因为虽然代码是有效的，但这不是他们想要的方向，也不要对PR进行评论。在这一点上，如果您强烈地感觉到需要一个特性，那么你可以fork这个项目。 当你想要向一个你不是核心贡献者的项目提交一个非常大的pull reqest请求时，如果你想要的方向是有意义的，那么通过一个issue来表达这个请求是一个好主意。这也意味着你更有可能获得合并请求，因为你已经给了他们一个提示并传达了计划。更好的是，将它分解成更小的pull request，这样在一次合并中就不会花太多的时间去摸索。 避免索要权利。这个项目的维护者不欠你任何东西。当你开始使用这个项目时，你有责任帮助维护它。如果你不喜欢这个项目的维护方式，当你提供建议并提供帮助来改善情况时，要保持尊重。如果你的需求强烈，并且觉得这不是你一个人的需求，你就可以自己动手去做。 在对项目做任何事情之前，要熟悉在项目的贡献者指南，通常都是在项目存储库根目录的CONTRIBUTING.md文件里。如果这个文件不存在，就提出一个issue来问你是否可以帮忙创建一个。
最后的一些想法
这些建议的主题是礼貌、尊重和友善。开源对我们行业的价值是不可估量的。通过遵循一些简单的礼仪规则，我们可以让它对于每个人来说都变得更美好。请记住，项目的维护人员经常在业余时间进行开发。也不要忘记，项目的用户有时对不断增长的软件世界是陌生的。在沟通和合作时，我们应该牢记这一点。通过这样做，我们可以使开源社区变得更好。 | 
