欢迎来到开源的永恒九月。以下是我们为维护者计划的内容。
Source: GitHub Blog
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保持原有的格式。
当贡献成本下降时
在邮件列表的时代，向开源项目做出贡献需要付出真实的努力。你必须：
- 订阅邮件列表。
- 潜伏并了解社区文化。
- 正确地格式化补丁。
- 解释为何此更改重要。
这些努力并不能保证质量，但它们 筛选出了真正投入的参与者。大多数贡献来自于真正对项目投入了时间和精力的人。
高门槛的问题
- 排斥性： 高门槛让许多潜在贡献者望而却步。
- 付出与回报： 在任何人能够尝试帮助之前，都需要付出大量工作。
项目意识到了这一点，并努力降低进入门槛，使开源更加友好。
拉取请求的革命
在 GitHub 上托管项目、使用拉取请求（Pull Request），并标记 “Good First Issues” 大幅降低了摩擦：
- 即时创建 PR： 拉取请求现在可以在几秒钟内生成。
- 引导式入门： “Good First Issue” 标签把新人指向低风险任务。
- 更广泛的参与： 社区规模扩大，贡献变得更易获取。
这是一件好事。
新的平衡：摩擦 vs. 信任
摩擦是一种平衡：
- 摩擦过多 → 思想和贡献者被排除在外。
- 摩擦过少 → 维护者可能被淹没，信任受损。
如今，生成式 AI 让编写代码、提出问题或安全报告变得轻而易举。创建的成本 已大幅下降，但 审查的成本 并未下降。
为什么大多数贡献者仍然值得信赖
- 善意： 大多数人想帮助他们关心的项目。
- 学习与曝光： 贡献是提升技能和获得声誉的途径。
- 职业收益： 参与广泛使用的开源项目可以提升简历。
这些动机 并不新鲜，也没有错——它们正是推动开源参与数十年的同样动力。
真正的挑战
当低质量的贡献大规模涌入时，审查工作量可能超过维护者的承受能力。即使是出于好意的提交，也可能让项目不堪重负，导致：
- PR 堆积
- 反馈延迟
- 协作过程中的信任 衰减
如果信任——开放协作的基石——开始受压，生态系统的健康就会受到影响。如何在保持低入口门槛的同时，实现可持续的审查实践，已成为现代开源社区的关键挑战。
Source:
噪声的新尺度
把“低质量贡献”或“AI 垃圾”描述为近期、独特的现象是很诱人的想法。事实并非如此——维护者一直在处理嘈杂的外部提交。
- Linux kernel – 采用 信任网络 的理念，正式制定了 SubmittingPatches 指南，并在 2004 年引入 Developer Certificate of Origin (DCO)，这并非偶然。
- Mozilla 与 GNOME – 围绕大多数进入的缺陷报告需要过滤的现实，构建了正式的分诊系统，以免维护者投入更深的时间。
- 自动化扫描器 – 早在生成式 AI 之前，维护者就已经处理来自商业和开源扫描工具的大量自动安全和代码质量报告。
“你是真在帮我，还是只在帮自己？”
维护者常问的也是同一个问题。仅仅因为某个工具——不论是静态分析器还是大语言模型——让生成报告或修复变得容易，并不意味着该贡献对项目有价值。创建的便利往往会给维护者带来负担，因为收益不平衡：贡献者可能获得荣誉（或 CVE、或曝光），而维护者则承担后续维护的工作。
最近的例子
- cURL – 在 AI 生成的安全报告激增、每条都需数小时验证后，终止了其漏洞赏金计划。
阅读公告 - Ghostty – 转向 仅限邀请 的贡献模式，要求在接受代码贡献前先进行讨论。
贡献指南 - 各类项目 – 采用明确的规则来限制 AI 生成的贡献。
这些都是对“生成贡献的容易程度”和“维护所需努力”之间不平衡的理性回应。
我们在 GitHub 正在做的事
在 GitHub，我们并非只是坐视不理。维护者的可持续性是开源的基石——也是我们的基石。作为开源的聚集地，我们有责任帮助你管理源源不断的需求。
我们正从多个角度着手：立即提供救急措施，同时构建面向长期、系统性的改进。其中一些涉及工具；另一些则是提供更清晰的信号，让维护者能够决定将有限的时间投入到何处。
已发布的功能
- Pinned comments on issues – 从评论菜单直接将评论置顶到议题的顶部。
- Banners to reduce comment noise – 显示横幅，鼓励使用表情或订阅，而不是 “+1” 或 “我也是” 的评论，从而减少不必要的通知。
- Pull‑request performance improvements – 优化的差异使新的 Files changed 视图提升至 67 % 更快，尤其在大型拉取请求中效果显著。
- Faster issue navigation – 大幅提升的浏览速度帮助维护者更高效地对 bug 进行分流。
- Temporary interaction limits – 在公共仓库中临时限制特定用户的活动。
这些改进旨在降低审查负担，简化开发者工作流。
我们即将发布的功能
-
Repo‑level pull request controls
允许维护者将拉取请求的创建限制为协作者，或完全禁用拉取请求。虽然拉取请求是开源项目增长的基石，但维护者需要工具来有效管理他们的项目。 -
Pull request deletion from the UI
使得能够从用户界面删除垃圾或滥用的拉取请求，从而让仓库更易于管理。
探索下一步
墙壁并不能建立社区。展望未来，我们的目标是让维护者拥有更多控制权，同时保护使开源工作得以进行的协作精神。
我们正在探索的方向（与维护者协商后）
-
基于标准的门控
- 在打开拉取请求之前必须关联一个议题。
- 定义贡献必须满足的规则，才能被接受。
-
改进的分流工具
- 利用 automated triage 根据项目自己的指南（例如
CONTRIBUTING.md）评估贡献。 - 优先展示需要维护者关注的拉取请求。
- 利用 automated triage 根据项目自己的指南（例如
这些工具旨在支持决策，而不是取代决策。维护者仍然掌控全局。
权衡与保障
- 限制可能会对以善意参与的首次贡献者产生不成比例的影响。
- 所有控制都是可选且可配置的，以降低此类风险。
社区实验
| 项目 / 方法 | 他们在做什么 |
|---|---|
| 仅限邀请的工作流 | 将贡献限制在经过审查的协作者。 |
| 自定义 GitHub Actions | 自动化贡献者分流和声誉评分。 |
| Mitchell Hashimoto 的 Vouch | 实现了显式的信任管理系统，贡献者必须得到受信任的维护者的担保才能参与。 |
| Python 社区 | 强调贡献者指南、导师制度以及明确标记的入口点。 |
| Kubernetes | 强有力的治理结合广泛的文档和贡献者教育，阐明如何以及什么构成有价值的贡献。 |
这些方法并非互斥：
- 教育帮助善意的贡献者取得成功。
- 护栏帮助维护者应对规模化的挑战。
为什么没有一种解决方案能适用于所有情况
每个项目都有自己的价值观。围绕平台构建的工具成为特性试验场，随后可能被更广泛地采纳。我们正密切关注这些实验。
重新思考激励机制
如果我们只构建“阻断和封禁”，就会形成堡垒，而不是集市。
- 拓宽“贡献”的概念。
- 在 WordPress 中，手动编写的“致谢”会为代码、文档、测试、社区支持等贡献者提供荣誉。
- 认可多元化的贡献会显现信任信号（例如，一贯的议题分流、文档合并），帮助维护者更快、更明智地做出决策。
我们希望 GitHub 能够展示并庆祝所有推动项目前进的方式。
告诉我们你的需求
我们已经开启了一个社区讨论，以收集对我们正在探索的方向的反馈：探索在 GitHub 上解决低质量贡献的方案。
我们想听听你的声音。分享哪些做法对你的项目有效，存在哪些缺口，以及哪些改进能显著提升你维护开源项目的体验。
开源的 永恒九月 是值得庆祝的现象：比以往任何时候都有更多人想要参与。贡献的数量只会继续增长——这本身是件好事。但正如早期互联网在规模化社区中通过演进规范和工具来维系社区一样，开源也需要如此。不是提升门槛，而是为维护者提供更好的信号、更好的工具，以及更好的方式，将所有能量引导到推动项目前进的工作上。
让我们一起构建它。
作者
Ashley Wolf – GitHub 开源项目总监
我负责 GitHub 内部及整个生态系统中支持维护者的开源战略和项目。我还在 TODO Group 的指导委员会任职，帮助组织负责任地使用和维护开源。
