**Proposal:** This issue defines the contribution-intake framework we intend to adopt to reduce PR firehose and improve quality/signal.

[SeaCelo]

[Proposal] Enforce issue-first, priority-scoped contribution intake to reduce PR firehose

Proposal: This issue defines the contribution-intake framework we intend to adopt to reduce PR firehose and improve quality/signal.
We welcome input, and this discussion will guide the PRs and repository changes that follow.

Why this issue exists

As of March 5, 2026, repo intake has become a firehose (many low-effort or overlapping PRs), which is increasing maintainer load and diluting focus from core goals:

• Cross-platform app stability
• OG onboarding
• OG-CLEWS integration

We are happy to see strong contributor enthusiasm. Nobody wants a situation where good intent turns into queue chaos.
To build a vibrant community, we need to encourage high-quality interaction: clear problem framing, scoped implementation, and coordinated effort.

We already have policy text and templates, but enforcement is weak:

• CONTRIBUTING.md says “issue first”
• PR/issue templates exist
• Priority labels exist (Priority: High/Medium/Low)
• A workflow syncs priority labels to project fields

Current gap: these are mostly guidance, not hard gates.

Current status (snapshot: March 5, 2026)

• Open PRs: 72
• Open issues: 67
• Open PRs with no detectable issue reference in PR body: 17/72 (23.6%)
• Open draft PRs: 7

Examples of open PRs currently missing issue linkage in body:
#189, #187, #170, #169, #168, #167, #146, #135, #134, #129, #111, #110 (non-exhaustive sample)

Additional operational observations:

• Existing ruleset is active but minimal (deletion/non-fast-forward); intake quality is not enforced.
• No hard gate for linked issue + triaged scope.
• No required “related work already researched” field enforcement.

Proposed solution

Implement a strict intake gate and triage flow:

1. Issue-first enforcement

• Require linked issue for PRs (except an explicit tiny-docs/typo allowlist)
• Require linked issue to be maintainer-triaged (ready-for-pr)

2. Priority/track alignment

• Keep Priority:* labels
• Add track labels:
  • Track: Cross-Platform
  • Track: OG Onboarding
  • Track: Integration
• Review focus goes to priority + track scoped items

3. Research-first requirement

• Issue form requires links to related existing issues/PRs
• PR template requires overlap check (“existing efforts reviewed”)

4. Automation and branch/review protection

• Add PR intake workflow check (required status check)
• Require PR approval before merge
• Add stale/needs-info automation for triage queue hygiene

Implementation plan (PRs to follow)

This will be implemented in one or more PRs:

• PR A (Intake Gates + Templates)

  • Add PR intake check workflow
  • Update PR template and issue forms with required research/link fields
  • Add ready-for-pr policy language in docs

• PR B (Rules/Ownership)

  • Update ruleset/merge requirements for main

• PR C (Triage Automation + Docs)

  • Add stale/needs-info automation
  • Add maintainer triage playbook + pinned contributor guidance

Acceptance criteria

• New PRs cannot pass required checks without a linked issue
• Linked issue must be triaged for implementation (ready-for-pr)
• Templates require related-work links
• Track labels are in active use for scope control
• Merge path requires passing checks + reviewer approval
• Triage load is reduced and duplicate/low-effort intake decreases measurably

Notes

This is a process/governance proposal, not a feature issue.
The objective is to protect maintainer bandwidth and keep delivery aligned to roadmap priorities while supporting productive contributor participation.

cc: @autibet

[brightyorcerf]

The 'firehose' effect is a real risk to project velocity, especially as we approach the GSoC application window. From a contributor's perspective, these proposed hard gates (Issue-first + Triaged scope) actually provide much-needed clarity.

I particularly support the 'Research-first' requirement. It encourages us to do the due diligence of checking existing efforts before opening a branch, which directly reduces the triage burden on the team. Quality over quantity is definitely the right move for the project's long-term health.

As I continue work on the Cross-Platform track, I'll ensure my upcoming documentation and PRs serve as a clean reference for these new standards.

[lil-aditya]

This seems like a very reasonable step given the current volume of PRs. Enforcing issue-first with triaged scope should help reduce duplicate work and make reviews more focused.

I support this proposal and look forward to seeing it implemented.