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>
1.0 KiB
title, target-version
| title | target-version |
|---|---|
| feature-name | 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.