| 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. -->
