Writing the Proposal

Tips

Is the proposal summary really a summary? This should only be 1 or 2 sentences about what you are aiming to achieve if this proposal passes.
Does the details section provide more context about your proposal? It’s often the case that people put the purpose of the proposal in the details, and the details in the purpose.
Details should act as an expansion of your summary. This isn’t the place to make an argument about what your proposal hopes to achieve, it’s the place to set the stage for that. It’s also not the place to include the execution details of your proposal, that can be appended to the document.
Purpose is where you can make an outcome-driven argument about why people should vote yes on your proposal.
Needs is where you outline exactly what you will need to achieve the desired outcomes of the proposal. These needs generally involve funding or collaboration from an external party.
If you have any open questions that you would like the community to answer, you can add them at the bottom of the proposal.

Before making a proposal, it’s important that the language that you use is clear, with a particular focus on transparency.

Goal: stakeholders that attentively read the document once should understand your proposal well enough to make an informed vote.

Getting Feedback

Tips

Proposals are permissionless, but it’s always useful to get feedback from others to try to understand the existing product vision and execution, so that your proposal has the effect that you intend it to.

Once your messaging is clear, it’s time to share that information with:

Key Stakeholders

To reach out to key stakeholders:

Outline affected parties:

external dependencies (are you requesting another party to work on something?)
any potential conflicts (will this proposal conflict with something that someone else is working on?)