你开了一家社区食堂：每天几十张顾客留言单（Issue）飘进来——有人报错“番茄炒蛋太咸”，有人点新菜“想吃红烧肉”，还有志愿者端着拿手菜（PR）想上架。一开始你亲自回单、试菜、记账，轻松惬意；可当月单量过百，满墙便签、漏看的留言、试菜试到嘴麻，食堂开始失控。 GitHub 的 Issue/PR 管理，就是这套“食堂运营术”：标签是墙上的菜单分类磁贴，模板是标准点单纸，机器人是传菜履带和定时闹钟，代码评审是主厨试菜，分支保护是厨房门禁，社区规范是排班表和食堂公约。把它们配齐，一家再热闹的食堂也能井井有条，还能从路边小店扩张成连锁集团——这就是开源项目的“规模化治理”。

岗位关联

学好 Issue/PR 管理，你能在任何开源或团队项目中成为“靠谱的维护者”：用系统化流程降低沟通成本、保护代码质量，这是大厂招聘与个人作品集里最亮眼的工程素养。

目录
  1. 可视化演示
  2. 标签体系设计
  3. Issue模板规范
  4. 自动化机器人
  5. 评审流程规范
  6. 分支保护规则
  7. 社区协作规范
  8. 规模化治理
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Issue生命周期流转、PR评审流水线与自动化机器人协作流程，直观呈现开源项目治理的核心工作流。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Issue生命周期流转 Issue从开启到关闭经过分流、处理、验证三个关键阶段 标签体系实现优先级分类与类型标记，支撑自动化分流 Open → Triage → Progress → Closed 标签驱动状态流转，减少人工协调成本

标签体系设计

社区食堂后厨最显眼的，是门口那面磁贴墙：红的是“荤菜”、绿的是“时蔬”、黄的是“辣度”，还有“过敏原”“大份”“外带”。顾客单子一到，帮工五秒打上磁贴，炒菜师傅扫一眼就排出先后。这面墙的魔力在于——分类统一、颜色一眼可辨、数量克制。

GitHub 的 Issue/PR 同样会像雪花一样飞来。没有分类，维护者只能一条条点开看，漏掉重要缺陷是家常便饭。GitHub 的“标签（label）”就是那面磁贴墙：给每个 Issue/PR 贴上彩色标签，之后可以按标签搜索、过滤，还能让机器人基于标签自动处理后续流程。

一套优秀的标签体系通常沿三个维度设计：类型（bug/feature/doc/question）回答“这是什么”；优先级（high/mid/low）回答“多急”；状态（triage/confirmed/fixed）回答“到哪一步了”。命名上推荐前缀统一，如 type: bug、prio: high；颜色上固定规则，如红=缺陷、绿=发布、灰=待定；总量控制在 20~30 个。当多个标签同时出现，如何排出处理顺序？需要可计算的优先级得分。

这套体系的本质，就是把磁贴墙的秩序数字化：字段统一、颜色有约定、数量克制。标签不是越多越好——墙贴太满，师傅反而不知先看哪张。

Priority=ws⋅S+wi⋅I+wf⋅F\text{Priority} = w_s \cdot S + w_i \cdot I + w_f \cdot F
优先级 = 严重度、影响面、频度三项的加权和。就像后厨按“菜做错了 + 十人桌 + 反复投诉”三项打分，分高者先做。
  1. 严重度项 $w_s \cdot S$$S$ 表示缺陷的严重等级（如 1~5 分），$w_s$ 是它的权重。崩溃比拼写错误严重，先解决分高的。
    ws⋅Sw_s \cdot S
  2. 影响面项 $w_i \cdot I$$I$ 表示受影响的用户范围。核心模块挂掉影响全部食客，权重自然更高。
    wi⋅Iw_i \cdot I
  3. 频度项 $w_f \cdot F$$F$ 表示问题出现的频率。天天复现的 bug，比一年一次的更需要立刻处理。
    wf⋅Fw_f \cdot F
  4. 加权求和得到总分三项加权相加后排序，团队按分值从高到低逐条处理——这就是标签背后可量化的“出菜顺序”。
    Priority=ws⋅S+wi⋅I+wf⋅F\text{Priority} = w_s \cdot S + w_i \cdot I + w_f \cdot F

Issue模板规范

新来的顾客写字潦草：“来一份那个。”帮工猜半天，端错菜、退货、吵架。后来食堂在柜台压了一张标准点单纸：必填菜名、忌口、分量；选填辣度、备注。再潦草的客人也被引导着写完整、说清楚。

GitHub 的 Issue 模板就是这张“标准点单纸”：在 .github/ISSUE_TEMPLATE/ 目录放好 markdown 模板，用户点击 “New issue“ 时自动预填结构。它把”猜“变成”填空”，大幅减少一来一回的追问。

缺陷报告模板通常包含复现步骤、期望行为、实际行为、运行环境、截图；功能请求模板则需要使用场景、当前痛点、期望方案、验收标准；模板头部用 YAML front matter 声明 name/about/title/labels/assignees，还可以用 form schema 做出下拉框、复选框、输入框等交互表单。一个模板的好坏可以数学化——看信息完整度。

标准点单纸的意义不是刁难顾客，而是让最没有经验的顾客也能交出合格的信息。模板写得越贴心，维护者的“追问成本”就越低。

Rbug(I)={1,I⊇{st,ex,ac}0,otherwiseR_{\text{bug}}(I) =\begin{cases}1, & I \supseteq \{st, ex, ac\} \\0, & \text{otherwise}\end{cases}
把一份 Issue 看成字段集合，若同时包含“复现步骤(st)、期望行为(ex)、实际行为(ac)”则判定合格，否则打回补全。
  1. 集合 $I$把一份 Issue 的内容当作一个集合，记下它包含的所有字段。
    II
  2. 必要条件 $\{st, ex, ac\}$分别代表“复现步骤(steps)、期望行为(expected)、实际行为(actual)”，缺一条，Issue 就不完整。
    {st,ex,ac}\{st, ex, ac\}
  3. 包含判定 $I \supseteq$判断 Issue 是否完整包含这三个元素，这是“必填项”的数学含义。
    I⊇{st,ex,ac}I \supseteq \{st, ex, ac\}
  4. 输出 1 或 0完整得 1 分进入处理队列，不完整得 0 分自动打回，请提交者补充信息。
    Rbug(I)=1R_{\text{bug}}(I) = 1

自动化机器人

食堂上了三样设备：传菜履带（菜从后厨自动到窗口）、定时闹钟（到点提醒该煮饭了）、电子秤（出菜前自动称重，分量不足自动报警）。基础服务自动运转，师傅腾出手做真正需要手艺的事。

GitHub 上，这些设备就是“机器人（bot）”——通过 GitHub Actions、Probot 或第三方服务挂在仓库上的自动程序。它们只适合规则明确、重复性高的活儿，比如欢迎新人、检查格式、清理过期任务。

常用四类：欢迎机器人（新人第一个 Issue 自动回复并附上贡献指南）；失效 Issue 检测（长期无活动先贴标签提醒，再自动关闭）；PR 检查机器人（检查标题规范、CI 状态、是否冲突、文件变更范围）；定时清理（每周扫描无人认领的 Issue 汇总给维护者）。其中 stale 失效检测是最经典的设计。

履带与闹钟不是万能的：它们只是把规则执行得更忠实。规则本身——多久算过期、什么算失效——仍然要由人来定义。

Pstale(t)={0,t<twt−twtc−tw,tw≤t<tc1,t≥tcP_{\text{stale}}(t) =\begin{cases}0, & t < t_w \\\dfrac{t - t_w}{t_c - t_w}, & t_w \le t < t_c \\1, & t \ge t_c\end{cases}
过期概率随时间从 0 线性升到 1：7 天先提醒，30 天自动关闭。这就是 stale 机器人“先礼后兵”的数学表达。
  1. $t_w$（提醒线）比如 7 天没有动静的 Issue，stale 机器人先贴上“过期”标签，给作者一个反应窗口。
    tw=7t_w = 7
  2. $t_c$（关闭线）比如 30 天。过了这个时间点，机器人自动关闭 Issue，并留言“欢迎重新开启”。
    tc=30t_c = 30
  3. 线性攀升段$\dfrac{t - t_w}{t_c - t_w}$ 表示从提醒到关闭之间，“过期概率”随着天数线性上升到 1。
    t−twtc−tw\frac{t - t_w}{t_c - t_w}
  4. 分段取值$t < t_w$ 概率为 0（无人打扰），$t \ge t_c$ 概率为 1（必关）。中间每一天都在“逼近死亡线”。
    Pstale(t)∈[0,1]P_{\text{stale}}(t) \in [0, 1]

评审流程规范

社区食堂最怕“菜品翻车”。主厨立了一条铁律：任何新菜上菜单前必须试菜，且试菜要用同一张清单——咸淡、熟度、分量、摆盘。有了清单，三位师傅试出来的口味才一致，不会因为“我觉得还行”放水。

PR 就是志愿者的“新菜”。合并进 main 分支之前必须经过评审（code review），评审质量决定代码质量的下限。一个没有被试过的新菜直接上架，翻车只是时间问题。

评审三件套：评审清单（功能正确、测试覆盖、文档同步、无性能隐患）；代码所有权（CODEOWNERS 文件按目录/文件自动指派最有经验的评审人）；合并策略（squash merge 把一堆提交压成一个干净提交，保留整洁历史）。评审的放行条件可以写成一条逻辑公式——三个条件同时满足才准合并。

试菜清单的意义是去掉主观随意性：每个人的口味偏好不同，但标准一致，菜品（代码）的稳定才能沉淀为口碑。

M(PR)=CI∧(∣R∣≥1)∧(∣A∣≥n)M(PR) = CI \wedge (|R| \ge 1) \wedge (|A| \ge n)
合并 = CI 通过，且至少 1 名评审人被指派，且至少 n 人批准。三者缺一不可，就像试菜必须“尝过 + 记录 + 签字”。
  1. $CI$持续集成通过，等价于自动化测试与构建全部绿灯，是机器对代码的基本体检。
    CI=1CI = 1
  2. $|R| \ge 1$至少 1 位有权限的评审人被指派。没人负责的 PR，就像没人试菜的菜。
    ∣R∣≥1|R| \ge 1
  3. $|A| \ge n$至少 $n$ 个人批准（approve）。核心代码建议 $n=2$，双人互相制约。
    ∣A∣≥n|A| \ge n
  4. 逻辑与 $\wedge$三者同时为真才允许合并。任何一个不满足，PR 就继续挂起等待——这是“一票否决”的质量闸门。
    M(PR)=CI∧(∣R∣≥1)∧(∣A∣≥n)M(PR) = CI \wedge (|R| \ge 1) \wedge (|A| \ge n)

分支保护规则

后厨不是谁都能进的：没戴厨师帽、没洗手、没穿围裙，一律挡在门外。门禁不是为了防自己人，而是防止“没准备好的东西进入核心工序”。

Git 仓库同样有门禁：分支保护规则（branch protection），通常施加在 main 等核心分支上。它回答一个问题：什么样的提交，才有资格进入主干？

常用规则：强制状态检查（CI、lint、覆盖率必须全绿）；会话讨论必须解决（conversation resolution，所有评论处理完才能合）；过时评审自动失效（代码更新后需重新评审）；禁止强制推送（防止重写历史）。权限角色则按 read / triage / write / maintain / admin 逐级收敛。数学上看，门禁是所有检查的“与”运算——任何一个不通过，整扇门就关闭。

门禁挡的是错误，不是人。规则越贴近团队实际，就越少有人想绕开它；反之，过度保护只会让大家在门口排长队。

G(PR)=⋀i=1ksiG(PR) = \bigwedge_{i=1}^{k} s_i
合并放行 = 所有 k 项状态检查同时为 1（通过）。一张检查表里有一项红，门禁整体就是红。
  1. $s_i$（单项检查）第 $i$ 个状态检查的结果，通过为 1，不通过为 0，比如 CI、lint、覆盖率。
    si∈{0,1}s_i \in \{0, 1\}
  2. $\bigwedge$（连合取）要求所有 $k$ 个检查同时为 1。一个 0 就拖垮整体。
    ⋀i=1ksi\bigwedge_{i=1}^{k} s_i
  3. $G(PR)$ 为 1 表示放行门禁全部满足时，这条 PR 才拿到“进厨房”的资格。
    G(PR)=1G(PR) = 1
  4. 人为审查不包含在内这扇门只拦机器能判断的事，人的判断由评审流程负责——门禁和试菜是两道不同的关卡。
    G(PR)≠M(PR)G(PR) \neq M(PR)

社区协作规范

食堂开了三个月，问题来了：谁周三掌勺？顾客投诉找谁？新帮工不知道拖把放哪。于是墙上多了一张排班表、一份食堂公约——把预期写清楚，把责任分散开。

开源项目对应的是CONTRIBUTING.md（贡献指南：怎么提 Issue、怎么提 PR、代码风格、测试要求）、CODE_OF_CONDUCT.md（行为准则：什么样的讨论是被欢迎的）、维护者轮值（maintainer rotation，避免同一个人长期独自扛），以及里程碑规划（milestone 把 Issue 按版本目标聚合，让团队知道这一仗打到哪里）。维护者轮值的核心，是“别让同一个人累死”。

用工作量占比可以度量均衡程度。假设一个团队有 $m$ 位维护者，统计每个人实际处理的评审与合并数量，占比悬殊就说明轮值失效了。

公约和排班表看起来琐碎，却是社区能长期运转的土壤：把责任分散、把预期写清楚，人情味和秩序才能共存。

Li=Ri∑j=1mRjL_i = \frac{R_i}{\sum_{j=1}^{m} R_j}
$L_i$ 是第 i 位维护者的工作量占比。越接近 $1/m$ 越均衡，像排班表一样，各司其职才不累垮一个人。
  1. $R_i$（个人处理量）某位维护者在一个统计周期内处理的评审与合并数量。
    RiR_i
  2. 分母求和所有 $m$ 位维护者处理量的总和，代表团队的“总出力”。
    ∑j=1mRj\sum_{j=1}^{m} R_j
  3. $L_i$ 为工作量占比个人出力占总出力的比例，理想状态是 $L_i \approx \frac{1}{m}$。
    Li=Ri∑j=1mRjL_i = \frac{R_i}{\sum_{j=1}^{m} R_j}
  4. 轮值看扳机当某位维护者的 $L_i$ 长期偏高、其他人接近 0 时，就该启动轮值，防止“英雄病”与单点故障。
    Li→1L_i \to 1

规模化治理

小店口碑好，开了分店、连锁，最后成了集团。总店发现：每家分店各自为政会乱，必须中央厨房统一配方、统一培训手册、统一供应链。

开源项目同样会从单仓库长成多仓库、多团队。此时需要：多仓库协同（organization 分区管理 + project board 跨仓库跟踪进度）；依赖自动更新（Dependabot 自动提交升级依赖的 PR，机器人盯着供应链）；治理经验沉淀（changelog、迁移指南、贡献者分级，把踩过的坑写成文档）。判断这套系统是否健康，看一个核心指标——治疗率。

它衡量的是一个仓库“应对新任务 + 清理历史积压”的能力。治疗率接近 1，说明团队跟得上节奏；远小于 1，说明积压正在恶化。

从路边小馆到连锁集团，靠的不是某位传奇大厨，而是可复制的系统。治理经验沉淀下来，规模才能不牺牲质量。

E=NclosedNopened+NbacklogE = \frac{N_{\text{closed}}}{N_{\text{opened}} + N_{\text{backlog}}}
治疗率 = 本月关闭数 ÷（新增数 + 期初积压数）。它像食堂的翻台率：能消化多少单，比收了多少单更重要。
  1. 分子 $N_{\text{closed}}$月度内关闭的 Issue/PR 数量，代表“消化能力”。
    NclosedN_{\text{closed}}
  2. 分母 $N_{\text{opened}} + N_{\text{backlog}}$新增量加期初积压量，代表本月“本该处理的总量”。
    Nopened+NbacklogN_{\text{opened}} + N_{\text{backlog}}
  3. $E$ 为治疗率越接近 1，说明应对越及时；越接近 0，说明单子越堆越多。
    E∈[0,1]E \in [0, 1]
  4. 监控节奏连续三个月 $E < 0.5$，就该加人、减范围或增强自动化——别让食堂变成积压的后厨。
    E<0.5⇒警报E < 0.5 \Rightarrow \text{警报}

AI 应用场景

场景1：AI 自动打标签与分流

阶段：数据标注 + 文本分类

解决的问题：传统方式靠维护者手动给每个 Issue 贴标签、指派评审人，量大时容易漏和慢。AI 用预训练语言模型读 Issue 标题和正文，自动推荐 bug/feature/doc/question 标签、估算优先级，甚至按 CODEOWNERS 把任务路由到对应模块负责人——把“五秒贴磁贴”也自动化了。

具体案例：某中型开源项目接入 LLM 分流后，Issue 首次响应时间从 48 小时降到 6 小时，无人认领率下降 70%。

场景2：AI 辅助 PR 评审

阶段：代码理解 + 自动检查

解决的问题：评审人打开 PR 面对上千行 diff 头大。AI 对 diff 做摘要、检测常见问题（缺少测试、密钥泄露、超大单文件），生成初步评审意见清单，人类评审只做确认和补充——像主厨试菜时多了个配菜师，先备料再调味。

具体案例：Copilot code review 在 CI 阶段自动评论，把 30 分钟的人工浏览压缩到 5 分钟重点确认。

场景3：社区健康度预警

阶段：时序分析 + 异常检测

解决的问题：人工看不出“积压正在恶化”。AI 分析 Issue/PR 打开关闭曲线、响应时长中位数、bus factor，在治疗率跌破阈值时自动告警。相当于食堂的“客流预警系统”——客人还没挤爆门口，你就知道该加人手了。

具体案例：用 GitHub API 拉取数据，配合简单统计模型生成周报，自动识别“无人认领超过 7 天的 PR”并 @ 轮值维护者。

Python 演示

python58 行
"""Issue/PR 分流助手：模拟标签推荐、失效检测与评审清单生成"""  class TriageBot:    def __init__(self):        self.label_rules = {            'bug': ['崩溃', '报错', '异常', '失败'],            'feature': ['建议', '新增', '需求', '支持'],            'doc': ['文档', '教程', '拼写', '示例'],            'question': ['怎么', '如何', '请教', '求助'],        }        self.label_count = {}     def suggest_labels(self, text):        self.label_count = {name: 0 for name in self.label_rules}        for name, keys in self.label_rules.items():            for key in keys:                if key in text:                    self.label_count[name] += 1        ranked = sorted(            self.label_count.items(), key=lambda kv: kv[1], reverse=True        )        return [name for name, count in ranked if count > 0][:2]     def stale_check(self, age_days, warn=7, close=30):        if age_days < warn:            return 'normal'        if age_days < close:            return 'warning'        return 'closed'     def review_checklist(self, paths):        checklist = ['ci-passed', 'has-tests']        if any(p.startswith('src/') for p in paths):            checklist.append('needs-2-approvals')        if any(p.endswith('.md') for p in paths):            checklist.append('docs-reviewed')        return checklist  def main():    bot = TriageBot()    issues = [        '登录页频繁报错崩溃，请求失败',        '建议新增深色模式支持',        '求助：怎么配置本地环境',        '文档拼写错误，示例代码有误',    ]    for issue in issues:        labels = bot.suggest_labels(issue)        print('Issue:', issue[:12], '-> 标签:', labels)    print('9 天未动的 Issue 状态:', bot.stale_check(9))    print('含核心代码的 PR 清单:', bot.review_checklist(['src/api.py', 'test/api_test.py']))    print('纯文档 PR 清单:', bot.review_checklist(['docs/readme.md']))  if __name__ == '__main__':    main()
目的：用一个不依赖外部库的规则引擎，模拟开源维护者的三大日常——标签推荐、失效 Issue 检测、PR 评审清单生成。
  1. self.label_rules = {...}预置关键词规则库，对应“磁贴墙”的分类维度
  2. self.label_count = {name: 0 for name in self.label_rules}每处理一条 Issue 先把计数器清零
  3. if key in text关键词匹配，是文本分类最简单朴素的形态
  4. ranked = sorted(self.label_count.items(), ...)按命中数从高到低排序，取前两个作为推荐标签
  5. stale_check(age_days, warn=7, close=30)三个分支恰好对应过期概率分段函数：正常/提醒/关闭
  6. any(p.startswith('src/') for p in paths)识别“核心代码”，一旦命中就要求双人批准，模拟 CODEOWNERS 逻辑

常见误区

误区把标签加到 50 多个，觉得分类越细体系越完整。结果维护者每次贴标签都要想半天，新贡献者也看不懂。

正解标签的本质是“一眼可懂的分类”，20~30 个就够。就像食堂磁贴墙，贴 100 个磁贴反而没人看。标签应围绕三个维度（类型/优先级/状态）设计，并定期合并冷门标签，让墙始终清爽。

为何常见：人们把“标签数量”当成专业度的度量，忽略了标签是为了减少认知负担——越多越重，适得其反。

误区配了一堆 bot 就可以当甩手掌柜，以为自动化等于治理。

正解机器人只执行规则，不创造规则。stale 机器人再勤快，如果团队没有“什么时候算失效”的标准，它只会乱杀 Issue；传菜履带再快，菜单混乱也只是加速混乱。自动化的前提是流程本身被定义清楚。

为何常见：看到机器人自动关闭 Issue 很解压，误以为机器人就是治理本身，忘了规则设计才是真正的治理工作。

误区PR 来了赶紧合，大家开心效率高，评审是浪费时间。

正解快而糙的合并把质量问题留给用户。合并公式 $CI \wedge (|R| \ge 1) \wedge (|A| \ge n)$ 说明质量闸门是一票否决。试菜花 3 分钟，省下的是“顾客吃吐了再来投诉”的 3 小时。

为何常见：速度是显性指标，质量是隐性风险，人天然高估短期收益而低估长期负债。

误区每个字段都设为必填，一张表单 20 项，看似专业严谨。

正解高门槛会把新手贡献者挡在门外。模板的数学意义是保证最小完整集合 $\{st, ex, ac\}$，而不是无限膨胀。点单纸只需要必填“菜名、忌口、分量”，其余选填，才能让陌生人愿意坐下来写。

为何常见：用“防呆”的思维设计面向陌生人的表单，忘了陌生人也是需要被友好对待的用户。

误区把全部分支都保护起来，任何提交都要 5 个人批准，以为这样最安全。

正解过度保护会让高频小修（比如文档错别字）也寸步难行，最终大家会想办法绕过流程。门禁要因地制宜：main 分支严，feature 分支松，用等级差引导贡献者走正确路径。

为何常见：把“安全”等同于“严苛”，忽略了安全的核心是可执行、可持续——堵死所有路，等于逼人翻墙。

面试题

Q1. GitHub 中用于对 Issue 分类管理的核心机制是？

单选题 · easy

  • A.分支保护规则
  • B.标签分类体系← 正确答案
  • C.里程碑规划
  • D.版本发布管理

答案：B。标签是给 Issue/PR 贴分类颜色的机制；分支保护管哪些代码能合入，里程碑管版本目标，版本发布管交付节奏，都与“分类”无关。就像食堂的磁贴墙，标签就是那面墙。

Q2. Issue 模板的主要作用是？

单选题 · easy

  • A.增加填写表单的难度
  • B.提高提交信息完整度← 正确答案
  • C.限制普通用户的发言
  • D.自动修复发现的缺陷

答案：B。模板等于标准点单纸，用预设必填字段引导用户提交完整信息（复现步骤、期望、实际），减少维护者追问成本。它不限制发言，也不修代码，更不是为了刁难人。

Q3. stale 机器人发现一个 Issue 长期无活动，首先会？

单选题 · easy

  • A.立即彻底删除该 Issue
  • B.先贴过期标签并提醒← 正确答案
  • C.直接强制关闭整个仓库
  • D.把内容转移到私密仓库

答案：B。stale 机器人的行为对应分段函数：先到提醒线 $t_w$ 贴“过期”标签给作者反应时间，到关闭线 $t_c$ 才自动关闭。一上来就删除会误伤有效反馈，也不涉及仓库级操作。

Q4. 分支保护中的“强制状态检查”要求？

单选题 · mid

  • A.合并前所有检查项都必须通过← 正确答案
  • B.只要有一个检查项通过即可
  • C.检查失败也可以强行合并
  • D.仅管理员不受任何检查限制

答案：A。强制状态检查就是门禁公式 $G = \bigwedge s_i$，所有检查（CI、lint、覆盖率）必须全绿才放行。任何一项为 0，整体为 0，连管理员也不例外。

Q5. CODEOWNERS 文件的主要作用是？

单选题 · mid

  • A.记录仓库的版权所有者信息
  • B.按路径自动指派代码评审人← 正确答案
  • C.决定仓库是否对外开源
  • D.统计每个贡献者的代码行数

答案：B。CODEOWNERS 按目录/文件路径声明负责人，PR 改动对应路径时自动指派这些人为评审人——像食堂里“谁负责哪口锅就由谁试菜”。它和版权、开源协议、行数统计无关。

Q6. Squash merge 与普通 merge 的主要区别是？

单选题 · mid

  • A.把多个提交压缩成一个干净提交← 正确答案
  • B.把所有代码更改全部丢失掉
  • C.合并过程不需要任何状态检查
  • D.只有管理员才能执行这个操作

答案：A。Squash merge 将一个 PR 的多个 commit 压成一个提交，保持 main 历史的线性整洁。代码更改不会丢失，状态检查仍然执行，也不是管理员专属权限。

Q7. 某仓库本月新增 Issue 40 个、关闭 30 个、期初积压 20 个，治疗率是多少？

单选题 · hard

  • A.40%
  • B.50%← 正确答案
  • C.60%
  • D.75%

答案：B。治疗率 = 关闭数 ÷（新增数 + 期初积压数）= 30 ÷ (40 + 20) = 50%。它衡量仓库消化任务的能力，而不是简单的关闭率。

Q8. 一套好的标签体系通常包含哪些维度？

多选题 · mid

  • A.类型：缺陷/功能/文档← 正确答案
  • B.优先级：高/中/低← 正确答案
  • C.状态：待办/进行/完成← 正确答案
  • D.贡献者的姓名与联系方式

答案：ABC。类型回答“是什么”，优先级回答“多急”，状态回答“到哪步了”，三者构成标签三维度。贡献者个人信息属于隐私，不属于标签分类维度——就像食堂磁贴不会贴厨师手机号。

Q9. 关于自动化机器人在开源治理中的作用，正确的有？

多选题 · hard

  • A.欢迎机器人可降低新人门槛← 正确答案
  • B.stale 机器人定期提醒并关闭← 正确答案
  • C.机器人可以替代所有人工决策
  • D.机器人需结合明确规则运行← 正确答案

答案：ABD。欢迎机器人自动回复降低首次贡献的陌生感，stale 机器人按“先提醒后关闭”清理积压，两者都依赖明确规则。但机器人不创造规则，复杂决策（如设计取舍）仍需要人类判断。

Q10. 设置 main 分支保护时，推荐开启的选项有？

多选题 · mid

  • A.要求 PR 经过至少一人评审← 正确答案
  • B.强制要求所有状态检查全绿← 正确答案
  • C.禁止任何形式的强制推送← 正确答案
  • D.允许所有人无需评审直接推送

答案：ABC。评审要求、状态检查全绿、禁止强制推送是保护 main 的三道标准防线；相反，允许无评审直接推送会绕过所有质量闸门，属于错误选项——就像敞开厨房门让任何人进。