If there is no problem, there is no need for changing anything, no need for a proposal. This might feel trivial, but we should first ask ourselves this question before even thinking about writing a proposal.
It takes time to propose an idea, find consensus and implement more significant concepts, so let’s not use the time before we feel it’s worth it. Even good ideas sometimes have to wait for a good moment to discuss them.
Let’s assume the idea sounds interesting to you. Yet, some ideas are quick and trivial enough to not require a formal proposal. To learn if we need proposal, ask yourself a following questions:
If any of this is yes, this idea might require a formal proposal. See full proposal process, visualised below:
Note: It’s totally ok for your proposal to be rejected if the community feels the idea is not needed now or having gaps. Not all ideas are as good as it looks at the first glance, with less context. Sometimes it’s not a good time for it either. It’s better to explicitly oppose it than to ignore it and leave it in limbo.
See rationales in our proposal for proposal process
<@author: single champion for the moment of writing>
<JIRA, GH Issues>
TL;DR: Give a summary of what this document is proposing and what components it is touching.
For example: This design doc is proposing a consistent design template for “example.com” organization.
Provide a motivation behind the change proposed by this design document, give context.
For example: It’s important to clearly explain the reasons behind certain design decisions in order to have a consensus between team members, as well as external stakeholders. Such a design document can also be used as a reference and knowledge-sharing purposes. That’s why we are proposing a consistent style of the design document that will be used for future designs.
What specific problems are we hitting with the current solution? Why it’s not enough?
For example, We were missing a consistent design doc template, so each team/person was creating their own. Because of inconsistencies, those documents were harder to understand, and it was easy to miss important sections. This was causing certain engineering time to be wasted.
Goals and use cases for the solution as proposed in How:
If this is not clear already, provide the target audience for this change.
Explain the full overview of the proposed solution. Some guidelines:
The section stating potential alternatives. Highlight the objections reader should have towards your proposal as they read it. Tell them why you still think you should take this path [ref]
The tasks to do in order to migrate to the new idea.
Found a typo, inconsistency or missing information in our docs? Help us to improve Thanos documentation by proposing a fix on GitHub here ❤️