forked from rook/rook
Sébastien Han
db17533435
Rook already has a design process in place when introducing new functionality. The only missing thing is a clear template to bring consistency in our design documents. This is inspired and shrunk version of https://github.com/openshift/enhancements/tree/master/guidelines to add some guidelines when it comes to writing a design document. Signed-off-by: Sébastien Han <seb@redhat.com>
44 lines
1.0 KiB
Markdown
44 lines
1.0 KiB
Markdown
---
|
|
title: feature-name
|
|
target-version: release-X.X
|
|
---
|
|
|
|
# Feature Name
|
|
|
|
## Summary
|
|
|
|
### 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 details
|
|
|
|
This is where we get down to the nitty gritty of what the proposal actually is.
|
|
API changed in any, Golang snippets.
|
|
|
|
### Risks and Mitigation
|
|
|
|
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 OKD
|
|
ecosystem.
|
|
|
|
## Drawbacks
|
|
|
|
The idea is to find the best form of an argument why this feature 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 a feature.
|
|
|
|
## Open Questions [optional]
|
|
|
|
This is where to call out areas of the design that require closure before deciding
|
|
to implement the design.
|