GitHub 45 天搞定 1.4 万仓库归属
How GitHub gave every repository a durable owner
GitHub 内部曾面临严峻挑战：14000 多个仓库中，超过一半没有明确归属。这导致在秘密扫描修复等安全工作中，我们常常因找不到负责人而陷入困境。在短短 45 天内，我们利用 GitHub custom properties 和自动化流程，为所有活跃仓库验证了所有者，并将 8000 个废弃仓库归档。通过强制新仓库在创建时即指定归属，我们将所有权变成了系统的基础设施，彻底消除了“无主仓库”带来的安全隐患。
归档操作是可逆且非破坏性的：仓库变为只读状态且 GitHub Actions 停止运行，但没有任何数据被删除。
HN 评论区
26- simonw
我之前的一家雇主就遇到过类似问题：大量遗留功能没有明确的负责人，导致无法确定该把 Bug 报告转给谁。
他们的解决方案是建立一份包含所有功能的目录，然后将每一项都分配给现有的某个团队。
有些团队最终可能要负责他们从未见过、也一无所知的功能……但这没关系，因为其他所有团队也都处于同样的境地。
效果出奇地好。Bug 被修复了，团队也摸索出了门道。
- roadbuster
如果连“明确的负责人”都没有，那代码变更合并时是谁在审批？
微软其他所有主要部门都被要求对生产环境的源代码变更实施繁琐的管控和追踪，但 GitHub 却在一个近 80% 的仓库（14000 个中的 11000 个）缺乏有效的所有权系统和记录的情况下运营？
- dotwaffle
要求服务目录中的每一项都必须列出一位“高管赞助人”（指具体个人，而非职位或团队），这看起来完全是无脑的官僚主义。
与此同时，给每个仓库附加“自定义属性”的感觉，简直就是在管理 JIRA，再加上 GitOps 世界里随处可见的无模式 YAML 数据块。
是我一个人这么觉得吗？这个问题的显而易见解决方案难道不应该是真正的数据库和 API，而不是随意附加一些没有实时验证等功能的元数据碎片吗？