开源与贡献墓地

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) so I can convert it into Simplified Chinese while preserving the formatting?

贡献墓地概览

简要查看几个流行的 GitHub 项目会发现一个共同的模式：大量未关闭的 issue 和 pull request（PR）：

• python‑requests – 145 个 issue，80 个 PR
• VS Code – 5 k+ 个 issue，1.8 k 个 PR
• Kubernetes – 1.8 k 个 issue，889 个 PR
• Ruby on Rails – 518 个 issue，1.1 k 个 PR
• Rust Language – 5 k+ 个 issue，1.1 k 个 PR
• lodash – 68 个 issue，72 个 PR

即使是相对较小的库 lodash 也有数十个未关闭的 issue，说明这个挑战在流行的开源软件中非常普遍。

维护的负担

虽然代码是免费且公开的，但维护它的成本依然非常真实。例如，python‑requests 现在只有两名维护者，较之前的更大团队大幅减少。像 Kubernetes 这样的项目虽然有更多贡献者，但仍然面临大量的 issue 和 PR。AI 生成的 PR 增加了额外的压力，甚至 Linux 内核也开始删除那些维护不佳的代码，因为安全报告的潮水般涌来（LWN 文章）。

最近一次个人经历凸显了这个问题：我尝试安装我之前使用过的 Vim 发行版 LunarVim，结果发现它已经被弃用（GitHub 讨论）。

贡献者困境

潜在的贡献者面临着艰巨的局面。即使出现了明确的 bug，他们也必须确保自己的修复不会与数百甚至数千个其他 PR 冲突，并确定自己的工作对应的是哪个（如果有的话）未解决的问题。庞大的数量会产生一种悖论：如果每个人都能贡献，那么就没有人能贡献。

寻找规模更小、压力更小的项目并不总是容易的。虽然 GitHub 的collections page对仓库进行分类，但仍有许多仓库面临着高 issue 与 PR 比例的问题。

从何开始

解决方案会因社区的规模和性质而异。以下是几种可以帮助缓解“贡献墓地”的方法。

Bug 处理

我的第一次开源经历是在 Gentoo Linux 项目，我进行“bug 处理”：复现 bug 报告、缩小原因范围，并引导维护者找到解决方案。通过专职志愿者或轮流的“bug 处理冲刺”来扩大此实践，可能会减少未解决问题的积压。

Bug 报告超时

一些项目实现了计时器，在一段时间不活跃后自动关闭陈旧的 issue。虽然并不适用于每个仓库，但缩短超时时间窗口可以鼓励及时分流，防止未解决报告无限累积。

项目重构

大型、单体项目（例如 Linux 内核）由于其广度自然会产生大量 issue。逐步重构——将组件拆分为更小、更易管理的子项目——可以降低整体 issue 负载，使维护更易于处理。明确的项目愿景和更严格的接受标准也有帮助。

完全重置

一个激进的选项是关闭所有未解决的 issue 和 PR，重新开始。此做法可能会疏远那些工作被丢弃的贡献者，并且可能只是导致同样的积压在以后再次出现。应仅在万不得已时考虑。

新工具

采用外部 issue 跟踪系统（例如 Bugzilla），并通过 SSO 与 GitHub 集成，能够提供更清晰的 UI 来进行 triage 和工作优先级排序。在 GitHub 原生 issue/PR 之上叠加此类系统，可能会让积压更易消化。

团队扩展

扩大维护者团队，加入专职的“issue 清理”成员，增加审阅者数量，并加强自动化 lint 检查，可提升处理吞吐量。让有经验的贡献者与新人结对的导师计划，也能加速入门和知识传递。

未来带来什么

AI 生成的贡献激增加剧了这一问题，迫切需要在其导致停滞之前加以解决。开源仍然至关重要，但如果没有有效的策略来管理大量的 issue 和 PR，项目就有可能变得难以维护。现在是社区共同探索并采纳解决方案，保持开源生态系统健康、可持续的时机。