docs(policy): contributor relationships and recourse, with the mechanism behind each claim - #9981
Conversation
…ism behind each claim
Two things that should be written down before anyone needs them -- how
contributor relationships are handled, and what recourse exists when a
contributor believes a verdict was wrong -- existed only in practice and
scattered discussion. This is the page to point at.
Every claim names what enforces it, because a policy whose enforcement cannot be
checked is a promise, and this project's whole posture is to publish fewer
promises and more mechanisms. Each mechanism was read before being cited:
uniform pipeline the gate's inputs contain no author identity field; where
identity IS read it comes from the repo's own GitHub
permissions at event time, never a maintained list --
priority-label-eligibility.ts, author-association.ts
label eligibility priority-label-eligibility.ts (#9737) and
priority-eligibility-window.ts (#9738), both already
documented in full on the label-policy page
immutability REEVALUATION_REASONS' closed set in decision-record.ts
(#9742), and why closed: so re-evaluations can be COUNTED
by cause without interpreting free text
parity review-parity-rollups.ts (#9743), published under
reviewParity at /v1/public/stats and recomputable from a
ledger export
reversal detection recordReversalSignals in outcomes-wire.ts, published on
/fairness
The recourse section is deliberately not an appeals process, and says so. It
documents what exists: offline verification first (it does not depend on anyone
agreeing with you), automatic detection of wrong closes via outcome confirmation
(stronger than an appeals queue -- it measures the mistakes that happened, not
the ones somebody contested), and resubmission, which is not a workaround but a
property of the ledger key: a record is `record:<repo>#<pr>@<head sha>`, so a
new head SHA is a fresh verdict by definition.
It also states plainly why no human appeals queue exists -- timing, since open
issues are typically re-solved before an appeal could conclude; and selection,
since re-running only contested verdicts makes the published accuracy figure
describe complaint volume rather than behaviour.
Disclosure is called out as the one item a mechanism does NOT enforce, rather
than being blended in with the ones that are. The rules above mean it needs no
elevated trust anyway: priority eligibility is decided by issue authorship read
from GitHub, and the window applies to every PR regardless of author.
Linked from the label-policy page and CONTRIBUTING, per the issue's placement
requirement, and registered in the docs sidebar (which docs-nav.test.tsx
enforces for every published page).
Closes #9746
|
Tip ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-31 01:10:19 UTC
Review summary Nits — 8 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
loopover-ui | 4a66bb4 | Commit Preview URL Branch Preview URL |
Jul 31 2026, 01:05 AM |
Bundle ReportChanges will increase total bundle size by 29.3kB (0.37%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|


One page an outsider can be pointed to, covering both halves of the issue: the contributor-relationship (conflict-of-interest) policy, and recourse.
Every claim names its mechanism
That was the acceptance bar, and it is the part that took the time — each mechanism was read before being cited, not recalled:
priority-label-eligibility.ts,author-association.ts— never a maintained list of people.src/review/priority-label-eligibility.ts(#9737)src/review/priority-eligibility-window.ts(#9738)REEVALUATION_REASONS' closed set,src/review/decision-record.ts(#9742)src/review/review-parity-rollups.ts(#9743), served underreviewParityat/v1/public/statsrecordReversalSignals,src/review/outcomes-wire.ts, published on/fairnessI verified the specifics rather than paraphrasing: the five
REEVALUATION_REASONSvalues, the record id shaperecord:<owner/repo>#<pr>@<head sha>, and thatreviewParityreally does publishreevaluationsandbyReason.Two things the page argues rather than asserts
Why immutability makes the recourse section honest. The set of re-evaluation causes is closed so that an outsider can count re-evaluations by cause without interpreting free text. That is also why on-demand re-evaluation cannot exist: re-running only the contested verdicts makes the published accuracy figure describe complaint volume instead of behaviour.
Why automatic detection beats an appeals queue. An appeals queue measures the mistakes somebody bothered to contest. Outcome confirmation measures the ones that actually happened — including the ones nobody complained about — and publishes the rate either way. Reopening a wrongly-closed PR is the signal; nothing needs filing.
Recourse, documented honestly
Per the issue's framing, this is a description of what exists, not an appeals process:
Disclosure is called out as the exception
Disclosure is a process commitment, and the page says so explicitly rather than blending it in with the mechanical guarantees — it is the one item no mechanism enforces. It also notes why that matters less than it sounds: priority eligibility is decided by issue authorship read from GitHub, and the window applies to every PR regardless of author, so an undisclosed relationship still buys no elevated label eligibility.
Placement
Linked from the label policy page and from
CONTRIBUTING.md, as the issue requires, and registered in the docs sidebar —docs-nav.test.tsxenforces a sidebar entry for every published.mdx, so an unregistered page fails CI.Verification
docs:drift-check,ui:typecheck,ui:lint,typecheck,branding-drift:checkgreenui:testgreen, includingdocs-nav.test.tsx(4 tests)Closes #9746