# 1. 你想贡献开源但 PR 被 reject（没充分理由），你怎么看怎么 argue A 立即在社交平台公开指责维护者，利用舆论施压 B 反复提交一模一样的 PR，直到维护者妥协 C 先理解拒绝的具体原因，再基于事实与项目文档理性回应 ✓ 正确答案 D 放弃所有开源贡献，认为维护者不尊重新人
# 2. 你想贡献开源但项目 issue 被 close（觉得不够好），你怎么看怎么 argue A 不断重新打开同一 issue，直到被接受 B 把 issue 重新组织成信息完整、符合项目范围的请求，再与维护者沟通 ✓ 正确答案 C 直接发邮件投诉维护者歧视 D 放弃该项目，换一个项目随便提
# 3. 你想贡献开源但 PR 被拆分要求（每个 PR 独立），你怎么看怎么推动 A 一次性提交所有改动，让维护者自己看 B 拒绝拆分，认为自己的改法更好 C 按功能内聚拆成相互独立、各自可评审通过的小 PR，并规划合并顺序 ✓ 正确答案 D 把拆分的 PR 全部塞进一个分支一次性提交
# 4. 你想贡献开源但 PR 被搁置（半年没 review），你怎么看怎么推动 A 每天在群里 @ 维护者，直到其回复 B 直接删除 PR，认为项目不值得贡献 C 让 PR 保持 rebase 到最新、可合并状态，并低频礼貌地跟进步伐 ✓ 正确答案 D 把 PR 内容公开到社交平台施压
# 5. 你想贡献开源但公司不允许员工贡献（policy），你怎么看怎么推动 A 私下用个人账号偷偷贡献，不告诉公司 B 公开抱怨公司政策阻碍技术成长 C 通过与法务/leader 沟通了解合规路径，并主动划清不影响公司的边界 ✓ 正确答案 D 直接辞职以便自由贡献
# 6. 你想贡献开源但维护者 push 太快（要你做完），你怎么看怎么推动 A 无条件加班熬夜赶工，以牺牲质量为代价合并 B 与维护者确认期望和时间表，给出现实计划并分阶段交付、及时同步 ✓ 正确答案 C 不理会维护者，按自己的节奏慢慢做 D 直接拒绝修改，认为维护者无理
# 7. 你想贡献开源但项目 CI 失败（环境问题），你看怎么推动 A 直接忽略失败，认为不是自己的问题 B 定位失败原因、确认与改动无关并附证据，提出修复建议并配合维护者 ✓ 正确答案 C 抱怨项目 CI 太差然后放弃 D 随便改一行代码重新提交蒙混过关
# 8. 你想贡献开源但项目 CLA 要求（公司签），你怎么看怎么推动 A 伪造签名绕过 CLA 尽快合并 B 理解 CLA 必要性，主动推动公司合规签约，并询问是否可先以非代码方式参与 ✓ 正确答案 C 拒绝签署并公开指责项目官僚 D 冒充同事签名再提交
# 9. 你想贡献开源但项目 issue 太多（不知道做哪个），你怎么看怎么推动 A 优先选"good first issue"等标签、范围小且匹配自身能力的任务，并先确认 issue 有效 ✓ 正确答案 B 随机挑一个 issue 就埋头做 C 全做一遍证明自己 D 只找大 issue 以展示能力
# 10. 你想贡献开源但项目 issue 是"good first issue"但维护者没回应，你看怎么推动 A 既然没回应就放弃，换别的项目 B 基于完整 issue 信息自主完成规范 PR 并关联 issue，让 PR 自足易 review ✓ 正确答案 C 反复 @ 维护者直到回应 D 绕过流程直接改 main 分支
# 11. 你想贡献开源但项目 license 不让商用，你怎么看怎么推动 A 绕过 license 限制，偷偷商用 B 无视 license 直接 fork 商用 C 到处发帖骂这个 license 阻止商业发展 D 尊重 license 条款，区分贡献与商用需求，评估自身场景并寻找合规替代方案 ✓ 正确答案
# 12. 你想贡献开源但项目 rebase 要求（保持最新），你怎么看怎么推动 A 拒绝 rebase，坚持用自己旧分支 B rebase 后不测试直接提交 C 把自己的分支 rebase 到最新 main、解决冲突、重跑测试，并在 force-push 前说明 ✓ 正确答案 D 用 merge 把 main 全部塞进自己的提交历史
# 13. 你想贡献开源但项目对新人门槛高（PR 要求 CI 过），你看怎么推动 A 抱怨门槛高，请求维护者绕过 CI 合并 B 找维护者求情破例 C 视 CI 为质量保障，本地先复现环境与命令，吃透 CI 配置后逐项通过 ✓ 正确答案 D 提交一个永远过不了 CI 的 PR 表示抗议
# 14. 你想贡献开源但项目签名要求（DCO），你看怎么推动 A 忽略签名，等 bot 报错再说不关自己事 B 伪造邮箱签名 C 用 git commit -s 添加 Signed-off-by，并对历史提交补签后 force-push ✓ 正确答案 D 让维护者代签
# 15. 你想贡献开源但项目要求"必须 review 过"，你看怎么推动 A 请求维护者直接合并跳过 review B 频繁 @ 所有人催促合并 C 对 review 意见一律拒绝 D 让 PR 小而聚焦、描述清晰，逐条友善回应 review 意见并主动改进 ✓ 正确答案
# 16. 你想贡献开源但项目要求"必须 test coverage 不减"，你怎么看怎么推动 A 用配置把新代码从覆盖率统计中排除 B 只写一个空测试凑数 C 为新增代码补充覆盖真实行为的测试，难覆盖处说明理由与维护者确认 ✓ 正确答案 D 删掉旧测试以平衡覆盖率
# 17. 你想贡献开源但项目要求"必须不破坏 API"，你怎么看怎么推动 A 直接修改旧函数签名，反正测试会过 B 隐瞒 breaking change 悄悄合并 C 优先用新增可选参数、新函数等兼容方式扩展，确需 breaking 时说明理由与迁移方案并规划版本 ✓ 正确答案 D 删除旧 API 节省代码
# 18. 你想贡献开源但项目要求"必须有 bench"，你怎么看怎么推动 A 随便写一个从不运行的 benchmark 模板 B 只口头声称性能没变 C 为关键路径编写可复现的 benchmark，改动前后对比并将数据附在 PR 中 ✓ 正确答案 D 用 main 分支的假数据充当 bench
# 19. 你想贡献开源但项目要求"必须有 discuss 链接"，你怎么看怎么推动 A 动手前先发起设计讨论收集意见，在 PR 中关联讨论并说明设计收敛过程 ✓ 正确答案 B 随便编一个链接应付 C 实现完再补一个讨论 D 用无关 issue 链接冒充
# 20. 你想贡献开源但项目要求"必须有 perf 测试"，你怎么看怎么推动 A 写一个运行一次就完事的测试 B 性能测试只在本地跑一次 C 用并发压测海量数据把 CI 拖垮 D 设计可重复、方差可控的性能测试设定合理阈值，与功能测试分离并附上数据 ✓ 正确答案
# 21. 你想贡献开源但项目要求"遵守 CoC"，你怎么看怎么推动 A 无论沟通还是处理违规都保持尊重建设性，维护者违规走正规流程 ✓ 正确答案 B 只要代码好，态度无所谓 C 遇到冒犯就公开反击 D 只在被要求时才装模作样
# 22. 你想贡献开源但项目要求 changelog，你看怎么推动 A 随便往 changelog 末尾加一行 B 遵循项目 changelog 格式与分类约定，只记录用户可见的变化 ✓ 正确答案 C 不写 changelog，认为用户不该看 D 把每次提交都写进 changelog 制造噪音
