📖 update the template for proposals (#3219)

* 📖 update the template for proposals

* Apply suggestions from code review

Author: camilamacedo86

designs/template.md

@@ -1,4 +1,8 @@
-Title of the Design
+| Authors       | Creation Date | Status      | Extra |
+|---------------|---------------|-------------|---|
+| @name | date | Implementeble | - |
+
+Title of the Design/Proposal
 ===================
 
 <!-- Describe your change here.  This is purposefully freeform: we want
@@ -19,3 +23,92 @@ might need to re-evaluate the user experience of your design.
 This is also a good opportunity to stop and write a proof-of-concept, if
 you haven't already, which should help catch practical nits with the
 design. -->
+
+## Open Questions [optional]
+
+<!-- This is where to call out areas of the design that require closure before deciding
+to implement the design.  For instance,
+> 1. This requires exposing previously private resources which contain sensitive
+     information.  Can we do this?
+-->
+
+## Summary
+
+<!-- The `Summary` section is incredibly important for producing high quality
+user-focused documentation such as release notes or a development roadmap. It
+should be possible to collect this information before implementation begins in
+order to avoid requiring implementers to split their attention between writing
+release notes and implementing the feature itself.
+
+A good summary is probably at least a paragraph in length.-->
+
+## Motivation
+
+<!-- This section is for explicitly listing the motivation, goals and non-goals of
+this proposal. Describe why the change is important and the benefits to users.-->
+
+### Goals
+
+<!-- List the specific goals of the proposal. How will we know that this has succeeded?-->
+
+### Non-Goals
+
+<!-- What is out of scope for this proposal? Listing non-goals helps to focus discussion
+and make progress.-->
+
+## Proposal
+
+<!-- This is where we get down to the nitty gritty of what the proposal actually is. -->
+
+### User Stories
+
+<!-- Detail the things that people will be able to do if this is implemented.
+Include as much detail as possible so that people can understand the "how" of
+the system. The goal here is to make this feel real for users without getting
+bogged down.
+
+User story examples
+- As a user, I want to link the credit card to my profile so that I can pay for a rent faster, easier and without cash.
+- As a service provider, I want to add photos of my vehicles in the application so that I can attract more users.
+- As a user, I want several available vehicles to be displayed so that I can choose the most suitable option for me.
+
+- As a <role> I can <capability>, so that <receive benefit> -->
+
+### Implementation Details/Notes/Constraints [optional]
+
+<!-- What are the caveats to the implementation? What are some important details that
+didn't come across above. Go in to as much detail as necessary here. This might
+be a good place to talk about core concepts and how they relate. -->
+
+### Risks and Mitigations
+
+<!-- What are the risks of this proposal and how do we mitigate. Think broadly. For
+example, consider both security and how this will impact the larger Operator Framework
+ecosystem.
+
+How will security be reviewed and by whom? How will UX be reviewed and by whom?
+
+Consider including folks that also work outside your immediate sub-project. -->
+
+### Proof of Concept [optional]
+
+<!-- A demo showcasing a prototype of your design can be extremely useful to the
+community when reviewing your proposal. There are many services that enable
+you to record and share demos. Most OLM features can be showcased from the
+command line, making [https://asciinema.org](https://asciinema.org) an
+excellent option to [record](https://asciinema.org/docs/usage) and
+[embed](https://asciinema.org/docs/embedding) your demo.
+
+Be sure to include:
+- An embedded recording of the prototype in action.
+- A link to the repository hosting the changes that the prototype introduces. -->
+
+## Drawbacks
+
+<!-- The idea is to find the best form of an argument why this enhancement should _not_ be implemented. -->
+
+## Alternatives
+
+<!-- Similar to the `Drawbacks` section the `Alternatives` section is used to
+highlight and record other possible approaches to delivering the value proposed
+by an enhancement. -->