An improvement proposal is a short, durable record of a problem, a proposed change, and how the work will be delivered and checked. It gives contributors something concrete to review and build on.
The process here is a working draft. It is a proposed workflow for website and repository contributions, not an adopted DAO-wide policy. It does not create funding, voting rules, or authority over contracts or shared assets.
Start with the work
If you are still finding the problem or choosing an approach, start with a contribution concept. Compare alternatives and test the smallest useful result before expanding it into a formal plan. Protocol and on-chain improvement proposals need prior research into deployed dependencies, authority, obligations, and failure modes.
For a small, reversible website fix, clearer documentation, or a focused tool improvement, use the normal contribution workflow. Explain the change, prepare the result, and ask the appropriate maintainer for review. You do not need a separate proposal for every contribution.
Use a proposal when a change spans several contributions, introduces a new process, or needs a durable record of the choices and risks. Keep the first draft small enough to act on. Feedback should help improve and deliver the work.
Read or prepare a proposal
- Browse proposals by stage: find drafts and read their separate decision, funding, and delivery records.
- A lightweight improvement process: the working draft describing the suggested workflow.
- Proposal template: copy it and describe the outcome, evidence, delivery plan, checks, and decision needed.
The Markdown source lives in the website repository so proposals can be reviewed alongside implementation. Check existing issues and pull requests before starting. Each proposal is maintained once in Markdown; its wiki page and the stage index are generated from that source.
Keep decisions and delivery clear
Document stages describe the writing: working draft, in review, stable, or archived. A stable document can still have a pending decision. Funding and delivery are recorded separately.
A published draft is an invitation to review. It is not evidence of acceptance. An accepted proposal should link the actual decision and say who or which process authorized it. An implemented proposal should link the delivered work and checks, and say whether it has been deployed.
Site maintainers can make decisions within their responsibility for the website. Funding, covenant, contract, and on-chain governance changes require their own existing authorization processes. A repository merge cannot make those decisions.
General site and contributor-experience improvements can move ahead while protocol ideas are researched separately. No on-chain change is proposed by this process draft.
See How you can contribute for useful starting points and Navigating core community infrastructure for the systems relevant to funding and governance.