开源项目 学会说不

把所有的事情都写下来，当然，对你执行你制定的规则的时候客观分析实际情况也有帮助。

拒绝别人确实不是很好玩，但是也要表现出专业程度，比如使用”你的贡献不符合这个项目的标准”而不是”我不喜欢你的贡献”这样显得粗鲁的语句。

作为一个维护者，在很多情况下，你都要拒绝别人：不符合项目规则的 PR, 某个人脱离了讨论的重点，给别人做无关紧要的工作等等。

保持友好沟通

你要学会拒绝的最重要的地方就是 Issue 和 PR 请求。作为一个项目的维护者, 你会不可避免的收到你不想接受的建议。

可能某个贡献并不在项目的范围或者和你的期望不合。又或者是可能想法很好，但是实现的却很烂。

不管是什么原因，在处理这些不符合项目标准的贡献的时候都要婉转。

如果你收到了你不想接受的贡献，你的第一反应可能是忽略或者假装没看到。但是这么做会严重伤害到别人而且可能会让你社区里的其他贡献者失去动力。

管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个IOS开发者，你会知道提交雷达是多么让人沮丧。您可能会在2年后收到回复，并被告知要再次使用最新版本的iOS。

— @KrauseFx , “开源社区黑客增长”

别因为自己感到内疚或者想做一个好人就把你不想接受的贡献继续保留。随着时间的流逝，这些你没有回答的 issue 和 PR 会让你觉得很不爽。

更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题，@steveklabnik 可以给你点儿建议，如何高效的解决 issue 。

第二点，忽略别人的贡献等于是在社区传递了一个负面的信号。让人感觉提交一个贡献是蛮恐惧的事情，尤其是对于刚加入的新手来说。即使你不接受他们的贡献，告诉他们为什么然后致谢。这会让人觉得更舒服。

如果你不想接受某个贡献：

• 感谢他们 的贡献
• 解释为什么他们的贡献不符合 项目的需求范围，然后提供清楚的建议以供改善，如果你可以的话。和蔼一点，但同时也要讲原则。
• 引用相关的文档， 如果你有的话。如果你发现你反复收到你不想接受的贡献，把他们加到文档以免你重复叙述。

你不需要用超过 1-2 两句话来回复。比如，当一个celery 的用户报告了一个window相关的错误，@berkerpeksag 是这么 回复的

如果你感觉拒绝别人很不好意思，也很正常，其实很多人都是这样。就像 @jessfraz 说到的 :

我和很多来自诸如 Mesos, Kubernetes, Chromium 等不同开源项目的维护者交流过，他们都异口同声的觉得做一个维护者最难的就是拒绝你不想要的补丁。

对于不想接受别人的贡献这件事不要感到愧疚。如 @shykes 所说开源的第一原则就是 “拒绝是暂时的，接受是永远的。” 当然啦，认同别人的热情还是一件好事，拒绝他的贡献和拒绝他这个人是两码事。（要做到对事不对人。）

最后，如果一个贡献不是够好，你没任何义务接受它。对那些想对你的项目做贡献的人保持和蔼和积极的态度，但是只能接受那些你确定会让你的项目变得更好的提交。你说拒绝的次数越多，对你来说拒绝别人就越容易。谨记！

保持主动

要想减少你不想接受的贡献的数量，首先，在你项目的贡献指南中解释如何提交贡献以及怎样的贡献会被接受。

如果你收到太多低质量的贡献，让那个贡献者先多做做功课，比如：

• 填写一个 issue 或者 PR 的模板/清单
• 在提交PR之前先开一个 issue

如果他们不遵从你的规则，马上关掉 issue 并引用你的文档。

当然啦，这么搞一开始是不太舒服，但是你主动一点确实对双方都好。它减少了某个人花了太多时间到一个你不想要的 PR 上的可能性。而且让你管理起来更轻松。

理论上，在 CONTRIBUTING.md 文件里面告诉别人在他们开始干活之前如何更清楚的知道的干完之后会不会被接受。

— @MikeMcQuaid , “优雅的关闭 PR “

有时候，当你说不的时候，你潜在的贡献者会感到对你的沮丧或者不爽。如果他们开始找你撕逼了，采取必要的措施以应对局势 或者干脆把他们从你的社区开除，如果他们不打算和你保持建设性的合作关系的话。

成为导师

可能在你的社区里有人不断提交一些不符合项目需求的贡献。对你们双方来说，不停的拒绝他的提交，会令双方都很尴尬。

如果你发现有人对你的项目很上心，但是就是需要调教，那就耐心一点。给他解释明白每次它的提交为什么不符合项目需求。尝试着让他先做一些简单一点的事，比如那些标有 “good first issue” 标签的 issue，以此让他慢慢习惯。如果你有时间的话，考虑教 Ta 怎么完成第一次贡献，或者在社区找一个人教 Ta。