2019年12月31日 openEuler 在码云上正式亮相，眼看就要一岁了。 在年底的评奖季里，openEuler 这个新生社区，收获的不仅是开源和业界的奖状，更重要的是来自合作伙伴和最终用户的认可。特别让我们感到开心的是，鹏城实验室使用基于 openEuler 的麒麟 V10 操作系统，在华为昇腾 910 服务器上，通过清华大学开发的高性能文件系统 MadFS，跑出了 IO500 世界第一的成绩。本月运作报告不仅是关于社区运作情况的总结，还提出了一些新的倡议与设想，希望能在峰会时与大家做深入的讨论。
对 10 月运作报告提出问题的跟进
10月的报告中提到两个问题，一是 openEuler 社区的 Maintainer 能力参差比较明显，二是 PR 审视与合入缺少规范。经过内部讨论，社区在 11 月采取这样几个措施。Maintainer 的能力提升。@zyp-rock 和 @overweight 两位同学在组织准备
openEuler社区开发指导课程需求收集。这是由 @zyp-rock 发起的任务，希望集合社区的力量一起完善开发指导课程。@overweight 还自告奋勇承担了和几个 SIG Maintainer 的交流工作，通过这些前期交流收集到更多的问题和诉求。我们也邀请了北京大学的周明辉老师对 openEuler 社区的运作做分析。周老师很热情的反馈了对社区运作洞见和建议。我们感到收益良多。一方面启动讨论这些建议在社区具体的落地方式，另一方面也邀请周老师在峰会上给社区所有的 Maintainer 做一个报告，介绍她对 openEuler 运作的建议。随着
openEuler微信小程序的上线，我们也高兴的看到越来越多的 SIG 例行化使用这些基础设施，例如：会议预定和线上纪要记录。有效的 SIG 例行会议从 10 月的 20 次，上升到 11 月的 41 次。有些 SIG，比如 sig-Java，已经开始例行每周的线上讨论；比如 dev-utils 的
线上会议纪要 就清晰而且开放。这段时间 @myeuler 经常接入 SIG 例会旁听进展，他给各个 SIG 的建议如下：
-
各个企业内部的 PPT 拿到社区讨论时，请提前脱敏，避免给其他与会人造成困扰。包括但不限于产品代码，路标等等。
-
对于遗留问题，在社区中提交相关的 issue 保证相关议题不丢失，建议会议的开始对遗留问题能够做审视和闭环，避免出现“议而不决”。
-
固定与会人需要保证时间，避免轮到议题时负责人缺席，议题取消的情况发生。Maintainer 是社区主心骨，开发者也是希望听到 Maintainer 的声音。
-
参会的议题还是需要做好充分的准备，建议用简洁明了的 PPT 来引导听众。
-
沟通语言上向社区统一，避免各个企业内部术语，特别是华为的员工。
-
SIG 组除了日常的例行事务，需要多讨论 SIG 未来的发展方向，我们希望每一个 SIG 都能拥有自己原创的项目。
openEuler 社区也在努力从其他成功的开源项目中学习运作的方式。特别是 Apache 基金会的孵化机制。对于 Apache 基金会来说，所有开放给 Apache 基金会的项目，都首先要进入孵化器进行孵化。在孵化器中完成代码和知识产权的移交，然后在导师的指导下完成构建过程梳理、代码规范制定、官网构建、版本发布，最终达成生态构建的目的。当前 openEuler 运作时，通过 CLA 签署等动作部分完成了孵化中的要求。但是我们缺少导师以及孵化过程的指导。而且社区本身的文档还比较缺少，使得新 SIG 成立后，Maintainer 需要花费很大的精力寻找相应的文档和负责人。因此技术委员会希望发起 openEuler 社区的导师制度。理想情况下，为后续新建的每个 SIG 配备 2 到 3 名导师。这个倡议需要社区里各方的支持。具体如何运作，会放在 openEuler Summit 上讨论。我们希望通过工具的改进来统一提升 openEuler 社区的代码质量，同时降低维护者和开发者的工作压力。openEuler 社区原创的项目中，Compass-CI,pkgship,patch-tracking,sync bot, review_tool 等工具针对开发过程的各个阶段，都提供了一些解决方法。相关的开发者也都申请了 openEuler Summit 的技术分享议题，欢迎对这方面内容感兴趣的伙伴们到现场交流。其中，review_tool 是为了提升 PR 审视过程而开发的。review_tool 最初的想法受到
FedoraReview 的影响。Fedora 社区在引入一个新的软件包的时候，有一个相对的完整的 Review Check List。这其实也是很多领域的最佳实践，比如航空领域中起飞前检查清单。但从 openEuler 角度看，构建/执行 rpmlint 等等操作，应该是 CI 的一部分。所以我们试图按照 openEuler 的理念实现一个能在 openEuler 社区推广的工具，而没有去尝试复用 FedoraReview。当前 review_tool 和 FedoraReview 在代码上没有任何的关系。@smileknife 在和基础设施团队合作，准备将 review_tool 生成的审视清单作为 PR 处理流程中的一部分。
openEuler 与学术界的合作
在 2020 年，openEuler 社区参与了中科院软件所发起的开源软件供应链点亮计划 ，在其中扮演了重要的角色；当前正在举办的 openEuler 高校开发者大赛，也吸引了众多参与者。但我们认为 openEuler 与学术界的合作，还有很大的提升空间，希望能够在未来的 2021 年进一步拓展 openEuler 社区与学术研究机构的互动。比如操作系统、编译原理等基础学科教育领域，openEuler 可以作为实验或者竞赛的平台；比如高校或者研究机构的新技术探索，可以通过 openEuler 做集成验证与发布；比如开源生态的运作，可以把 openEuler 作为一个典型案例分析。我们也注意到国内学术界对基础软件，对开源社区运作的研究投入还在不断增加。技术委员会希望搭建一个连接 openEuler 社区，参与社区的商业公司，以及学术研究机构之间的桥梁。具体的方案，计划在 openEuler Summit 上讨论。
LTS 版本开发
openEuler 20.03-LTS-SP1 在11月23日已经代码冻结，进入了第一轮封闭测试。这个 SP 版本中，目前看除了 LTS 已有本身软件演进与特性增强外，树莓派、DDE、UKUI 以及 HA 都有计划集成到社区版本中。具体的特性与问题修复清单，将在 LTS-SP1 发布之后完整说明。这是第一次 LTS 的 SP 版本开发，社区与合作伙伴之间还有不少需要磨合的点。但值得一提的是，@charlie_li 分享的 LTS-SP1 测试方案文档，这应该是除了文档团队之外，第一份基于 Creative Common 协议发布的 openEuler 开发过程文档。虽然是一小步，但也体现了 openEuler 坚定向透明、开放共建的方向前进的决心。
