开源软件正在蓬勃发展。大型企业正建立在开源协作的软件之上，享受着开源社区带来的诸多好处。自由和开放源代码的软件是令人惊叹的，因为它能够汇集许多来自世界各地的人，并根据他们的兴趣和本身技能划分。
这就是说，因为我们的背景不同，所以值得花点时间思考我们如何一起工作。当你在与他人合作时，自我的行为是否会影响协作工作的进行，某人是否会根据你的问题开展工作，或者在某些情况下会影响你被参与某存储库的构建。
这篇文章是为了尽可能地引导开发者如何更好的沟通。这里有一个开放源代码的礼仪列表，帮助你在社区中度过更愉快的时光，并为建立一个更好的地方做出贡献。
对于维护者
如果他们对项目不熟悉，可以使用“需要帮助”或“初学者友好”等标签来引导开发者去解决他们可以处理的issue
运行基准测试时，请在运行基准测试之前向框架/库等的作者显示您要运行的代码。让他们进行PR(可以给出提交截止日期)。这样，当你的基准测试运行时，你知道他们已经得到你的认可，并且尽可能公平。这也解决了诸如基准测试引起的而不是生产环境或用户错误等引起的问题。
当你向某人寻求帮助或给某个问题贴上标签时，如果你决定不合并，请写一条评论，解释为什么你要关闭它。否则就是不尊重他人的时间，因为他们正在遵循你的号召行事。任何你要关闭或合并的PR，都发表一条评论解释一下，这是非常好的行为。
不要关闭活跃贡献者的PR，然后自己重新实现相同的功能。
如果在个人的issue上发生争执时，尽快将其关闭给核心维护人员。锁定issue，并确保在必要时强制执行行为准则。
制定明确的行为准则，你可以考虑参与者契约的行为准则。GitHub现在还提供了一些简单的行为守则模板的集成。
对于用户
在对新功能进行查询或提交bug之前，先对其项目表示感谢
在解决问题时，如果可能的话，使用在线代码编辑器(如codepen或codesandbox)创建一个小的，独立的，简单的Issue副本，或者创建一个GitHub存储库。这个过程可以帮助你发现潜在的问题(或者有可能会发现这不是项目的问题)。这也将使维护人员更容易帮助你解决问题。
在新建一个issue时，请提出解决方案，花几分钟做一点挖掘，深入了解源代码的建议。如果你不确定，请解释你一下你不知道该做什么。
在一个issue上，如果你无法自己解决问题，请解释一下，当然最好是你自己解决。如果有人有人帮你解决了，那么，这时候你应该适当的表示感谢。
不要开诸如“这样的东西还能维持下去?”之类的issue。这样的评论是对作者劳动成果的侮辱，它读起来好像项目没什么用处了，你完全可以换种方式问问项目是否有未来的规划路线图，或者根据过去的提交来判断它的维护是否足够满足你的需求。对那些为你免费创造这个项目的开发者来说，消极的攻击他们是非常不好的。
如果有人委婉地拒绝了PR，即便代码是有效的，但这不是他们想要参与的方向，不要对PR发表评论。此时，如果迫切需要某项功能，那么你fork这个项目可能会更好。
当你不是项目的核心贡献者，但却想向项目提交一个非常大的request时，那么可通过一个issue来询问你的想法是否是正确的。这也意味着你更有可能将合并请求，因为你已经向项目维护者并传达了你的想法。更好的是，将它分解成更小的PR，这样每一次的合并就不用花费大量的时间
避免享有权利。项目的维护者并不会欠你任何东西。当你开始使用这个项目时，你有责任帮助维护它。如果您不喜欢项目的维护方式，当你提供建议并提供帮助来改善情况时，要保持尊重。如果你的需求十分强烈，那么你可以随时将项目分解为独立工作，自己去完成它。
在对项目进行任何操作之前，请熟悉通常在存储库根目录的CONTRIBUTING.md文件中找到的贡献者准则。如果不存在，请提出一个issue询问是否需要你帮助创建一个。
最后的想法
以上这些建议主要围绕是礼貌、尊重和友善。开源对我们行业的价值是不可估量的。通过遵循一些简单的礼仪规则，我们可以让它对于每个人来说都变得更美好。请记住，项目的维护人员经常在业余时间进行开发。也不要忘记，项目的用户有时对不断增长的软件世界是陌生的。在沟通和合作时，我们应该牢记这一点。通过这样做，我们可以使开源社区变得更好。
开源最前线(ID：OpenSourceTop) 猿妹编译
链接：https://css-tricks.com/open-source-etiquette-guidebook/
