Submitting an idea

Overview

A Policy Idea is a lightweight way to ask the community for a policy you'd like to see, without authoring one yourself. If you have a use case or a governance need but don't have the time or technical background to build a working policy, you can file an idea and let others in the community pick it up. File one from the Ideas page, and track yours under My Contributions — that page lists both the policies and the ideas you've submitted, side by side.

When to file an idea vs a full submission

Use an idea when you want to say "I wish this existed" — you describe the problem, the desired behavior, and any relevant context, then let the community decide whether to build it.

Use a submission when you have a working policy in hand — you've authored the Rust code, tested it locally, and you're ready to contribute it to the registry for review and publication.

Ideas lower the barrier for non-developers to shape the policy ecosystem. If someone picks up your idea and builds it, you'll be credited as the original requester when the policy is published.

What an idea includes

An idea captures:

• Title — a descriptive, concrete summary of the policy you want.
• Category — optional tag like security, compliance, or routing to help with discovery.
• Description — the problem you're trying to solve, the desired behavior, and any relevant context. Markdown is supported.

The form is quick to fill out, and your idea appears in the public Ideas page where contributors can browse, comment, and claim ideas to implement.

Lifecycle states

Every idea moves through one of five states. Unlike policies, ideas don't have a separate "submitted" gate — every new idea lands directly in under_review so it's queued for an admin to triage.

                       ┌────► needs_improvement ──── (you edit, it goes back to under_review)
                       │
new idea ► under_review┤────► approved ──┬─── visible in the public Ideas tab
                       │                 │
                       │                 └─► delivered ── a published policy was built for it
                       │
                       └────► rejected

The screenshots below all show the same example idea — GraphQL Query Complexity Limiter — at different points in its lifecycle, so you can see exactly how the same card looks as the badge and feedback change.

under_review

Every idea starts here. It's not yet visible in the public Ideas page, but admins can see it and triage. While the idea is under_review, it is frozen pending admin review — you cannot edit it. You only regain the ability to edit the title, description, and category when it reaches needs_improvement.

needs_improvement

The admin has sent the idea back with feedback — usually a vague description, an unclear use case, or duplication with an existing idea. The feedback appears on the idea detail page as a feedback history: every round the idea was sent back is listed newest-first, each with the reviewer's note and when it was sent, so you can see how the guidance evolved across resubmissions rather than only the latest note. Update the idea and the next save flips it back to under_review for re-triage.

approved

The admin has accepted the idea. It's now visible in the public Ideas page where the community can browse, upvote, and claim it for implementation.

delivered

A contributor built a policy for the idea and it was published. The idea flips to delivered, gains a Built as a policy card linking to the published policy on its detail page, and you — the original submitter — get an email letting you know your idea was built. An idea only reaches this state once; the link is one-to-one with the policy that delivered it. Delivered ideas stay visible in the Ideas page with their badge so the demand-to-delivery trail is preserved.

rejected

The admin has decided the idea won't be tracked further — typically because it duplicates an existing approved idea or sits outside the catalog's scope. The idea is hidden from the public Ideas page.

Community triage

Once your idea is approved, the community can upvote it, ask clarifying questions, and propose implementation approaches. Platform maintainers may tag it with labels like good first policy to help new contributors find approachable projects.

The upvote button lives on each idea's detail page. You can't upvote your own ideas — the platform enforces this at the database level so the vote count stays an honest signal of community demand. The screenshot below is the Cache Control with Redis idea, viewed from an account that didn't submit it (so the upvote button is enabled).

If your idea gains traction, a contributor will claim it, build the policy, and submit it through the standard review process.

Building a policy for an idea

Any signed-in user can offer to build an approved idea that hasn't been delivered yet. Open the idea's detail page and click Submit a policy — this opens the policy submission form with the idea already linked, so you don't have to find it again. Declaring the idea on your submission tells the reviewers which request you're delivering.

The link is recorded in two phases. While your policy is still under review, the idea it's declared to deliver is shown as a pending intent — the idea stays approved and isn't counted as delivered yet. An admin can confirm or adjust that declared idea during review. Only when the policy is approved and published does the idea flip to delivered: its detail page gains a Built as a policy card linking to the published policy, and the original idea submitter is emailed. The link is one-to-one: each idea is delivered by exactly one published policy, and each policy delivers at most one idea.