Rust 项目存在倦怠问题
Rust 编程语言核心贡献者中的倦怠正成为一个严重问题，其原因包括持续不断的审查工作量、高质量期望，以及一种让人觉得“如果我不做就没人会做”的文化。评论者将这与更广泛的开源动态联系起来：无偿或低薪维护者不断吸收无穷无尽的问题、PR 和用户需求，而 GitHub 以互动为驱动的模型以及对时间和责任缺乏明确边界又加剧了这一切。许多人认为，更健康的规范——更明确地说“不”、更好的工具和分流、明确的时间限制、付费支持，以及减少个人英雄主义的治理——对于 Rust 和类似的大型项目能否保持可持续性至关重要。
倦怠问题的范围
- 许多人认为，文中所描述的体验是大型开源（“开放贡献”）项目的典型现象，而不只是 Rust。
- 也有人认为 Rust 的情况比同类项目更严重，理由包括高理想主义、快速发布节奏、复杂的编译器工作，以及年轻且高度理想化的贡献者群体。
- 一个强烈的主题是：倦怠源于那些关心、尽责的人，却身处一个让人感觉冷漠或混乱的环境。
主要倦怠驱动因素
- 觉得“如果我不做，就没人会做”，尤其是在自己偏好的功能或被忽视的领域。
- 审查负担：来自缺乏经验的贡献者的大量 PR；审查者会觉得自己对捕捉 CI 和测试无法发现的细微错误负有个人责任。
- 社区期望和“理所当然的用户”：抱怨、低投入的问题/PR、对速度的压力。
- 内部文化问题：回避冲突、难以及时说“不”、高度自下而上的决策使协调变得困难。
- 对志愿工作情感投入过深；贡献者把它当作第二份无薪工作。
缓解与治理思路
- 个人边界：设定工作时间预算，把付费 OSS 工作当作一份工作来对待（不长期加班），接受有些事情不会完成。
- 组织实践：轮换审查职责，正式的“休假”选项，更多扮演分流/“阻隔干扰”而非编码角色的人。
- 技术/流程方案：在可能的地方加强 CI/lint，对 PR 提高测试要求，更清晰的贡献者指南，针对常见细微陷阱的检查清单。
- 社区卫生：关闭低质量 PR，封禁有毒用户，把问题从 GitHub Issues 转移到论坛/邮件列表，使用机器人/Actions 自动关闭和进行情绪过滤。
- 有些人主张更直接、甚至更严厉地拒绝理所当然的行为；也有人警告这会制造毒性并赶走优秀贡献者。
Rust 特有观察
- Rust 被认为在特性稳定化上既慢、又以 6 周发布节奏快速推进，这会提高压力。
- 公司确实资助了一些核心工作，但对情感投入的志愿者的依赖仍然很高。
- 有人担心封闭性和文化问题（包括人口统计和风格规范），这可能强化群体思维并排斥不同性格的人。
元话题：写作风格争论
- 关于博客全小写风格的长篇分支讨论：许多人觉得它显著更难阅读，并认为这不够体贴；也有人把它视为一种正当的审美选择，或一种刻意的“筛选器”。