issue 与 PR 治理

• 对大规模 PR 积压的治理策略
• 建立分拣、优先级与清理机制的思路
• 用机器人辅助分流的能力

我会先意识到 200+ 的积压意味着"流入大于处理能力"，需要系统性治理而非逐个硬扛。我会先做一次批量 triage：按状态（可合并、需修改、无回应、已过时）把 PR 分桶，先清理能快速合并的、标记需要修改的、关闭长期无回应的僵尸 PR，把存量降到可管理。然后建立增量机制：设 PR 模板与 CI 门禁让提交更规范，用 bot 自动请求 review、标记 stale、提醒无响应 PR，让"处理哪些"由规则决定。我会按优先级（安全、bug、功能、文档）排定期 review，并公开处理节奏，让贡献者知道预期。同时考虑是否扩大 review 人力或调整合并策略降低处理成本。

200+ 积压是典型的"治理问题"而非"单纯工作量"。核心是"先清理存量、再治理增量"，用批量分拣、模板、bot 把流程自动化，把维护者精力聚焦到真正需要判断的地方。这体现大规模治理能力。

• 对低质量 PR 成因与治理的认知
• 用模板与文档提高提交质量的能力
• 在维护质量与鼓励参与间平衡

我会先判断低质量 PR 的成因：多数是贡献者不了解项目规范，而非恶意。推动时我会用"工具与文档"而非"抱怨"来治理：完善 PR 模板（要求问题描述、测试、changelog、影响范围），在 CONTRIBUTING 中写清规范，让提交前就覆盖大部分要求；用 CI 门禁自动拦截格式、lint、测试问题，减少人工判断。对仍不规范的 PR，我会给出具体、善意的修改建议并关联相应文档，帮助贡献者改进，而不是直接拒绝。对反复低质量且不配合的，我会按规则处理（如关闭并说明），但整体上把"提高提交质量"当作长期的引导过程。

低质量 PR 的根治是"降低提交门槛"而非"降低标准"。用模板、文档、CI 把规范前置到提交环节，再配合善意引导，既保质量又留新人。这体现流程治理与社区经营的双重能力。

• 对 label 在治理中作用的认知
• 设计自动化打标签与人工分工的机制
• 用分类提升处理效率的思路

我会先把 label 视为"让 PR 可被排序、可被分配"的治理基础设施，没有 label 会导致 PR 难以按优先级处理。推动时我会设计一套清晰的 label 体系（类型：bug/feature/docs；状态：待 review/待修改/需讨论；优先级），并尽量用自动化实现：基于 PR 模板字段、标题前缀、文件路径等规则由 bot 自动打标签，把常规分类交给规则。对需要人工判断的，我会在固定维护时段内批量补标。我会把标签与工作流绑定（如按标签自动请求对应 reviewer、按优先级排队），让 label 真正服务于处理效率，而不是摆设。

label 治理的核心是"分类服务于处理流程"。用自动化 + 人工批量补标，让 PR 一进门就被合理归类，后续的 review、分配、优先级才有依据。体现代码与流程治理的闭环思维。

• 对 SLA 作为治理承诺的理解
• 设计可执行、可监督的 SLA 指标
• 把 SLA 与治理透明度结合的能力

我会把 SLA 定义为"对社区可预期的响应承诺"，关键是要可执行、可衡量、可公开。设计时我会先评估实际处理能力，设定现实的目标（如首次回应 48 小时内、定期 review 每 N 天），避免承诺过高而失信。我会把 SLA 按类型区分（如 issue 首次回应、PR 首次 review、安全报告紧急响应），并公开在治理文档或网站，说明"多久能得到什么响应"。为了让社区监督，我会用工具跟踪响应时间（如 bot 自动标记超时、定期公布统计），定期复盘兑现情况，对未达标的调整流程或资源。SLA 的核心是"承诺与现实匹配 + 透明可查"，而非空喊口号。

SLA 是治理透明度的体现，它把"我们多久响应"变成可监督的承诺。设计的关键是现实可执行、公开可查、定期复盘，让社区信任治理节奏。这体现对治理承诺与问责的成熟理解。

• 对 issue 生命周期状态机设计的理解
• 通过状态流转管理 issue 的处理质量
• 让状态与贡献者可见、可预期的治理意识

我会把 issue 生命周期设计成一组清晰、可流转的状态，让每个 issue 都有明确的"当前位置"。典型状态如：待复现（需确认）、已确认（是 bug）、修复中（有人在做）、待发布（已修复等待发版）、关闭（已解决/无效/重复）。我会用 label 或状态字段承载这些状态，并定义状态间的流转规则（哪些状态可以到哪些状态，由谁触发），避免状态混乱。为让贡献者透明，我会在状态变更时主动通知提交者（如自动评论说明"已确认，正在修复"），并公开状态含义说明，让贡献者知道"我的 issue 现在在哪、下一步会怎样"。我会定期清理长期停滞的状态，避免"僵尸"路径。

issue 生命周期状态是把"散乱的问题"变成"可追踪的流程"的关键。清晰的状态机 + 定义流转规则 + 主动通知提交者，能让治理对贡献者透明、可预期。这体现流程设计与透明沟通能力。

• 对 PR 无回应的理性理解
• 有分寸地跟进与争取回应的能力
• 在坚持与放弃间把握平衡

我会先理解 PR 无回应常见于维护者资源有限，而非贡献者的问题。推动时我会先检查 PR 是否易于处理：是否保持 rebase 到最新、描述是否清晰、测试是否完整，先把"对方不愿看"的成本降到最低。然后我会用有分寸的方式跟进：低频（如数周一次）在 PR 里礼貌 comment 说明改动仍有效、询问进展，避免刷屏或 @ 过多。我会尝试提供多种跟进渠道（discussion、邮件、社区），并主动询问是否可协助 review 或调整优先级。若长期无回应，我会评估是否把 PR 撤回到自己的分支继续维护，或转向其他渠道，避免无限等待。

面对无回应 PR，关键是把"对方 review 的成本降到最低"并"有分寸地跟进"。先让 PR 自足易审，再低频礼貌提醒，最后评估是否撤回或转向，体现耐心与务实。

• 对 spam 处理的识别与分类能力
• 用工具与规则批量清理 spam 的方案
• 防止 spam 再次入侵的机制

我会先识别 spam 的特征（批量无意义内容、广告、自动生成提交），与正常 PR 区分开，避免误伤。清理时我会用批量方式：借助 bot 或脚本按规则（如无意义内容、重复模式、来源异常）批量关闭 spam PR，并加上标记。为防止反复，我会在 PR 模板中要求必要信息，用 bot 对可疑 PR 自动标为需人工确认，必要时设置门槛（如是否正确填写模板、是否关联 issue）。对反复 spam 的账号，我会按规则处理（举报、限制）。我会保留少量样本用于后续识别，并保持清理记录，让处理透明可核。

spam 治理的核心是"识别 + 批量清理 + 防再入侵"。用规则与工具批量处理，配模板和门槛阻断增量，同时保护正常贡献者不被误伤，是维护者应对骚扰的工程化手段。

• 对僵尸 PR 成因的判断
• 区分"值得救"与"该关闭"的方式
• 用 stale 机制防止僵尸堆积

我会先判断僵尸 PR 的成因：是贡献者没完成、维护者没处理、还是 PR 已过时。对有能力救的（改动有意义、内容基本完整），我会主动联系贡献者确认是否继续，必要时由我或他人接手完成；对已过时、无回应的，我会在统一说明后关闭，并解释原因（如"长期未更新，可重新提交"）。为防止僵尸累积，我会用 stale bot 机制：给长期无活动的 PR 自动打标记并提醒，超期后自动关闭，让"僵尸"被规则化处理而非人肉跟踪。我会公开清理标准，让贡献者知道"什么样的 PR 会被判为僵尸"。

僵尸 PR 的清理要"能救则救、该关则关"，并用 stale 机制把清理变成自动化规则。这样既避免误杀有意义的 PR，又从机制上防止积压，体现治理的规范与温度。

• 对 PR 与发版节奏关联的理解
• 管理"等发版"期间 PR 状态的能力
• 与贡献者沟通预期的方式

我会理解部分 PR 需要等发版（如 breaking change 要等大版本、或与特定版本周期绑定）是合理的版本管理策略。推动时我会先确认该 PR 是否真的必须等发版，还是可以提前合并到下一版本分支。若确实需要 hold，我会给 PR 打上 hold 标记，并在 PR 里说明原因与预期发版时间，让贡献者知道"为什么等、等多久"。期间我会保持 PR 可合并状态（rebase 到最新、处理冲突），避免到了发版窗口还要重新修。到发版时我会按承诺及时合并，并跟贡献者确认。我会把 hold 作为显式状态管理，避免它悄悄变成无人关注的僵尸 PR。

hold 是版本治理工具，目标是"该等的等、不该等的别等"。用显式标记、说明原因、保持可合并、到期兑现，能把 hold 变成可控的排队而非拖延，体现版本管理的严谨。

• 对低质量 issue 成因与处理的认知
• 用模板与引导提升 issue 质量的方法
• 在关闭与帮助间平衡

我会把低质量 issue（重复、信息不清）视为"信息基础设施不足"的结果，而非贡献者不负责。推动时我会先用模板从源头收紧：issue 模板强制要求复现步骤、版本、期望与实际行为，让不清楚的提交变少。对已存在的低质量 issue，我会先判断是否可救：能补充的（如让贡献者补复现信息）会引导补齐；确属重复的会合并到已有 issue 并说明；无关的会关闭。我会常用"搜索后再提交"的引导和常见问题清单减少重复。对不配合的极端情况才关闭，整体上以"引导完善"为主，维护 issue 列表的信息质量。

低质量 issue 的根治是"让提交者第一次就提供足够信息"。用模板前置要求、用引导补全已有 issue、用合并消除重复，能把治理从"事后清理"变成"事前预防"。

• 对 spam issue 的识别与处理
• 用规则与工具批量清理 spam 的方案
• 防止 spam 再次入侵的机制

我会先识别 spam issue 的特征（广告、无关链接、批量无意义内容），与正常 issue 区分。清理时我会用批量方式：借助 bot 或脚本按规则批量关闭 spam issue 并标记，必要时对来源账号做限制。为防止反复，我会在 issue 模板中要求必要信息，用 bot 对可疑 issue 自动标记需人工确认，或对接垃圾信息过滤。对反复 spam 的账号按规则处理（举报、限制）。我会保留处理记录，让清理透明可核，同时注意不误伤正常用户提交的 issue。

spam 治理的关键是"识别、批量、防再入"。用规则与工具批量清理，用模板与门槛阻断增量，同时保护正常提交，是维护者应对骚扰的工程化与机制化手段。

• 对 issue 与 discussion 用途区分的理解
• 引导不当 issue 到正确渠道的能力
• 维护 issue 列表信息质量的方式

我会先理解 issue 与 discussion 的定位差异：issue 用于可追踪的 bug 与功能请求，discussion 用于讨论、问答与想法交流。把讨论塞进 issue 会污染可追踪列表。推动时我会在 issue 里友善说明"这属于讨论性质，建议转到 discussion"，并提供链接引导，同时更新状态，给用户合理的去处。我会在 issue 模板和 README 中明确说明"什么该提 issue、什么该去 discussion"，从源头引导。对已存在的讨论型 issue，我会移动到 discussion 或关闭并注明原因，并保持 issue 列表只保留真正可追踪的事项。

区分 issue 与 discussion 是维护信息秩序的关键。用引导、模板、明确说明把"该讨论的"引流到正确渠道，让 issue 保持可追踪、可治理，体现对信息架构的把握。

• 对 issue 模板与自动标签治理价值的理解
• 设计模板字段与自动标签规则的能力
• 把澄清成本前置到提交环节的思路

我会把"issue 模板 + 自动标签"当作把"澄清成本从维护者身上前置到提交者身上"的机制。实现上：先设计结构化的 issue 模板，强制要求复现步骤、版本、期望与实际行为、环境等关键字段，让提交者提交时就补齐信息，减少维护者回头追问。再配合自动标签：基于模板字段是否完整、标题关键词、路径等规则，由 bot 自动打标签（如"待复现""bug""feature"），并自动标记信息不全的 issue 为"缺信息"并提醒提交者补充。这样维护者只需处理"已初步过滤"的 issue，把宝贵时间聚焦到真正的判断与修复，而不是反复澄清基础信息。

issue 模板与自动标签的核心是把"信息收集"从一次性的口头往返变成"提交时的结构化要求"。它减少维护者反复澄清的时间成本，同时提升 issue 列表的质量，是流程治理的典型实践。

• 对三种合并策略差异的理解
• 根据项目历史偏好选择合并策略的思维
• 把策略写入文档以约定共识的能力

我会先理解三种合并策略的差异：squash 把 PR 压缩成单个提交（历史干净、便于回滚）；rebase 保持线性历史（每个提交保留，适合精细追踪）；merge commit 保留完整分支历史（适合保留协作过程）。选择时我会根据项目的历史组织与团队偏好决定：若项目追求简洁线性历史，用 squash 或 rebase；若需要保留协作细节，用 merge commit。决定后我会在 CONTRIBUTING 中明确写清"本项目用哪种合并策略、为什么"，并说明对提交规范的要求（如 conventional commits），让贡献者遵守，减少"为什么我的 PR 被 squash 了"之类的争议。我会保持策略一致并定期评估是否需要调整。

合并策略没有绝对优劣，关键是"选择 + 约定一致"。把策略写进 CONTRIBUTING、说明理由，就能把个人的偏好纠纷变成透明的项目规范，减少争议。这体现版本管理决策与文档化的成熟度。

• 对僵尸 issue 成因的判断
• 区分"值得救"与"该关闭"的清理方式
• 用 stale 机制预防僵尸堆积

我会先判断僵尸 issue 的成因：是问题已解决未关闭、信息不足无法复现、还是已过时。对可救的（有价值但信息不全），我会联系提交者补充信息或确认是否仍存在；对已解决、已过时、无回应的，我会在说明原因后关闭（如"问题已解决""长期无法复现，需补充信息后可重开"）。为防止僵尸累积，我会用 stale bot 机制：长期无活动的 issue 自动打标记并提醒，超期后自动关闭，把清理变成自动化规则。我会公开清理标准，让提交者知道"什么样的 issue 会被判为僵尸、如何避免"。

僵尸 issue 清理要"能救则救、该关则关"，并用 stale 机制把清理自动化，避免人肉跟踪。这样既保留有价值的问题，又从机制上防止积压，是治理规范与温度的结合。

• 对"先讨论再实现"流程的理解
• 引导 issue 到 discussion 的协作方式
• 在讨论与实现间取得平衡

我会认可"先讨论再实现"能避免重要改动方向跑偏、防止实现后返工。推动时我会先把这类 issue 标记为"需讨论"，并把它相关的 RFC/讨论引导到 discussion 或邮件列表，说明背景、可选方案与权衡，邀请社区与维护者参与。我会在讨论中做收集与收敛，把社区意见整理成可实现的方向。若讨论仍未达成一致，我不会贸然实现，而是继续补充信息或等待共识；若讨论已清晰，我会在实现 PR 中关联讨论上下文，说明如何根据讨论收敛设计。我会跟提交者沟通"这个 issue 的价值在于先讨论"，避免其误以为被搁置。

"先 discuss 再实现"是防止重大改动跑偏的治理机制。关键是引导讨论、收敛共识、并把讨论与实现关联，让流程既尊重社区意见又不拖延。这体现流程治理与协作沟通能力。

• 对收集错误反馈必要性的理解
• 引导提交者提供有效错误信息的方式
• 把反馈闭环起来推动修复的思路

我会把"需要回报错误"理解为"修复需要足够信息"，这是合理的。很多 issue 看似 bug 但缺复现信息，无法定位。推动时我会在 issue 里明确列出需要的反馈信息（完整报错堆栈、版本、环境、复现步骤、预期与实际行为），并说明这些信息如何帮助定位，引导提交者补充。我会用模板或 checklist 让反馈更结构化，避免来回询问。拿到反馈后我会实际复现定位，确认问题后修复，并在 issue 中反馈进展与结果，让提交者看到"这个 bug 被闭环了"。对长时间不反馈的，我会按规则标记或关闭，但不打击积极反馈的贡献者。

收集错误反馈是"让每条 issue 可被定位修复"的前提。关键是用结构化引导降低反馈门槛、拿反馈后闭环修复，让提交者愿意配合。这体现问题定位与闭环管理的工程态度。

• 对 CI 门禁与人工评审分工的理解
• 设计 CI 门禁自动拦截机械性问题的能力
• 把评审精力聚焦到设计判断上的思路

我会把 CI 门禁当作"自动过滤机械性问题"的第一道关卡，让人工评审聚焦到真正需要判断的设计与权衡。具体上：lint 自动检查格式与基础规范，单元测试自动验证功能正确性，覆盖率门禁防止测试退化，这些都能在 CI 上自动执行并给结果。这样评审者不用逐行挑格式、重复跑测试，而是把注意力放到设计合理性、架构取舍、兼容性、边界情况、可维护性等需要判断的层面。我会在 CONTRIBUTING 中说明 CI 门禁覆盖什么、人工评审关注什么，让贡献者知道"先过 CI 再求评审"。同时我会把 CI 结果作为评审的输入，避免人肉重复 CI 已覆盖的检查。

CI 门禁与人工评审的分工是"机器做确定性检查、人做判断性评估"。把 lint/测试/覆盖率自动化，评审者就能聚焦设计判断，既提高效率又防止评审疲劳。这体现工程化与质量管理的成熟思路。

• 对安全漏洞处理流程的理解
• 设计私密上报与协调披露的机制
• 对安全与透明平衡的把握

我会为安全漏洞设计"私密上报 + 协调披露"的流程，避免在修复前公开。具体上：在项目内建立安全上报渠道（如 security.txt、专门的安全邮箱或 GitHub 的 private security advisory），让安全报告不进入公开 issue，避免被公开利用。接报后我会评估漏洞严重度与影响，确认后进入修复流程，并在修复完成前对漏洞细节保密。修复后按"协调披露"的方式发布：先发安全补丁，再在准备的窗口期（如 90 天）内公开披露，给用户和下游升级时间。我会在披露中说明漏洞详情、影响范围、修复版本与临时缓解措施。全过程让"修复优先于披露"，兼顾安全与社区的知情权。

安全漏洞处理的黄金准则是"先修复、后披露"。私密上报 + 协调披露能避免 0day 被公开利用，同时给用户升级缓冲。这体现对安全敬畏与对社区负责的双重成熟度。