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

An approved idea may also show as partially delivered when one or more policies cover part of it but none delivers it in full.

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 once a policy fully delivers it (or an admin marks a policy as completing it), and you — the original submitter — get an email when the first such policy is published. The Delivered by area of the idea's detail page lists every policy delivering it, each showing whether it delivers the idea in full or in part. Delivered ideas stay visible in the Ideas page with their badge so the demand-to-delivery trail is preserved.

An idea can also be partially delivered. When policies cover only part of the idea (all partial coverage, none marked as completing), the idea shows a Partially delivered badge and stays open to further delivery. The idea's detail page lists the policies contributing partial coverage, and the submitter is not yet notified.

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(s) on your submission tells the reviewers which request(s) you're delivering.

The link is recorded in two phases. A submission may declare it delivers one or more approved ideas, each with a coverage (full or partial). While your policy is still under review, the ideas it's declared to deliver are shown as a pending intent — the ideas stay approved and aren't counted as delivered yet. An admin can confirm or adjust the declared set during review. Only when the policy is approved and published do those declared links become committed: each fully-delivered (or admin-completed) idea flips to delivered and its original submitter is emailed, while partially-covered ideas show as partially delivered and stay open to further delivery.