我对 FOSS 存储库做出了贡献，增加了重要的范围。在向 FOSS 存储库添加新功能时，什么时候最好创建新的分支/存储库，而不是拉取请求？这里的最佳实践是什么？
向存储库添加新功能的最明显方法是通过 PR 做出贡献。它使维护人员有机会将您的扩展合并到项目中。缺点是贡献会增加，并且范围/复杂性会在最初可能不希望的方向上增加。维护者显然必须小心将哪些贡献拉入回购协议。
作为贡献者，为了尊重软件的维护者和最初的愿景，是否应该创建一个新的分支/存储库，而不是拉取请求？变革何时爆发？什么时候贡献有新的方向？什么时候功能会难以维护？只有在 PR 被拒绝的情况下才应该创建新的存储库吗？等等
例如：许多人分叉 Linux 发行版，进行微小的更改，并拥有自己的个性化发行版，而不是将他们的更改作为 PR 添加到源发行版中。
我以这两种方式为各种项目做出了贡献，并且听到了对这个问题的不同答案，但希望获得最佳实践。
我认为你从根本上误解了 github（和 FOSS 开发）的工作原理。
拉取请求总是从一个分支发送到另一个分支，即从进行更改的分支发送到某个包含您所贡献的软件的开发版本的分支（某些存储库使用主分支，其他存储库则使用一个或多个分支）更多开发分支）。阅读文档和/或与软件维护人员交谈，找出哪个分支是正确的以及您的 PR 应该满足哪些要求。
在 Github 中，您还可以执行跨存储库拉取请求，以分支中的分支作为源，将原始（也称为“上游”）存储库中的分支作为目标。
由于几乎所有 FOSS 项目都限制将存储库直接提交给受信任的贡献者（并避免在所有其他情况下使主存储库混乱），因此您应该始终创建自己的分支，在那里进行更改，然后创建 PR 以带来上游贡献。
我倾向于将大多数这些分叉保留为私人存储库，因为其他人不需要看到我的半成品。但是，如果您认为值得其他人看到它，请随意将分叉公开。由于我们谈论的是 FOSS，所以这不应该是许可问题 - 如果您不被允许进行公共分叉，那么它就不是 FOSS。不过，请注意商标。一些自由软件具有与之相关的商标名称，您不能随意复制。
如果您正在修复错误或添加功能，那么与上游维护者讨论他们是否想要合并它总是值得的 - 这是拉取请求的一种用途。如果他们不想要，他们可以拒绝 PR。
如果您计划对现有功能进行大规模更改，那么在开始之前与上游维护人员讨论您的计划通常是个好主意。也许他们很热情并且想要加入，也许他们已经尝试过类似的事情并且可以告诉你为什么它没有成功，也许他们愿意部分，但不是全部。
如果您的版本由于不会合并到上游的更改而开始显着分歧（例如，如果您正在进行上游维护者不喜欢的完整重新设计），那么最好为版本选择不同的名称您的软件，以防止混淆哪个是哪个。
永远不要因为制作叉子而感到难过。这是你能做的最自由和开源的事情之一。