关于贡献、自豪与傲慢

作者： 作者： Kaj Arnö 1 条评论 关于贡献、自豪与傲慢的评论

在 MariaDB Foundation，我们为 MariaDB Server 获得了大量贡献而感到自豪。但我们不想变得傲慢，所以这里是对我们现状和希望实现目标的更新。

首先，我们在多个场合展示了我们的贡献自豪感。在 2019 年 2 月 15 日，我发了一条推文：

重复：在代码贡献方面，#MariaDB 以 1009 对 247 击败 #MySQL：我们在 GitHub 上有超过一千（1009）个已关闭的 pull request（还有 179 个开放），MySQL 有 247 个已关闭（1 个开放）。

在我们的 2018 年年度报告中，我们用了几页篇幅谈论 pull request 和 patches，展示了代码贡献统计数据。我们列出了 2018 年和 2009-2018 年历史总榜的前 30 名个人提交者。我们感谢所有贡献，并希望它们能持续涌现。

与此同时，我们还远未完美。部分贡献来自 Tempesta，它是 MariaDB Corporation 的分包商，因此只是半外部的。此外，我们有相当数量的贡献积压，这意味着有些贡献者通过 GitHub 提交了 pull request，但他们的贡献尚未合并到代码库中。他们正在等待，这让他们感到沮丧。这对所有人来说都是令人失望的：MariaDB Foundation 错失了改进 MariaDB Server 的机会，贡献者看不到他们的辛勤工作上线并感到沮丧，而 MariaDB 的用户也无法使用新功能。对我们来说，改进这个流程似乎是理所当然的事。

这就是我们着手要做的事情。经过一些内部会议后，我们与我们最多产的贡献者，来自 IBM 的 Daniel Black 进行了交流——以 pull request 的绝对数量衡量，他贡献最多。目标是改进我们的贡献处理，或者用稍微技术化的语言来说，是改进我们的 pull request 处理。我们希望在合理的时间内消除积压，如果可能的话，不增加额外的资源。我们把问题表述如下：

最终目标

  • 减少开放 pull request 的积压
  • 激励贡献者进行更多贡献

实现目标的方法

  • 明确设定贡献者的期望
  • 文档化、细化、改进 pull request 处理流程

具体来说，我们想检验几个假设：

1. 等待很糟糕，看到自己已合并的贡献被撤销更糟糕。Daniel 证实了这一点。因此，我们不会改变对合并非常严格的政策，而是宁愿小心谨慎，只以可持续的方式进行合并。

2. 上下文切换很糟糕；互动性可以加快流程。有意义的贡献并非易事，审阅者需要花时间深入研究。审阅者可能会有详细的问题，而贡献者回答这些问题也需要时间。我们的想法是在提交后尽快在审阅者和贡献者之间引入半强制性的初步联系，在此联系中，审阅者向贡献者提供初步反馈，提出需要澄清的问题，并设定合并流程时长的预期。合并不是持续发生的，而是在特定的冲刺中进行，我们最好正确设定贡献者的期望，因为从提交 patch 到看到它正式发布的过程可能非常漫长。

Daniel 同意这个理由。我们的计划是向所有审阅者确认他们是否准备好进行这种初步审阅，以及是否通常能在相当短的时间内完成（不包括会议和年度假期）。我们的计划是审阅通过 Zulip 进行，采用类似 IRC 的文本互动。如果贡献者和审阅者愿意，他们也可以通过视频进行互动，使用任何他们认为合适的共同工具。

除了检验我们的假设外，与 Daniel 的会议以及随后与 MariaDB Corporation 服务器团队工程副总裁 Rasmus Johansson 的讨论得出了另外两个关键结论：

3. 在 GitHub 上保留所有互动的书面记录是强制性的，但这还不够。仅在 GitHub 上进行互动会导致前面提到的上下文切换，此外，审阅者的评论也不总是容易理解。我们是要求贡献者修改什么，还是不改？这是建议还是要求？下一步是什么，由谁来做？写作是一项困难的任务！部分问题可以通过选择聊天而非电子邮件作为沟通方式来解决，但是，这样的话沟通内容必须在 GitHub 上进行总结，而且并非所有互动都会通过聊天进行。

4. MariaDB Foundation 管理员应进行 Pull Request 的生命周期管理。这意味着不仅通过官方方式（Jira）提醒审阅者，还可以通过互动方式（Zulip），在聊天中提醒审阅者处理 pull request。审阅者可能主要负责审阅 Corporation 同事的代码，可能需要提醒外部贡献有何不同之处。如果审阅未能按合理预期进行，管理员也可以催促审阅者，这样贡献者就不会在未知期限内被搁置。

因此，我们计划为我们的审阅者制定一些指南，这将在我们为负责与贡献者进行初步联系的管理员推出的已经相当详细的指南基础上进行。这个初步步骤包括检查贡献是否使用了允许我们接受的许可证、将事项输入 Jira、找到合适的合并版本以及分配正确的审阅者。这通常应该在贡献后的下一个工作日内完成，但这尚未设定审阅者方面的任何期望。

总结一下，我很高兴指出我们已经取得了一些进展。2018 年期间，共提交了 535 个 Pull Request，但只有 392 个 PR 被关闭。积压因此增加了 143 个贡献。在 2019 年，我们改变了趋势，关闭了 266 个 pull request，而提交的 PR 为 238 个。积压因此减少了 28 个。这是一个开始。

总的来说，在 1302 个 pull request 中，我们关闭了 89%，即 1154 个 PR。我们正在处理剩下的 148 个。

至于“关闭”的意思，它意味着“处理”，即已合并或已拒绝。我们可以更具体一些，例如添加“已拒绝”、“非代码库合并”和“重新提交”等类别。但我们还有更基础的工作要做：在追求其他目标之前，我们现在将主要专注于减少积压和改进期望设定。

如果您对如何改进有任何意见，请联系我们！本月，Vicentiu Ciorbaru 和 Robert Bindar 将参加在美国奥斯汀举行的 Percona Live 大会，我将参加在克罗地亚斯普利特举行的 Open Shift 大会。您也可以通过 Zulip 联系我们，或使用我们的 firstname@mariadb.org 邮箱地址发送电子邮件。Zulip 和个人邮箱都可以作为升级沟通途径，如果您发现我们太慢或没有按照我们设定的期望行事。