| title | authors                                  | creation-date | last-updated |
|-------|------------------------------------------|---------------|--------------|
| title | [@username1](https://github_profile_url) | yyyy-mm-dd    | yyyy-mm-dd   |

# Title

This is the title of the enhancement. It should be short, clear, and descriptive.

- [Summary](#summary)
- [Motivation](#motivation)
  - [Goals](#goals)
  - [Non-Goals](#non-goals)
- [Proposal](#proposal)
  - [Use Cases](#use-cases)
  - [Implementation Details](#implementation-details)
- [Risks and Mitigations](#risks-and-mitigations)
- [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
- [Drawbacks](#drawbacks)
- [Alternatives](#alternatives)
- [References](#references)

## Summary

The `Summary` section should be a short description of the enhancement. Before you get started this documentation, We recommend that you read the [CONTRIBUTING.md](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md) and check whether the enhancement you are proposing is already in the [issues](https://github.com/litmuschaos/litmus/issues).

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

### Use Cases

Detail the things that people will be able to do if this is `implemented`.

#### Use case 1

#### Use case 2

### Implementation Details

What are the caveats to the implementation? What are some important details that didn't come across above? Go into as much detail as necessary here. This is a good place to discuss core concepts and their relationships.

If you want to use images, store images in the `proposals/images` directory.

## 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 Litmus ecosystem`.

## Upgrade / Downgrade Strategy

If applicable, how will the component be upgraded and downgraded? Make sure this is in the test plan.

Consider the following in developing an upgrade/downgrade strategy for this enhancement:

- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to keep previous behavior?
- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to make use of the enhancement?

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

## References

Is their any reference for this proposal? If yes, please mention here.