openEuler 社区运作 2020 年 10 月运作报告

openEuler 10 个月大了。本次的月度报告比较特别，我们把目光从技术转移到社区的根本上，那就是代码和人。按照报告的惯例，我们尝试总结当前 openEuler 社区的现象，然后从现象中看到问题，以及问题的原因，帮助社区在后续运作中实现自我调整。

对于所有的开源社区，代码变更是最根本的活力体现。在码云代码托管平台上，代码的变更依托 PR（Pull Request）来实现。PR 的数量可以用来评价活力。

• openEuler 当前已合并
  3858 个 PR，关闭未合入
  989 个。
  
• src-openEuler 当前已合并
  12324 个 PR，关闭未合入
  2481 个。
  

再算上目前正在处理的 PR，openEuler 社区 PR 总和已经超过了 20000 个。平均每天有超过 60 个 PR 进入到社区，这个结果还是很让人振奋的，说明 openEuler 社区保持了相当的活力。做一个不太恰当的比较，Kubernetes 项目有近 60000 个 PR，短短的 10 个月，我们的 PR 数量已经达到了老牌开源社区 Kubernetes 的三分之一，这充分说明了 openEuler 是一个充满活力的社区。

我们关注的第一个问题是：为什么会有关闭未合入的 PR？

我们对实际 PR 做了分析，发现关闭的场景大多出现在对 gitee 开发流程不熟悉的新贡献者，因为不知道如何正确的 rebase 或者解决冲突，关掉然后重新开新 PR 反而成了最简单的解决方案。也就成了新贡献者的常态。我们观察到一些提交记录，都是重复地关闭然后重新提交了多次。而这在其他社区看起来也是开源项目的常态。

简单算术可知，openEuler 代码仓中的关合比大约是 26%，而 src-openEuler 中是 20%。

@initlove 帮助获取了一些其他成功开源项目的相关数据。比如 Kubernetes，44880 merged， 13579 closed，关合比 30.3%；runc 也是 30%，而 hadoop 则高达 53%。

从这个比较看，我们的关合比例不是太高，而是太低了。这进一步激起了好奇。

技术委员会和相关的一些 maintainer 做了小范围讨论，当前我们理解是这样的：

1. openEuler 的开发过程参与相对其他的成功开源项目，参与者大多数来自特定领域，其实并不够开放的。作为一个特定案例，openeuler/community 是大部分 OS 无关开发人员的参与入口，这个代码仓的关合比是
   59.8%。我们觉得这个比例大致上是外部开发者参与比较多的情况下，更正常的比例。而 src-openEuler 的关合比更低，也是因为这部分参与者主要都是国内有经验的 OS 开发厂商员工。
   
2. 当前 openEuler 开发过程中对贡献者的指导（甚至包括部分的 SIG maintainer）不到位，我们理想中的码云工作流程，其实能被贡献者了解并接受的比例非常低。
   

由此，我们进一步审视了当前 PR review 过程中的一般性问题，我对社区中的 PR 做了抽样调查：

1. 绝大部分的 PR 关闭，并不是因为 review 过程中提出的显示拒绝，而更多是门禁发现的问题。这提醒我们注意 maintainer 对于当前 PR 合入，除了批准之外，给予提交者的指导和反馈不足。CI 发现的问题，是合入的最低标准，不应该直接替代合入标准。比如：
   !1 sync from upstream linux-nvme
   ^[1] 这个提交，码云的內建代码扫描工具提示有 261 个规范问题，但是在 PR 的讨论中，除了 maintainer 反复留下 /lgtm 和 /approve 之外，没有任何有意义的文字讨论关于代码本身。这体现了我们的 maintainer 对 PR 审视动作本身的不够重视。
   
2. 相应的，还有不少 PR 长期处于开放状态。这里有一些是 maintainer 不活跃导致的，比如
   !4 modify makefile, delete some test
   ^[2] ，这是 10 月 20 日创建的 PR，maintainer 当前还没有任何响应；而另一些则是因 maintainer 对 openEuler 的自动化流程机制还不熟悉，有一些常见的问题。比如 maintainer 只留了 /approve 却忘了 /lgtm，或者反过来，或者是看不懂 CI 错误，不知道怎么指导贡献者做修改。例如：
   !1 移植开源项目openstack-keystone的源码到openEuler社区
   ^[3] 。
   
3. openEuler 的 review 过程不够结构化。虽然不同的领域，不同的组件的 review 要求是应该有自己特点的，但是实际情况则是同一个 SIG 的不同 maintainer 也各自有评审偏好，并不统一。随之而来就是 PR 合入的最终状态，取决于当时参与的 reviewer(s)。有些 SIG 的合入门槛过于宽松，对代码中明显的问题也放过不提。
   

由此看到，openEuler 技术委员会对 maintainer 的辅导，maintainer 对贡献者的辅导，都是不足的，我们的沟通方式上还有很大的改进空间的。作为一个改进措施，从本月开始，所有新的 maintainer 都会收到 openEuler 技术委员会的一封邮件。我们也欢迎 maintainer 们发邮件给 tc@openeuler.org 讨论。

考虑到 maintainer 是社区真正的中坚力量，我对当前 openEuler 社区中所有拥有批准合入权限的账号（视同为各个组件的 maintainer）在码云上的公开活动记录做了整理。

在这个调查中，我关注 maintainer 近期公开活动记录中的以下几个事实：

1. 作为一个 SIG 的 maintainer，在码云上有没有贡献度。码云的贡献度包括了代码提交，issue 创建，PR 提交，以及 PR 合并。这个统计是针对码云全站的，所以这个贡献度并不能直观反映 maintainer 对 openEuler 项目的代码贡献。
   
2. openEuler 的 maintainer 通过对 PR 的 comment，和 ci bot 以及代码提交者交互。我关注 maintainer 履职的情况（通过 /lgtm 和 /approve 批准合入），以及在履职过程中，是否通过讨论，牵引帮助贡献者更快融入社区。
   
3. 关注 maintainer 有没有直接参与 openEuler 社区的代码贡献。
   

当前 openEuler 共有 163 个 maintainer 账号。

1. 有
   36 个账号，无论是作为 maintainer 还是作为开发者，都活跃在当前 openEuler 日常开发的第一线。是社区当之无愧的中流砥柱。
   
2. 有
   4 个账号看起来是 openEuler 社区的早期开发者，在今年 6 月之后就没有继续参与 openEuler 社区。我认为这些 maintainer 对 openEuler 的贡献是值得尊重的，但同时也没有必要继续占用 maintainer 的名额。我们可以设立社区的 Honorable 奖，给这些曾经为 openEuler 做出过贡献的朋友。
   
3. 其中
   21 个账号几乎从没参与过 openEuler 的开发和讨论工作，其中 1 个账号已经失效。看起来这些开发人员并不适合也没有意愿作为 openEuler 社区的 maintainer。建议各个 SIG 考虑这些 maintainer 的退出机制。
   

剩下的 102 个账号，多多少少存在需要改进的地方：

1. 一类是几乎没有代码贡献，从不参加讨论，只评审合入 PR 的，可以被看做（很有可能是）工具人。这样的 /lgtm 和/approve，我觉得是没有温度的，个人认为这样的 maintainer 不值得托付。
   
2. 另一类是推送代码很多，但从来不参与评审 PR 活动。也就是说这些同学实际上没有承担 maintainer 的职责，更适合作为开发人员。
   
3. 第三类是很活跃的参与社区讨论，review，但基本没有代码活动。这类 maintainer 可能会逐步丧失技术敏感性（至少针对 openEuler 社区而言），这需要提请注意。
   

技术委员会还要讨论如何培养 maintainer，如何规范 PR review，把 openEuler 的代码质量做到日常运作过程里去。这将会在未来几个月的报告中重点关注。

openEuler 社区计划在 12 月 24-25 日两天在北京召开 openEuler Summit，这次 Summit 我们会专门针对社区的开发工作的流程，文化培养等举行相关议题研讨，欢迎大家能够积极参与 Summit ，共同营造一个健康的社区文化。

参考资料