特性与驱动维护者¶
“维护者”一词涵盖了极其广泛的参与程度，从几乎将处理补丁和拉取请求作为全职工作的人，到负责某个小特性或驱动程序的人。
与本章的大部分内容不同，本节是为后者（人数更多的一组）准备的。它提供了针对小型代码段维护者的建议，并描述了对他们的期望和职责。
驱动程序及类似代码通常没有自己的邮件列表和 git 树，而是在更大子系统的邮件列表上发送和审查补丁。
职责¶
维护工作量通常与代码库的大小和流行程度成正比。小特性和驱动程序所需维护和照料的工作量应该相对较少。尽管如此，当工作真正到来时（以需要审查的补丁、用户错误报告等形式），必须迅速采取行动。即使某个特定的驱动程序一个月或一个季度才收到一个补丁，一个子系统也可能有一百个这样的驱动程序。子系统维护者经不起长时间等待审查者的回复。
对响应时间的具体期望因子系统而异。子系统为其自身设定的补丁审查服务等级协议（SLA）有时可以在子系统文档中找到。如果没有找到，作为经验法则，审查者的响应速度应尽量快于子系统维护者通常的补丁审查延迟。由此产生的期望可能从快节奏子系统（例如网络子系统）的两个工作日，到内核中进展较慢部分的几周不等。
参与邮件列表¶
Linux 内核将邮件列表作为主要的沟通形式。维护者必须订阅并关注相应的子系统范围的邮件列表。可以通过订阅整个列表，或者使用更现代、具有选择性的设置（如 lei）。
维护者必须知道如何在列表中进行沟通（纯文本、无侵入性的法律页脚、不使用顶部发帖等）
审查¶
维护者必须审查所有仅涉及其驱动程序的补丁，无论其多么微不足道。如果补丁是跨整个源码树的更改并修改了多个驱动程序——是否进行审查由维护者自行决定。
当某段代码有多个维护者时，来自单个维护者的 Acked-by 或 Reviewed-by 标签（或审查意见）就足以满足此要求。
如果针对某个特定更改的审查过程或验证所需时间超过了子系统预期的审查时间线，维护者应对提交内容进行回复，说明工作正在进行中，以及预计何时能得到完整的结果。
重构与核心更改¶
有时为了提高整个内核的可维护性，需要更改核心代码。期望维护者能够参与进来，并帮助指导和测试对其代码的更改，以适应新的基础设施。
错误报告¶
维护者必须确保及时解决报告给他们的代码中的严重问题：回归、内核崩溃、内核警告、编译错误、死锁、数据丢失以及其他类似范围的错误。
此外，如果报告质量合理或指出了可能严重的故障，维护者也应对关于其他类型错误的报告做出响应——特别是当他们在 MAINTAINERS 文件中对代码库拥有 Supported（受支持）状态时。
开放式开发¶
关于用户报告的问题的讨论以及新代码的开发，应以更大子系统的典型方式进行。在单一公司内部的开发通常是在闭门造车（私下）进行的。但是，由社区成员发起的发展和讨论绝不能从公共论坛重定向到封闭论坛或私密电子邮件对话中。对此准则的合理例外包括关于安全相关问题的讨论。
选择维护者¶
前一节描述了对维护者的期望，本节提供关于如何选择维护者的指导并描述常见的误区。
多个维护者¶
现代的最佳实践表明，任何代码段都应该至少有两名维护者，无论它多么微不足道。这可以分担负担，帮助人们休假并防止职业倦怠，培养社区新成员等。即使明显只有一个完美的人选，也应该找到另一位维护者。
维护者必须是人类，因此，添加邮件列表或群发邮件作为维护者是不可接受的。信任和理解是内核维护的基石，人们无法与邮件列表建立信任。在人类维护者之外拥有一个邮件列表是完全可以的。
公司结构¶
对于局外人来说，Linux 内核可能类似于一个以林纳斯为 CEO 的层级组织。虽然代码按层级方式流动，但企业模板并不适用于这里。Linux 是一个靠（很少表达的）相互尊重、信任和便利维系在一起的无政府状态。
这也就是说，管理者几乎从来不会成为优秀的维护者。维护者职位更类似于值班轮换，而不是权力职位。
被选为维护者的人员如果具备以下特征，则是明显的危险信号：
对社区而言完全陌生，以前从未向列表发送过电子邮件
没有编写过任何代码
（当开发是外包的时）效力于为开发付费的公司，而不是实际完成工作的公司
未履行职责¶
子系统维护者可以从 MAINTAINERS 文件中移除不活跃的维护者。如果该维护者曾是重要的作者或在代码开发中扮演过重要角色，则应将其移至 CREDITS 文件。
移除不活跃的维护者不应被视为惩罚行为。拥有一个不活跃的维护者需要付出切实的代价，因为所有开发者都必须记住将维护者包含在讨论中，并且子系统维护者需要耗费精力去弄清楚如何征求反馈。
子系统维护者可以因缺乏维护而移除代码。
子系统维护者可以拒绝接受屡次忽视其维护职责的公司的代码。