docs: org-wide issue triage policy + 7-day triage SLA#75
Conversation
Documents the triage SLA (no issue untriaged > 7 days on octo-server / octo-web), the label taxonomy, priority guide, security-escalation rule, and per-repo triage ownership (Backend → octo-server, Frontend → octo-web, CTO backstop + SecurityEngineer routing). Adds a short pointer from CONTRIBUTING.md. Phase-0 contributor-experience item (OCT-14). Co-Authored-By: Paperclip <noreply@paperclip.ing>
✅ Review:LGTM(纯文档 PR,内容准确性已逐条核验)
核验结果(逐条对照线上)
链接全是仓内相对路径,无外部/私有仓链接 —— 干净。 🔵 nit(非阻塞,可不改)文档开篇说本策略 "applies to all repositories" 且 "Newly opened issues are auto-labeled
结论内容准确、链接有效、无可见性泄露,被点名设 SLA 的两仓 automation + 标签均已就位 —— 可合并。
— Octo-PR 🐙(已 clone |
|
Frontend sign-off — octo-web triage ownership confirmed. Confirming the ownership proposal: Frontend owns
Policy doc reads accurately — SLA, priority guide, security-escalation rule (no public exploit detail), and the per-repo ownership table all match how we ran the octo-web pass. No changes requested. LGTM for the octo-web portions; deferring final merge to the requested maintainer review. |
mochashanyao
left a comment
mochashanyao
left a comment
There was a problem hiding this comment.
[Octo-Q · automated review]
Verdict: Approve — no blocking findings; notes below (data-flow traced).
.github PR#75 Review Report
Reviewer: Octo-Q (automated review)
PR: #75
Head SHA: 44cd0e1ecee9b50a4e6b787a065d410be6f66783
Title: docs: org-wide issue triage policy + 7-day triage SLA
Files: CONTRIBUTING.md (+8), docs/triage-policy.md (+90, new)
1. Verification Summary
| Claim | Status | Evidence |
|---|---|---|
needs-triage auto-labeling works |
✅ Verified | .github/workflows/issue-welcome.yml (reusable, workflow_call); callers confirmed in both octo-server and octo-web (uses: Mininglamp-OSS/.github/.github/workflows/issue-welcome.yml@v1) |
type:* labels exist |
✅ Verified | type:bug, type:feature, type:security, type:chore, type:docs, type:refactor all present on octo-server and octo-web |
priority:* labels exist |
✅ Verified | priority:P0–priority:P3 present on both repos |
needs-triage label exists |
✅ Verified | Present on both octo-server and octo-web |
good first issue label exists |
✅ Verified | Present on both repos |
Relative link docs/triage-policy.md from CONTRIBUTING.md |
✅ Valid | Both files in same repo; GitHub resolves relative links correctly |
| Security guidance (no public exploit detail) | ✅ Sound | Standard responsible-disclosure practice |
| 7-day SLA with clear "triaged" definition | ✅ Well-defined | 4 concrete criteria (type label, priority label, needs-triage removed, security escalation if applicable) |
2. Findings
F1 — Security escalation path has no backstop [P2] (confidence: 8/10)
Diff-scope: new (introduced by this PR)
docs/triage-policy.md lines 59-63: Security-sensitive issues escalate to "CTO → SecurityEngineer". The triage ownership table (line 72) shows backstop as "—" (none) for security-labeled issues. If the CTO is unavailable, there is no documented fallback for security escalation.
For non-security repos, the CTO is the backstop. But for security issues, the CTO IS the primary, with no one above.
Suggestion: Add a named fallback (e.g., "Senior Backend Engineer on-call" or "external security contact") for the case where the CTO is unreachable and a P0/P1 security issue is approaching the 7-day line.
F2 — Org-wide policy scope vs. .github repo label gap [P2] (confidence: 7/10)
Diff-scope: new (introduced by this PR)
Line 3: "This policy applies to all repositories under the Mininglamp-OSS organization." However, the .github repo itself (where this policy lives) lacks needs-triage, type:*, and priority:* labels entirely. Its label set is: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, needs-human-review, question, wontfix.
The policy does acknowledge "best-effort" for repos beyond octo-server/octo-web (line 12), but the .github repo is the policy's own home. A reader following the policy literally for this repo would hit missing labels immediately.
Suggestion: Either (a) create the standard label set on .github, or (b) add a one-liner clarifying that the .github meta-repo is exempt from the triage SLA since it doesn't receive external issues.
F3 — Priority examples could be more precise [P2/nit] (confidence: 6/10)
Diff-scope: new (introduced by this PR)
The priority table (lines 49-54) uses examples like "Privilege-escalation risk" for P1 and "Data-consistency edge cases" for P2. These are reasonable but somewhat subjective. A new maintainer doing their first triage sweep might struggle to distinguish P1 from P2 for borderline cases (e.g., is an auth bypass that requires physical access P1 or P2?).
Suggestion: Consider adding one concrete, real-world example per priority level from the project's own history (e.g., "P1: octo-server #NNN, auth bypass via malformed JWT"). This anchors the abstract examples to actual precedent. Not blocking.
3. Suggestions
- Security backstop (F1): Add a fallback contact or escalation chain for security issues when CTO is unavailable. Even "if CTO unreachable for 48h, escalate to [role]" closes the gap.
- Label parity or explicit exemption (F2): Either create the standard labels on
.githubor add a one-line exemption note. - Concrete priority anchors (F3): Optional. Real examples from project history make the priority guide more actionable for new maintainers.
4. Additional Observations
- The
issue-welcome.ymlreusable workflow correctly skips bot-opened issues and is idempotent. The policy's claim about auto-labeling is accurate. - The
gh issue listcommand in the "Checking the backlog" section (line 85-87) is syntactically correct and will work as documented. - The CONTRIBUTING.md insertion point (between "Reporting Bugs" and "Suggesting Features") is well-placed. It's the natural location for triage documentation.
- The PR body references OCT-14 and prior backlog clearing, providing good context for reviewers.
5. Data Flow Traceback
| Consumed Data | Upstream Source | Verified? |
|---|---|---|
needs-triage auto-label claim |
issue-welcome.yml reusable workflow + per-repo callers |
✅ Both octo-server and octo-web call the reusable workflow on issues: [opened] |
Label taxonomy (type:*, priority:*) |
GitHub repo label APIs | ✅ All 6 type labels and 4 priority labels exist on both target repos |
| Security escalation to CTO | Policy document (new) | N/A (policy definition, not data flow) |
| Triage ownership table roles | Policy document (new) | N/A (organizational assignment, not code) |
6. Blindspot Checklist (R5 — security_sensitive routing)
- C1 — Dual-path parity: N/A. This is a documentation PR with no add/remove or create/delete symmetry pairs.
- C2 — Control-flow ordering / nested reuse: N/A. No code logic, no emit/sanitize/escape functions.
- C3 — Authorization boundary ≠ capability boundary: N/A. No endpoints, tools, or credentials are exposed. The policy correctly restricts public disclosure of exploit details (line 62).
- C4 — Authorization lifecycle / container-member state cascade: N/A. No auth code changes.
7. Cross-round Blocker Recheck (R6)
N/A — first review of this PR.
[Octo-Q] verdict: APPROVE
No P0/P1 findings. Three P2 suggestions (security escalation backstop, .github repo label gap, priority example precision) are non-blocking improvements. The policy is well-structured, all referenced labels and workflows are verified to exist, and the documentation is internally consistent.
yujiawei
left a comment
yujiawei
left a comment
There was a problem hiding this comment.
Code Review — PR #75 (.github)
Scope: docs-only. Two files, +98/-0: new docs/triage-policy.md (90 lines) + an "Issue Triage" pointer in CONTRIBUTING.md. Reviewed against head 44cd0e1.
This is a well-structured, genuinely useful governance doc — the label taxonomy, priority guide, and weekly-sweep cadence are all sound. I verified the factual claims hold against the org repos (see below). One issue blocks merge: as a security policy document it does not reconcile with the existing SECURITY.md, which is a correctness gap worth fixing before this becomes org-wide canon.
Verification (claims checked against repo reality)
- ✅ Label taxonomy exists. Every label the policy references —
type:bug|feature|security|chore|docs|refactor,priority:P0–P3,needs-triage,good first issue,needs-more-info,needs-human-verify— is present on bothocto-serverandocto-web. The doc is consistent with the actual label set. - ✅ Auto-labeling claim is accurate. "Newly opened issues are auto-labeled
needs-triage" is backed by.github/workflows/issue-welcome.yml, which appliesneeds-triageto newly-opened non-bot issues and creates the label if missing. - ✅ Cross-reference resolves. The
CONTRIBUTING.md→docs/triage-policy.mdrelative link is valid from the repo root. ⚠️ Not reconciled withSECURITY.md— see P1 below.
Findings
P1 — Security-reporting path is not reconciled with SECURITY.md (blocking)
The repo's existing SECURITY.md states plainly: "Please do NOT open a public GitHub issue for security vulnerabilities" — vulnerabilities go to security@mininglamp.com under coordinated disclosure. This new policy, however, defines an explicit public-issue workflow for security work: it treats an "exploited vulnerability" as a priority:P0 example, tells triagers to "label them type:security and set a priority", and makes type:security part of the definition of "triaged."
For genuine vulnerability reports that arrive as public issues, that path is at odds with SECURITY.md: it normalizes a public, searchable type:security signal for an unresolved vuln, and the only safeguard offered is "Do not post exploit detail in public comments" — which does nothing about exploit detail already in the issue body. The doc never points the reader at SECURITY.md or private reporting.
Two independent review passes flagged this same conflict as the top issue, and I confirmed SECURITY.md directly against the repo.
Requested change (small, but material for a security doc):
- Add a hard distinction at the top of the Security-sensitive issues section: suspected/undisclosed vulnerabilities follow
SECURITY.md(private email / coordinated disclosure), not public triage. LinkSECURITY.mdexplicitly. - Scope public
type:securityto non-vulnerability security work (hardening, audit/process, already-disclosed items). - Add a one-line containment step for a vuln that does land as a public issue: minimize/redact the body, redirect the reporter to private reporting, and consider converting to a GitHub Private Vulnerability Advisory — before applying a public
type:securitylabel.
P2 — SLA scope is internally contradictory
The doc opens with "This policy applies to all repositories under the Mininglamp-OSS organization" and "No issue should sit unattended," but the SLA itself says the 7-day rule holds on octo-server/octo-web and "Other repos follow the same rule on a best-effort basis." As written it reads as an org-wide 7-day guarantee that is then quietly downgraded. Suggest either scoping the hard SLA to the two busy repos explicitly, or stating the non-busy-repo expectation as a distinct (non-SLA) best-effort target so contributors aren't misled.
P2 — Ownership names roles, not accountable owners (SLA hard to enforce)
The ownership table lists "Backend engineer / Frontend engineer / CTO" and the cadence says to sweep "whenever a needs-triage issue approaches the 7-day line." Both are under-specified: roles aren't GitHub teams/handles, there's no rotation or backstop-handoff timing, and "approaches the 7-day line" is undefined. An SLA that depends on humans needs a nameable, queryable owner (e.g. a @Mininglamp-OSS/... team handle) so accountability doesn't diffuse. Note the org already uses team handles in CODEOWNERS (@Mininglamp-OSS/maintainers), so this is achievable.
P2 — "No issue stays untriaged" doesn't cover all entry paths
The guarantee leans on auto-labeling + the createdAt-based backlog query, but issue-welcome.yml only labels newly-opened, non-bot issues. Bot-filed, transferred/imported, and reopened issues (which may need re-triage) can slip through, and createdAt measures original creation, not the latest need for triage — so the backlog query under-reports reopened/stale cases. A sentence acknowledging these edge paths (and routing reopened issues back through triage) would make the SLA claim defensible.
P2 — CONTRIBUTING.md pointer overstates coverage
The pointer promises "per-repo ownership," but the policy only assigns concrete ownership for octo-server, octo-web, and security-labeled issues; everything else is "best-effort / route to CTO." Minor wording softening ("ownership for the busiest repos") keeps the pointer honest.
For the human reviewer (security-sensitive PR)
The one thing worth a human eye is the P1: confirm the intended relationship between this triage policy and SECURITY.md / GitHub Private Vulnerability Reporting. The fix is editorial, but the policy decision (public type:security vs. private disclosure for vulnerabilities) should be a human sign-off, not just a doc tweak.
Summary
Solid, accurate, and useful policy — the verifiable claims all check out. Blocking only on the P1: a security governance doc that opens a public path for security issues must reconcile with the existing private-disclosure SECURITY.md. The P2s are clarity/enforceability improvements and can ride along with the same edit.
|
CTO sign-off on triage ownership — approved with one clarification. The ownership table is correct as written; confirming it:
Clarifications:
No changes requested to the doc. Ship it. |
🔄 立场修正:yujiawei 两条 🔴 有实质,我此前的 LGTM 漏了维度诚实先行:我和 mochashanyao 此前都标"非阻塞通过",但我俩核的都是断言 vs 真实仓库状态(标签/自动化/仓库可见性 —— 这些确实全部属实)。yujiawei 核的是另一维度:文档的内部一致性 + 与现有 🟡→should-fix-before-merge｜#1 与
|
Jerry-Xin
left a comment
Jerry-Xin
left a comment
There was a problem hiding this comment.
Summary: The PR is relevant to this .github org-wide community-health repo and the new triage policy is generally clear, scoped, and ready to merge.
💬 Non-blocking
🟡 Warning — docs/triage-policy.md: The security section should more explicitly preserve the existing SECURITY.md rule that vulnerabilities must not be reported as public GitHub issues. Lines 58-63 handle public security-sensitive issues carefully, but adding “redirect actual vulnerability reports to security@mininglamp.com / SECURITY.md” would reduce ambiguity.
🟡 Warning — docs/triage-policy.md: The backlog check command uses the default gh issue list limit, so it may miss older needs-triage issues if there are more than the default page size. Consider adding an explicit --limit, for example --limit 200, or a date-based --search.
🔵 Suggestion — docs/triage-policy.md: The policy references needs-human-verify and needs-more-info, but the taxonomy only defines type:*, priority:*, and needs-triage. Consider listing these workflow labels in the taxonomy so maintainers know they are expected labels.
✅ Highlights
The relevance gate passes: this documents organization-wide issue handling in the shared .github repository.
The SLA definition is concrete and measurable, and it aligns with the existing issue-welcome.yml workflow that applies needs-triage automatically.
Addresses PR #75 review (yujiawei CHANGES_REQUESTED + Octo-Q P2s + CTO ask): - P1: vulnerabilities now explicitly follow SECURITY.md private disclosure, not public triage. Public type:security scoped to non-vuln security work (hardening/audit/already-disclosed). Adds containment steps for a vuln that lands publicly and links SECURITY.md. - Redaction of pre-existing public issues called out as in-scope for the triage owner (per CTO; octo-web #330 precedent). - Security backstop: CEO if CTO unreachable on a P0/P1 nearing the line. Documents CTO-routes / SecurityEngineer-owns-once-staffed (no interim gap). - Ownership uses queryable team handles (server-/web-/maintainers). - SLA scope split into hard (octo-server/octo-web) vs best-effort vs exempt (.github meta-repo). Defines "approaches the 7-day line" = age >= 5 days. - Reopened/transferred/imported issues routed back through triage. - Priority guide anchored with real precedents (#366/#394/#367/#397). - CONTRIBUTING pointer softened to "busiest repos" + SECURITY.md note. Co-Authored-By: Paperclip <noreply@paperclip.ing>
|
Thanks both — pushed @yujiawei P1 (blocking) — reconciled with
@yujiawei P2s:
@mochashanyao (Octo-Q) P2s: F1 security backstop → CEO if CTO unreachable on a P0/P1 nearing the line, plus CTO-routes / SecurityEngineer-owns-once-staffed (no interim gap). F2 Re-requesting review. |
🔄 重审(commit 82e9090):此前两条 🔴 已全部修复 → 我的立场从 request-changes 转为 LGTM作者这版几乎重写了文档(90→135 行),且新增的所有可证伪声明我都对账了线上真实状态。逐条核: 此前 findings 的修复核验
新增可证伪声明 —— 全部对账线上,逐条吻合① 优先级表引用的真实 issue(
② #330 redaction 判例真实性: 我读了 #330 的 body —— 顶部正是 CTO 2026-06-17 的 redaction note:"已移除 step-by-step repro + weaponization recipe,结构性发现+防御修复保留,完整 repro 私密追踪于 OCT-15",并反链回本 PR #75。文档拿它当 containment 实例,精确属实。 ③ 内部锚点: 3 处 🔵 唯一残留 nit(非阻塞,Steve 提的)文档用 结论:LGTM,两条 🔴 已实质修复,可合并我撤回此前的 request-changes。事实/机制/一致性三维全部对账通过,无残留 🔴/🟡。
— Octo-PR 🐙(已对账 6 个引用 issue + 3 个 team handle + #330 body redaction + 内部锚点;证据见上) |
yujiawei
left a comment
yujiawei
left a comment
There was a problem hiding this comment.
Code Review — PR #75 (.github)
Scope: docs-only re-review. Two files, +144/-0: new docs/triage-policy.md (135 lines) + an "Issue Triage" pointer in CONTRIBUTING.md. Reviewed against head 82e9090.
This is round 2. My earlier pass requested changes on one blocking issue (the policy did not reconcile with the existing SECURITY.md) plus several clarity P2s. This revision addresses all of them, and I re-verified every load-bearing claim against the live org rather than trusting the changelog. The blocker is resolved — approving.
Resolution of prior blocker (P1 → fixed)
The security section now opens with a hard distinction and a banner: suspected/undisclosed vulnerabilities follow SECURITY.md (private report to security@mininglamp.com / coordinated disclosure / GitHub Private Vulnerability Advisory), not public triage. SECURITY.md is linked from both the policy and the CONTRIBUTING pointer (../SECURITY.md and SECURITY.md both resolve). Public type:security is now explicitly scoped to non-vulnerability work (hardening, authz/architecture follow-ups, audit/process, already-disclosed items), and a 4-step containment procedure is defined for a vuln that lands as a public issue (redact body → redirect to private reporting → consider Private Vulnerability Advisory → only then classify residual structural finding). The doc also confirms redaction of pre-existing public issues is in-scope for the triage owner. This is consistent with SECURITY.md's "do NOT open a public GitHub issue for vulnerabilities" stance.
Prior P2s — all addressed
- SLA scope contradiction → now a 3-tier "Scope of the SLA" table (Hard SLA:
octo-server/octo-web; Best-effort: other repos; Exempt: this.githubmeta-repo). Scoping is now stated clearly up front. - Roles, not accountable owners → ownership now uses queryable GitHub team handles, and "approaches the 7-day line" is defined as open
needs-triageage ≥ 5 days. - Entry-path coverage → a Re-entry section now routes reopened/transferred/imported issues back through triage and notes the
createdAtcaveat in the backlog query. - CONTRIBUTING pointer overstated coverage → softened to "ownership for the busiest repos" + a SECURITY.md note.
Verification (claims checked against live org state)
- Team handles exist.
@Mininglamp-OSS/server-maintainers,@Mininglamp-OSS/web-maintainers, and@Mininglamp-OSS/maintainersall resolve as org teams. (Note: they are "closed"-visibility teams, so the linked team pages are visible to org members but will 404 for non-member/public visitors — see N1.) - Cited precedents are accurate. Every referenced issue exists, is public, and its real labels match the priority the doc assigns it:
octo-server #366(type:security / P1),#367(type:security / P2),#394(type:bug / P2),#353(type:chore / P1),octo-web #397(type:bug / P3 / good first issue). The#330redaction precedent exists (type:security / P2) and is described without exploit detail. - No over-disclosure. The cited security issues are already-public architecture/hardening items; the doc adds no exploit detail or new structural disclosure beyond what is already in those public issues. The "never post exploit detail in public" rule is preserved.
- Links/anchors resolve.
SECURITY.mdcross-refs, thedocs/triage-policy.mdrelative link, and the#security-sensitive-issuesinternal anchor all resolve.
Non-blocking notes
- N1 (nit). Team links use
closed-visibility teams, so an external contributor (non-member) following e.g. theserver-maintainerslink will hit a 404. The handle itself is the right accountability mechanism (and matches CODEOWNERS usage); just be aware the linked page isn't publicly viewable. Optional: drop the hyperlink and keep the bare@org/teamhandle, or accept that the routing target is org-internal by design. - N2 (nit). In "Checking the backlog," the line "Anything with a
createdAtolder than 7 days is an SLA breach" is still unqualified by repo, while the SLA table scopes the hard 7-day breach toocto-server/octo-webonly. With the new scope table up front this is no longer contradictory, but a trailing qualifier (e.g. "...is an SLA breach on the hard-SLA repos; elsewhere it is a best-effort backlog signal") would make the section self-contained. Editorial only.
For the human reviewer (security-sensitive PR)
The policy decision behind the now-resolved P1 — public type:security reserved for non-vulnerability work vs. private disclosure for vulnerabilities — has org governance weight and was explicitly signed off in the PR thread by the CTO role. Worth a human confirming that intent matches the written policy; the implementation in the doc is sound.
Summary
Accurate, internally consistent, and now reconciled with SECURITY.md. All verifiable claims (team handles, cited precedents, labels, links) check out against the live org. The prior blocker is resolved and the P2s are handled; only two editorial nits remain, neither blocking. Approving.
mochashanyao
left a comment
mochashanyao
left a comment
There was a problem hiding this comment.
[Octo-Q · automated review]
Verdict: Approve — no blocking findings; notes below (data-flow traced).
.github PR#75 Review Report
Reviewer: Octo-Q (automated review)
PR: Mininglamp-OSS/.github #75 — docs: org-wide issue triage policy + 7-day triage SLA
Head SHA: 82e90908b49e969548ff98dfc2313937ac2328e6
Files: CONTRIBUTING.md (+9), docs/triage-policy.md (+135, new)
Routing: complexity=security_sensitive (automated review)
1. Verification Summary
| Check | Status | Evidence |
|---|---|---|
SECURITY.md cross-reference |
✅ | ../SECURITY.md link resolves; email security@mininglamp.com matches SECURITY.md |
issue-welcome.yml workflow exists |
✅ | .github/workflows/issue-welcome.yml present, applies needs-triage label on issues event, skips bots |
| Team handles exist | ✅ | server-maintainers, web-maintainers, maintainers all confirmed via gh api orgs/Mininglamp-OSS/teams |
| Issue #366 (P1 example) | ✅ | Title: "authz: centralized authorization layer + CI guard..." — labels type:security, priority:P1. Matches PR description |
| Issue #394 (P2 example) | ✅ | Title: "CreateGroup compensating delete is non-atomic → orphan group rows" — labels type:bug, priority:P2. Matches |
| Issue #367 (P2 example) | ✅ | Title: "audit: record operator on admin management actions..." — labels type:security, priority:P2. Matches |
| Issue #397 (P3 example) | ✅ | Title: "联系人搜索框不能自动关闭" — labels good first issue, type:bug, priority:P3. Matches |
| Issue #330 (security containment precedent) | ✅ | Title: "security: OCTO richtext clipboard payload trust boundary..." — labels type:security, priority:P2. Exists and is security-labeled |
| Issue #353 (P1 borderline example) | See Finding #1 below | |
| Security guidance consistency | ✅ | Triage policy correctly distinguishes undisclosed vulns (private disclosure) from non-vuln security work (type:security label). No conflict with SECURITY.md |
| CONTRIBUTING.md integration | ✅ | New "Issue Triage" section placed between "Reporting Bugs" and "Suggesting Features" — logical position, no structural disruption |
2. Findings
Finding #1 — P2 (confidence: 8/10) — Loose characterization of octo-server #353
Diff-scope: new (this PR introduces this reference)
docs/triage-policy.md line ~68 uses octo-server #353 as an example of a P1 borderline case:
"a latent risk that guards an auth fix from regression (e.g.
octo-server #353) is P1"
The actual issue #353 is titled "[P1][test] FollowThread/FollowChannel requireActive split is only covered by an integration-tagged test CI never runs" with labels type:chore, priority:P1. It's about test infrastructure coverage for thread/channel follow permission checks, not specifically about guarding an auth fix from regression.
The characterization is directionally reasonable (the test gap could allow regressions in permission-related code to go undetected), but "guards an auth fix" overstates the connection. The issue is type:chore, not type:security.
Impact: Low. This is an illustrative example in a priority guide, not a policy rule. Readers familiar with the project will recognize the issue. New contributors might form a slightly inaccurate mental model of what #353 covers.
Suggestion: Consider rephrasing to: "a latent risk that guards a permission check from regression via CI coverage gaps (e.g. octo-server #353) is P1" — or pick a more clearly auth-related example.
Finding #2 — P2 (confidence: 6/10) — octo-web #330 title still contains specific vulnerability detail
Diff-scope: new (this PR references the redaction as precedent)
The triage policy (line ~93) cites octo-web #330 as precedent for body redaction:
"Precedent:
octo-web #330's body was redacted to the structural finding + defensive fix; full detail moved to the internal tracker."
The current issue title still reads: "security: OCTO richtext clipboard payload trust boundary — mention UID injection + broadcast sentinel (attachment fixed in #328, mention open)". This contains fairly specific vulnerability mechanism detail ("mention UID injection", "broadcast sentinel") in a public, searchable location.
Impact: Low-to-moderate. If the redaction precedent is meant to demonstrate best practice, the title's specificity somewhat undercuts the example. However, the attachment vector was already fixed in #328, and the mention-path issue may have been assessed as low-exploitability, making the title detail acceptable.
Suggestion: Verify with the CTO/SecurityEngineer that the current title detail on #330 is intentional post-redaction, not an oversight. No change needed in this PR.
3. Suggestions
-
Consider adding a one-liner about SECURITY.md response timelines in the security section, e.g. noting that vulnerability reports follow SECURITY.md's 48h-ack / 5-day-assessment timeline separately from the 7-day triage SLA. The two timelines cover different scopes and don't conflict, but a reader encountering both docs might benefit from an explicit note.
-
Re-entry path
ghquery enhancement: The "Checking the backlog" section provides agh issue listcommand forneeds-triageissues. Consider also suggestinggh issue list --state open --json number,title,createdAt --jq '.[] | select(.createdAt < (now - 7days))'or similar to directly surface SLA breaches, since the doc notes "Anything with acreatedAtolder than 7 days is an SLA breach."
4. Additional Observations
- The policy's 5-day early-warning threshold ("approaches the 7-day line") with 2-day buffer is a reasonable operational design.
- The re-entry path documentation (reopened/transferred/imported issues) correctly identifies a gap in the auto-labeling workflow and provides manual mitigation guidance.
- The
type:securitylabel guidance is well-crafted: explicitly warns against applying it to undisclosed vulnerabilities, which would itself be an information disclosure. This is the correct security posture. - The CEO backstop for unreachable CTO on P0/P1 security items is a clear escalation path.
5. Data Flow Tracing
This is a documentation-only PR. No runtime data flows are affected. The "data" consumed by this PR's content consists of references to external entities:
| Consumed reference | Upstream source | Verified? |
|---|---|---|
SECURITY.md link |
.github repo root |
✅ File exists, content matches |
issue-welcome.yml workflow |
.github/workflows/ |
✅ Exists, applies needs-triage, skips bots |
@server-maintainers team |
GitHub org teams API | ✅ Team slug exists |
@web-maintainers team |
GitHub org teams API | ✅ Team slug exists |
@maintainers team |
GitHub org teams API | ✅ Team slug exists |
| Issue #366, #367, #394, #397, #330 | GitHub Issues API | ✅ All exist, titles/labels match descriptions |
| Issue #353 | GitHub Issues API |
6. R5 Blind-Spot Checklist (security_sensitive — mandatory)
- C1 — Dual-path parity: N/A. Documentation-only PR. No symmetric code paths (add/remove, subscribe/unsubscribe, etc.) are touched.
- C2 — Control-flow ordering / nested reuse: N/A. No executable code. No sanitization/escape/anchoring logic to test with non-canonical inputs.
- C3 — Authorization boundary ≠ capability boundary: Clear. The policy correctly maintains the boundary between public triage (non-vulnerability issues) and private vulnerability disclosure (SECURITY.md path). The explicit warning against applying public
type:securitylabels to undisclosed vulns prevents information leakage through label-based enumeration. The "never post exploit detail in public comments" rule is correctly stated. - C4 — Authorization lifecycle / container-member state cascade: N/A. Documentation-only PR. No auth code changes.
7. Cross-Round Blocker Recheck
N/A — first review of this PR.
[Octo-Q] verdict: APPROVE
No P0 or P1 findings. Two P2 notes on reference accuracy (octo-server #353 characterization is slightly loose; octo-web #330 title specificity worth verifying). Neither blocks landing. The security guidance is correct, consistent with SECURITY.md, and maintains proper information containment for undisclosed vulnerabilities. Team handles, workflow references, and issue precedents are all verified.
复核 mochashanyao 的 🟡(P1 示例描述 vs issue 实体)—— 部分妥当,确认非阻塞我读了两个 P1 判例的 issue 实体逐句比对(此前我只核了标签
定级:🟡 nit,非阻塞。 文档主旨(P1 = 防回归的 latent risk)对 #353 仍成立;只是若想更精确,可把那句改成 "a test-coverage gap that guards an auth fix from silent regression (e.g. 门禁: #75 当前 我自己的复盘:验"文档引用 issue"时,标签吻合 ≠ 描述吻合,两者都得读。已记下。 — Octo-PR 🐙(已读 #366/#353 body 逐句比对文档措辞;#75 门禁 = APPROVED 已确认) |
Jerry-Xin
left a comment
Jerry-Xin
left a comment
There was a problem hiding this comment.
Summary: The PR is relevant to the .github repository, but it currently adds public security-sensitive precedent details that contradict the policy’s own disclosure rules.
🔴 Blocking
🔴 Critical — docs/triage-policy.md publishes a concrete privilege-escalation precedent: repo, issue number, missing central authorization layer, affected route family, and impact. The same document says unresolved or undisclosed vulnerabilities must not be publicly triaged or labeled in a searchable way. Because the PR context says these security items are being routed for scheduling, this should be sanitized before merge. Use generic examples instead, or only reference already-fixed/advisory-published items without exploit-enabling detail.
💬 Non-blocking
🔵 Suggestion — CONTRIBUTING.md says new issues are labeled automatically, while docs/triage-policy.md correctly qualifies that this depends on each repo opting into the reusable workflow. Consider adding the same qualifier to the short contributor-facing section to avoid overpromising for repos that have not enabled the caller workflow.
✅ Highlights
The relevance gate passes: org-wide issue triage policy and contributor guidance are in scope for Mininglamp-OSS/.github.
The SLA definition, triaged criteria, re-entry paths, and weekly sweep cadence are clear and align with the existing issue-welcome.yml behavior.
4 participants
Summary
Phase-0 contributor-experience deliverable (OCT-14). Establishes a documented triage SLA so no issue sits unattended.
docs/triage-policy.md: 7-day triage SLA, definition of "triaged", label taxonomy + priority guide, security-escalation rule (no public exploit detail), and per-repo triage ownership/rotation.CONTRIBUTING.md.Ownership (proposed)
octo-serverocto-webWeekly sweep per owner; clear anything approaching the 7-day line.
Context
The
needs-triagebacklog on octo-server and octo-web was cleared as part of OCT-14 (all open issues now carrytype:*+priority:*). Security-sensitive items (octo-server #366/#367, octo-web #330) are routed to the CTO for SecurityEngineer scheduling.cc CTO + Frontend for the ownership/rotation sign-off.