R1.06.6ownership on merge设计
维护责任需随组件一起被接收
别名: 维护交接 · 合并即接收 · maintainer of record · 所有权
概念解释
合并不是收礼，是接下一笔会继续产生利息的负债：主题改版、平台升级、对比度诉讼、弃用公告，都会再来敲这个名字的门。合并时接收维护（ownership on merge）要求在合入的同一时刻，有一个在职的人、轮值或团队声明「缺陷和后续改动找我们」——不是贡献说明末尾一句「欢迎提 issue」，也不是合并庆祝之后的沉默。写入权回答谁能送进来；维护回答送进来之后谁还在。
没有接收人的组件是孤儿。下一次破坏性变更来时，日程表上没有人的名字。
机制
代码一旦进入共享库，失败模式从「这一页坏了」变成「所有调用页一起坏」。修复需要人排期。贡献者在功能压力下把件送进来，压力消失后他们回到产品线；系统团队若未在合并时点头接手，件就停在「人人能改、无人必改」的区间。平台小版本、令牌改名、辅助技术更新都按自己的日历到来，它们不等待原作者有空。接收是把负债记到一个仍有编制的科目上：值班表、代码所有权、问题分诊队列。只有「合并通过」而没有科目，等于把负债记到空气。
接收可以转手，但转手也是一次显式事件：旧科目关、新科目开，中间不留空窗。
边界
供应商提供、以依赖包形式引入的控件，维护科目在供应商的支持合同里，不在本库的值班表上；本库要记的是「封装层」的主人，不是上游每一行。明确标为试用、到期删除的实验件，可以指定一个较短的接收窗口，窗口结束即删除，不必假装有长期主人。个人周末项目、实习作业，若不能指出实习期结束后的接手人，就不该合并进公共库。单人公司里接收人就是那个人，流程可以省；一旦第二个人开始调用，孤儿风险出现，科目就要写下来。原作者离职是一次强制转手：走之前没有新科目，就从库中移除或冻结，而不是默认为「组里总会有人看到」。
怎么落地
- 合并清单最后一项是「维护科目」：人名或轮值，加上问题跟踪里的默认经办。缺这一项不能合并。
- 代码所有权文件与该科目一致；组件目录的审查人就是会被自动点名的人。
- 季度确认：科目里的人仍在职、仍认领。离职流程包含「名下组件转手或删除」。
- 验证：对每个共享组件，在问题跟踪里开一个无害的测试单（或查最近一次真实缺陷的响应）。有科目且在约定时间内有人认领，接收是真的。单子挂着、或被转给一个已停用的账号、或评论区出现「这谁写的」，合并时的接收就是仪式。抽查原作者已离开的组件：若没有后继科目，这些件应立即进入删除或寻找接手的队列。