Copy edit contributing.
Attempt to clarify request/proposal/impl cycle and @mention usage. Cut ~700 words (~30%), fixed some links, pluralize mention tags.
This commit is contained in:
Jeffrey Regan
parent
96dd28871b
commit
1825417a43
|
|
@ -13,7 +13,7 @@ We focus on the development and standardization of the CLI [framework](https://g
|
||||||
* Slack: <https://kubernetes.slack.com/messages/sig-cli> ([archive](http://kubernetes.slackarchive.io/sig-cli))
|
* Slack: <https://kubernetes.slack.com/messages/sig-cli> ([archive](http://kubernetes.slackarchive.io/sig-cli))
|
||||||
* Google Group: <https://groups.google.com/forum/#!forum/kubernetes-sig-cli>
|
* Google Group: <https://groups.google.com/forum/#!forum/kubernetes-sig-cli>
|
||||||
|
|
||||||
## Organizers:
|
## Leads
|
||||||
|
|
||||||
**Note:** Escalate to these folks if you cannot get help from slack or the Google group
|
**Note:** Escalate to these folks if you cannot get help from slack or the Google group
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,312 +1,202 @@
|
||||||
# Contributing to sig-Cli
|
# Contributing
|
||||||
|
|
||||||
This document explains the process for contributing code to the Kubernetes
|
The process for contributing code to Kubernetes via the sig-cli [community][community page].
|
||||||
repo through the sig-cli community.
|
|
||||||
|
|
||||||
## TL;DR
|
## TL;DR
|
||||||
|
|
||||||
- New contributors should reach out on slack sig-cli - [link](https://github.com/kubernetes/community/tree/master/sig-cli) for an issue to work on that has an approved design
|
- The sig-cli [community page] lists sig-cli [leads],
|
||||||
- New contributors should attend the next sig-cli meeting and introduce themselves
|
channels of [communication], and group [meeting] times.
|
||||||
- Write tests
|
- New contributors: please start by adopting an [existing issue].
|
||||||
|
- Request a feature by making an [issue] and mentioning
|
||||||
|
`@kubernetes/sig-cli-feature-requests`.
|
||||||
|
- Write a [design proposal] before starting work on a new feature.
|
||||||
|
- Write [tests]!
|
||||||
|
|
||||||
## Important
|
## Before You Begin
|
||||||
|
|
||||||
The [sig-cli community page](https://github.com/kubernetes/community/tree/master/sig-cli)
|
|
||||||
contains the GitHub handles for the sig-cli leads, slack channels,
|
|
||||||
email discussion group, and bi-weekly meeting time.
|
|
||||||
|
|
||||||
## Message to new contributors
|
|
||||||
|
|
||||||
Welcome to the Kubernetes sig-cli contributing guide. We are excited
|
Welcome to the Kubernetes sig-cli contributing guide. We are excited
|
||||||
about the prospect of you joining our community. Please understand
|
about the prospect of you joining our [community][community page]!
|
||||||
that all contributions to Kubernetes require time and commitment from
|
|
||||||
the project maintainers to review the ux, software design, and code. We
|
|
||||||
recommend that you reach out to one of the sig leads
|
|
||||||
and ask the best way to get started. It is likely that there a couple
|
|
||||||
issues perfect for a new contributor to get started on.
|
|
||||||
|
|
||||||
sig leads can be reached in the sig-cli slack channel or at the sig-cli
|
Please understand that all contributions to Kubernetes require time
|
||||||
bi-weekly meeting. See the [sig-cli community page](https://github.com/kubernetes/community/tree/master/sig-cli)
|
and commitment from the project maintainers to review the ux, software
|
||||||
for a link to the slack channel, list of sig leads, and the community meeting time and location.
|
design, and code. Mentoring and on-boarding new contributors is done
|
||||||
|
in addition to many other responsibilities.
|
||||||
|
|
||||||
Example message for asking how to become a contributor:
|
### Understand the big picture
|
||||||
|
|
||||||
Hello, my name is <your name>. I would like to get involved in
|
- Complete the [Kubernetes Basics Tutorial].
|
||||||
contributing to the Kubernetes project. What is the best way to
|
- Be familiar with [kubctl user facing documentation ][kubectl docs].
|
||||||
get started?
|
- Read the concept guides starting with the [management overview].
|
||||||
|
|
||||||
Please understand that mentoring and on boarding new contributors takes
|
### Modify your own `kubectl` fork
|
||||||
a lot time and energy from maintainers who have many other
|
|
||||||
responsibilities.
|
|
||||||
|
|
||||||
## Before you begin
|
Make sure you are ready to immediately get started once you have been
|
||||||
|
assigned a piece of work. Do this right away.
|
||||||
|
|
||||||
We are so glad you are ready to get started. Please complete the following steps
|
- Setup your [development environment][development guide].
|
||||||
to join the community.
|
- Look at code:
|
||||||
|
- [kubernetes/cmd/kubectl] is the entry point
|
||||||
- Read the Kubectl user facing documentation to make sure you understand the tool
|
- [kubernetes/pkg/kubectl] is the implementation
|
||||||
- Complete the [Kubernetes Basics Tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/)
|
|
||||||
- Read the concept guides starting with the [Overview](https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview/)
|
|
||||||
- This is really important so that you have a good understanding of the tool before you start trying to work on it
|
|
||||||
- Visit the [sig-cli community page](https://github.com/kubernetes/community/tree/master/sig-cli)
|
|
||||||
- Join the `kubernetes-sig-cli@googlegroups.com` so you get email updates
|
|
||||||
- Join the Kubernetes slack channel `sig-cli`
|
|
||||||
- Introduce yourself to the community by sending an email to kubernetes-sig-cli@googlegroups.com and let us know you want to be a contributor
|
|
||||||
|
|
||||||
Completing the following steps will make sure you are ready to immediately
|
|
||||||
get started once you have been assigned a piece of work. Do these right
|
|
||||||
away.
|
|
||||||
|
|
||||||
- Setup your development environment so you can build and run Kubernetes. See [this guide for details](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md)
|
|
||||||
- Starting taking a look at the code:
|
|
||||||
- `kubernetes/cmd/kubectl`: This is the entry point
|
|
||||||
- `kubernetes/pkg/kubectl`: This contains the implementation
|
|
||||||
- Look at how some of the other commands are implemented
|
- Look at how some of the other commands are implemented
|
||||||
- Try adding a new command to do something simple:
|
- Add a new command to do something simple:
|
||||||
- Add `kubectl hello-world`: print "Hello World"
|
- Add `kubectl hello-world`: print "Hello World"
|
||||||
- Add `kubectl hello-kubernetes -f file`: Print "Hello <kind of resource> <name of resource>"
|
- Add `kubectl hello-kubernetes -f file`: Print "Hello \<kind of resource\> \<name of resource\>"
|
||||||
- Add `kubectl hello-kubernetes type/name`: Print "Hello <kind of resource> <name of resource> <creation time>"
|
- Add `kubectl hello-kubernetes type/name`: Print "Hello \<kind of resource\> \<name of resource\> \<creation time\>"
|
||||||
|
|
||||||
## Finding an existing issue to work on
|
### Adopt an issue
|
||||||
|
|
||||||
The preferred way to own a piece of work is to directly reach out
|
New contributors can try the following to work on an existing [bug] or [approved design][design repo]:
|
||||||
to one of the sig-cli leads. This will ensure that the issue is
|
|
||||||
high-priority enough that it will receive PR review bandwidth from
|
|
||||||
the sig-cli community.
|
|
||||||
|
|
||||||
1. In the Kubernetes sig-cli slack channel, mention @pwittrock, @adohe, or @fabianofranz and ask if there are any issues you could pick up
|
- In [slack], @mention a [lead][leads] and ask if there are any issues you could pick up.
|
||||||
2. Send an email to the `kubernetes-sig-cli@googlegroups.com`
|
Leads can recommend issues that have enough priority to receive PR review bandwidth.
|
||||||
|
- Send an email to the _kubernetes-sig-cli@googlegroups.com_ [group]
|
||||||
|
|
||||||
Subject: `New Sig-Cli Contributor <Your Name>`
|
> Subject: New sig-cli contributor _${yourName}_
|
||||||
Body: Hello, my name is <your name>. I would like to get involved in
|
>
|
||||||
contributing to the Kubernetes project. I have read all of the
|
> Body: Hello, my name is _${yourName}_. I would like to get involved in
|
||||||
user documentation listed on the community contributring page.
|
> contributing to the Kubernetes project. I have read all of the
|
||||||
What should I do next to get started?
|
> user documentation listed on the community contributring page.
|
||||||
|
> What should I do next to get started?
|
||||||
|
|
||||||
3. Attend the sig-cli [bi-weekly meeting](https://github.com/kubernetes/community/tree/master/sig-cli).
|
- Attend a sig-cli [meeting] and introduce yourself as looking to get started.
|
||||||
- Introduce yourself at the beginning of the meeting
|
|
||||||
|
|
||||||
## Expectations
|
### Bug lifecycle
|
||||||
|
|
||||||
If a sig-cli identifies a bug or feature to you to work on,
|
1. An [issue] is filed that
|
||||||
they will need your help to ensure that continual progress is
|
- includes steps to reproduce the issue including client / server version,
|
||||||
made and the fix / feature makes it into a Kubernetes release.
|
- mentions `@kubernetes/sig-cli-bugs`.
|
||||||
While you are working on the issue, you must leave a weekly update
|
2. A [PR] fixing the issue is implemented that
|
||||||
including:
|
- __includes unit and e2e tests__,
|
||||||
|
- incorporates review feedback,
|
||||||
|
- description includes `Closes #<Issue Number>`,
|
||||||
|
- description or comment @mentions `@kubernetes/sig-cli-pr-reviews`.
|
||||||
|
3. Fix appears in the next Kubernetes release!
|
||||||
|
|
||||||
1. What has been finished
|
## Feature requests
|
||||||
2. What is being worked on
|
|
||||||
3. What if anything is blocking progress
|
|
||||||
|
|
||||||
## Life of a sig-cli bug overview
|
__New contributors:__ Please start by adopting an [existing issue].
|
||||||
|
|
||||||
1. File a GitHub issue
|
A feature request is an [issue] mentioning `@kubernetes/sig-cli-feature-requests`.
|
||||||
- Mention `@kubernetes/sig-cli-bugs`
|
|
||||||
- Describe steps to reproduce the issue including client / server version
|
|
||||||
2. Implement the fix
|
|
||||||
- Send a PR
|
|
||||||
- Add `Closes #<Issue Number>` to the description
|
|
||||||
- Mention `@kubernetes/sig-cli-pr-reviews` in a comment
|
|
||||||
- Incorporate review feedback
|
|
||||||
- **Note:** Include unit and e2e tests
|
|
||||||
7. Release
|
|
||||||
- Wait for your feature to appear in the next Kubernetes release!
|
|
||||||
|
|
||||||
## Life of a sig-cli feature overview
|
To encourage readership, the issue description should _concisely_ (2-4 sentence) describe
|
||||||
|
the problem that the feature addresses.
|
||||||
|
|
||||||
Picking up an issue and implementing it without getting approval for
|
### Feature lifecycle
|
||||||
the user experience and software design often results in wasted time
|
|
||||||
and effort due to decisions such as flag-names, command names, specific
|
|
||||||
command behavior.
|
|
||||||
|
|
||||||
In order to minimize wasted work and improve communication across efforts,
|
Working on a feature without getting approval for the user experience
|
||||||
|
and software design often results in wasted time and effort due to
|
||||||
|
decisions around flag-names, command names, and specific command
|
||||||
|
behavior.
|
||||||
|
|
||||||
|
To minimize wasted work and improve communication across efforts,
|
||||||
the user experience and software design must be agreed upon before
|
the user experience and software design must be agreed upon before
|
||||||
any PRs are sent for code review.
|
any PRs are sent for code review.
|
||||||
|
|
||||||
1. Identify a problem - GitHub issue with basic description
|
1. Identify a problem by filing an [issue] (mention `@kubernetes/sig-cli-feature-requests`).
|
||||||
2. Propose a solution - GitHub design proposal PR
|
2. Submit a [design proposal] and get it approved by a lead.
|
||||||
- **Action:** Write a design proposal using the [template](contributors/design-proposals/sig-cli/template.md). Once
|
3. Announce the proposal as an [agenda] item for the sig-cli [meeting].
|
||||||
complete, create a pull request and mention `@kubernetes/sig-cli-misc`
|
- Ensures awareness and feedback.
|
||||||
- Avoid "Work In Progress" PRs (WIP), only send the PR after you
|
- Should be included in meeting notes sent to the sig-cli [group].
|
||||||
consider it complete. To get early feedback, consider messaging the
|
4. _Merge_ the proposal PR after approval and announcement.
|
||||||
email discussion group.
|
5. A [lead][leads] adds the associated feature to the [feature repo], ensuring that
|
||||||
- Expect feedback from 2-3 different sig-cli community members in the form of PR comments
|
- release-related decisions are properly made and communicated,
|
||||||
- Incorporate feedback from sig-cli community members and comment "PTAL" (please take another look)
|
- API changes are vetted,
|
||||||
- Proposal accepted by at least one sig-cli lead
|
- testing is completed,
|
||||||
- Proposal merged
|
- docs are completed,
|
||||||
3. Communicate what will be done - Discussion at sig-cli bi-weekly meeting - See the [sig-cli community page](https://github.com/kubernetes/community/tree/master/sig-cli) for meeting time and location.
|
- feature is designated _alpha_, _beta_ or _GA_.
|
||||||
- **Note:** This should be done *before* the proposal has been merged, and after an initial round of feedback - e.g. several folks have looked at it and left comments.
|
6. Implement the code per discussion in [bug lifecycle][bug].
|
||||||
- **Action:** Add the design proposal as an item to the [bi-weekly meeting agenda](https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit)
|
7. Update [kubectl concept docs].
|
||||||
- Make sure the sig-cli community is aware of the work that is being done and can comment on it
|
8. Wait for your feature to appear in the next Kubernetes release!
|
||||||
- Should be included in meeting notes sent to the sig-cli googlegroup
|
|
||||||
4. Add feature to Kubernetes release feature repo in [kubernetes/features](https://github.com/kubernetes/features/)
|
|
||||||
- **Action:** *Done by sig-cli lead* - add the feature to the feature tracking repo tag
|
|
||||||
to a release. This is done to ensure release related decisions are
|
|
||||||
properly made and communicated. Such as defining alpha / beta / ga
|
|
||||||
release, proper testing, and documentation are completed.
|
|
||||||
5. Implement the code - GitHub implementation PR
|
|
||||||
- **Action:** Implement the solution described in the proposal, then
|
|
||||||
send a PR - **include a link to the design proposal in the description**
|
|
||||||
- Incorporate review feedback
|
|
||||||
- **Note:** Include unit and e2e tests
|
|
||||||
6. Update related documentation
|
|
||||||
- [Concept Docs](https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/concepts/tools/kubectl)
|
|
||||||
7. Release
|
|
||||||
- Wait for your feature to appear in the next Kubernetes release!
|
|
||||||
|
|
||||||
# New feature development
|
|
||||||
|
|
||||||
## Creating a GitHub issue
|
## Design Proposals
|
||||||
|
|
||||||
**Note:** For new contributors, it is recommended that you pick up an
|
__New contributors:__ Please start by adopting an [existing issue].
|
||||||
existing issue with an approved design proposal by reaching out a sig-lead.
|
|
||||||
See the [Message to new contributors](#message-to-new-contributors).
|
|
||||||
|
|
||||||
In order to start a discussion around a feature, create a new GitHub issue
|
A design proposal is a single markdown document in the [design repo]
|
||||||
in the https://github.com/kubernetes/kubernetes repo and mention `@kubernetes/sig-cli-misc`.
|
that follows the [design template].
|
||||||
|
|
||||||
Keep the issue to 2-4 sentence description of the basic description of
|
To make one,
|
||||||
the problem and proposed solution.
|
- Prepare the markdown document as a PR to that repo.
|
||||||
|
- Avoid _Work In Progress_ (WIP) PRs (send it only after
|
||||||
|
you consider it complete).
|
||||||
|
- For early feedback, use the email discussion [group].
|
||||||
|
- Mention `@kubernetes/sig-cli-proposals` in the description.
|
||||||
|
- Mention the related [feature request].
|
||||||
|
|
||||||
**Note:** You must mention `@kubernetes/sig-cli-feature-requests` in the description of the
|
Expect feedback from 2-3 different sig-cli community members.
|
||||||
issue or in a comment for someone from the sig-cli community to look
|
|
||||||
at the issue.
|
|
||||||
|
|
||||||
## Creating a design proposal
|
Incorporate feedback and comment [`PTAL`].
|
||||||
|
|
||||||
**Note:** For new contributors, it is recommended that you pick up an
|
Once a [lead][leads] has agreed (via review commentary) that design
|
||||||
existing issue with an approved design proposal by reaching out to a sig-lead.
|
and code review resources can be allocated to tackle the proposal, the
|
||||||
See the [Message to new contributors](#message-to-new-contributors).
|
details of the user experience and design should be discussed in the
|
||||||
|
community.
|
||||||
|
|
||||||
Once at least one sig-lead has agreed that design and code review resources
|
This step is _important_; it prevents code churn and thrashing around
|
||||||
can be allocated to tackle a particular issue, the fine details
|
issues like flag names, command names, etc.
|
||||||
of the user experience and design should be agreed upon.
|
|
||||||
|
|
||||||
A PR is filed against the https://github.com/kubernetes/community repo.
|
It is normal for sig-cli community members to push back on feature
|
||||||
This will provide a chance for community members to comment on the
|
proposals. sig-cli development and review resources are extremely
|
||||||
user experience and software design.
|
constrained. Community members are free to say
|
||||||
|
|
||||||
**Note:** This step is important to prevent a lot of code churn and
|
- No, not this release (or year).
|
||||||
thrashing around issues like flag names, command names, etc.
|
- This is desirable but we need help on these other existing issues before tackling this.
|
||||||
|
- No, this problem should be solved in another way.
|
||||||
|
|
||||||
**Note:** It is normal for sig-cli community members to push back on
|
The proposal can be merged into the [design repo] after [lead][leads]
|
||||||
feature requests and proposals. sig-cli development and review resources are extremely constrained.
|
approval and discussion as a meeting [agenda] item.
|
||||||
If your proposal is not high-impact or urgent it may not be accepted
|
|
||||||
in favor of more pressing needs. sig-cli community members should
|
|
||||||
be free to say: "No, not this release." or "No, not this year." or "No, not right now because although this
|
|
||||||
is desirable we need help on these other concrete issues before we can
|
|
||||||
tackle this." or "No, this problem should be solved in another way."
|
|
||||||
|
|
||||||
Create a design proposal PR under
|
Then coding can begin.
|
||||||
https://github.com/kubernetes/community/tree/master/contributors/design-proposals/sig-cli/
|
|
||||||
by copying template.md.
|
|
||||||
|
|
||||||
Mention `@kubernetes/sig-cli-proposals` on the proposal and link to
|
## Implementation
|
||||||
the proposal from the original issue. Expect to get feedback
|
|
||||||
from 2-3 community members. At least
|
|
||||||
one sig lead must approve the design proposal for it to be accepted.
|
|
||||||
|
|
||||||
## Discussing at sig-cli
|
|
||||||
|
|
||||||
Finally, when a contributor picks up a design proposals and is ready
|
|
||||||
to begin implementing it, we should put it as an item on the next
|
|
||||||
sig-cli agenda. This ensures that everyone in sig-cli community
|
|
||||||
is aware that work is being started.
|
|
||||||
|
|
||||||
## Updating the feature repo
|
|
||||||
|
|
||||||
The kubernetes/feature repo exists to help PMs, folks managing the release,
|
|
||||||
and sig leads coordinate the work going into a given release. This
|
|
||||||
includes items like:
|
|
||||||
|
|
||||||
- ensuring all items slated for the release have been completed, or have
|
|
||||||
been disabled and pushed into the next release.
|
|
||||||
- support level for items has been properly defined - alpha / beta / ga
|
|
||||||
- api changes have been properly vetted by the appropriate parties
|
|
||||||
- user facing documentation has been updated
|
|
||||||
|
|
||||||
**Note:** in most cases this will be done by sig leads on behalf of the
|
|
||||||
other community members.
|
|
||||||
|
|
||||||
## Implementing the feature
|
|
||||||
|
|
||||||
Contributors can begin implementing a feature before any of the above
|
Contributors can begin implementing a feature before any of the above
|
||||||
steps have been completed, but should not send a PR until
|
steps have been completed, but _should not send a PR until
|
||||||
the design proposal has been approved / merged.
|
the [design proposal] has been merged_.
|
||||||
|
|
||||||
Go [here](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md)
|
See the [development guide] for instructions on setting up the
|
||||||
for instructions on setting up the Kubernetes development environment.
|
Kubernetes development environment.
|
||||||
|
|
||||||
|
Implementation PRs should
|
||||||
|
- mention the issue of the associated design proposal,
|
||||||
|
- mention `@kubernetes/sig-cli-pr-reviews`,
|
||||||
|
- __include tests__.
|
||||||
|
|
||||||
**Note:** All new features must have automated tests in the same PR.
|
|
||||||
Small features and flag changes require only unit/integration tests,
|
Small features and flag changes require only unit/integration tests,
|
||||||
while larger changes require both unit/integration tests and e2e tests.
|
while larger changes require both unit/integration tests and e2e tests.
|
||||||
|
|
||||||
If you get stuck or need help, reach out in the Kubernetes slack
|
### Report progress
|
||||||
channel and mention @jess and @adohe.
|
|
||||||
|
|
||||||
## Updating documentation
|
_Leads need your help to ensure that progress is made to
|
||||||
|
get the feature into a [release]._
|
||||||
|
|
||||||
Most new features should include user facing documentation. This is
|
While working on the issue, leave a weekly update on the issue
|
||||||
important to make sure that users are aware of the cool new thing that
|
including:
|
||||||
was added. Depending on the contributor and size of the feature, this
|
|
||||||
|
1. What's finished?
|
||||||
|
2. What's part is being worked on now?
|
||||||
|
3. Anything blocking?
|
||||||
|
|
||||||
|
|
||||||
|
## Documentation
|
||||||
|
|
||||||
|
_Let users know about cool new features by updating user facing documentation._
|
||||||
|
|
||||||
|
Depending on the contributor and size of the feature, this
|
||||||
may be done either by the same contributor that implemented the feature,
|
may be done either by the same contributor that implemented the feature,
|
||||||
or another contributor who is more familiar with the existing docs
|
or another contributor who is more familiar with the existing docs
|
||||||
templates.
|
templates.
|
||||||
|
|
||||||
## Notes on release
|
## Release
|
||||||
|
|
||||||
Several weeks before a Kubernetes release, development enters a stabilization
|
Several weeks before a Kubernetes release, development enters a stabilization
|
||||||
period where no new features are merged. For a feature to be accepted
|
period where no new features are merged. For a feature to be accepted
|
||||||
into a release, it must be fully merged and tested by this time. If
|
into a release, it must be fully merged and tested by this time. If
|
||||||
your feature is not fully complete - including tests - it will have
|
your feature is not fully complete, _including tests_, it will have
|
||||||
to wait until the next release.
|
to wait until the next release.
|
||||||
|
|
||||||
# Escalation
|
## Merge state meanings
|
||||||
|
|
||||||
## What to do if your bug issue is stuck
|
|
||||||
|
|
||||||
If an issue isn't getting any attention and is unresolved, mention
|
|
||||||
@kubernetes/sig-cli-bugs.
|
|
||||||
Highlight the severity and urgency of the issue. For severe issues
|
|
||||||
escalate by contacting sig leads and attending the bi-weekly sig-cli
|
|
||||||
meeting.
|
|
||||||
|
|
||||||
## What to do if your feature request issue is stuck
|
|
||||||
|
|
||||||
If an issue isn't getting any attention and is unresolved, mention
|
|
||||||
@kubernetes/sig-cli-feature-requests.
|
|
||||||
If a particular issue has a high impact for you or your business,
|
|
||||||
make sure this is clear on the bug, and reach out to the sig leads
|
|
||||||
directly. Consider attending the sig meeting to discuss over video
|
|
||||||
conference.
|
|
||||||
|
|
||||||
## What to do if your PR is stuck
|
|
||||||
|
|
||||||
It may happen that your PR seems to be stuck without clear actionable
|
|
||||||
feedback for a week or longer. If your PR is based off a design proposal,
|
|
||||||
the chances of the PR getting stuck for a long period of time
|
|
||||||
are much smaller. However, if it happens do the following:
|
|
||||||
|
|
||||||
- If your PR is stuck for a week or more because it has never gotten any
|
|
||||||
comments, mention @kubernetes/sig-cli-pr-reviews and ask for attention.
|
|
||||||
If this is not successful in a day or two, escalate to sig leads or
|
|
||||||
attend the bi-weekly meeting.
|
|
||||||
- If your PR is stuck for a week or more after it got comments, but
|
|
||||||
the attention has died down. Mention the reviewer and comment with
|
|
||||||
"PTAL" (please take another look). If you are still not able to
|
|
||||||
get any attention after a couple days, escalate to sig leads by
|
|
||||||
mentioning them.
|
|
||||||
|
|
||||||
## What to do if your design docs is stuck
|
|
||||||
|
|
||||||
It may happen that your design doc gets stuck without getting merged
|
|
||||||
or additional feedback. This may happen for a number of reasons. If you believe that your
|
|
||||||
design is important and has been dropped, or it is not moving forward,
|
|
||||||
please add it to the sig cli bi-weekly meeting agenda and email
|
|
||||||
kubernetes-sig-cli@googlegroups.com notifying the community you would
|
|
||||||
like to discuss it at the next meeting.
|
|
||||||
|
|
||||||
Merge state meanings:
|
|
||||||
|
|
||||||
- Merged:
|
- Merged:
|
||||||
- Ready to be implemented.
|
- Ready to be implemented.
|
||||||
|
|
@ -319,10 +209,91 @@ Merge state meanings:
|
||||||
- Not something we plan to implement in the proposed manner.
|
- Not something we plan to implement in the proposed manner.
|
||||||
- Not something we plan to revisit in the next 12 months.
|
- Not something we plan to revisit in the next 12 months.
|
||||||
|
|
||||||
## General escalation instructions if you get stuck
|
## Escalation
|
||||||
|
|
||||||
See the [sig-cli community page](https://github.com/kubernetes/community/tree/master/sig-cli) for points of contact and meeting times:
|
### If your bug issue is stuck
|
||||||
|
|
||||||
- attend the sig-cli bi-weekly meeting
|
If an issue isn't getting any attention and is unresolved, mention
|
||||||
- message one of the sig leads [on slack](https://kubernetes.slack.com/messages/sig-cli/)
|
`@kubernetes/sig-cli-bugs`.
|
||||||
- send an email to the [kubernetes-sig-cli@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-sig-cli)
|
|
||||||
|
Highlight the severity and urgency of the issue. For severe issues
|
||||||
|
escalate by contacting sig [leads] and attending the [meeting].
|
||||||
|
|
||||||
|
### If your feature request issue is stuck
|
||||||
|
|
||||||
|
If an issue isn't getting any attention and is unresolved, mention
|
||||||
|
`@kubernetes/sig-cli-feature-requests`.
|
||||||
|
|
||||||
|
If a particular issue has a high impact for you or your business,
|
||||||
|
make sure this is clear on the bug, and reach out to the sig leads
|
||||||
|
directly. Consider attending the sig meeting to discuss over video
|
||||||
|
conference.
|
||||||
|
|
||||||
|
### If your PR is stuck
|
||||||
|
|
||||||
|
It may happen that your PR seems to be stuck without clear actionable
|
||||||
|
feedback for a week or longer. A PR _associated with a bug or design
|
||||||
|
proposal_ is much less likely to be stuck than a dangling PR.
|
||||||
|
|
||||||
|
However, if it happens do the following:
|
||||||
|
|
||||||
|
- If your PR is stuck for a week or more because it has never gotten any
|
||||||
|
comments, mention `@kubernetes/sig-cli-pr-reviews` and ask for attention.
|
||||||
|
- If your PR is stuck for a week or more _after_ it got comments, but
|
||||||
|
the attention has died down. Mention the reviewer and comment with
|
||||||
|
[`PTAL`].
|
||||||
|
|
||||||
|
If you are still not able to get any attention after a couple days,
|
||||||
|
escalate to sig [leads] by mentioning them.
|
||||||
|
|
||||||
|
### If your design proposal issue is stuck
|
||||||
|
|
||||||
|
It may happen that your design doc gets stuck without getting merged
|
||||||
|
or additional feedback. If you believe that your design is important
|
||||||
|
and has been dropped, or it is not moving forward, please add it to
|
||||||
|
the sig cli bi-weekly meeting [agenda] and mail the [group] saying
|
||||||
|
you'd like to discuss it.
|
||||||
|
|
||||||
|
### General escalation instructions
|
||||||
|
|
||||||
|
See the sig-cli [community page] for points of contact and meeting times:
|
||||||
|
|
||||||
|
- attend the sig-cli [meeting]
|
||||||
|
- message one of the sig leads on [slack]
|
||||||
|
- send an email to the _kubernetes-sig-cli@googlegroups.com_ [group].
|
||||||
|
|
||||||
|
## Use of @mentions
|
||||||
|
|
||||||
|
- `@{any lead}` solicit opinion or advice from [leads].
|
||||||
|
- `@kubernetes/sig-cli-bugs` sig-cli centric bugs.
|
||||||
|
- `@kubernetes/sig-cli-pr-reviews` triggers review of code fix PR.
|
||||||
|
- `@kubernetes/sig-cli-feature-requests` flags a feature request.
|
||||||
|
- `@kubernetes/sig-cli-proposals` flags a design proposal.
|
||||||
|
|
||||||
|
[Kubernetes Basics Tutorial]: https://kubernetes.io/docs/tutorials/kubernetes-basics
|
||||||
|
[PR]: https://help.github.com/articles/creating-a-pull-request
|
||||||
|
[`PTAL`]: https://en.wiktionary.org/wiki/PTAL
|
||||||
|
[agenda]: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit
|
||||||
|
[bug]: #bug-lifecycle
|
||||||
|
[communication]: https://github.com/kubernetes/community/tree/master/sig-cli#communication
|
||||||
|
[community page]: https://github.com/kubernetes/community/tree/master/sig-cli
|
||||||
|
[design proposal]: #design-proposals
|
||||||
|
[design repo]: https://github.com/kubernetes/community/tree/master/contributors/design-proposals/sig-cli
|
||||||
|
[design template]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/sig-cli/template.md
|
||||||
|
[development guide]: https://github.com/kubernetes/community/blob/master/contributors/devel/development.md
|
||||||
|
[existing issue]: #adopt-an-issue
|
||||||
|
[feature repo]: https://github.com/kubernetes/features
|
||||||
|
[feature request]: #feature-requests
|
||||||
|
[feature]: https://github.com/kubernetes/features
|
||||||
|
[group]: https://groups.google.com/forum/#!forum/kubernetes-sig-cli
|
||||||
|
[issue]: https://github.com/kubernetes/kubernetes/issues
|
||||||
|
[kubectl concept docs]: https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/concepts/tools/kubectl
|
||||||
|
[kubectl docs]: https://kubernetes.io/docs/user-guide/kubectl-overview
|
||||||
|
[kubernetes/cmd/kubectl]: https://github.com/kubernetes/kubernetes/tree/master/cmd/kubectl
|
||||||
|
[kubernetes/pkg/kubectl]: https://github.com/kubernetes/kubernetes/tree/master/pkg/kubectl
|
||||||
|
[leads]: https://github.com/kubernetes/community/tree/master/sig-cli#leads
|
||||||
|
[management overview]: https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview
|
||||||
|
[meeting]: https://github.com/kubernetes/community/tree/master/sig-cli#meetings
|
||||||
|
[release]: #release
|
||||||
|
[slack]: https://kubernetes.slack.com/messages/sig-cli
|
||||||
|
[tests]: https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue