summaryrefslogtreecommitdiff
path: root/sig-multicluster
diff options
context:
space:
mode:
authorJonathan MacMillan <dvorak@google.com>2017-10-13 10:30:12 -0700
committerJonathan MacMillan <dvorak@google.com>2017-10-13 10:30:12 -0700
commitdcb675122bbcf3d3e74ef49d16033cee1d260f1c (patch)
tree3bd32b01255882b83fcab6be67ce0b714c2254e2 /sig-multicluster
parente8f6a0f8b4ba8fc3afb6733cc9301b74d35090a1 (diff)
Move one straggler file from sig-federation to sig-multicluster.
Diffstat (limited to 'sig-multicluster')
-rw-r--r--sig-multicluster/CONTRIBUTING.md294
1 files changed, 294 insertions, 0 deletions
diff --git a/sig-multicluster/CONTRIBUTING.md b/sig-multicluster/CONTRIBUTING.md
new file mode 100644
index 00000000..a89780ff
--- /dev/null
+++ b/sig-multicluster/CONTRIBUTING.md
@@ -0,0 +1,294 @@
+# Contributing
+
+The process for contributing code to Kubernetes via the sig-multicluster [community][community page].
+
+## TL;DR
+
+- The sig-multicluster [community page] lists sig-multicluster [leads]
+ and group [meeting] times.
+- Request a feature by making an [issue] and mentioning
+ `@kubernetes/sig-multicluster-feature-requests`.
+- Write a design proposal before starting work on a new feature.
+- Write [tests]!
+
+## Before You Begin
+
+Welcome to the Kubernetes sig-multicluster contributing guide. We are excited
+about the prospect of you joining our [community][community page]!
+
+Please understand that all contributions to Kubernetes require time
+and commitment from the project maintainers to review the ux, software
+design, and code. Mentoring and on-boarding new contributors is done
+in addition to many other responsibilities.
+
+### Understand the big picture
+
+- Complete the [Kubernetes Basics Tutorial].
+
+### Agree to contribution rules
+
+Follow the [CLA signup instructions](../CLA.md).
+
+### Adopt an issue
+
+New contributors can try the following to work on an existing bug or approved design:
+
+- In [slack][slack-messages] (signup [here][slack-signup]),
+ @mention a [lead][leads] and ask if there are any issues you could pick up.
+ We also maintain a list of [multi cluster issues where help is wanted][multicluster_help_wanted_issues].
+ Most of them are not very complex, so that's probably a good starting point.
+ Leads can recommend issues that have enough priority to receive PR review bandwidth.
+- Send an email to the _kubernetes-sig-multicluster@googlegroups.com_ [group]
+
+ > Subject: New sig-multicluster contributor _${yourName}_
+ >
+ > Body: Hello, my name is _${yourName}_. I would like to get involved in
+ > contributing to the Kubernetes project. I have read all of the
+ > user documentation listed on the community contributing page.
+ > What should I do next to get started?
+
+- Attend a sig-multicluster [meeting] and introduce yourself as looking to get started.
+
+### Bug lifecycle
+
+#### Filing a bug
+
+1. An [issue] is filed that
+ - includes steps to reproduce the issue including client / server version,
+ - mentions `@kubernetes/sig-multicluster-bugs`.
+
+#### Sending a fix
+
+2. A [PR] fixing the issue is implemented that
+ - __includes unit and test-cmd tests__,
+ - incorporates review feedback,
+ - description includes `Closes #<Issue Number>` or `Fixes #<Issue Number>`,
+ - description or comment @mentions `@kubernetes/sig-multicluster-pr-reviews`.
+3. Fix appears in the next Kubernetes release!
+
+## Feature requests
+
+__New contributors:__ Please start by adopting an [existing issue].
+
+A feature request is an [issue] mentioning `@kubernetes/sig-multicluster-feature-requests`.
+
+To encourage readership, the issue description should _concisely_ (2-4 sentence) describe
+the problem that the feature addresses.
+
+### Feature lifecycle
+
+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 names and user experience.
+
+To minimize wasted work and improve communication across efforts,
+the user experience and software design must be agreed upon before
+any PRs are sent for code review.
+
+1. Identify a problem by filing an [issue] (mention `@kubernetes/sig-multicluster-feature-requests`).
+2. Submit a [design proposal] and get it approved by a lead.
+3. Announce the proposal as an [agenda] item for the sig-multicluster [meeting].
+ - Ensures awareness and feedback.
+ - Should be included in meeting notes sent to the sig-multicluster [group].
+4. _Merge_ the proposal PR after approval and announcement.
+5. A [lead][leads] adds the associated feature to the [feature repo], ensuring that
+ - release-related decisions are properly made and communicated,
+ - API changes are vetted,
+ - testing is completed,
+ - docs are completed,
+ - feature is designated _alpha_, _beta_ or _GA_.
+6. Implement the code per discussion in [bug lifecycle][bug].
+7. Update docs.
+8. Wait for your feature to appear in the next Kubernetes release!
+
+
+## Design Proposals
+
+__New contributors:__ Please start by adopting an [existing issue].
+
+A design proposal is a single markdown document in the [design repo]
+that follows the [design template].
+
+To make one,
+- 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-multicluster-proposals` in the description.
+- Mention the related [feature request].
+
+Expect feedback from 2-3 different sig-multicluster community members.
+
+Incorporate feedback and comment [`PTAL`].
+
+Once a [lead][leads] has agreed (via review commentary) that design
+and code review resources can be allocated to tackle the proposal, the
+details of the user experience and design should be discussed in the
+community.
+
+This step is _important_; it prevents code churn and thrashing around
+issues like flag names, command names, etc.
+
+It is normal for sig-multicluster community members to push back on feature
+proposals. sig-multicluster development and review resources are extremely
+constrained. Community members are free to say
+
+- No, not this release (or year).
+- This is desirable but we need help on these other existing issues before tackling this.
+- No, this problem should be solved in another way.
+
+The proposal can be merged into the [design repo] after [lead][leads]
+approval and discussion as a meeting [agenda] item.
+
+Then coding can begin.
+
+## Implementation
+
+Contributors can begin implementing a feature before any of the above
+steps have been completed, but _should not send a PR until
+the [design proposal] has been merged_.
+
+See the [development guide] for instructions on setting up the
+Kubernetes development environment.
+
+Implementation PRs should
+- mention the issue of the associated design proposal,
+- mention `@kubernetes/sig-multicluster-pr-reviews`,
+- __include tests__.
+
+Small features and flag changes require only unit/integration tests,
+while larger changes require both unit/integration tests and e2e tests.
+
+### Report progress
+
+_Leads need your help to ensure that progress is made to
+get the feature into a [release]._
+
+While working on the issue, leave a weekly update on the issue
+including:
+
+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,
+or another contributor who is more familiar with the existing docs
+templates.
+
+## Release
+
+Several weeks before a Kubernetes release, development enters a stabilization
+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
+your feature is not fully complete, _including tests_, it will have
+to wait until the next release.
+
+## Merge state meanings
+
+- Merged:
+ - Ready to be implemented.
+- Unmerged:
+ - Experience and design still being worked out.
+ - Not a high priority issue but may implement in the future: revisit
+ in 6 months.
+ - Unintentionally dropped.
+- Closed:
+ - Not something we plan to implement in the proposed manner.
+ - Not something we plan to revisit in the next 12 months.
+
+## Escalation
+
+### If your bug issue is stuck
+
+If an issue isn't getting any attention and is unresolved, mention
+`@kubernetes/sig-multicluster-bugs`.
+
+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-multicluster-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-multicluster-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 multicluster bi-weekly meeting [agenda] and mail the [group] saying
+you'd like to discuss it.
+
+### General escalation instructions
+
+See the sig-multicluster [community page] for points of contact and meeting times:
+
+- attend the sig-multicluster [meeting]
+- message one of the sig leads on [slack][slack-messages] (signup [here][slack-signup])
+- send an email to the _kubernetes-sig-multicluster@googlegroups.com_ [group].
+
+## Use of [@mentions]
+
+- `@{any lead}` solicit opinion or advice from [leads].
+- `@kubernetes/sig-multicluster-bugs` sig-multicluster centric bugs.
+- `@kubernetes/sig-multicluster-pr-reviews` triggers review of code fix PR.
+- `@kubernetes/sig-multicluster-feature-requests` flags a feature request.
+- `@kubernetes/sig-multicluster-proposals` flags a design proposal.
+
+[@mentions]: https://help.github.com/articles/basic-writing-and-formatting-syntax/#mentioning-users-and-teams
+[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/18mk62nOXE_MCSSnb4yJD_8UadtzJrYyJxFwbrgabHe8/edit
+[bug]: #bug-lifecycle
+[community page]: https://github.com/kubernetes/community/tree/master/sig-multicluster
+[design proposal]: #design-proposals
+[design repo]: https://github.com/kubernetes/community/tree/master/contributors/design-proposals/sig-multicluster
+[design template]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/sig-multicluster/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-multicluster
+[issue]: https://github.com/kubernetes/kubernetes/issues
+[multicluster_help_wanted_issues]: https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Ahelp-wanted%20label%3Asig%2Fmulticluster
+[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-multicluster#leads
+[management overview]: https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview
+[meeting]: https://github.com/kubernetes/community/tree/master/sig-multicluster#meetings
+[release]: #release
+[slack-messages]: https://kubernetes.slack.com/messages/sig-multicluster
+[slack-signup]: http://slack.k8s.io/
+[tests]: https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md