Authors	Creation Date	Status	Extra
@name	date	Implementable	-

Title of the Design/Proposal

<!-- Describe your change here. This is purposefully freeform: we want enough information to evaluate the design, but not so much that you're annoyed by the overall design process and decide to bake cookies instead. -->

Example

<!-- Specify an example of how the user would use this. It helps other contributors get a feel for how this will look in real code, and provides a good opportunity to evaluate the end-user feel of the code for yourself. If you find yourself groaning at verbosity, copy-and-pasting a lot, or writing a bunch of tiny helper functions, it's a good indication that you 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. -->