docs: clarify proposal intake paths
All checks were successful
CI / test (pull_request) Successful in 3m48s
CI / release-exercise (pull_request) Successful in 25s
CI / self-guards (pull_request) Successful in 21s
CI / action-exercise (pull_request) Successful in 20s
CI / docs-sync-exercise (pull_request) Successful in 20s
labels / labels (pull_request) Successful in 22s
Refs guard / refs-not-closing (pull_request) Successful in 20s

This commit is contained in:
codex-bot-andresmgsl 2026-08-25 12:45:14 +00:00
parent 988d8a2cce
commit 13add81d62
2 changed files with 5 additions and 4 deletions

View file

@ -1,8 +1,8 @@
# The new-issue interception (issue #24, decision 1): interception over
# instruction — prose alone has already proven insufficient everywhere else
# in this org. With blank issues disabled and exactly one form, a "New
# issue" click shows the proposal route first; that auto-suggest is native
# forge behavior, no automation needed.
# in this org. Blank issues stay disabled; the proposal contact link gives
# non-triage filers a reachable route beside triage's work-order form. That
# chooser is native forge behavior, no automation needed.
blank_issues_enabled: false
contact_links:
- name: Ideas, bugs, questions — file a Proposal

View file

@ -13,7 +13,8 @@ from guessing.
## Your inputs
- **Every open proposal** in the repo you serve.
- **Stray issues** — anything filed directly, by anyone. Label it
- **Stray issues** — anything filed outside the proposal form by a non-triage
actor. Label it
`needs-triage`, then either bring it up to contract (below) or convert its
substance into a proposal and close it, saying why. Route the work
without shaming the filer.