功能和驅動維護者¶
“維護者”一詞涵蓋了非常廣泛的參與程度，從幾乎全職處理補丁和拉取請求的人員，到負責小型功能或驅動程式的人員，均屬此範疇。
與本章的大部分內容不同，本節面向的是後一類（人數更多）群體。它提供了關於一小部分程式碼的維護者的提示，並描述了他們的期望和職責。
驅動程式及類似程式碼通常沒有自己的郵件列表和 Git 樹，而是透過較大的子系統的列表來發送和審查補丁。
職責¶
維護工作的數量通常與程式碼庫的大小和受歡迎程度成正比。小型功能和驅動程式所需的維護量相對較少。儘管如此，當工作（以需要審查的補丁、使用者錯誤報告等形式）到來時，必須迅速採取行動。即使某個特定驅動程式每月或每季度只收到一個補丁，一個子系統也可能有一百個這樣的驅動程式。子系統維護者不能長時間等待審查者的回覆。
對響應時間的具體期望因子系統而異。子系統為自身設定的補丁審查 SLA（服務水平協議）有時可以在子系統文件中找到。如果找不到，作為經驗法則，審查者應嘗試比子系統維護者的常規補丁審查延遲更快地響應。由此產生的期望可能從快速子系統（例如網路）的兩天工作日到核心中較慢部分的幾周不等。
郵件列表參與¶
Linux 核心使用郵件列表作為主要的溝通形式。維護者必須訂閱並關注相應的子系統郵件列表。可以透過訂閱整個列表，也可以使用更現代、更具選擇性的設定，例如 lei。
維護者必須知道如何在郵件列表中進行溝通（純文字、無侵入性法律頁尾、不置頂回復等）。
審查¶
維護者必須審查所有專門涉及其驅動程式的補丁，無論其多麼微不足道。如果補丁是涉及整個程式碼樹的更改並修改了多個驅動程式，則是否提供審查由維護者決定。
當一段程式碼有多個維護者時，來自單個維護者的 Acked-by 或 Reviewed-by 標籤（或審查意見）足以滿足此要求。
如果對特定更改的審查過程或驗證將耗時超過子系統預期的審查時間線，維護者應回覆提交，表明工作正在進行中，並告知何時可以期待完整結果。
重構和核心更改¶
偶爾，核心程式碼需要更改以提高整個核心的可維護性。維護者應參與其中，協助指導和測試其程式碼的更改，使其適應新的基礎設施。
錯誤報告¶
維護者必須確保及時解決向他們報告的程式碼中的嚴重問題：包括迴歸、核心崩潰、核心警告、編譯錯誤、死鎖、資料丟失以及其他類似範圍的錯誤。
此外，如果報告質量合理或表明可能存在嚴重問題，維護者還應回應其他型別的錯誤報告——特別是當他們在 MAINTAINERS 檔案中擁有程式碼庫的受支援狀態時。
開放開發¶
關於使用者報告的問題以及新程式碼的開發應以大型子系統慣用的方式進行。在單一公司內部進行的開發通常是在幕後進行的。然而，社群成員發起的開發和討論不得從公開論壇重定向到封閉論壇或私人電子郵件對話。此指導的合理例外情況包括關於安全相關問題的討論。
選擇維護者¶
上一節描述了對維護者的期望，本節提供了選擇維護者的指導並描述了常見的誤解。
多位維護者¶
現代最佳實踐要求任何一段程式碼都應該至少有兩名維護者，無論其多麼微不足道。這可以分擔負擔，幫助人們休假，防止倦怠，培養社群新成員等等。即使有一個明顯的完美人選，也應該找到另一位維護者。
維護者必須是人類，因此，將郵件列表或群組電子郵件新增為維護者是不可接受的。信任和理解是核心維護的基礎，而無法與郵件列表建立信任。在人類維護者之外擁有一個郵件列表是完全可以的。
公司結構¶
對一個局外人來說，Linux 核心可能看起來像一個以 Linus 為執行長的層級組織。儘管程式碼以層級方式流動，但公司的模板不適用於此。Linux 是一個由（鮮有表達的）相互尊重、信任和便利所維繫的無政府狀態。
總而言之，管理者幾乎從不成為優秀的維護者。維護者職位更像是輪值的隨叫隨到，而非權力職位。
被選為維護者的人員若具有以下特徵，則明確亮起紅燈：
社群不認識，之前從未向郵件列表傳送過電子郵件
不是任何程式碼的作者
（當開發是承包的）為支付開發費用的公司工作，而不是實際完成開發的公司
不合規¶
子系統維護者可以從 MAINTAINERS 檔案中移除不活躍的維護者。如果該維護者是重要的作者或在程式碼開發中發揮了重要作用，他們應該被移到 CREDITS 檔案中。
移除不活躍的維護者不應被視為一種懲罰性行為。擁有不活躍的維護者會帶來實際成本，因為所有開發人員都必須記住在討論中包含維護者，並且子系統維護者需要花費精力來思考如何徵求反饋。
子系統維護者可能會因缺乏維護而移除程式碼。
子系統維護者可能會拒絕接受那些屢次忽視其維護職責的公司的程式碼。