贡献被采纳并被他人看见本身构成回报
别名: 采纳回报 · 被合并的满足 · prosocial impact
概念解释
在报酬光谱的最末端有一类常被忽略的回报：贡献的产出被系统真实采纳，且这件事被他人看见。补丁被合并进主干、建议被产品采纳上线、词条修改被保留——对贡献者，这不只是「事成了」，而是一次公开的能力证明与影响确认。它同时满足两个深层需求：胜任的社会证明（有人检验过我的工作并判定可用）与影响的意义感（我的产出被真实使用，而不只是沉入仓库）。对开源新手与志愿贡献者的追踪研究反复看到同一现象：第一次贡献被合并的人，后续持续贡献的概率显著上升；被拒且得不到解释的人，大概率一去不返。采纳是这类系统里真正流通的货币。
机制
采纳回报的成立需要两个条件叠加，缺一即失效。采纳必须真实且有筛选：来者必收的采纳不构成证明——正因为合并门槛存在，「被合并」才是胜任的信号；这也是为什么开源的 merge 是有仪式感的事件。可见必须发生：私下采纳（无人知晓的贡献）只解决影响感，不解决声誉——声誉经济的记账单位是「他人看见的采纳」，所以变更日志署名、致谢名单、合并通知不是锦上添花，而是回报的兑现机制。组织心理学的影响实验（Grant 让员工接触自己工作的受益者，绩效与留存显著上升）确认了另一半：知道产出被谁、如何使用，本身就能驱动投入。负面通路同样锋利：对开源新手的追踪显示，被拒绝后得不到解释是流失的最强预测因素之一——拒绝不只是「这次没成」，而是当众的否定；Tsay 与同事对 GitHub 评价的实验还发现，评审对贡献者身份与历史的依赖会污染信号本身（同样代码，署名不同待遇不同），使采纳证明的部分含金量来自人而非作品。这些负面通路决定了采纳系统的设计重心：拒绝的私密化与解释、评审的去身份化。
怎么研究
- 范式：新手队列追踪——以首次贡献的结局（被合并 / 被拒有解释 / 被拒无解释）分组，比较后续留存与贡献量；评价实验（Tsay 式设计：操纵署名可见性与提交者历史，看评审决定随人还是随作品变）；现场干预（给贡献者推送「你的产出已被 X 使用」的影响信息，对照留存与投入）。
- 变量：自变量为采纳结局、采纳的可见性操作（署名 / 公示 / 通知）、影响信息的呈现；因变量为后续贡献概率、贡献持续时间、投入量。
- 在界面研究里的用途：贡献工作流的「回报兑现点」审计——采纳发生时，系统是否自动完成署名、通知、公示三个动作。
- 方法论注意点：采纳与后续贡献的相关里混着能力自选择（好作品本来就更可能被采纳且作者更有能力），需要倾向得分或工具变量剥离；影响信息的效应有适应（重复推送边际递减），长期留存要分时段测。
边界
采纳回报的前提是贡献者在意这个共同体与这个信号源——对纯打工心态的计件参与者，「被采纳」只是验收通过，不构成额外回报，那里的兑现机制是单价与结算速度。可见性本身有反面：公开的拒绝记录构成寒蝉，对新手尤甚——高门槛社区若把拒绝也公开展示，等于用声誉系统惩罚学习者。采纳信号还能被反向博弈：为通过评审而迎合评审口味、放弃有争议但正确的方向，使系统整体趋于保守——那是治理层的权衡，不在动机层的讨论内。徽章、等级等声誉系统的设计属于声誉机制主题，这里只涉及「产出被采纳」这一事件本身的回报属性。
怎么落地
- 把采纳的兑现自动化：合并 / 采纳即触发署名（变更日志、致谢名单）+ 定向通知（告诉贡献者他的产出已在哪里上线）——三个动作一个都不该是手动的。
- 拒绝走私密通道且必附一句具体解释；公开记录只保留采纳，不展示拒绝。
- 评审界面对贡献者身份做去强调（默认以内容视图评审，身份按需展开），压低信号被人格化的部分。
- 影响信息具体化：「你的建议上线后，用户反馈了……」优于抽象的「感谢贡献」——受益者与使用场景是意义感的原料。
- 验证：按首次贡献结局分组追踪 90 天留存曲线；若「被拒有解释」组的留存显著逼近「被合并」组，解释机制在起作用；若同样崩塌，先检查拒绝通知的措辞与可见性设置。