Linux内核贡献成熟度模型
背景
作为2021年Linux内核维护者峰会的一部分，讨论了招募内核维护者以及维护者继任方面的挑战。其中一些结论包括，作为Linux内核社区的一部分，公司需要允许工程师作为工作的一部分成为维护者，以便他们能够成长为受人尊敬的领导者，最终成为内核维护者。为了支持强大的人才储备，开发人员应被允许并鼓励参与上游贡献，如审核他人的补丁、重构内核基础设施和撰写文档。
为此，Linux基金会技术咨询委员会（TAB）提出了这个Linux内核贡献成熟度模型。这些对上游社区参与的共同期望旨在增加个人开发者的影响力，增加组织的合作，并改善Linux内核生态系统的整体健康状况。
TAB敦促组织不断评估其开源成熟度模型，并承诺进行改进以与该模型保持一致。为了有效，这种评估应该包括来自组织各个层级的管理和开发人员的反馈。在开源精神的指导下，我们鼓励组织公开其评估和改进与上游社区的合作计划。
Level 0
- 软件工程师不被允许向Linux内核贡献补丁。
Level 1
- 软件工程师被允许作为工作职责的一部分或在个人时间内向Linux内核贡献补丁。
Level 2
-
软件工程师被期望作为工作职责的一部分向Linux内核贡献。
-
软件工程师将获得支持，作为工作的一部分参加与Linux相关的会议。
-
软件工程师的上游代码贡献将在晋升和绩效评估中予以考虑。
Level 3
-
软件工程师被期望作为工作职责的一部分审核补丁（包括其他公司工程师编写的补丁）。
-
向Linux相关或学术会议（如Linux基金会、Usenix、ACM等组织的会议）贡献演讲或论文被视为工程师的工作的一部分。
-
软件工程师的社区贡献将在晋升和绩效评估中予以考虑。
-
组织将定期报告其开源贡献的指标，并随时间跟踪这些指标。这些指标可以仅在组织内部发布，或者根据组织的决定，部分或全部可以在外部发布。强烈建议包括以下指标：
-
团队或组织的上游内核贡献数量（例如，所有向经理、总监或副总裁汇报的人员）。
-
在组织中，已经向上游贡献的内核开发人员所占的比例与组织中总内核开发人员的比例。
-
组织服务器和/或产品使用的内核版本与基于内部内核的上游内核发布日期之间的时间间隔。
-
内部内核中存在的离线提交数量。
Level 4
-
鼓励软件工程师在工作时间的一部分专注于上游工作，包括审核补丁、担任程序委员会成员、改进核心项目基础设施（如编写或维护测试）、上游技术债务减少、撰写文档等。
-
支持软件工程师参与组织Linux相关会议的组织工作。
-
组织将在官方绩效评估中考虑社区成员的反馈。
Level 5
-
上游内核开发被视为正式的工作职位，至少三分之一的工程师时间用于上游工作。
-
组织将积极寻求社区成员的反馈作为官方绩效评估的因素。
-
组织将定期在内部报告上游工作与直接追求业务目标的工作比例。