erictune / features Goto Github PK

Thanks for wanting to add a feature to Kubernetes! You will be responsible for guiding
your feature through completion, and asking the right people for approvals.

Large features typically go through three stages: Alpha, Beta, and Stable
Each stage requires various approvals from various teams.

You can use the checkboxes below to
track your progress. You can delete the text above once you have read it. Please keep the checklist.

• Before Alpha
  • Propose your feature. See [Advice for proposing features].
  • Start with a < 1 page description of design in an issue comment below this. [advice for design description]
  • Initial design review @kubernetes/new-feature-reviewers [advice for getting a review from a team]
  • Initial API review (if API) @kubernetes/api-reviewers
  • Minimal testing part of code PR process
  • OWNER approval for code part of code PR process
  • Code needs to be disabled by default. Verified by code OWNERS
  • Write code and tests get them merged.
• Before Beta
  • Testing is sufficient for beta @kubernetes/test-review-team
  • User docs with examples @kubernetes/docs-review-team
  • Thorough API review @kubernetes/api-review-team
• Before Stable
  • Soak, load testing @kubernetes/test-review-team
  • detailed user docs and examples @kubernetes/docs-review-team

More advice:

Design

• If the feature is simple, the approver might ask you to write a longer design doc.
• If there is a design doc, that goes in a PR under github.com/kubernetes/kubernetes/docs/proposals. Link that PR on this issue.
• Once you get LGTM from a feature reviewer, you can check this checkbox, and the reviewer will apply the "feature-lgtm" label.
• If your code changes an API (/pkg/apis/...), it needs an API review.

Coding

• Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
• As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
  and sometimes http://github.com/kubernetes/contrib, or other repos.
• When you are done with the code, apply the "code-complete" label.
• When the feature has user docs, please add a comment mentioning @kubernetes/feature-complete-reviewers and they will
  check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
  testing. They won't do detailed code review: that already happened when your PRs were reviewed.
  When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

• Write user docs and get them merged in.
• User docs go into http://github.com/kubernetes/kubernetes.github.io.
• When the feature has user docs, please add a comment mentioning @kubernetes/docs-reviews.
• When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Thanks for wanting to add a feature to Kubernetes! You will be responsible for guiding
your feature through completion, and asking the right people for approvals.

Large features typically go through three stages: Alpha, Beta, and Stable
Each stage requires various approvals from various teams.

You can use the checkboxes below to
track your progress. You can delete the text above once you have read it. Please keep the checklist.

• Before Alpha
  • Propose your feature. See [Advice for proposing features].
  • Start with a < 1 page description of design in an issue comment below this. [advice for design description]
  • Initial design review @kubernetes/new-feature-reviewers [advice for getting a review from a team]
  • Initial API review (if API) @kubernetes/api-reviewers
  • Minimal testing part of code PR process
  • OWNER approval for code part of code PR process
  • Code needs to be disabled by default. Verified by code OWNERS
  • Write code and tests get them merged.
• Before Beta
  • Testing is sufficient for beta @kubernetes/test-review-team
  • User docs with examples @kubernetes/docs-review-team
  • Thorough API review @kubernetes/api-review-team
• Before Stable
  • Soak, load testing @kubernetes/test-review-team
  • detailed user docs and examples @kubernetes/docs-review-team

More advice:

Design

• If the feature is simple, the approver might ask you to write a longer design doc.
• If there is a design doc, that goes in a PR under github.com/kubernetes/kubernetes/docs/proposals. Link that PR on this issue.
• Once you get LGTM from a feature reviewer, you can check this checkbox, and the reviewer will apply the "feature-lgtm" label.
• If your code changes an API (/pkg/apis/...), it needs an API review.

Coding
- Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
- As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
- When you are done with the code, apply the "code-complete" label.
- When the feature has user docs, please add a comment mentioning @kubernetes/feature-complete-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.
Docs
- [ ] Write user docs and get them merged in.
- User docs go into http://github.com/kubernetes/kubernetes.github.io.
- When the feature has user docs, please add a comment mentioning @kubernetes/docs-reviews.
- When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Thanks for wanting to add a feature to Kubernetes!

If you are just requesting a new feature, but have no plans to start on it, please file an issue at http://github.com/kubernetes/kubernetes

If you are ready to lead the implementation of a new feature, then this is the place for you.
You will be responsible for guiding your feature through completion, and asking the right people for approvals. Please don't file an issue here until you or your team is ready to start work on a new feature.

You can use the checkboxes below to track your progress. First, give this issue a title that describes the feature
you want to add. Then click "Submit new issue". Then follow the checklist that appears.

You can delete the text above once you have read it.
Please keep the text below. You can come back and edit the checklist later using the edit button.

• Propose your feature. See [Advice for proposing features].
  • Start with a < 1 page description in an issue comment below this.
  • Refer to existing issues on http://github.com/kubernetes/kubernetes
  • Request an initial feature review by mentioning @kubernetes/new-feature-reviewers.
  • Keep pinging that every few days if you don't get a response.
  • If the feature is simple, the approver might ask you to write a longer design doc.
  • If there is a design doc, that goes in a PR under github.com/kubernetes/kubernetes/docs/proposals. Link that PR on this issue.
  • Once you get LGTM from a feature reviewer, you can check this checkbox, and the reviewer will apply the "feature-lgtm" label.
• Write code and tests get them merged.
  • Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
  • As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
    and sometimes http://github.com/kubernetes/contrib, or other repos.
  • When you are done with the code, apply the "code-complete" label.
  • When the feature has user docs, please add a comment mentioning @kubernetes/feature-complete-reviewers and they will
    check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
    testing. They won't do detailed code review: that already happened when your PRs were reviewed.
    When that is done, you can check this box and the reviewer will apply the "code-complete" label.
• Write user docs and get them merged in.
  • User docs go into http://github.com/kubernetes/kubernetes.github.io.
  • When the feature has user docs, please add a comment mentioning @kubernetes/docs-reviews.
  • When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.
• And so on...