How GitHub Gave Every Repository a Durable Owner

编译摘要

核心结论1: 组织级资源治理的关键瓶颈不是技术工具，而是"所有权缺失"——当资源无人负责时，安全事件响应、审计、生命周期管理全部失效。
- 关键证据: GitHub 内部 14,000+ 仓库中 11,000 未归档但不到一半有可识别所有者；secret scanning 修复时工程师靠 Slack 猜测、README 翻查、commit 历史审计来定位负责人。
核心结论2: 所有权必须成为一等公民数据属性（first-class data property），而非依赖间接推断。GitHub 通过 Custom Properties 将 ownership-type + ownership-name 设为仓库级强制字段，并配合验证逻辑（团队成员数>=2、Handle 在职校验、Service Catalog 交叉引用）确保数据可信。
- 关键证据: 三种所有权分类（Service Catalog / Hubber Handle / Team），每种都有内建耐久性——Team 要求最少 2 人避免单人离职即失效；Service Catalog 条目随服务生命周期自动归档。
核心结论3: 治理落地靠"宽限期 + 自动归档"而非强制命令。45 天内稳定约 3,000 活跃仓库、归档约 11,000 inactive 仓库；归档可逆，降低阻力。
- 关键证据: 执行流水线——扫描缺失所有权 → 开 warning issue → 30 天宽限 → 自动归档 → 解决后自动关闭 issue。首次执行选在周六，但分布式团队立刻在 Slack 反馈。

关于"所有权分类足够完备"的质疑: 三种类型假设了组织内所有仓库要么关联服务、要么归属团队、要么归属个人。但跨团队协作仓库、临时实验项目、fork 后长期维护的工具库可能落在分类缝隙。文章未讨论这些边界情况。
关于"Team >= 2 人即稳定"的质疑: 最小 2 人约束防止单人离职导致所有权悬空，但如果整个团队解散或重组（常见于组织调整），所有权同样失效。文中将 Team 视为"稳定问责"，实际稳定性取决于组织结构变动频率。
关于数据可靠性的质疑: 文中自述了 low-water-mark 阈值保护，但数据同步（Service Catalog → Custom Properties）存在时间差。如果同步逻辑有 bug，"错误标记仓库失去服务绑定"可能触发批量误归档。文中未披露同步频率和冲突解决机制。
关于通知缺口修复的质疑: 解决方案是 @mention 仓库管理员 + 分配所有 write access 用户。这在小规模可行，但在大型组织中如果 warning issue 批量产生，@mention 风暴本身可能成为噪声问题。

跨域关联1: 此机制类似云基础设施的 [CMDB / 资源标签治理]（AWS Resource Groups、GCP Labels），可迁移到 Agent 治理场景——每个 Agent 实例强制绑定 owner（团队/个人/服务），未绑定者自动禁用。这对 Policy-as-Code-for-Agent-Governance 有直接参考价值。
跨域关联2: "宽限期 + 自动归档"模式类似 DNS 域名过期机制和 SaaS 订阅的休眠账号清理。核心设计原则一致：非破坏性、可逆、有缓冲期。可迁移到 AI-ready 组织中废弃 Agent workflow 的自动清理。
跨域关联3: 所有权作为一等公民属性的设计思路，与 AI-Ready-Organization 中"让 AI 可寻址的组织元数据"要求一致——如果 Agent 需要调用仓库、访问数据、触发 CI/CD，它首先需要知道"找谁负责"。

Ownership — 注意：现有 Ownership entity 聚焦个体决策权归属（谁做决定），本文聚焦组织级资源治理（谁拥有仓库）。两者是不同维度的"ownership"，前者是认知/决策层，后者是基础设施/治理层。
AI-Ready-Organization
Policy-as-Code-for-Agent-Governance