Repo-level review policy file #77
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Reference
marvin8/wuming#77
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Project-specific review decisions currently live only in PR threads: intentional patterns, accepted trade-offs, severity expectations, style conventions. Every fresh review re-raises them.
Evidence from #75's five review waves: the debug-logging security findings were re-raised although the behaviour is documented in the README as an intentional feature; the mixed-backend
agentsexample was flagged three separate times; the HTTPS-for-local-servers guidance kept generating findings.WuMing needs a way for a repo to declare its review policy once, so reviewers start from settled ground instead of rediscovering it. Shape (e.g.
.wuming.ymlvs a markdown section) is open for discussion at implementation time.