术语“维护者”涵盖了从处理补丁和拉取请求几乎全职工作的人，到负责小特性或驱动程序的人的广泛范围。
与本章的大部分内容不同，本节适用于后者（更多人的群体）。它提供了维护者小规模代码部分的建议，并描述了期望和责任。
驱动程序等通常没有自己的邮件列表和git树，而是在更大子系统的列表上发送和审查补丁。
责任
维护工作的量通常与代码库的规模和受欢迎程度成正比。小特性和驱动程序应该需要相对较少的关注和维护。然而，当工作到来时（以需要审查的补丁、用户错误报告等形式），必须及时采取行动。即使特定驱动程序每月或每季度只看到一个补丁，一个子系统可能会有一百个这样的驱动程序。子系统维护者不能等待很长时间才能听到审阅者的回复。
对响应时间的确切期望会因子系统而异。子系统设定的补丁审查SLA有时可以在子系统文档中找到。如果找不到，作为一个经验法则，审阅者应该尽量比子系统维护者的通常补丁审查延迟更快地做出回应。由此产生的期望可能从快节奏子系统（例如网络）的两个工作日，到内核较慢移动部分长达几周。
邮件列表参与
Linux内核使用邮件列表作为主要的沟通形式。维护者必须订阅并关注适当的子系统广泛邮件列表。可以通过订阅整个列表或使用更现代的选择性设置（如lei）来实现。
维护者必须知道如何在列表上进行沟通（纯文本，没有侵入性的法律页脚，不是顶部回复等）。
审查
维护者必须审查所有仅涉及其驱动程序的补丁，无论多么微不足道。如果补丁是对整个树的更改并修改了多个驱动程序，则是否进行审查留给维护者决定。
当一个代码片段有多个维护者时，来自单个维护者的Acked-by或Reviewed-by标签（或审查意见）足以满足此要求。
如果对特定更改的审查过程或验证将超出子系统的预期审查时间表，维护者应该回复提交，指示正在进行工作，并说明何时可以期望获得完整结果。
重构和核心更改
偶尔需要更改核心代码以改善整个内核的可维护性。维护者应该在场并帮助指导和测试其代码的更改以适应新的基础设施。
错误报告
维护者必须确保及时解决其代码中报告给他们的严重问题：回归、内核崩溃、内核警告、编译错误、死锁、数据丢失以及其他类似范围的错误。
此外，如果报告的质量合理或指示可能严重的问题，维护者还应该回复关于其他类型的错误报告，特别是如果它们在MAINTAINERS文件中具有支持状态。
选择维护者
前一节描述了维护者的期望，本节提供了选择维护者的指导，并描述了常见的误解。
作者
最自然和常见的维护者选择是代码的作者。作者对代码非常熟悉，因此是最适合持续照顾它的人选。
也就是说，成为维护者是一个积极的角色。MAINTAINERS文件不是一个名单（事实上，还有一个单独的CREDITS文件），而是那些将积极帮助处理代码的人的名单。如果作者没有时间、兴趣或能力来维护代码，必须选择不同的维护者。
多个维护者
现代最佳实践规定，无论多么微不足道，任何代码片段都应该至少有两个维护者。这样可以分担负担，帮助人们度假，防止过度劳累，培养社区的新成员等等。即使有一个明显的完美候选人，也应该找到另一个维护者。
维护者必须是人类，因此，将邮件列表或组邮件添加为维护者是不可接受的。信任和理解是内核维护的基础，而邮件列表无法建立信任。除了人类之外，拥有邮件列表也是完全可以的。
公司结构
对外人来说，Linux内核可能类似于一个以Linus为首的分层组织。虽然代码以分层方式流动，但公司模板在这里不适用。Linux是一个由（很少表达的）相互尊重、信任和便利所维系的无政府状态。
这一切都是说，经理几乎永远不会成为好的维护者。维护者的位置更接近于一个值班轮换，而不是一个权力职位。
作为维护者的人选的以下特征是明显的警示信号：
- 社区不认识的人，以前从未向列表发送过邮件
- 没有编写任何代码
- （当开发是外包时）为付款开发的公司工作，而不是实际进行工作的公司
不遵守规定
子系统维护者可以从MAINTAINERS文件中删除不活跃的维护者。如果维护者是重要的作者或在代码开发中扮演了重要角色，他们应该被移到CREDITS文件中。
删除不活跃的维护者不应被视为一种惩罚行为。拥有不活跃的维护者会产生实际成本，因为所有开发人员都必须记住在讨论中包括维护者，并且子系统维护者要花费大量精力来想办法征求反馈。
子系统维护者可以删除缺乏维护的代码。
子系统维护者可以拒绝接受来自反复忽视其维护职责的公司的代码。
