Colors for resources

[erictune]

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
  • [x] Propose your feature. See [Advice for proposing features].
  • [x] Start with a < 1 page description of design in an issue comment below this. [advice for design description]
  • [x] 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.

[erictune]

All objects get new metadata field: metadata.color. UI and CLI will show those objects in that color. Colors must conform to https://www.w3.org/TR/SVG/types.html#ColorKeywords

[erictune]

@sarahnovotny please do a new feature review

[sarahnovotny]

LGTM