Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

design-proposals: Clean template and add feature lifecycle section #343

Closed
wants to merge 1 commit into from
Closed

design-proposals: Clean template and add feature lifecycle section #343

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 31 additions & 4 deletions design-proposals/proposal-template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,43 +1,70 @@
# Proposal Template Title

This template is simply a guide. When making proposals, feel free to add and
remove portions of this outline to best fit your specific case. There is no
expectation that people strictly stick to this outline, but it is a good place
to start.
to start.

## Overview

# Overview
(Provide a brief overview of the topic)

## Motivation

(Why this enhancement is important)

## Goals

(The desired outcome)

## Non Goals

(limitations to the scope of the design)

## Definition of Users

(who is this feature set intended for)

## User Stories

(list of user stories this design aims to solve)

## Repos

(list of repose this design impacts)

# Design
## Design

(This should be brief and concise. We want just enough to get the point across)

## API Examples

(tangible API examples used for discussion)

## Scalability

(overview of how the design scales)

## Update/Rollback Compatibility

(does this impact update compatibility and how)

## Functional Testing Approach

(an overview on the approaches used to functional test this design)

# Implementation Phases
## Implementation Phases

(How/if this design will get broken up into multiple phases)

## Feature lifecycle Phases

(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)
Comment on lines +60 to +62
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome to see this!

In order to provide some more guidance, I'd add sub-sections for alpha, beta and GA.

Suggested change
## Feature lifecycle Phases
(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)
## Feature lifecycle Phases
(How and when will the feature progress through the Alpha, Beta and GA lifecycle phases)
### Alpha:
### Beta:
### GA:

The Kubernetes KEP template does so with a comment:

#### Alpha

- Feature implemented behind a feature flag
- Initial e2e tests completed and enabled

#### Beta

- Gather feedback from developers and surveys
- Complete features A, B, C
- Additional tests are in Testgrid and linked in KEP

#### GA

- N examples of real-world usage
- N installs
- More rigorous forms of testing—e.g., downgrade tests and scalability tests
- Allowing time for feedback

WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And it should be clear that the phases are not mandatory, e.g. a feature can reach GA directly. Usually if it is trivial.


(Refer to https://github.com/kubevirt/community/blob/main/design-proposals/feature-lifecycle.md#releases for more details)

### Alpha (v1.5.0)

### Beta (v1.6.0)

### GA (v1.7.0)