你可能已经看到了这篇文章，或者是因为你通过某种方式找到了它，或者是通过链接，也许是在一个已关闭的拉取请求（PR）、问题（Issue）或聊天中。如果你来自一个已关闭的问题或 PR，那么首先要感谢你的贡献和帮助，我非常感激 ❤️。
问题是，维护多个开源项目并不像你想象的那么容易。 作为一名全职的开源项目维护者，我每 12 小时就会收到 200 多条通知和随机信息，而且所有通知和信息都需要回复。这些信息往往来自完全不同的人，他们的背景、技能水平、关注的重点等等都不尽相同。
我知道你们面临的问题很重要，足以让你们来到 GitHub 并尝试报告以修复它们。我也知道你们可能会
- 希望某个功能能够上线
- 希望解决一个 bug
- 希望你的 PR 得到审核或发布
- 希望得到更新和跟进
- 希望做出贡献并等待维护者的更新
以上当然是维护者的责任，但我们的能力有限。请理解，你的请求对你来说无疑是超级重要的，但它并不是唯一需要解决的问题。有时，在你看来很小的问题，其范围却比你想象的要大得多，即使是解释问题也耗费时间和精力。
我建议阅读 Addy Osmani 撰写的 管理上下文切换的混乱 managing the chaos of context switching 一文，以掌握一些上下文。
有时，你可能会认为回答或修复问题只需要几分钟。我理解你的想法，也希望尽快回复你，但如果为了你的要求而不得不这样做，我的成本就会大大增加，也会降低我的日常工作效率和专注度。对我来说，每个人的需求都很重要，我需要根据常识和实际情况来确定优先顺序。
你或其他人可能已经开始尝试提出改进或修复建议，但你看到对你来说整体看起来不错的 PR 仍在等待处理。甚至维护者或其他人（虽然他们真的不应该！）也可能已经部分或全部批准了 PR。而你却发现它仍未被合并。以下是一些可能的原因：
- 代码质量不够好，维护者想“礼貌”一点，不要打击作者的积极性
- 该 PR 虽然只针对一个具体问题，但与整个项目的目标不符
- PR 需要更彻底的测试和扩展验证
- 维护者需要对修改进行“思考”
- 维护者忙于其他优先事项
无论如何，请耐心等待。请相信，维护者最喜欢的事情就是分流 PR 并将其向前推进。请理解，在项目中做决定并不像你想象的那么容易。大多数情况下，你可能不太了解更多的背景情况。
最后，如果某些改动对你至关重要，而且你认为自己可以接受这些改动，但你/你的用户需要承担风险，那么你可以使用 patch-package 等解决方案手动应用这些改动。
太棒了！没有什么比为开放源码软件项目做出贡献更好的事了。
当我觉得一项任务可以接受贡献时，我会尽可能在时间允许的情况下提供更多细节。如果你看到这样的问题，我们非常欢迎你提供帮助，但请务必严格遵守这些意见，如有异议，请在尝试修改前进行讨论。如果维护者没有明确答复，请保持耐心；如果该问题明确表示不接受贡献，则表示它根本不开放！
请理解，贡献总是需要双方的合作。否则，虽然你的目标可能是好的并愿意提供帮助，但你可能会因此而拖慢工作进度。
只有当作者处理问题的成本 ≤ 时间成本时，合作才有意义。
请不要这样。这样做没有任何帮助，最终可能导致你的请求被故意延迟、忽略、标记为垃圾邮件或关闭。但千万不要认为你的请求是被故意延迟的，默认情况下它肯定不会被延迟！
请耐心理解 FOSS 的工作方式。
在沟通时，请尽量为维护者提供更好的背景信息：
- 为什么某些事情很重要并需要优先处理
- 为什么你认为应该以特定的方式完成某件事？
最后，如果你想贡献代码或跟进 PR，请与维护者保持一致，以尽量减少合作成本。此外，请将你的 PR 限制为一个明确的修复，并尊重项目惯例和代码风格。
从一个已经延迟的问题或 PR 到这些注意事项可能并不令人愉快（对我来说也是如此），但除非我们对开源如何运作以及作为维护者的感受缺乏共同的认识，否则我们无法一起把事情做得更好。