RFC 0003How To… create a proposalDecember 2021
axklmn.dev
Request for Comments: 0003
Category: Best Current Practice
A. Klimenkov
December 2021
2 min read

How To… create a proposal

Figure 1

Overview

Sometimes we need to suggest improvements that may affect different areas and teams. To have a history and save the decision for the future employees, we have to write it down.

As with any document with a few participants, the document should have “Reviewers”, “Ideas”, and a final decision (Action Items) sections.

Idea

To make a “proposal” easy to understand, we developed the following policies and structures for the document.

Policies

One proposal should solve one problem only

If we have more than one problem in the document, we may mix everything, and “resolving” time goes to infinity.

All comments and ideas from other participants are welcome and discussed politely and respectfully. All participants can add their thoughts into comments and/or directly to a proposal (“ideas” or similar sections)

We are building a friendly atmosphere in a company, and every one is essential. Sometimes even crazy ideas are the best.

The “proposal” can have the status Approved when 70% of reviewers set the “Approve” mark, AND all comments have “resolve” status

Everyone knows having 100% of “approves” is almost impossible; that’s why we agreed to have 70%. For us, it looks enough to go forward.

The reviewers could be any person who wants to bе. The proposal’s author should choose 3–5 default persons who fit best for the problem. Ideally, if default, reviewers would be from different teams.

The author should share the link for all engineers (or others)

One more time, we know that everyone can bring a great idea. So we very much appreciate it if someone not from the area left a comment or an improvement. That’s why we invite everyone and share the link in a “general” channel.

The “proposal” can be taken to the development (or similar) when it has “Approved” status

Statuses

  • “Draft” — a “proposal” still in progress and doesn’t ready for review.
  • “In Review” — a “proposal” has been finished and ready to review by other teammates
  • “Approved” — a “proposal” is reviewed and accepted by at least 70% of reviewers.
  • “Implemented” — a “proposal” is implemented and launched.
  • “Declined” — a “proposal” has been declined, and we decided not to implement (launch) it at all.

To reduce confusion, we agreed that the owner should manage the statuses.

Reviewers

Reviewers set an approval mark when they don’t want to add anything, and everything is clear, and they agree with the proposal. We have this section as a “checkbox” list of people.

Action Items

In the final section, we specify the final decision if needed. It can be helpful if we have a discussion and different approaches to reach the goal.

Instead of conclusion

Everything should be documented to make the future more predictive (YES, it is not very funny work). But it helps you and your new teammate understand your decision and make the onboarding process faster.

I hope these small policies help you create a good document or build your own rules.

Also published on Medium.

KlimenkovBest Current Practice[Page 1]
Comments: linkedin(1), mention "RFC 0003"