您如何措辞“它是开源的，请提交补丁”，以便友好？

在“对它的开源，提交补丁”的典型反驳中，有什么答案？，许多人表达了这样的观点，即简单地要求人们提交补丁是傲慢无礼的。

但是在我看来，作为任何开源项目的开发人员，您在邮件列表中都会看到比您可能实现的功能更多的功能请求。因此，当用户说“我希望看到功能X”时，事情的真相通常是，除非他们自己提交补丁，否则实施该功能的可能性很小。另外，有时可能需要一些鼓励才能使用户成为贡献者。

另一方面，您不想因为粗鲁而吓跑（潜在）贡献者。

那么，您如何以友好的方式说“请提交补丁而不是请求功能”？

更新：感谢您的所有建议！我看到其中大多数需要冗长的解释。但是，由于我宁愿避免（a）每隔一天解释一次相同的事情（这会花费太多时间），还是（b）使用粘贴到电子邮件中的代码片段（它会很快变得不真实），所以我想知道：有人在我可以链接的文档中写过吗？

（当然，仍然需要记录特定于项目的事情，例如如何编写测试，编译代码和提交补丁，但我认为那些技术问题还是应该放在CONTRIBUTING.txt中。）

你不知道

就我所经历的而言，候选贡献者是修补匠，他们不会仅通过请求来提交功能请求。他们通常会要求获得一定程度的参与：

• 如果[...]会不会很甜蜜？可能会进行A，B和C。（这很诱人：我没有时间，但是如果您愿意，这是一个规范的想法）
• 这是一个补丁程序，这是[...]的修复程序。
• 我正在考虑编写一个补丁来做，可以使用反馈/有兴趣帮助的人。
• 等等。

编码员直接提交功能请求通常是出于某种原因。其中一些包括（例如，我知道事实是后两个发生在WordPress中）：

• 他们在其他开放源代码项目中深陷其中，即没有时间。
• 他们是搭便车者，并打算保持这种状态。
• 这远远超出了他们的技能水平/以他们一无所知的语言编写。
• 他们由于缺乏更好的选择而使用该软件，并且不想处理臭味累累的batsh * t ^ \ b代码。
• 他们不再被打扰，因为先前的补丁被忽略/拒绝了，即认为他们在浪费时间。

更典型的是，功能请求将来自最终用户，即使他们愿意也无法提供补丁。特别是在票务系统之外提交时。

我认为您最重要的优先事项应该是不拖延潜在/现有的贡献者，而是尝试积极招募新的贡献者。这非常重要，我是凭经验说的。我有一种怪异的方式来获取新的代码库，其中包括粗读代码以对代码有一定程度的了解，跳入票务系统，并修复易于查找的错误以深入了解内部（并归档）我测试过的新产品）。多年来，我用几十个票证和补丁充斥了一些项目。很多时候，这些故障单几乎不会引起及时关注（甚至没有得到确认，例如，继续加油！）-包括附带有记录的诊断步骤和单元测试时。

简而言之，您向您解释说您没有无限的时间免费从事他们的工作。（您可以跳过“免费”位），并且他们可以在自己喜欢的任何时间做出贡献，这不是“您的”项目，而是每个人的项目。

所以您说：“我们很抱歉，这是个好主意，但是我们正忙于其他所有工作，因此我们会将其添加到列表中，但是如果您真的想加入，并且您想通过为该项目做出贡献来帮助我们，那真是太好了。我们有一些文档可以帮助人们对项目进行更改，他们就在这里，所以如果您有技能和时间，并希望为我们提供帮助，然后请向我们发送您所做更改的补丁。我们可能会在获得补丁时对其进行一些修改，以使其符合项目的标准，但您将为我们做一个至少可以让我们对此工作有所帮助，我们将非常感谢，我们会爱上您的帮助”。

当然，一旦开始索要补丁，就永远不会让它们在票务系统上放置太久，如果您获得了很多，那么与他们以前所做的工作相比，它们将被更多地集成。您可能不喜欢这样，但是如果您希望补丁不断出现，则很有必要。

保持礼貌，并清楚说明情况。怎么样呢？

感谢您的反馈意见。我们发现您的功能非常有趣，但是尽管我们努力实现产品中最需要的功能，但是我们没有足够的时间来实现所有功能。如果您是开发人员，因为它是开源的，因此可以通过为该项目做出贡献来加入我们。

瞧，您不能只说“您为什么要打扰我？我不是在这里免费为您工作；如果您想使用此功能，请自己实施。” 该人可能不是开发人员，可能不知道用于开发产品的语言等。

因此，您可能会建议您参与该项目，而不是粗鲁无礼，并说明为什么您自己无法实现该功能。

不粗鲁的另一种方法是不必说任何话。如果您有一个网站，您的应用程序的用户可能在其中建议新功能并报告错误，则您可能希望按其优先级对项目进行排序：例如，如果某功能是由10,000位用户请求的，而另一项只有10位用户的请求， ，则有可能第一个实施。

在此类网站上，您总是可以对几天或几周后仍未收到其他用户的好评的功能提出“自己实施”的建议。

感谢您的要求。我们已将其添加到我们的项目积压中，并将很快对其进行审核。

请注意，由于请求量很大，我们不能保证会执行所有请求。我们依靠志愿者，因此，如果您是开发人员，请考虑捐赠一些时间并提交补丁。否则，请知道我们都在努力解决积压问题，并将尽快处理您的请求。

真的，那么难吗？

好吧，您不仅应该说“提交补丁”，还需要详细说明。

• 明确一点，您现在或可预见的时间没有时间，因此，如果其他人希望尽快实施，则只能提供补丁。
• 花时间评估功能。如果您真诚地喜欢它，那么这样说是没有害处的。鼓励人们。或者，如果您认为该功能实际上不好，那么请花一些时间来解释一下。
• 提供一些开始帮助。没有人像您一样了解代码库。您没有时间去做，但是您可能确切地知道如何做以及从哪里开始。在5到10分钟内，您可以分享知识，其他人需要几个小时才能弄清楚。同样，这有助于您赢得大局。您可以将贡献者引导到一个不错的整数上，而不是在项目上附加外来功能。

这是我通常说的...

“这是一个有趣的建议，如果FooBarLib能够做到这一点将是很酷的。不幸的是，FooBarLib对我来说只是一个业余时间项目，因此我不太可能在不久的将来回过头来。我欢迎向FooBarLib提交的内容，因此，如果您能够自己实现此目的，请随时提交补丁（请确保您先阅读我们的“如何为FooBarLib做出贡献”指南）。

除了说“提交补丁”的好方法之外，还提供面向开发人员的文档，以便真正希望使用此功能的其他人可以轻松加快项目进度。许多项目对开发人员都不友好，并且至少需要几天的时间才能读取数千行代码和大量的小型测试用例，然后在系统的不同部分进行调试以确保正确。

如果您向可能的开发人员提供帮助，他们将更愿意提供帮助。这意味着好的代码文档，好的Wiki页面说明了流程（或好的UML /白板图），以及使补丁被接受的简便方法。

我真的很喜欢github鼓励其他人参与该项目的方式。同一项目的多个版本可以在不同的用户帐户下存在。如果您不喜欢我正在指导的项目，则请分叉。您可以轻松提交请求，但不会等待我接受它。

因此，我的答案经常是，只需分叉即可。