[Feature]: vouch:unvouched has no documented path to vouch:trusted

[eddieajau]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Docs

Problem or use case

Every external PR is automatically labelled vouch:unvouched. CONTRIBUTING.md states contributors remain unvouched "until we explicitly add you to .github/VOUCHED.md" but provides no criteria, process, or signal for how that happens. The admission path is undocumented.

Proposed solution

Add a single paragraph to CONTRIBUTING.md stating what behaviour, track record, or criteria result in being added to VOUCHED.md.

Why this matters

Without a documented path, vouch functions as an opaque gate rather than a trust-building system. Contributors who follow every stated guideline correctly have no way to know if or how they can earn review. This suppresses exactly the high-quality contributors the project wants.

Smallest useful scope

Three to five sentences in CONTRIBUTING.md. No code changes required.

Alternatives considered

None.

Risks or tradeoffs

Publishing explicit vouching criteria creates a game to optimise against. Contributors may target the criteria mechanically rather than demonstrating genuine sustained quality. The current ambiguity, while frustrating for good-faith contributors, does give maintainers flexibility to make judgment calls without being held to a stated standard. Any documented criteria should therefore describe the spirit of what trusted contribution looks like rather than a checklist that can be gamed.

Examples or references

The Vouch tool itself: https://github.com/mitchellh/vouch Mitchell Hashimoto's own documentation for the system T3Code has adopted. Notably it does not prescribe admission criteria, which is a deliberate design choice. That responsibility sits with the project adopting it.

The Linux kernel's Submitting Patches guide is the canonical example of a project that documents trust-building explicitly, from first patch to maintainer, without reducing it to a checklist.

Contribution

• I would be open to helping implement this.