📍RQ1 阶段进展：AIDev 上 contributor-level governance 真的比 PR-level 多了什么？
RQ1 阶段进展：AIDev 上 contributor-level governance 真的比 PR-level 多了什么？
一句话结论
到目前为止，最有价值的发现不是“我们能给 contributor 打分”，而是：
一旦把研究对象从 PR 推到 contributor，AIDev 中的“治理负担”定义就会被迫重写。
仅用 review 数、review comments 或 merge/reject 来表示治理负担都不够；PR discussion、workflow intervention，以及 self-triggered 与 external-triggered 行为的区分，会系统性改变你对治理负担的理解。
1. 这轮 RQ1 最重要的价值，不是造了一个分数，而是排除了几种错误建模方式
做 contributor-level governance 研究，最危险的地方是：
- 很容易把 PR-level 变量换个单位求平均；
- 很容易以为自己在研究治理，实际上只是在重复 PR outcome mining；
- 很容易被看起来“有信号”的 pooled pattern 误导。
这轮最重要的成果，不是我已经得到了一个完美 CADS，而是我已经用数据把几种看似合理、实际上会误导的建模方式排掉了。
2. 第一条高价值 insight：治理负担不能被简化成 review
2.1 如果只看 review，你会系统性漏掉一大片治理表面
这轮最清楚的发现，是 contributor-level 的治理负担根本不能用“review 数量”近似。
在当前 contributor-level 聚合里，已经出现了这样一类情况：
- 有大量 contributor-agent 行对应的 PR 有 PR discussion comments；
- 但这些 PR 没有 review events，也没有 line-level review comments。
这说明一件很关键的事：
社区治理并不只发生在 formal review 流程里。
维护者、bot、其他参与者可能根本没有走 GitHub review 状态机，而是在 PR discussion 里完成了大量“治理动作”：
- 追问
- 纠偏
- 要求修改
- 指出问题
- 协调后续动作
如果研究者把 contributor-level governance burden 简化成：
#reviews#review_commentschanges_requested
那他看到的只是治理的一部分，而且会系统性低估那些discussion-heavy but review-light 的 contributor 负担。
2.2 为什么这条比一般“描述统计”更重要
很多 AIDev 论文已经会研究：
- merge / reject
- review effort
- line review comments
但这条 insight 真正推进的是研究对象本身：
它迫使我们承认 contributor-level governance 不是 PR review 的简单放大版，而是一个更宽的协作负担表面。
这条如果写清楚，其实已经不是“多统计一个变量”，而是在改这个研究问题的 measurement boundary。
3. 第二条高价值 insight：workflow event 不能直接当治理负担，必须区分 self vs external
3.1 一个很容易犯的错误
看到 pr_timeline 很丰富，最自然的冲动是：
- 统计 timeline 事件数量；
- 把它并进 governance burden。
这轮我一开始也差点这么做。后来往下挖以后发现，这样会出大问题。
3.2 问题出在哪
很多高频 workflow event 并不是外部治理动作，而是 PR 作者自己触发的流程行为，比如：
- 自己加 label
- 自己 request review
- 自己 assign
如果把这些都算作“治理负担”，就会把 contributor 自己的流程操作误写成社区对他的治理压力。
于是这轮我进一步把 timeline 事件拆成：
- self-authored workflow actions
- external interventions
结果很明确：
大多数 selected workflow events 并不能被直接解释成 external governance burden。
真正更像外部治理动作的，是那些更少但更强的事件：
lockedunassignedunlabeledreopenedready_for_review
3.3 这条 insight 的研究价值
这意味着后续任何 contributor-level governance 构造，如果把 timeline volume 一股脑并进来，都会产生 measurement pollution。
换句话说：
timeline 在这个题里不是“有没有用”的问题，而是“必须分角色才能用”的问题。
这是一条很典型的“数据越丰富，越容易误用”的 insight。它不花哨，但很关键。
4. 第三条高价值 insight：contributor-level dominance 不能做成硬标签，而应该做成浓度画像
4.1 为什么“这个 contributor 属于哪个 agent”不够好
如果只从直觉出发，最容易做的 contributor-level 构造是：
- 看某个 contributor 最常用哪个 agent；
- 然后给他一个 dominant agent label。
这轮跑下来后，我认为这个做法太粗。
原因不是因为所有 contributor 都很混，而是因为：
- 大多数 contributor 确实看起来比较集中；
- 但少数 mixed contributors 覆盖的 PR 体量并不小；
- 而且真正有意思的治理现象，恰恰可能发生在这些 mixed / low-concentration contributor 上。
4.2 所以更好的构造是什么
这轮更支持的做法是：
- 不用 one-hot label；
- 改用 concentration/profile construct，比如：
- dominant agent share
- distinct agents used
- entropy / HHI
- agent mix string
这类构造的好处是：
- 不会把 contributor 简化成单一身份；
- 更容易承接“稳定 contributor vs 混合 contributor”的治理差异；
- 也更适合后面测试它是否真的提供了 PR-level 之外的增量解释力。
4.3 为什么这不是纯技术决定
因为这关系到后面论文到底在说什么。
如果用硬标签，论文会更像：
- 比较不同 agent contributor
如果用 concentration/profile construct，论文就更像：
- 研究 contributor 持续贡献模式与治理负担的关系
后者明显更贴近我们想守住的 gap。
5. 第四条高价值 insight：一个看起来很强的 pooled pattern，进一步检验后并不稳
这是这轮里最像“研究真正开始了”的部分。
5.1 最初看到的信号
在做 observable_cads_v0 时，最初出现了一个挺诱人的结果：
- dominance concentration 低的 contributor bucket，
- governance touchpoints / PR 看起来更高。
如果停在这里，很容易写出一句很好听的话：
越混合的 contributor，越容易制造治理负担。
5.2 为什么我没直接写进结论
因为这类 pooled pattern 很容易被 confound。
所以我接着做了两件事：
第一，within-agent 检查
在最大的可分析子群（OpenAI Codex）里，这个信号仍然存在。
第二，只保留 clearly external governance touchpoints
把那些可能由 contributor 自己触发的东西剔掉以后，整体 pooled pattern 翻掉了。
5.3 这条 negative/corrective insight 的价值
这意味着：
cross-agent composition 是一个非常强的混淆因素。
也就是说，现在我不能诚实地说：
- 低 concentration contributor 一定更难治理
我现在只能说：
- 在 pooled 数据里，这个效应不稳；
- 在 OpenAI Codex 子集里，信号更明显；
- 任何正式结论都必须先做 within-agent stratification，或者显式控制 agent composition。
这类 negative result 很值钱，因为它不是“没做出来”，而是：
它阻止我们把一个看似漂亮、但实际上站不住的叙事提前写进论文。
我宁愿有这种纠偏式 insight，也不想拿一个虚假的强结论去堆砌 proposal。
6. 所以 contributor-level governance 到底比 PR-level 多了什么？
如果要直面这个问题，我现在的回答已经比之前更硬一些了。
不是因为 contributor 更大
而是因为它让我们看到三件 PR-level 很难完整看到的事：
6.1 负担会在 contributor 身上累积，而不是在单个 PR 上结束
单个 PR 可以被 merge、被关掉、被改完。 但 contributor-level 让你能看到：
- 某类 contributor 是否持续在消耗 review attention；
- 某种治理负担是偶发还是模式化。
6.2 社区治理发生在多个通道，而不是只在 PR review 状态机里
PR-level 容易只盯 review。
contributor-level 研究逼着我们把这些通道放到一起看：
- review
- line comments
- PR discussion
- workflow interventions
6.3 contributor-level 构造更容易暴露 measurement bias
很多看起来“合理”的 pooled 结果，一旦换成 contributor profile、再拆 self/external、再做 within-agent 检查，就开始变得不稳。
这说明 contributor-level 不是简单换个统计单位，而是真的在暴露更深层的 measurement issue。
换句话说：
PR-level 研究更像在回答“这一条 PR 怎么样”；contributor-level 研究开始逼我们回答“社区到底在治理什么，以及我们是不是一直把治理负担测错了”。
这才是我觉得它有研究价值的地方。
7. 这一阶段我认为已经站住的结论
如果现在必须给出阶段性结论，我会只保留下面三条：
C1. RQ1 的 contributor-level governance construct 必须是多通道的
至少要显式包含：
- review-level signals
- line-review signals
- PR-discussion signals
- actor-separated workflow signals
C2. timeline 和 discussion 不是 review 的冗余替代物
它们会改变 contributor-level governance burden 的定义，而不是只是补充一点噪音。
C3. contributor dominance 需要被当作浓度画像而不是硬标签来建模
但这个 dominance 与治理负担的关系，不能在 pooled 数据上草率下结论；后续分析必须控制或分层处理 agent composition。
8. 还没到可以下结论的部分
我也明确说一下，哪些我现在还不想写进正式主张：
- “混合 contributor 一定更难治理” —— 现在证据不稳
- “高 dominance contributor 一定更轻/更重” —— 也不稳
- “贡献者层分析已经证明比 PR-level 更强” —— 还没正式做 RQ2 型增量检验
这些都应该留到下一步，而不是现在硬写成结论。
9. 下一步最值得做什么
如果继续推进，我觉得最值钱的下一步不是再补更多表，而是两件事：
9.1 把 RQ1 的 construct 正式写成一个清楚的 measurement memo
也就是把当前已经被数据逼出来的设计原则写死：
- 哪些 signal 算 governance burden
- 哪些要拆 self/external
- 哪些只能当 artifact hint
- 哪些 pooled pattern 不能直接信
9.2 用一个最小但像样的 baseline 给 RQ2 开头
重点问：
这些 contributor-level 变量，是否真的比单纯 PR-level 特征多提供了解释力？
只有这一步成立，contributor-level framing 才算真正被 defend 住。
10. 一句话总结
如果要把这轮阶段性进展压成一句最有价值的话，我会写：
在 AIDev 上，一旦研究对象从 PR 推到 contributor，治理负担就不再能被简化成 review activity；PR discussion、actor-separated workflow interventions 和 contributor dominance concentration 会共同重写这个构造，而一些看似强的 pooled 结论在更严格的治理定义下会失稳。
这句话比“我们多统计了几个变量”更接近这轮工作的真正价值。