译:疲惫开源维护者的笔记

原文:https://github.com/pi0/tired-maintainer
作者:pi0
译者:ChatGPT 4 Turbo

编者注:写出了忙碌的开源维护者的心声。

嗨。你可能是因为某种方式发现了这段文字,或者通过一个链接,可能是在一个已关闭的 Pull-Request、Issue 或聊天中。如果你是从一个已关闭的问题或 PR 来的,在一切之前,感谢你的贡献和帮助,我真的很感激 ❤️

事实上,维护多个开源项目并不像你想象的那么容易。作为一个全职开源项目维护者,我大约每 12 小时就会收到 200 多个通知,加上随机消息,而且都需要回应。这些通知通常来自完全不同的人,他们有着不同的背景、技能水平、优先级关注等等。

我明白你遇到了一些重要的问题,这些问题让你来到 GitHub 并尝试报告以解决它们。我也知道你可能会:

  • 希望一个功能能够上线
  • 希望一个错误得到解决
  • 希望你的 PR 被审查或发布
  • 想要获得某事的更新和后续跟进
  • 想要贡献代码,正在等待维护者的更新

以上是维护者的职责,但我们的能力有限。请理解,虽然您的请求对您来说无疑非常重要,但它并不是唯一需要解决的问题。有时候,您认为小的问题实际上比您想象的要复杂得多,即便是解释这个问题也需要时间和注意力

上下文切换是昂贵的(对于人类和机器而言)

我建议阅读 Addy Osmani 的文章《管理上下文切换的混乱》,以了解一些背景。

有时你可能会认为回答或解决某事只需要几分钟。我理解并希望尽快回复你,但如果我必须为了你的请求这样做,这会让我付出很大代价,并且破坏我的日常工作效率和专注力。每个人的需求对我来说都很重要,我需要根据常识和实际情况来确定优先顺序。

这个 PR 对我来说看起来不错(或者告诉我该怎么做)

你或其他人可能已经提出了增强或修复的建议,并且你看到 PR 总体上看起来不错,但仍然处于待处理状态。即使是维护者或其他人(尽管他们真的不应该!)可能已经部分或完全批准了 PR。而你看到它仍然没有被合并。这里有一些可能的原因:

  • 代码质量不够好,维护者在尽量“礼貌”,不想打击作者
  • 这个 PR 虽然解决了一个特定问题,但与整个项目的目标不兼容
  • 这个 PR 需要更彻底的测试和扩展验证
  • 维护者需要“思考”更改的内容
  • 维护者忙于其他优先事项

在所有情况下,请保持耐心。请确信,维护者最喜欢的就是处理 PR 并推动它们向前发展。请理解,在项目中做决定并不像你想象的那么简单。大多数时候,还有更多你可能不太了解的背景。

最后,如果某些内容对您至关重要,并且您相信您可以承担这些更改带来的风险,您或您的用户,您可以使用像 patch-package 这样的解决方案来手动应用这些更改。

我想要贡献,请告诉我该怎么做

太棒了!没有什么比为开源软件项目做出贡献更让人感觉良好的了。

当我觉得一个任务可以接受贡献时,我会尽可能提供更多细节,并且在时间允许的情况下。如果你看到这样的问题,非常欢迎你帮忙,但请确保严格遵循那些评论,如果不同意,请在尝试更改之前讨论。如果维护者没有明确的答复,请保持耐心,同时如果问题明确表示不开放贡献,那就是真的不开放!

请理解,贡献总是需要双方的合作。否则,虽然你可能是出于好意并愿意帮忙,但可能会因此而减慢进度。

合作只有在成本 作者解决问题所需的时间成本时才有意义。

所以我会尽可能地联系你

请不要这样做。这样做没有帮助,反而可能导致你的请求被故意延迟、忽略、标记为垃圾邮件或关闭。但通常不要默认认为你的请求是故意被延迟的,它肯定不是故意延迟的!

那么我怎么能帮忙?

请对 FOSS 的运作方式保持耐心和理解。

在沟通时,请尽量向维护者提供更清晰的上下文:

  • 为什么某事很重要并且需要优先考虑
  • 你为什么认为某事应该以特定的方式来做?

最后,如果你想为代码做出贡献或跟进某个 PR,请与维护者保持一致,以减少合作成本。同时,请确保你的 PR 限于一个明确的修复,并且遵守项目约定和代码风格。

最后说明

从一个已经延迟的问题或 PR 来到这些笔记可能不太愉快(我也一样),但除非我们之间有对开源是如何运作的以及成为维护者是什么样的共同认识,我们无法一起改善情况。