# 1. 你的开源项目 PR 太多（200+），你怎么看怎么推动治理 A 按时间顺序一个个慢慢 review B 先批量分拣清理存量（合并/关闭/修改），再用模板与 bot 治理增量并按优先级处理 ✓ 正确答案 C 把 200 个 PR 全部合并 D 关闭所有 PR 重新开始
# 2. 你的开源项目 PR 是低质量（不规范），你怎么看怎么推动 A 直接关闭所有低质量 PR B 公开羞辱低质量贡献者 C 降低标准，全部放行 D 用 PR 模板、CONTRIBUTING 与 CI 门禁把规范前置，并对低质量 PR 给出善意、具体的改进引导 ✓ 正确答案
# 3. 你的开源项目 PR 没人 label（分类），你怎么看怎么推动 A 放弃 label，反正能看 B 让贡献者自己打 label C 给所有 PR 打同一个 label D 设计清晰 label 体系并用 bot 自动打标签、人工批量补标，绑定工作流提升处理效率 ✓ 正确答案
# 4. 如何为 issue 与 PR 定义响应 SLA（如首次回应时限）并公开承诺，让社区可以监督你的治理节奏？ A 按实际能力设定现实 SLA、区分类型并公开，用工具跟踪兑现、定期复盘调整 ✓ 正确答案 B 设定一个很高的 SLA 展示诚意 C SLA 只写给自己看 D SLA 定了就永不调整
# 5. 如何设计 issue 生命周期状态（待复现、已确认、修复中、待发布、关闭）并让状态流转对贡献者透明？ A 设计清晰状态机与流转规则，状态变更时主动通知提交者并公开状态含义 ✓ 正确答案 B 只用一个状态，所有 issue 统一 C 状态随意改，不记录 D 只在关闭时通知提交者
# 6. 你的开源项目 PR 被 ignore（无回应），你怎么看怎么推动 A 每天反复 @ 维护者 B 先让 PR 保持简洁、可合并并附完整信息，低频礼貌跟进，长期无回应时评估撤回或转其他渠道 ✓ 正确答案 C 直接删除 PR 放弃 D 去社交平台公开施压
# 7. 你的开源项目 PR 被 spam（机器人），你怎么看怎么推动清理 A 一个个手动删除 B 把疑似 spam 的一律关闭 C 用规则与 bot 批量识别关闭 spam，用模板与门槛阻断增量并保护正常 PR ✓ 正确答案 D 忽略 spam，等它自己消失
# 8. 你的开源项目 PR 长期 open（僵尸 PR），你怎么看怎么推动清理 A 全部关闭，不管有无价值 B 区分可救与过时，能救的促成完成、过时的统一关闭说明原因，并用 stale 机制自动化防堆积 ✓ 正确答案 C 永远保留所有僵尸 PR D 只清理自己不顺眼的
# 9. 你的开源项目 PR 需要等发版（hold），你怎么看怎么推动 A 直接把 PR 合并，不等发版 B 给 PR 打 hold 标记并说明原因与预期时间，保持其可合并状态，到发版按时合并 ✓ 正确答案 C 把 PR 关闭等待 D 让 PR 挂在那里，不处理
# 10. 你的开源项目 issue 是低质量（重复/不清楚），你怎么看怎么推动 A 用 issue 模板前置要求，能补的引导补齐、重复的合并、无关的关闭，并引导先搜索 ✓ 正确答案 B 直接关闭所有低质量 issue C 把低质量 issue 全部保留 D 让贡献者自己解决
# 11. 你的开源项目 issue 被 spam（广告），你怎么看怎么推动清理 A 手动一条条删除 B 不处理，等它自己消失 C 把所有疑似 spam 的都关闭 D 用规则与 bot 批量识别关闭 spam、限制来源账号，用模板与门槛阻断增量并保护正常 issue ✓ 正确答案
# 12. 你的开源项目 issue 被滥用（讨论代替 discussion），你怎么看怎么推动 A 允许所有讨论都留在 issue B 直接关闭所有讨论型 issue 不解释 C 在 issue 里与用户争论 D 友善引导到 discussion 并提供链接，用模板与说明明确用途，移动或关闭讨论型 issue 保持可追踪 ✓ 正确答案
# 13. 你如何通过“issue 模板+自动标签”治理低质量 issue，减少维护者反复澄清的时间成本？ A 模板会增加维护者负担，不该用 B 让维护者手动为每个 issue 补信息 C 用结构化模板强制前置信息收集，用 bot 按规则自动打标签并标记缺信息 issue，减少维护者反复澄清 ✓ 正确答案 D 模板是摆设，标签随便打
# 14. PR 合并策略（squash、rebase、merge commit）如何选择，并在 CONTRIBUTING 中约定以减少争议？ A 每个 PR 用不同策略，由心情决定 B 根据项目历史与团队偏好选择一种策略，写进 CONTRIBUTING 说明理由并保持一致 ✓ 正确答案 C 一律用 merge commit，不解释 D 合并策略不需要文档化
# 15. 你的开源项目 issue 长期 open（僵尸 issue），你怎么看怎么推动清理 A 全部关闭，不管有无价值 B 只清理自己不顺眼的 C 永远保留所有僵尸 issue D 区分可救与过时，可救的补信息确认、过时无回应的关闭说明原因，并用 stale 机制自动化防堆积 ✓ 正确答案
# 16. 你的开源项目 issue 需要先 discuss（社区讨论），你怎么看怎么推动 A 把 issue 标记为需讨论，引导到 discussion 收集意见并收敛，讨论清晰后再实现并关联上下文 ✓ 正确答案 B 直接跳过讨论，按自己的想法实现 C 无视讨论，直接关闭 D 让提交者自己讨论，维护者不管
# 17. 你的开源项目 issue 需要回报错误（feedback），你怎么看怎么推动 A 放弃，反正信息不全 B 让维护者自己猜问题 C 直接关闭所有信息不全的 issue D 在 issue 里明确列出所需反馈信息并用模板引导，拿到后复现定位并闭环修复 ✓ 正确答案
# 18. PR 治理中你如何用 CI 门禁（lint、测试、覆盖率）把“人工评审”聚焦到真正需要判断的地方？ A 让 CI 自动检查 lint/测试/覆盖率等机械性问题，评审聚焦到设计、架构、兼容性等判断性层面 ✓ 正确答案 B 用 CI 门禁完全替代人工评审 C 不用 CI，全靠人工 D CI 只跑 lint，其他全拒绝
# 19. 安全漏洞相关的 issue 应走怎样的私密上报与披露流程，避免漏洞在修复前被公开利用？ A 把漏洞直接发到公开 issue 让大家知道 B 永不披露，只保密 C 用私密上报渠道收集，修复完成后按协调披露窗口公开并附修复版本与缓解措施 ✓ 正确答案 D 先公开披露再慢慢修复
