LWN：建立健康的内核子系统社区！

关注了就能看到更多这么棒的文章哦～

Creating a healthy kernel subsystem community

By Jake Edge
September 12, 2025
OSS EU
Gemini flash translation
https://lwn.net/Articles/1036908/

在开源项目中创建热情友好的社区，是各类会议上反复讨论的话题；这些项目依赖于他人的贡献，因此营造欢迎的氛围至关重要。多年来，Linux 内核项目因其在这一方面声名狼藉，常被引为不友好项目的例子，尽管人们曾多次（现在也仍在）付出努力来改变这一现状，并取得了不同程度的成功。Hans de Goede 在 欧洲开源峰会上的一次演讲（YouTube 视频）中，谈到了在他负责的内核项目领域所做的这些努力。

De Goede 自我介绍说，他是红帽（Red Hat）员工，主要从事 Linux 硬件启用工作，"所以大部分是驱动相关的事务"；自此次演讲之后，他已宣布将在任职 17 年后离职。最近，他一直专注于笔记本电脑和 MIPI（移动行业处理器接口）摄像头。自 2020 年以来，他一直是 platform-drivers-x86 (pdx86) 内核子系统的维护者（maintainer）。

友好的邮件列表

他首先提出了一些建议，旨在将邮件列表（mailing list）打造成一个“友好而热情的地方”。内核邮件列表素来声誉不佳，"有时邮件措辞可能粗鲁或不友好；不过最近情况有所好转，正在向好的方向发展"。然而，这种不佳的声誉依然存在，许多人仍然觉得向邮件列表发帖是件令人望而生畏的事情。

作为一名内核维护者，他希望以身作则，因此在回复邮件列表帖子时，他总是力求专业和友好。一个问题可能看起来很愚蠢，但提问者很可能只是缺乏 De Goede 所具备的背景和知识；他试图设身处地为他人着想，并建议回复者回想自己第一次提交补丁（patch）时的情景。因为繁忙和压力而发出抱怨的回复于事无补；耐心是一种美德，"深呼吸，默数到十，保持耐心"。贡献者（contributor）和维护者都在努力改进内核，因此维护者应假定对方怀有善意——即便需要多次解释同一件事。

语言障碍可能是一个主要的问题来源。对 De Goede 来说，英语并不难，因为荷兰不进行电视和电影的配音，所以他从小就接触英语；"实际上，英语和荷兰语在某种程度上很接近"。然而，他注意到许多其他参与者在英语方面有所挣扎，因此他想出了一些规则来帮助克服这一障碍。

首先，De Goede 尝试写短小清晰的句子；他注意到工程师们常常写很长的句子，包含多个子句以作澄清，这在他的经验中应该避免。另一个错误是出现“文字墙”（wall of text），而不是许多清晰简洁的段落；若需进一步澄清，通常可以使用脚注。维护者有时需要对补丁提出多处修改，或者要求提供几种不同的调试信息（debugging information），因此使用带空行的编号列表来清晰地说明这些要求会有所帮助。他说：“这些都是非常简单的技巧，但它们有助于克服语言障碍。”

当维护者因某种原因心情不好时，尤其重要的是要尽量遵循他的建议。然而，即使维护者耐心、友好并努力清晰沟通，误解（miscommunication）有时仍然会发生。语言障碍可能是一个因素，但电子邮件也不是完美的沟通机制；无法看到对方以判断其态度和情绪，使其容易产生误解。由于回复固有的延迟，甚至可能需要时间才能意识到误解已经发生；通常情况下，一条最初被解读为不同意的消息，最终却发现是同意的——或者至少不像最初看起来那样强烈地不同意。

他提出了一套处理误解的四步流程，首先是识别回复中是否存在误解。接下来两步是，清晰地阐述对对方消息的原始解读，然后描述对对方意图的新理解。最后，提出如何推进讨论和/或补丁（patch）的建议。重要的是不要陷入追究责任的问题——是原始消息不清楚还是解读有误——因为这并不重要。"误解就是会发生的事情，它一直都在发生"；面对面交流时，误解很容易诊断和解决，但电子邮件会使误解的消除过程变得漫长。

一位听众提问了重复回复的问题：何时将这些回复整理成文档有意义？以及发送文档链接是否算作友好的回复？De Goede 说，他不擅长将回复转化为文档，但他确实有一些“罐头回复”，可以复制粘贴到回复中，并附注说明这是模板内容。关于提交内核补丁的文档已经非常多，令人望而生畏；他认为也许应该将其分成“补丁提交入门 101”和“包含所有细节的 201”。

另一个问题涉及如何腾出时间友好地帮助新来者。De Goede 说，他很幸运能因担任子系统维护者而获得报酬，"所以我可以利用老板的一部分时间来做这件事"。此外，他维护的子系统规模不大；邮件列表上的帖子数量，尤其是在初期，也很少。

不幸的是，帮助新来者可能不会立即带来回报，所以这“有点像撒网式的尝试”。他很幸运地有两位社区成员，他成功地将他们培养成了子系统部分内容的评审员（reviewer）。他指出，他们在特定领域工作，并直接请求他们提供帮助；“这既是开放和友好的结合”，也是在他非常忙碌时直接寻求他们帮助的结果。

De Goede 说，这个问题涉及他打算讨论的其他几个话题：社区发展和维护者倦怠。显然，花时间发展社区 可能 有助于减轻现有维护者的一些负担，但这并不能保证，所以这是一个棘手的平衡行为。如果所有维护者都能因为工作而获得报酬，那当然很好，但事实并非如此；他每周大约能花一天时间在他负责的子系统上，这通常足以处理最紧迫的事情。

未获报酬的维护者可能会觉得没有足够的时间来培养新来者，这是可以理解的，但这很可能会导致日后的倦怠。他建议与新来者管理预期，让他们对维护者能够提供何种程度的帮助以及何时提供有一个切实的了解。如果维护者确实太忙，鼓励新来者寻求其他导师（mentor）帮助他们的补丁（patch）可能更有意义。

社区发展

他说，一个友好的邮件列表（mailing list）只是社区发展所需的要素之一。对于新来者（newcomer）的补丁（patch），不应该过分吹毛求疵于细微的风格问题（例如，结构体初始化器（structure initializer）末尾忘记了一个逗号）；维护者（maintainer）如果需要，只需做一些小的清理工作，然后合并（merge）结果即可。对于经验丰富的开发者，吹毛求疵或许有道理，但对于新来者，目标应该是给他们“那种‘是的，我的第一个补丁已经合并到主线（mainline）了’的微小鼓舞；你想要让他们上钩”。指出已合并补丁中需要做的修改，可以帮助新来者学习，而无需为了风格问题而进行多次补丁修订。

如前所述，投入时间“手把手”指导新来者可能无法立即获得回报，但为了项目增加人手，这项投资是必须的。目前，获得报酬的维护者人数不足，无法满足所有新来者指导的需求。他说，这个信息需要更广泛地传播。他提到了当天早些时候的curl 主题演讲，并指出所有使用该工具的汽车公司都没有回馈（contributing back）项目。他说，对于一些依赖开源赚取数十亿美元的大公司来说，回馈社区的一种方式就是雇用维护者。

欣赏贡献（contributions）和贡献者（contributors）是作为维护者重要的一部分，这不仅对现有社区成员如此，对新来者（newcomers）尤其重要。他总是尝试用“感谢您的补丁”来开始他的补丁评审（patch review）邮件；这件小事做起来很简单，但其作用却“被大大低估了”。他还感谢评审他补丁的人，更重要的是，感谢那些他看到评审他人补丁的人。

另一种帮助社区成长的方式是委托任务并寻求帮助。留意在特定领域评审补丁（patch）的社区成员，然后直接请求他们在评审或 bug 方面提供帮助，这能很好地获得更多协助。当然，这并非总是有效，因为其他人也可能很忙，但值得一试。

有人问了两个关于 De Goede 所说的吹毛求疵（nitpicking）程度的问题。他澄清说，如果一个补丁在逻辑（logic）或实现（implementation）上有实际问题，他会要求修改，但对于简单的拼写错误（typo）之类的修复，最好直接处理。他知道其他维护者（maintainer）的做法不同，但在他看来，这样做可以节省维护者的时间，避免上下文切换（context switch）并再次（甚至可能多次）进行评审。

维护者倦怠

倦怠的根本原因是内核维护者“经常被要求过多”；他们通常也是那种为了追求完美而将自己推向极限的人。他发现自己也有这种情况，但他认为完美是优秀的敌人；“你想要的目标是‘足够好’，完美是不存在的”。一个有值得信赖的成员提供协助的健康社区会有所帮助，但这并非最终解决方案；他负责的子系统虽然小，但有时也会让人不堪重负，而且还有许多更大的子系统存在。

对于那些补丁数量如“消防水管喷涌”（firehose of patches）般的子系统，需要有第二个开发者获得报酬来承担评审（review）及其他任务，以帮助减轻负担。举例来说，他提到了媒体（media）子系统，他认为该子系统缺乏足够的评审人员能力来应对其巨大的补丁负载。目前正在努力转向多提交者模型（multi-committer model），这可能有所帮助，但他认为真正需要的是，由某些有兴趣的公司资助一些经验丰富的内核开发者来做补丁评审（patch review）工作。他们甚至不需要熟悉媒体子系统；如果知道他们每周有两到三天的时间获得报酬来处理这项工作，那么投入时间让他们熟悉情况是值得的。

他自己前段时间经历了一次“轻度倦怠”（mini-burnout），并注意到这并非直接由内核维护者（kernel-maintainer）的角色或他在红帽（Red Hat）的技术工作引起，而是由其他因素造成的。这种倦怠源于他觉得自己无法掌控时间的使用方式。“你在工作日结束时感觉自己富有成效吗？还是觉得自己只是在无用的行政任务上白费力气？”对 De Goede 来说，这些问题的答案是主要因素。

De Goede 说他“有过不幸和幸运的经历”，身边有人“经历了相当严重的倦怠，直到现在才完全康复”。因此，他知道倦怠的症状、需要注意什么以及 不 该做什么：“一直坚持下去直到崩溃；千万不要那样做”。重要的是要认识到症状，“尽早拉响紧急刹车”。

2023 年 3 月，他发现自己身上出现了一些倦怠症状；凭借对朋友经历的了解，他知道自己不想遭受同样的命运。他不是心理学家，但他观察到的症状包括“脾气非常暴躁、总是感到疲惫、没有精力”，以及很快就会被小事惹恼。他说：“对我来说，原因包括感觉失去控制、不被欣赏、感觉效率低下，[以及]感觉没有被倾听。”这些都与工作相关，但也存在个人因素，比如年迈的父母需要照护。他说，这总是多种因素的组合；无法在内核维护方面投入他认为所需的时间，只是加剧了这种负担。

一旦他意识到发生了什么，他立即向雇主报告了问题；“我的工作让我生病了，我请病假”。他说，他很幸运，“来自一个拥有适当工人权利和劳动保护的欧洲国家”。他要求工作上做些改变，他的管理层也同意了，“这真的太棒了”。他最终只请了三周的全薪病假，然后用了七周时间慢慢恢复到正常工作时间。

他建议所有与会者，如果发现自己有倦怠症状，应迅速介入，寻求专业人士、同事、朋友或其他人的帮助。“做点什么，不要继续在跑步机上跑下去。”认为精神疾病与身体疾病有所不同的观点是有问题的，也是不真实的；首先，精神疾病最终会导致身体症状。这可能很棘手，取决于您所在国家的法律，但他建议如果问题与工作相关，就让您的雇主参与进来；“尝试与他们合作解决问题，改变现状，让您的工作再次充满乐趣”。

他对 Linux 和开源软件的热爱，让他每天都“全力以赴”。因此，每天从这份努力中获得一些正能量就变得很重要，这样他第二天才能再次投入。他的经理建议他不要每天都尝试付出 100% 的努力，而要保留一些缓冲。他说：“我仍在努力做到这一点。”

交接

在经历了“轻度倦怠”（mini-burnout）后，他与经理合作，对他在维护者（maintainer）方面的工作进行了一些调整。他还希望减少“总线系数”（bus factor）为一的子系统数量，其中包括 pdx86。尽管该子系统相当小，但他认为分担工作量是合理的。他注意到许多补丁（patch）来自英特尔（Intel），于是他询问该公司是否能提供一位经验丰富的开发者来共同维护（co-maintain）该子系统。

英特尔公司安排 Ilpo Järvinen 参与协助，自 2023 年 9 月以来，他一直与 De Goede 共同维护 pdx86。最初，他们会在每个内核开发周期（kernel-development cycle）中轮换角色；一人负责该周期的 bug 修复，另一人则负责子系统的评审（review）和补丁合并（patch merging）。此后，De Goede 更多地参与到媒体（media）子系统和 MIPI 摄像头（MIPI camera）的工作中，部分原因是内核该部分缺乏评审员，因此他请求 Järvinen 在 2025 年 5 月成为 pdx86 的主要维护者。De Goede 仍然是团队的一员，并在需要时可以补位，这也为 pdx86 提高了总线系数。

本次演讲的幻灯片也已提供。

[在此感谢 Linux 基金会，作为 LWN 的差旅赞助商，支持我前往阿姆斯特丹参加欧洲开源峰会。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～