Merge branch 'master' of github.com:kubernetes/community

77 files changed, 1522 insertions, 975 deletions

diff --git a/contributors/design-proposals/apps/controller_history.md b/contributors/design-proposals/apps/controller_history.md
index d7140bea..e9384379 100644
--- a/contributors/design-proposals/apps/controller_history.md
+++ b/contributors/design-proposals/apps/controller_history.md
@@ -362,7 +362,7 @@ they have a nil revision. That is, without respect to the method of
 [version tracking](#version-tracking) used, the generated Objects may be 
 treated as if they have a version that corresponds to no revision, and the 
 controller may proceed to 
-[reconcile their state](target-object-state-reconciliation) as appropriate to 
+[reconcile their state](#target-object-state-reconciliation) as appropriate to 
 the internal implementation.
 
 ## Kubectl
@@ -442,7 +442,7 @@ create a `.Named` ControllerRevision via the API Server using a
 conflict, the method returns false.
 
 ### Unique Name Generation
-We can use our [hash function](#hashsing) and 
+We can use our [hash function](#hashing) and 
 [collision resolution](#collision-resolution) scheme to generate a system 
 wide unique identifier for an Object based on a deterministic non-unique prefix 
 and a serialized representation of the Object. Kubernetes Object's `.Name` 
diff --git a/contributors/design-proposals/apps/job.md b/contributors/design-proposals/apps/job.md
index 2094b125..5415ad76 100644
--- a/contributors/design-proposals/apps/job.md
+++ b/contributors/design-proposals/apps/job.md
@@ -204,5 +204,5 @@ Below are the possible future extensions to the Job controller:
   [this comment](https://github.com/kubernetes/kubernetes/issues/1624#issuecomment-97622142))
 * Be able to inspect Pods running a Job, especially after a Job has finished, e.g.
   by providing pointers to Pods in the JobStatus ([see comment](https://github.com/kubernetes/kubernetes/pull/11746/files#r37142628)).
-* help users avoid non-unique label selectors ([see this proposal](../../docs/design/selector-generation.md))
+* help users avoid non-unique label selectors ([see this proposal](selector-generation.md))
 
diff --git a/contributors/design-proposals/architecture/declarative-application-management.md b/contributors/design-proposals/architecture/declarative-application-management.md
index f1419200..d307a617 100644
--- a/contributors/design-proposals/architecture/declarative-application-management.md
+++ b/contributors/design-proposals/architecture/declarative-application-management.md
@@ -322,13 +322,13 @@ Benefits of these approaches:
 
 An area where more investigation is needed is explicit inline parameter substitution, which, while overused and should be rendered unnecessary by the capabilities described above, is [frequently requested](https://stackoverflow.com/questions/44832085/passing-variables-to-args-field-in-a-yaml-file-kubernetes) and has been reinvented many times by the community.
 
-A [simple parameterization approach derived from Openshift’s design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md) was approved because it was constrained in functionality and solved other problems (e.g., instantiation of resource variants by other controllers, [project templates in Openshift](https://github.com/openshift/training/blob/master/content/default-project-template.yaml)). That proposal explains some of the reasoning behind the design tradeoffs, as well as the [use cases](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md#use-cases). Work started, but was abandoned, though there is an independent [client-based implementation](https://github.com/InQuicker/ktmpl). However, the Template resource wrapped the resource specifications in another object, which is suboptimal, since transformations would then need to be able to deal with standalone resources, Lists of resources, and Templates, or would need to be applied post-instantiation, and it couldn’t be represented using multiple files, as users prefer.
+A [simple parameterization approach derived from Openshift’s design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/apps/OBSOLETE_templates.md) was approved because it was constrained in functionality and solved other problems (e.g., instantiation of resource variants by other controllers, [project templates in Openshift](https://docs.openshift.com/container-platform/3.5/dev_guide/templates.html)). That proposal explains some of the reasoning behind the design tradeoffs, as well as the [use cases](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/apps/OBSOLETE_templates.md#use-cases). Work started, but was abandoned, though there is an independent [client-based implementation](https://github.com/InQuicker/ktmpl). However, the Template resource wrapped the resource specifications in another object, which is suboptimal, since transformations would then need to be able to deal with standalone resources, Lists of resources, and Templates, or would need to be applied post-instantiation, and it couldn’t be represented using multiple files, as users prefer.
 
 What is more problematic is that our client libraries, schema validators, yaml/json parsers/decoders, initializers, and protobuf encodings all require that all specified fields have valid values, so parameters cannot currently be left in non-string (e.g., int, bool) fields in actual resources. Additionally, the API server requires at least complete/final resource names to be specified, and strategic merge also requires all merge keys to be specified. Therefore, some amount of pre-instantiation (though not necessarily client-side) transformation is necessary to create valid resources, and we may want to explicitly store the output, or the fields should just contain the default values initially. Parameterized fields could be automatically converted to patches to produce valid resources. Such a transformation could be made reversible, unlike traditional substitution approaches, since the patches could be preserved (e.g., using annotations). The Template API supported the declaration of parameter names, display names, descriptions, default values, required/optional, and types (string, int, bool, base64), and both string and raw json substitutions. If we were to update that specification, we could use the same mechanism for both parameter validation and ConfigMap validation, so that the same mechanism could be used for env substitution and substitution of values of other fields. As mentioned in the [env validation issue](https://github.com/kubernetes/kubernetes/issues/4210#issuecomment-305555589), we should consider a subset of [JSON schema](http://json-schema.org/example1.html), which we’ll probably use for CRD. The only [unsupported attribute](https://tools.ietf.org/html/draft-wright-json-schema-validation-00) appears to be the display name, which is non-critical. [Base64 could be represented using media](http://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.5.3.2). That could be useful as a common parameter schema to facilitate parameter discovery and documentation that is independent of the substitution syntax and mechanism ([example from Deployment Manager](https://github.com/GoogleCloudPlatform/deploymentmanager-samples/blob/master/templates/replicated_service.py.schema)).
 
 Without parameters how would we support a click-to-deploy experience? People who are kicking the tires, have undemanding use cases, are learning, etc. are unlikely to know what customization they want to perform initially, if they even need any. The main information users need to provide is the name prefix they want to apply. Otherwise, choosing among a few alternatives would suit their needs better than parameters. The overlay approach should support that pretty well. Beyond that, I suggest kicking users over to a Kubernetes-specific configuration wizard or schema-aware IDE, and/or support a fork workflow.
 
-The other application-definition [use cases mentioned in the Template proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md#use-cases) are achievable without parameterization, as well.
+The other application-definition [use cases mentioned in the Template proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/apps/OBSOLETE_templates.md#use-cases) are achievable without parameterization, as well.
 
 #### What about application configuration generation?
 
@@ -384,7 +384,7 @@ Consider more automation, such as autoscaling, self-configuration, etc. to reduc
 
 #### What about providing an intentionally restrictive simplified, tailored developer experience to streamline a specific use case, environment, workflow, etc.?
 
-This is essentially a [DIY PaaS](https://kubernetes.io/blog/2017/02/caas-the-foundation-for-next-gen-paas/). Write a configuration generator, either client-side or using CRDs ([example](https://github.com/pearsontechnology/environment-operator/blob/dev/User_Guide.md)). The effort involved to document the format, validate it, test it, etc. is similar to building a new API, but I could imagine someone eventually building a SDK to make that easier.
+This is essentially a [DIY PaaS](https://kubernetes.io/blog/2017/02/caas-the-foundation-for-next-gen-paas/). Write a configuration generator, either client-side or using CRDs ([example](https://github.com/pearsontechnology/environment-operator/blob/dev/docs/User_Guide.md)). The effort involved to document the format, validate it, test it, etc. is similar to building a new API, but I could imagine someone eventually building a SDK to make that easier.
 
 #### What about more sophisticated deployment orchestration?
 
@@ -392,4 +392,4 @@ Deployment pipelines, [canary deployments](https://groups.google.com/forum/#!top
 
 #### What about UI wizards, IDE integration, application frameworks, etc.?
 
-Representing configuration using the literal API types should facilitate programmatic manipulation of the configuration via user-friendly tools, such as UI wizards (e.g., [dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#deploying-containerized-applications), [Yipee.io](https://yipee.io/), and many CD tools, such as [Distelli](https://www.distelli.com/docs/k8s/add-container-to-a-project/)) and IDEs (e.g., [VSCode](https://www.youtube.com/watch?v=QfqS9OSVWGs), [IntelliJ](https://github.com/tinselspoon/intellij-kubernetes)), as well as configuration generation and manipulation by application frameworks (e.g., [Spring Cloud](https://github.com/fabric8io/spring-cloud-kubernetes)).
+Representing configuration using the literal API types should facilitate programmatic manipulation of the configuration via user-friendly tools, such as UI wizards (e.g., [dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#deploying-containerized-applications) and many CD tools, such as [Puppet Pipelines](https://puppet.com/docs/pipelines)) and IDEs (e.g., [VSCode](https://www.youtube.com/watch?v=QfqS9OSVWGs), [IntelliJ](https://github.com/tinselspoon/intellij-kubernetes)), as well as configuration generation and manipulation by application frameworks (e.g., [Spring Cloud](https://github.com/fabric8io/spring-cloud-kubernetes)).
diff --git a/contributors/design-proposals/aws/OWNERS b/contributors/design-proposals/aws/OWNERS
index cc03b55d..b035a798 100644
--- a/contributors/design-proposals/aws/OWNERS
+++ b/contributors/design-proposals/aws/OWNERS
@@ -1,8 +1,8 @@
 # See the OWNERS docs at https://go.k8s.io/owners
 
 reviewers:
-  - sig-aws-leads
+  - provider-aws
 approvers:
-  - sig-aws-leads
+  - provider-aws
 labels:
   - sig/aws
diff --git a/contributors/design-proposals/gcp/OWNERS b/contributors/design-proposals/gcp/OWNERS
index 4ff966b4..5edab0a0 100644
--- a/contributors/design-proposals/gcp/OWNERS
+++ b/contributors/design-proposals/gcp/OWNERS
@@ -1,8 +1,8 @@
 # See the OWNERS docs at https://go.k8s.io/owners
 
 reviewers:
-  - sig-gcp-leads
+  - provider-gcp
 approvers:
-  - sig-gcp-leads
+  - provider-gcp
 labels:
   - sig/gcp
diff --git a/contributors/design-proposals/node/troubleshoot-running-pods.md b/contributors/design-proposals/node/troubleshoot-running-pods.md
index 3fcc0223..d6895c28 100644
--- a/contributors/design-proposals/node/troubleshoot-running-pods.md
+++ b/contributors/design-proposals/node/troubleshoot-running-pods.md
@@ -1,703 +1,8 @@
 # Troubleshoot Running Pods
 
-*   Status: Implementing
-*   Version: Alpha
+*   Status: Superseded
+*   Version: N/A
 *   Implementation Owner: @verb
 
-This proposal seeks to add first class support for troubleshooting by creating a
-mechanism to execute a shell or other troubleshooting tools inside a running pod
-without requiring that the associated container images include such tools.
-
-## Motivation
-
-### Development
-
-Many developers of native Kubernetes applications wish to treat Kubernetes as an
-execution platform for custom binaries produced by a build system. These users
-can forgo the scripted OS install of traditional Dockerfiles and instead `COPY`
-the output of their build system into a container image built `FROM scratch` or
-a
-[distroless container image](https://github.com/GoogleCloudPlatform/distroless).
-This confers several advantages:
-
-1.  **Minimal images** lower operational burden and reduce attack vectors.
-1.  **Immutable images** improve correctness and reliability.
-1.  **Smaller image size** reduces resource usage and speeds deployments.
-
-The disadvantage of using containers built `FROM scratch` is the lack of system
-binaries provided by an Operating System image makes it difficult to
-troubleshoot running containers. Kubernetes should enable one to troubleshoot
-pods regardless of the contents of the container images.
-
-### Operations and Support
-
-As Kubernetes gains in popularity, it's becoming the case that a person
-troubleshooting an application is not necessarily the person who built it.
-Operations staff and Support organizations want the ability to attach a "known
-good" or automated debugging environment to a pod.
-
-## Requirements
-
-A solution to troubleshoot arbitrary container images MUST:
-
-*   troubleshoot arbitrary running containers with minimal prior configuration
-*   allow access to namespaces and the file systems of individual containers
-*   fetch troubleshooting utilities at debug time rather than at the time of pod
-    creation
-*   be compatible with admission controllers and audit logging
-*   allow discovery of current debugging status
-*   support arbitrary runtimes via the CRI (possibly with reduced feature set)
-*   require no administrative access to the node
-*   have an excellent user experience (i.e. should be a feature of the platform
-    rather than config-time trickery)
-*   have no _inherent_ side effects to the running container image
-*   v1.Container must be available for inspection by admission controllers
-
-## Feature Summary
-
-Any new debugging functionality will require training users. We can ease the
-transition by building on an existing usage pattern. We will create a new
-command, `kubectl debug`, which parallels an existing command, `kubectl exec`.
-Whereas `kubectl exec` runs a _process_ in a _container_, `kubectl debug` will
-be similar but run a _container_ in a _pod_.
-
-A container created by `kubectl debug` is a _Debug Container_. Unlike `kubectl
-exec`, Debug Containers have status that is reported in `PodStatus` and
-displayed by `kubectl describe pod`.
-
-For example, the following command would attach to a newly created container in
-a pod:
-
-```
-kubectl debug -c debug-shell --image=debian target-pod -- bash
-```
-
-It would be reasonable for Kubernetes to provide a default container name and
-image, making the minimal possible debug command:
-
-```
-kubectl debug target-pod
-```
-
-This creates an interactive shell in a pod which can examine and signal other
-processes in the pod. It has access to the same network and IPC as processes in
-the pod. When [process namespace sharing](https://features.k8s.io/495) is
-enabled, it can access the filesystem of other processes by `/proc/$PID/root`.
-Debug Containers can enter arbitrary namespaces of another visible container via
-`nsenter` when run with `CAP_SYS_ADMIN`.
-
-_Please see the User Stories section for additional examples and Alternatives
-Considered for the considerable list of other solutions we considered._
-
-## Implementation Details
-
-From the perspective of the user, there's a new command, `kubectl debug`, that
-creates a Debug Container and attaches to its console. We believe a new command
-will be less confusing for users than overloading `kubectl exec` with a new
-concept. Users give Debug Containers a name (e.g. "debug" or "shell") which can
-subsequently be used to reattach and is reported by `kubectl describe`.
-
-### Kubernetes API Changes
-
-This will be implemented in the Core API to avoid new dependencies in the
-kubelet. The user-level concept of a _Debug Container_ implemented with the
-API-level concept of an _Ephemeral Container_. The API doesn't require an
-Ephemeral Container to be used as a Debug Container. It's intended as a general
-purpose construct for running a short-lived process in a pod.
-
-#### Pod Changes
-
-Ephemeral Containers are represented in `PodSpec` and `PodStatus`:
-
-```
-type PodSpec struct {
-  ...
-  // List of user-initiated ephemeral containers to run in this pod.
-  // This field is alpha-level and is only honored by servers that enable the EphemeralContainers feature.
-  // +optional
-  EphemeralContainers []EphemeralContainer `json:"ephemeralContainers,omitempty" protobuf:"bytes,29,opt,name=ephemeralContainers"`
-}
-
-type PodStatus struct {
-  ...
-  // Status for any Ephemeral Containers that running in this pod.
-  // This field is alpha-level and is only honored by servers that enable the EphemeralContainers feature.
-  // +optional
-  EphemeralContainerStatuses []ContainerStatus `json:"ephemeralContainerStatuses,omitempty" protobuf:"bytes,12,rep,name=ephemeralContainerStatuses"`
-}
-```
-
-`EphemeralContainerStatuses` resembles the existing `ContainerStatuses` and
-`InitContainerStatuses`, but `EphemeralContainers` introduces a new type:
-
-```
-// An EphemeralContainer is a container which runs temporarily in a pod for human-initiated actions
-// such as troubleshooting. This is an alpha feature enabled by the EphemeralContainers feature flag.
-type EphemeralContainer struct {
-  // Spec describes the Ephemeral Container to be created.
-  Spec Container `json:"spec,omitempty" protobuf:"bytes,1,opt,name=spec"`
-
-  // If set, the name of the container from PodSpec that this ephemeral container targets.
-  // The ephemeral container will be run in the namespaces (IPC, PID, etc) of this container.
-  // If not set then the ephemeral container is run in whatever namespaces are shared
-  // for the pod.
-  // +optional
-  TargetContainerName string `json:"targetContainerName,omitempty" protobuf:"bytes,2,opt,name=targetContainerName"`
-}
-```
-
-Much of the utility of Ephemeral Containers comes from the ability to run a
-container within the PID namespace of another container. `TargetContainerName`
-allows targeting a container that doesn't share its PID namespace with the rest
-of the pod. We must modify the CRI to enable this functionality (see below).
-
-##### Alternative Considered: Omitting TargetContainerName
-
-It would be simpler for the API, kubelet and kubectl if `EphemeralContainers`
-was a `[]Container`, but as isolated PID namespaces will be the default for some
-time, being able to target a container will provide a better user experience.
-
-#### Updates
-
-Most fields of `Pod.Spec` are immutable once created. There is a short whitelist
-of fields which may be updated, and we could extend this to include
-`EphemeralContainers`. The ability to add new containers is a large change for
-Pod, however, and we'd like to begin conservatively by enforcing the following
-best practices:
-
-1.  Ephemeral Containers lack guarantees for resources or execution, and they
-    will never be automatically restarted. To avoid pods that depend on
-    Ephemeral Containers, we allow their addition only in pod updates and
-    disallow them during pod create.
-1.  Some fields of `v1.Container` imply a fundamental role in a pod. We will
-    disallow the following fields in Ephemeral Containers: `resources`, `ports`,
-    `livenessProbe`, `readinessProbe`, and `lifecycle.`
-1.  Cluster administrators may want to restrict access to Ephemeral Containers
-    independent of other pod updates.
-
-To enforce these restrictions and new permissions, we will introduce a new Pod
-subresource, `/ephemeralcontainers`. `EphemeralContainers` can only be modified
-via this subresource. `EphemeralContainerStatuses` is updated with everything
-else in `Pod.Status` via `/status`.
-
-To create a new Ephemeral Container, one appends a new `EphemeralContainer` with
-the desired `v1.Container` as `Spec` in `Pod.Spec.EphemeralContainers` and
-`PUT`s the pod to `/ephemeralcontainers`.
-
-The subresources `attach`, `exec`, `log`, and `portforward` are available for
-Ephemeral Containers and will be forwarded by the apiserver. This means `kubectl
-attach`, `kubelet exec`, `kubectl log`, and `kubectl port-forward` will work for
-Ephemeral Containers.
-
-Once the pod is updated, the kubelet worker watching this pod will launch the
-Ephemeral Container and update its status. The client is expected to watch for
-the creation of the container status and then attach to the console of a debug
-container using the existing attach endpoint,
-`/api/v1/namespaces/$NS/pods/$POD_NAME/attach`. Note that any output of the new
-container occurring between its creation and attach will not be replayed, but it
-can be viewed using `kubectl log`.
-
-##### Alternative Considered: Standard Pod Updates
-
-It would simplify initial implementation if we updated the pod spec via the
-normal means, and switched to a new update subresource if required at a future
-date. It's easier to begin with a too-restrictive policy than a too-permissive
-one on which users come to rely, and we expect to be able to remove the
-`/ephemeralcontainers` subresource prior to exiting alpha should it prove
-unnecessary.
-
-### Container Runtime Interface (CRI) changes
-
-The CRI requires no changes for basic functionality, but it will need to be
-updated to support container namespace targeting, as described in the
-[Shared PID Namespace Proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-pid-namespace.md#targeting-a-specific-containers-namespace).
-
-### Creating Debug Containers
-
-To create a debug container, kubectl will take the following steps:
-
-1.  `kubectl` constructs an `EphemeralContainer` based on command line arguments
-    and appends it to `Pod.Spec.EphemeralContainers`. It `PUT`s the modified pod
-    to the pod's `/ephemeralcontainers`.
-1.  The apiserver discards changes other than additions to
-    `Pod.Spec.EphemeralContainers` and validates the pod update.
-    1.  Pod validation fails if container spec contains fields disallowed for
-        Ephemeral Containers or the same name as a container in the spec or
-        `EphemeralContainers`.
-    1.  API resource versioning resolves update races.
-1.  The kubelet's pod watcher notices the update and triggers a `syncPod()`.
-    During the sync, the kubelet calls `kuberuntime.StartEphemeralContainer()`
-    for any new Ephemeral Container.
-    1.  `StartEphemeralContainer()` uses the existing `startContainer()` to
-        start the Ephemeral Container.
-    1.  After initial creation, future invocations of `syncPod()` will publish
-        its ContainerStatus but otherwise ignore the Ephemeral Container. It
-        will exist for the life of the pod sandbox or it exits. In no event will
-        it be restarted.
-1.  `syncPod()` finishes a regular sync, publishing an updated PodStatus (which
-    includes the new `EphemeralContainer`) by its normal, existing means.
-1.  The client performs an attach to the debug container's console.
-
-There are no limits on the number of Debug Containers that can be created in a
-pod, but exceeding a pod's resource allocation may cause the pod to be evicted.
-
-### Restarting and Reattaching Debug Containers
-
-Debug Containers will not be restarted.
-
-We want to be more user friendly by allowing re-use of the name of an exited
-debug container, but this will be left for a future improvement.
-
-One can reattach to a Debug Container using `kubectl attach`. When supported by
-a runtime, multiple clients can attach to a single debug container and share the
-terminal. This is supported by Docker.
-
-### Killing Debug Containers
-
-Debug containers will not be killed automatically unless the pod is destroyed.
-Debug Containers will stop when their command exits, such as exiting a shell.
-Unlike `kubectl exec`, processes in Debug Containers will not receive an EOF if
-their connection is interrupted.
-
-A future improvement to Ephemeral Containers could allow killing Debug
-Containers when they're removed the `EphemeralContainers`, but it's not clear
-that we want to allow this. Removing an Ephemeral Container spec makes it
-unavailable for future authorization decisions (e.g. whether to authorize exec
-in a pod that had a privileged Ephemeral Container).
-
-### Security Considerations
-
-Debug Containers have no additional privileges above what is available to any
-`v1.Container`. It's the equivalent of configuring an shell container in a pod
-spec except that it is created on demand.
-
-Admission plugins must be updated to guard `/ephemeralcontainers`. They should
-apply the same container image and security policy as for regular containers.
-
-### Additional Consideration
-
-1.  Debug Containers are intended for interactive use and always have TTY and
-    Stdin enabled.
-1.  There are no guaranteed resources for ad-hoc troubleshooting. If
-    troubleshooting causes a pod to exceed its resource limit it may be evicted.
-1.  There's an output stream race inherent to creating then attaching a
-    container which causes output generated between the start and attach to go
-    to the log rather than the client. This is not specific to Ephemeral
-    Containers and exists because Kubernetes has no mechanism to attach a
-    container prior to starting it. This larger issue will not be addressed by
-    Ephemeral Containers, but Ephemeral Containers would benefit from future
-    improvements or work arounds.
-1.  Ephemeral Containers should not be used to build services, which we've
-    attempted to reflect in the API.
-
-## Implementation Plan
-
-### 1.12: Initial Alpha Release
-
-We're targeting an alpha release in Kubernetes 1.12 that includes the following
-basic functionality:
-
-1.  Approval for basic core API changes to Pod
-1.  Basic support in the kubelet for creating Ephemeral Containers
-
-Functionality out of scope for 1.12:
-
-*   Killing running Ephemeral Containers by removing them from the Pod Spec.
-*   Updating `pod.Spec.EphemeralContainers` when containers are garbage
-    collected.
-*   `kubectl` commands for creating Ephemeral Containers
-
-Functionality will be hidden behind an alpha feature flag and disabled by
-default.
-
-## Appendices
-
-We've researched many options over the life of this proposal. These Appendices
-are included as optional reference material. It's not necessary to read this
-material in order to understand the proposal in its current form.
-
-### Appendix 1: User Stories
-
-These user stories are intended to give examples how this proposal addresses the
-above requirements.
-
-#### Operations
-
-Jonas runs a service "neato" that consists of a statically compiled Go binary
-running in a minimal container image. One of the its pods is suddenly having
-trouble connecting to an internal service. Being in operations, Jonas wants to
-be able to inspect the running pod without restarting it, but he doesn't
-necessarily need to enter the container itself. He wants to:
-
-1.  Inspect the filesystem of target container
-1.  Execute debugging utilities not included in the container image
-1.  Initiate network requests from the pod network namespace
-
-This is achieved by running a new "debug" container in the pod namespaces. His
-troubleshooting session might resemble:
-
-```
-% kubectl debug -it -m debian neato-5thn0 -- bash
-root@debug-image:~# ps x
-  PID TTY      STAT   TIME COMMAND
-    1 ?        Ss     0:00 /pause
-   13 ?        Ss     0:00 bash
-   26 ?        Ss+    0:00 /neato
-  107 ?        R+     0:00 ps x
-root@debug-image:~# cat /proc/26/root/etc/resolv.conf
-search default.svc.cluster.local svc.cluster.local cluster.local
-nameserver 10.155.240.10
-options ndots:5
-root@debug-image:~# dig @10.155.240.10 neato.svc.cluster.local.
-
-; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @10.155.240.10 neato.svc.cluster.local.
-; (1 server found)
-;; global options: +cmd
-;; connection timed out; no servers could be reached
-```
-
-Thus Jonas discovers that the cluster's DNS service isn't responding.
-
-#### Debugging
-
-Thurston is debugging a tricky issue that's difficult to reproduce. He can't
-reproduce the issue with the debug build, so he attaches a debug container to
-one of the pods exhibiting the problem:
-
-```
-% kubectl debug -it --image=gcr.io/neato/debugger neato-5x9k3 -- sh
-Defaulting container name to debug.
-/ # ps x
-PID   USER     TIME   COMMAND
-    1 root       0:00 /pause
-   13 root       0:00 /neato
-   26 root       0:00 sh
-   32 root       0:00 ps x
-/ # gdb -p 13
-...
-```
-
-He discovers that he needs access to the actual container, which he can achieve
-by installing busybox into the target container:
-
-```
-root@debug-image:~# cp /bin/busybox /proc/13/root
-root@debug-image:~# nsenter -t 13 -m -u -p -n -r /busybox sh
-
-
-BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1) built-in shell (ash)
-Enter 'help' for a list of built-in commands.
-
-/ # ls -l /neato
--rwxr-xr-x    2 0        0           746888 May  4  2016 /neato
-```
-
-Note that running the commands referenced above require `CAP_SYS_ADMIN` and
-`CAP_SYS_PTRACE`.
-
-#### Automation
-
-Ginger is a security engineer tasked with running security audits across all of
-her company's running containers. Even though his company has no standard base
-image, she's able to audit all containers using:
-
-```
-% for pod in $(kubectl get -o name pod); do
-    kubectl debug -m gcr.io/neato/security-audit -p $pod /security-audit.sh
-  done
-```
-
-#### Technical Support
-
-Roy's team provides support for his company's multi-tenant cluster. He can
-access the Kubernetes API (as a viewer) on behalf of the users he's supporting,
-but he does not have administrative access to nodes or a say in how the
-application image is constructed. When someone asks for help, Roy's first step
-is to run his team's autodiagnose script:
-
-```
-% kubectl debug --image=k8s.gcr.io/autodiagnose nginx-pod-1234
-```
-
-### Appendix 2: Requirements Analysis
-
-Many people have proposed alternate solutions to this problem. This section
-discusses how the proposed solution meets all of the stated requirements and is
-intended to contrast the alternatives listed below.
-
-**Troubleshoot arbitrary running containers with minimal prior configuration.**
-This solution requires no prior configuration.
-
-**Access to namespaces and the file systems of individual containers.** This
-solution runs a container in the shared pod namespaces (e.g. network) and will
-attach to the PID namespace of a target container when not shared with the
-entire pod. It relies on the behavior of `/proc/<pid>/root` to provide access to
-filesystems of individual containers.
-
-**Fetch troubleshooting utilities at debug time**. This solution uses normal
-container image distribution mechanisms to fetch images when the debug command
-is run.
-
-**Respect admission restrictions.** Requests from kubectl are proxied through
-the apiserver and so are available to existing
-[admission controllers](https://kubernetes.io/docs/admin/admission-controllers/).
-Plugins already exist to intercept `exec` and `attach` calls, but extending this
-to support `debug` has not yet been scoped.
-
-**Allow introspection of pod state using existing tools**. The list of
-`EphemeralContainerStatuses` is never truncated. If a debug container has run in
-this pod it will appear here.
-
-**Support arbitrary runtimes via the CRI**. This proposal is implemented
-entirely in the kubelet runtime manager and requires no changes in the
-individual runtimes.
-
-**Have an excellent user experience**. This solution is conceptually
-straightforward and surfaced in a single `kubectl` command that "runs a thing in
-a pod". Debug tools are distributed by container image, which is already well
-understood by users. There is no automatic copying of files or hidden paths.
-
-By using container images, users are empowered to create custom debug images.
-Available images can be restricted by admission policy. Some examples of
-possible debug images:
-
-*   A script that automatically gathers a debugging snapshot and uploads it to a
-    cloud storage bucket before killing the pod.
-*   An image with a shell modified to log every statement to an audit API.
-
-**Require no direct access to the node.** This solution uses the standard
-streaming API.
-
-**Have no inherent side effects to the running container image.** The target pod
-is not modified by default, but resources used by the debug container will be
-billed to the pod's cgroup, which means it could be evicted. A future
-improvement could be to decrease the likelihood of eviction when there's an
-active debug container.
-
-### Appendix 3: Alternatives Considered
-
-#### Container Spec in PodStatus
-
-Originally there was a desire to keep the pod spec immutable, so we explored
-modifying only the pod status. An `EphemeralContainer` would contain a Spec, a
-Status and a Target:
-
-```
-// EphemeralContainer describes a container to attach to a running pod for troubleshooting.
-type EphemeralContainer struct {
-        metav1.TypeMeta `json:",inline"`
-
-        // Spec describes the Ephemeral Container to be created.
-        Spec *Container `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
-
-        // Most recently observed status of the container.
-        // This data may not be up to date.
-        // Populated by the system.
-        // Read-only.
-        // +optional
-        Status *ContainerStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
-
-        // If set, the name of the container from PodSpec that this ephemeral container targets.
-        // If not set then the ephemeral container is run in whatever namespaces are shared
-        // for the pod.
-        TargetContainerName string `json:"targetContainerName,omitempty" protobuf:"bytes,4,opt,name=targetContainerName"`
-}
-```
-
-Ephemeral Containers for a pod would be listed in the pod's status:
-
-```
-type PodStatus struct {
-        ...
-        // List of user-initiated ephemeral containers that have been run in this pod.
-        // +optional
-        EphemeralContainers []EphemeralContainer `json:"ephemeralContainers,omitempty" protobuf:"bytes,11,rep,name=ephemeralContainers"`
-
-}
-```
-
-To create a new Ephemeral Container, one would append a new `EphemeralContainer`
-with the desired `v1.Container` as `Spec` in `Pod.Status` and updates the `Pod`
-in the API. Users cannot normally modify the pod status, so we'd create a new
-subresource `/ephemeralcontainers` that allows an update of solely
-`EphemeralContainers` and enforces append-only semantics.
-
-Since we have a requirement to describe the Ephemeral Container with a
-`v1.Container`, this lead to a "spec in status" that seemed to violate API best
-practices. It was confusing, and it required added complexity in the kubelet to
-persist and publish user intent, which is rightfully the job of the apiserver.
-
-#### Extend the Existing Exec API ("exec++")
-
-A simpler change is to extend `v1.Pod`'s `/exec` subresource to support
-"executing" container images. The current `/exec` endpoint must implement `GET`
-to support streaming for all clients. We don't want to encode a (potentially
-large) `v1.Container` into a query string, so we must extend `v1.PodExecOptions`
-with the specific fields required for creating a Debug Container:
-
-```
-// PodExecOptions is the query options to a Pod's remote exec call
-type PodExecOptions struct {
-        ...
-        // EphemeralContainerName is the name of an ephemeral container in which the
-        // command ought to be run. Either both EphemeralContainerName and
-        // EphemeralContainerImage fields must be set, or neither.
-        EphemeralContainerName *string `json:"ephemeralContainerName,omitempty" ...`
-
-        // EphemeralContainerImage is the image of an ephemeral container in which the command
-        // ought to be run. Either both EphemeralContainerName and EphemeralContainerImage
-        // fields must be set, or neither.
-        EphemeralContainerImage *string `json:"ephemeralContainerImage,omitempty" ...`
-}
-```
-
-After creating the Ephemeral Container, the kubelet would upgrade the connection
-to streaming and perform an attach to the container's console. If disconnected,
-the Ephemeral Container could be reattached using the pod's `/attach` endpoint
-with `EphemeralContainerName`.
-
-Ephemeral Containers could not be removed via the API and instead the process
-must terminate. While not ideal, this parallels existing behavior of `kubectl
-exec`. To kill an Ephemeral Container one would `attach` and exit the process
-interactively or create a new Ephemeral Container to send a signal with
-`kill(1)` to the original process.
-
-Since the user cannot specify the `v1.Container`, this approach sacrifices a
-great deal of flexibility. This solution still requires the kubelet to publish a
-`Container` spec in the `PodStatus` that can be examined for future admission
-decisions and so retains many of the downsides of the Container Spec in
-PodStatus approach.
-
-#### Ephemeral Container Controller
-
-Kubernetes prefers declarative APIs where the client declares a state for
-Kubernetes to enact. We could implement this in a declarative manner by creating
-a new `EphemeralContainer` type:
-
-```
-type EphemeralContainer struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Spec v1.Container
-        Status v1.ContainerStatus
-}
-```
-
-A new controller in the kubelet would watch for EphemeralContainers and
-create/delete debug containers. `EphemeralContainer.Status` would be updated by
-the kubelet at the same time it updates `ContainerStatus` for regular and init
-containers. Clients would create a new `EphemeralContainer` object, wait for it
-to be started and then attach using the pod's attach subresource and the name of
-the `EphemeralContainer`.
-
-A new controller is a significant amount of complexity to add to the kubelet,
-especially considering that the kubelet is already watching for changes to pods.
-The kubelet would have to be modified to create containers in a pod from
-multiple config sources. SIG Node strongly prefers to minimize kubelet
-complexity.
-
-#### Mutable Pod Spec Containers
-
-Rather than adding to the pod API, we could instead make the pod spec mutable so
-the client can generate an update adding a container. `SyncPod()` has no issues
-adding the container to the pod at that point, but an immutable pod spec has
-been a basic assumption and best practice in Kubernetes. Changing this
-assumption complicates the requirements of the kubelet state machine. Since the
-kubelet was not written with this in mind, we should expect such a change would
-create bugs we cannot predict.
-
-#### Image Exec
-
-An earlier version of this proposal suggested simply adding `Image` parameter to
-the exec API. This would run an ephemeral container in the pod namespaces
-without adding it to the pod spec or status. This container would exist only as
-long as the process it ran. This parallels the current kubectl exec, including
-its lack of transparency. We could add constructs to track and report on both
-traditional exec process and exec containers. In the end this failed to meet our
-transparency requirements.
-
-#### Attaching Container Type Volume
-
-Combining container volumes ([#831](https://issues.k8s.io/831)) with the ability
-to add volumes to the pod spec would get us most of the way there. One could
-mount a volume of debug utilities at debug time. Docker does not allow adding a
-volume to a running container, however, so this would require a container
-restart. A restart doesn't meet our requirements for troubleshooting.
-
-Rather than attaching the container at debug time, kubernetes could always
-attach a volume at a random path at run time, just in case it's needed. Though
-this simplifies the solution by working within the existing constraints of
-`kubectl exec`, it has a sufficient list of minor limitations (detailed in
-[#10834](https://issues.k8s.io/10834)) to result in a poor user experience.
-
-#### Inactive container
-
-If Kubernetes supported the concept of an "inactive" container, we could
-configure it as part of a pod and activate it at debug time. In order to avoid
-coupling the debug tool versions with those of the running containers, we would
-want to ensure the debug image was pulled at debug time. The container could
-then be run with a TTY and attached using kubectl.
-
-The downside of this approach is that it requires prior configuration. In
-addition to requiring prior consideration, it would increase boilerplate config.
-A requirement for prior configuration makes it feel like a workaround rather
-than a feature of the platform.
-
-#### Implicit Empty Volume
-
-Kubernetes could implicitly create an EmptyDir volume for every pod which would
-then be available as a target for either the kubelet or a sidecar to extract a
-package of binaries.
-
-Users would have to be responsible for hosting a package build and distribution
-infrastructure or rely on a public one. The complexity of this solution makes it
-undesirable.
-
-#### Standalone Pod in Shared Namespace ("Debug Pod")
-
-Rather than inserting a new container into a pod namespace, Kubernetes could
-instead support creating a new pod with container namespaces shared with
-another, target pod. This would be a simpler change to the Kubernetes API, which
-would only need a new field in the pod spec to specify the target pod. To be
-useful, the containers in this "Debug Pod" should be run inside the namespaces
-(network, pid, etc) of the target pod but remain in a separate resource group
-(e.g. cgroup for container-based runtimes).
-
-This would be a rather large change for pod, which is currently treated as an
-atomic unit. The Container Runtime Interface has no provisions for sharing
-outside of a pod sandbox and would need a refactor. This could be a complicated
-change for non-container runtimes (e.g. hypervisor runtimes) which have more
-rigid boundaries between pods.
-
-This is pushing the complexity of the solution from the kubelet to the runtimes.
-Minimizing change to the Kubernetes API is not worth the increased complexity
-for the kubelet and runtimes.
-
-It could also be possible to implement a Debug Pod as a privileged pod that runs
-in the host namespace and interacts with the runtime directly to run a new
-container in the appropriate namespace. This solution would be runtime-specific
-and pushes the complexity of debugging to the user. Additionally, requiring
-node-level access to debug a pod does not meet our requirements.
-
-#### Exec from Node
-
-The kubelet could support executing a troubleshooting binary from the node in
-the namespaces of the container. Once executed this binary would lose access to
-other binaries from the node, making it of limited utility and a confusing user
-experience.
-
-This couples the debug tools with the lifecycle of the node, which is worse than
-coupling it with container images.
-
-## Reference
-
-*   [Pod Troubleshooting Tracking Issue](https://issues.k8s.io/27140)
-*   [CRI Tracking Issue](https://issues.k8s.io/28789)
-*   [CRI: expose optional runtime features](https://issues.k8s.io/32803)
-*   [Resource QoS in Kubernetes](resource-qos.md)
-*   Related Features
-    *   [#1615](https://issues.k8s.io/1615) - Shared PID Namespace across
-        containers in a pod
-    *   [#26751](https://issues.k8s.io/26751) - Pod-Level cgroup
-    *   [#10782](https://issues.k8s.io/10782) - Vertical pod autoscaling
+The Troubleshooting Running Pods proposal has moved to the
+[Ephemeral Containers KEP](https://git.k8s.io/enhancements/keps/sig-node/20190212-ephemeral-containers.md).
diff --git a/contributors/design-proposals/release/versioning.md b/contributors/design-proposals/release/versioning.md
index da7f1bbb..1612d03b 100644
--- a/contributors/design-proposals/release/versioning.md
+++ b/contributors/design-proposals/release/versioning.md
@@ -90,9 +90,6 @@ should probably upgrade it, (and probably should have some time ago)". With
 minor releases happening approximately every three months, that means a minor
 release is supported for approximately nine months.
 
-This policy is in line with
-[GKE's supported upgrades policy](https://cloud.google.com/container-engine/docs/clusters/upgrade).
-
 ## Patch releases
 
 Patch releases are intended for critical bug fixes to the latest minor version,
diff --git a/contributors/devel/OWNERS b/contributors/devel/OWNERS
index 4b7cccf3..4daed338 100644
--- a/contributors/devel/OWNERS
+++ b/contributors/devel/OWNERS
@@ -3,7 +3,6 @@
 reviewers:
   - calebamiles
   - cblecker
-  - grodrigues3
   - idvoretskyi
   - Phillels
   - spiffxp
@@ -11,7 +10,6 @@ reviewers:
 approvers:
   - calebamiles
   - cblecker
-  - grodrigues3
   - idvoretskyi
   - lavalamp
   - Phillels
diff --git a/contributors/devel/README.md b/contributors/devel/README.md
index 3b81ef4e..e49af627 100644
--- a/contributors/devel/README.md
+++ b/contributors/devel/README.md
@@ -57,7 +57,7 @@ Guide](http://kubernetes.io/docs/admin/).
 * **Annotations** ([Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)): are for attaching arbitrary non-identifying metadata to objects.
   Programs that automate Kubernetes objects may use annotations to store small amounts of their state.
 
-* **API Conventions** ([api-conventions.md](api-conventions.md)):
+* **API Conventions** ([api-conventions.md](sig-architecture/api-conventions.md)):
   Defining the verbs and resources used in the Kubernetes API.
 
 * **API Client Libraries** ([Client Libraries](https://kubernetes.io/docs/reference/using-api/client-libraries/)):
diff --git a/contributors/devel/api-conventions.md b/contributors/devel/api-conventions.md
deleted file mode 100644
index 91eb7417..00000000
--- a/contributors/devel/api-conventions.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/api_changes.md b/contributors/devel/api_changes.md
deleted file mode 100644
index fa654177..00000000
--- a/contributors/devel/api_changes.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/bazel.md b/contributors/devel/bazel.md
deleted file mode 100644
index 82aa57d1..00000000
--- a/contributors/devel/bazel.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/bazel.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/cherry-picks.md b/contributors/devel/cherry-picks.md
deleted file mode 100644
index 5e587d47..00000000
--- a/contributors/devel/cherry-picks.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/collab.md b/contributors/devel/collab.md
deleted file mode 100644
index cdf234d2..00000000
--- a/contributors/devel/collab.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/guide/collab.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/component-config-conventions.md b/contributors/devel/component-config-conventions.md
deleted file mode 100644
index 3273f3b8..00000000
--- a/contributors/devel/component-config-conventions.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/component-config-conventions.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/conformance-tests.md b/contributors/devel/conformance-tests.md
deleted file mode 100644
index 414e9727..00000000
--- a/contributors/devel/conformance-tests.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/container-runtime-interface.md b/contributors/devel/container-runtime-interface.md
deleted file mode 100644
index 6b12b564..00000000
--- a/contributors/devel/container-runtime-interface.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/container-runtime-interface.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/controllers.md b/contributors/devel/controllers.md
deleted file mode 100644
index 725c3dde..00000000
--- a/contributors/devel/controllers.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-api-machinery/controllers.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/cri-container-stats.md b/contributors/devel/cri-container-stats.md
deleted file mode 100644
index 10ea700c..00000000
--- a/contributors/devel/cri-container-stats.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/cri-container-stats.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/cri-testing-policy.md b/contributors/devel/cri-testing-policy.md
deleted file mode 100644
index e0dec073..00000000
--- a/contributors/devel/cri-testing-policy.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/cri-testing-policy.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/cri-validation.md b/contributors/devel/cri-validation.md
deleted file mode 100644
index 23a04f02..00000000
--- a/contributors/devel/cri-validation.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/cri-validation.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/development.md b/contributors/devel/development.md
index 6c74f9b5..2312495e 100644
--- a/contributors/devel/development.md
+++ b/contributors/devel/development.md
@@ -137,9 +137,10 @@ development environment, please [set one up](http://golang.org/doc/code.html).
 | 1.10           | 1.9.1       |
 | 1.11           | 1.10.2      |
 | 1.12           | 1.10.4      |
-| 1.13           | 1.11.2      |
-| 1.13           | 1.11.4      |
-| 1.14+          | 1.12.1      |
+| 1.13           | 1.11.13     |
+| 1.14+          | 1.12.9      |
+
+Note that Go 1.13 is not supported yet.
 
 Ensure your GOPATH and PATH have been configured in accordance with the Go
 environment instructions.
diff --git a/contributors/devel/e2e-node-tests.md b/contributors/devel/e2e-node-tests.md
deleted file mode 100644
index 815fe0b8..00000000
--- a/contributors/devel/e2e-node-tests.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/e2e-node-tests.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/e2e-tests.md b/contributors/devel/e2e-tests.md
deleted file mode 100644
index f8427634..00000000
--- a/contributors/devel/e2e-tests.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/e2e-tests.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/event-style-guide.md b/contributors/devel/event-style-guide.md
deleted file mode 100644
index d91c62ac..00000000
--- a/contributors/devel/event-style-guide.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-instrumentation/event-style-guide.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/flaky-tests.md b/contributors/devel/flaky-tests.md
deleted file mode 100644
index 13eb57fb..00000000
--- a/contributors/devel/flaky-tests.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/flaky-tests.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/flexvolume.md b/contributors/devel/flexvolume.md
deleted file mode 100644
index f731c6df..00000000
--- a/contributors/devel/flexvolume.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-storage/flexvolume.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/generating-clientset.md b/contributors/devel/generating-clientset.md
deleted file mode 100644
index 4141df61..00000000
--- a/contributors/devel/generating-clientset.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-api-machinery/generating-clientset.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/getting-builds.md b/contributors/devel/getting-builds.md
deleted file mode 100644
index bbbcfa44..00000000
--- a/contributors/devel/getting-builds.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-release/getting-builds.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/godep.md b/contributors/devel/godep.md
deleted file mode 100644
index 6e896b94..00000000
--- a/contributors/devel/godep.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/godep.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/gubernator.md b/contributors/devel/gubernator.md
deleted file mode 100644
index c5361697..00000000
--- a/contributors/devel/gubernator.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/gubernator.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/help-wanted.md b/contributors/devel/help-wanted.md
deleted file mode 100644
index 984deb6a..00000000
--- a/contributors/devel/help-wanted.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/guide/help-wanted.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/instrumentation.md b/contributors/devel/instrumentation.md
deleted file mode 100644
index 6681740e..00000000
--- a/contributors/devel/instrumentation.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-instrumentation/instrumentation.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/kubectl-conventions.md b/contributors/devel/kubectl-conventions.md
deleted file mode 100644
index 4cc1c7e0..00000000
--- a/contributors/devel/kubectl-conventions.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-cli/kubectl-conventions.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
\ No newline at end of file
diff --git a/contributors/devel/kubelet-cri-networking.md b/contributors/devel/kubelet-cri-networking.md
deleted file mode 100644
index 148d9ae6..00000000
--- a/contributors/devel/kubelet-cri-networking.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/kubelet-cri-networking.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/kubemark-guide.md b/contributors/devel/kubemark-guide.md
deleted file mode 100644
index 719e2c76..00000000
--- a/contributors/devel/kubemark-guide.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-scalability/kubemark-guide.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/logging.md b/contributors/devel/logging.md
deleted file mode 100644
index a22fc799..00000000
--- a/contributors/devel/logging.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-instrumentation/logging.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/node-performance-testing.md b/contributors/devel/node-performance-testing.md
deleted file mode 100644
index e51417ed..00000000
--- a/contributors/devel/node-performance-testing.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-node/node-performance-testing.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/profiling.md b/contributors/devel/profiling.md
deleted file mode 100644
index 5c7e5a2e..00000000
--- a/contributors/devel/profiling.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-scalability/profiling.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/release.md b/contributors/devel/release.md
deleted file mode 100644
index 129efc96..00000000
--- a/contributors/devel/release.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-release/release.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/scheduler.md b/contributors/devel/scheduler.md
deleted file mode 100644
index 479f5136..00000000
--- a/contributors/devel/scheduler.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-scheduling/scheduler.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/scheduler_algorithm.md b/contributors/devel/scheduler_algorithm.md
deleted file mode 100644
index a64a2c3b..00000000
--- a/contributors/devel/scheduler_algorithm.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-scheduling/scheduler_algorithm.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/sig-architecture/api-conventions.md b/contributors/devel/sig-architecture/api-conventions.md
index f00d7c87..57fbfaad 100644
--- a/contributors/devel/sig-architecture/api-conventions.md
+++ b/contributors/devel/sig-architecture/api-conventions.md
@@ -86,6 +86,12 @@ word names ("extensions", "apps"), and any group name ending in "*.k8s.io" for
 its sole use. When choosing a group name, we recommend selecting a subdomain
 your group or organization owns, such as "widget.mycompany.com".
 
+Version strings should match
+[DNS_LABEL](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/identifiers.md)
+format.
+
+
+
 Resource collections should be all lowercase and plural, whereas kinds are
 CamelCase and singular. Group names must be lower case and be valid DNS
 subdomains.
diff --git a/contributors/devel/sig-architecture/api_changes.md b/contributors/devel/sig-architecture/api_changes.md
index 8bf99957..8125bd88 100644
--- a/contributors/devel/sig-architecture/api_changes.md
+++ b/contributors/devel/sig-architecture/api_changes.md
@@ -930,6 +930,9 @@ The preferred approach adds an alpha field to the existing object, and ensures i
 3. Before persisting the object to storage, clear disabled alpha fields on create,
 and on update if the existing object does not already have a value in the field.
 This prevents new usage of the feature while it is disabled, while ensuring existing data is preserved.
+Ensuring existing data is preserved is needed so that when the feature is enabled by default in a future version *n*
+and data is unconditionally allowed to be persisted in the field, an *n-1* API server
+(with the feature still disabled by default) will not drop the data on update.
 The recommended place to do this is in the REST storage strategy's PrepareForCreate/PrepareForUpdate methods:
 
     ```go
diff --git a/contributors/devel/sig-architecture/conformance-tests.md b/contributors/devel/sig-architecture/conformance-tests.md
index c3069402..919e7cd9 100644
--- a/contributors/devel/sig-architecture/conformance-tests.md
+++ b/contributors/devel/sig-architecture/conformance-tests.md
@@ -33,6 +33,9 @@ specifically, a test is eligible for promotion to conformance if:
 
 - it tests only GA, non-optional features or APIs (e.g., no alpha or beta
   endpoints, no feature flags required, no deprecated features)
+- it does not require direct access to kubelet's API to pass (nor does it
+  require indirect access via the API server node proxy endpoint); it MAY
+  use the kubelet API for debugging purposes upon failure
 - it works for all providers (e.g., no `SkipIfProviderIs`/`SkipUnlessProviderIs`
   calls)
 - it is non-privileged (e.g., does not require root on nodes, access to raw
@@ -48,12 +51,13 @@ specifically, a test is eligible for promotion to conformance if:
 - it passes against the appropriate versions of kubernetes as spelled out in
   the [conformance test version skew policy]
 - it is stable and runs consistently (e.g., no flakes), and has been running
-  for at least one release cycle
+  for at least two weeks
 - new conformance tests or updates to conformance tests for additional scenarios
   are only allowed before code freeze dates set by the release team to allow
   enough soak time of the changes and gives folks a chance to kick the tires
   either in the community CI or their own infrastructure to make sure the tests
   are robust
+- it has a name that is a literal string
 
 Examples of features which are not currently eligible for conformance tests:
 
@@ -242,7 +246,8 @@ To promote a test to the conformance test suite, open a PR as follows:
     than the `framework.It()` function
   - adds a comment immediately before the `ConformanceIt()` call that includes
     all of the required [conformance test comment metadata]
-  - adds the test name to the [conformance.txt] file
+  - `go run test/conformance/walk.go test/e2e > test/conformance/testdata/conformance.txt` 
+    adds the test name to the [conformance.txt] file 
 - add the PR to SIG Architecture's [Conformance Test Review board] in the To
   Triage column
 
@@ -287,7 +292,7 @@ framework.ConformanceIt("it should print the output to logs", func() {
 })
 ```
 
-The corresponding portion of the Kubernetes Conformance Documentfor this test
+The corresponding portion of the Kubernetes Conformance Document for this test
 would then look like this:
 
 > ## [Kubelet: log output](https://github.com/kubernetes/kubernetes/tree/release-1.9/test/e2e_node/kubelet_test.go#L47)
diff --git a/contributors/devel/sig-instrumentation/instrumentation.md b/contributors/devel/sig-instrumentation/instrumentation.md
index b0a11193..7595b436 100644
--- a/contributors/devel/sig-instrumentation/instrumentation.md
+++ b/contributors/devel/sig-instrumentation/instrumentation.md
@@ -90,7 +90,8 @@ apply additionally.
 
 ## Naming 
 
-Metrics added directly by application or package code should have a unique name. 
+General [metric and label naming best practices](https://prometheus.io/docs/practices/naming/) apply.
+Beyond that, metrics added directly by application or package code should have a unique name. 
 This avoids collisions of metrics added via dependencies. They also clearly
 distinguish metrics collected with different semantics. This is solved through
 prefixes:
diff --git a/contributors/devel/sig-node/container-runtime-interface.md b/contributors/devel/sig-node/container-runtime-interface.md
index 84dcddde..3941c942 100644
--- a/contributors/devel/sig-node/container-runtime-interface.md
+++ b/contributors/devel/sig-node/container-runtime-interface.md
@@ -3,10 +3,12 @@
 ## What is CRI?
 
 CRI (_Container Runtime Interface_) consists of a
-[protobuf API](https://git.k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2/api.proto),
 specifications/requirements (to-be-added),
+[protobuf API](https://git.k8s.io/kubernetes/staging/src/k8s.io/cri-api/pkg/apis/runtime/v1alpha2/api.proto),
 and [libraries](https://git.k8s.io/kubernetes/pkg/kubelet/server/streaming)
-for container runtimes to integrate with kubelet on a node. CRI is currently in Alpha.
+for container runtimes to integrate with kubelet on a node. The CRI API is
+currently in Alpha, and the CRI-Docker integration is used by default as of
+Kubernetes 1.7+.
 
 In the future, we plan to add more developer tools such as the CRI validation
 tests.
@@ -26,14 +28,7 @@ pluggable container runtimes and build a healthier ecosystem.
 
 ## How to use CRI?
 
-For Kubernetes 1.6+:
-
-1. Start the image and runtime services on your node. You can have a single
-   service acting as both image and runtime services.
-2. Set the kubelet flags
-   - Pass the unix socket(s) to which your services listen to kubelet:
-     `--container-runtime-endpoint` and `--image-service-endpoint`.
-   - Use the "remote" runtime by `--container-runtime=remote`.
+See the [CRI installation documentation](https://kubernetes.io/docs/setup/cri/).
 
 CRI is still young and we are actively incorporating feedback from developers
 to improve the API. Although we strive to maintain backward compatibility,
@@ -54,7 +49,6 @@ The old, pre-CRI Docker integration was removed in 1.7.
 The Kubernetes 1.5 [blog post on CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
 serves as a general introduction.
 
-
 Below is a mixed list of CRI specifications/requirements, design docs and
 proposals. We are working on adding more documentation for the API.
 
@@ -74,7 +68,7 @@ proposals. We are working on adding more documentation for the API.
 
 ## [Status update](#status-update)
 ### Kubernetes v1.7 release (Docker-CRI integration GA, container metrics API)
-  - The Docker CRI integration has been promoted to GA. 
+  - The Docker CRI integration has been promoted to GA.
   - The legacy, non-CRI Docker integration has been completely removed from
     Kubelet. The deprecated `--enable-cri` flag has been removed.
   - CRI has been extended to support collecting container metrics from the
@@ -104,6 +98,9 @@ default in Kubelet**.
 
 #### [CRI known issues](#cri-1.5-known-issues):
 
+Note, these are known issues as of the 1.5 release. They may or may not have
+been fixed since.
+
   - [#27097](https://github.com/kubernetes/kubernetes/issues/27097): Container
     metrics are not yet defined in CRI.
   - [#36401](https://github.com/kubernetes/kubernetes/issues/36401): The new
@@ -118,6 +115,9 @@ default in Kubelet**.
 
 #### [Docker CRI integration known issues](#docker-cri-1.5-known-issues)
 
+Note, these are known issues as of the 1.5 release. They may or may not have
+been fixed since.
+
   - Docker compatibility: Support only Docker v1.11 and v1.12.
   - Network:
      - [#35457](https://github.com/kubernetes/kubernetes/issues/35457): Does
diff --git a/contributors/devel/sig-node/cri-container-stats.md b/contributors/devel/sig-node/cri-container-stats.md
index c72f2c8b..a760d404 100644
--- a/contributors/devel/sig-node/cri-container-stats.md
+++ b/contributors/devel/sig-node/cri-container-stats.md
@@ -115,7 +115,10 @@ behind it.*
 
 ## Status
 
-The container metrics calls are added to CRI in Kubernetes 1.7, but Kubelet does not
-yet use it to gather metrics from the runtime. We plan to enable Kubelet to
-optionally consume the container metrics from the API in 1.8.
-
+The container metrics calls were added to CRI in Kubernetes 1.7, but Kubelet did not
+yet use it to gather metrics from the runtime. In Kubernetes 1.8, Kubelet was
+given the option to [consume the container metrics using CRI
+stats](https://github.com/kubernetes/kubernetes/pull/51557). See the
+`pkg/kubelet/cadvisor.go#UsingLegacyCadvisorStats`
+[function](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/cadvisor/util.go#L73)
+for more information on how Kubelet determines the proper metrics source.
diff --git a/contributors/devel/sig-node/e2e-node-tests.md b/contributors/devel/sig-node/e2e-node-tests.md
index 4f3327cb..31c0459c 100644
--- a/contributors/devel/sig-node/e2e-node-tests.md
+++ b/contributors/devel/sig-node/e2e-node-tests.md
@@ -148,6 +148,30 @@ test in parallel against different instances of the same image.
 make test-e2e-node REMOTE=true INSTANCE_PREFIX="my-prefix"
 ```
 
+## Run tests using a custom image config
+
+This is useful if you want to test out different runtime configurations. First, make a local
+(temporary) copy of the base image config from the test-infra repo:
+https://github.com/kubernetes/test-infra/tree/master/jobs/e2e_node
+
+Make your desired modifications to the config, and update data paths to be absolute paths to the
+relevant files on your local machine (e.g. prepend your home directory path to each). For example:
+
+```diff
+ images:
+   cos-stable:
+     image_regex: cos-stable-60-9592-84-0
+     project: cos-cloud
+-    metadata: "user-data</go/src/github.com/containerd/cri/test/e2e_node/init.yaml,containerd-configure-sh</go/src/github.com/containerd/cri/cluster/gce/configure.sh,containerd-extra-init-sh</go/src/github.com/containerd/cri/test/e2e_node/gci-init.sh,containerd-env</workspace/test-infra/jobs/e2e_node/containerd/cri-master/env,gci-update-strategy=update_disabled"
++    metadata: "user-data</home/tallclair/go/src/github.com/containerd/cri/test/e2e_node/init.yaml,containerd-configure-sh</home/tallclair/go/src/github.com/containerd/cri/cluster/gce/configure.sh,containerd-extra-init-sh</home/tallclair/go/src/github.com/containerd/cri/test/e2e_node/gci-init.sh,containerd-env</home/tallclair/workspace/test-infra/jobs/e2e_node/containerd/cri-master/env,gci-update-strategy=update_disabled"
+```
+
+Finally, run the tests with your custom config:
+
+```sh
+make test-e2e-node REMOTE=true IMAGE_CONFIG_FILE="<local file>" [...]
+```
+
 # Additional Test Options for both Remote and Local execution
 
 ## Only run a subset of the tests
diff --git a/contributors/devel/sig-release/cherry-picks.md b/contributors/devel/sig-release/cherry-picks.md
index 934111a3..aad88ac6 100644
--- a/contributors/devel/sig-release/cherry-picks.md
+++ b/contributors/devel/sig-release/cherry-picks.md
@@ -31,37 +31,102 @@ branches.
    * You will need to run the cherry-pick script separately for each patch release you want to cherry-pick to.
 
  * Your cherry-pick PR will immediately get the `do-not-merge/cherry-pick-not-approved` label. 
+   [Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
+   with some additional caveats outlined in the next section of this document.
+
+## Cherry-pick Review
+
+As with any other PR, code OWNERS review (`/lgtm`) and approve (`/approve`) on
+cherry-pick PRs as they deem appropriate.
+
+The same release note requirements apply as normal pull requests,
+except the release note stanza will auto-populate from the master
+branch pull request from which the cherry-pick originated.  If this
+is unsuccessful the `do-not-merge/release-note-label-needed` label
+will be applied and the cherry-pick author must edit the pull request
+description to [add a release note](https://git.k8s.io/community/contributors/guide/release-notes.md)
+or include in a comment the `/release-note-none` command.
+
+Cherry-pick pull requests are reviewed slightly differently than normal
+pull requests on the master branch in that they:
+
+ * Are by default expected to be `kind/bug` and `priority/critical-urgent`.
+
+ * Milestones must be set on the PR reflecting the milestone for the target
+   release branch (for example, milestone v1.11 for a cherry-pick onto branch
+   release-1.11). This is normally done for you by automation.
+
+ * Have one additional level of review in that they must be approved specifically
+   for cherry-pick by branch approvers.
+
    The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
    will triage PRs targeted to the next .0 minor release branch up until the 
    release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager) 
    will handle all cherry-picks to patch releases.
-   Normal rules apply for code merge.
-   * Reviewers `/lgtm` and owners `/approve` as they deem appropriate.
-   * Milestones on cherry-pick PRs should be the milestone for the target 
-   release branch (for example, milestone 1.11 for a cherry-pick onto 
-   release-1.11).
-   * During code freeze, to get attention on a cherry-pick by the current
-   release team members see the [appropriate release folder](https://git.k8s.io/sig-release/releases)
-   for the target release's team contact information. You may cc them with
-   `<@githubusername>` on your cherry-pick PR.
+
+   The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
+   or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
+   are the final authority on branch approval by removing the `do-not-merge/cherry-pick-not-approved`
+   label and triggering a merge into the target branch.
+
+   The team scrubs through incoming cherry-picks on at least a weekly basis, daily during
+   burndown ahead of a .0 release.  Ahead of point releases, reminders of the
+   cherry-pick deadline will be sent out to the community.  Cherry-pick PRs are
+   often metered into the release branches to give more deliberate CI signal across
+   changes.  For this reason your cherry-pick must be ready to merge ahead of
+   the cherry-pick deadline, but those candidates may be merged during the days
+   between the deadline and release.
+
+   Open cherry-pick PRs which do not land in the current release will
+   continue to be tracked by the team for consideration for inclusion in a next
+   patch release.
+
+   If you are concerned about the status of your cherry-pick, err on the
+   side of overcommunicating and reach out to the branch reviewer(s):
+
+   * During code freeze or after code thaw and ahead of a .0 release, to get attention on a cherry-pick by the current
+     release team members see the [appropriate release folder](https://git.k8s.io/sig-release/releases)
+     for the target release's team contact information. You may cc them with
+     `@<githubusername>` on your cherry-pick PR.
+
    * For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md), which includes contact information for the patch release team.
 
-## Cherry-pick Review
+Compared to the normal master branch's merge volume across time,
+the release branches see one or two orders of magnitude less PRs.
+This is because there is an order or two of magnitude higher scrutiny.
+Again the emphasis is on critical bug fixes, eg:
+ * Loss of data
+ * Memory corruption
+ * Panic, crash, hang
+ * Security
 
-Cherry-pick pull requests have an additional requirement compared to normal pull
-requests.
-They must be approved specifically for cherry-pick by Approvers.
-The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager) 
-or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
-are the final authority on removing the `do-not-merge/cherry-pick-not-approved`
-label  and triggering a merge into the target branch.
-
-Cherry-pick pull requests follow the same release note requirements as
-other pull requests, except the release note stanza will auto-populate from
-the master branch pull request from which the cherry-pick originated.  If
-this is unsuccessful the `do-not-merge/release-note-label-needed` label
-will be applied and the cherry-pick author must edit the pull request
-description to [add a release note](https://git.k8s.io/community/contributors/guide/release-notes.md).
+If you are proposing a cherry-pick and it is not a clear and obvious
+critical bug fix, please reconsider.  If upon reflection you wish to
+continue, bolster your case by supplementing your PR with, eg:
+
+ * A GitHub issue detailing the problem
+
+ * Scope of the change
+
+ * Risks of adding a change
+
+ * Risks of associated regression
+
+ * Testing performed, test cases added
+
+ * Key stakeholder SIG reviewers/approvers attesting to their confidence in the
+   change being a required backport
+
+ * If the change is in cloud-provider-specific platform code (which is in the
+   process of being moved out of core Kubernetes), describe the customer impact,
+   how the issue escaped initial testing, remediation taken to prevent similar
+   future escapes, and why the change cannot be carried in your downstream
+   fork of the Kubernetes project branches.  It is critical that our full
+   community is actively engaged on enhancements in the project.  If a
+   released feature was not enabled on a particular provider's platform, this
+   is a community miss that needs to be resolved in the master branch for
+   subsequent releases.  Such enabling will not be backported to the patch
+   release branches.
 
 ## Searching for Cherry-picks
 
diff --git a/contributors/devel/sig-scalability/hollow-node_simplified_template.yaml b/contributors/devel/sig-scalability/hollow-node_simplified_template.yaml
new file mode 100644
index 00000000..8d33982e
--- /dev/null
+++ b/contributors/devel/sig-scalability/hollow-node_simplified_template.yaml
@@ -0,0 +1,93 @@
+apiVersion: v1
+kind: ReplicationController
+metadata:
+  name: hollow-node
+  namespace: kubemark
+spec:
+  replicas: {{numreplicas}}
+  selector:
+      name: hollow-node
+  template:
+    metadata:
+      labels:
+        name: hollow-node
+    spec:
+      initContainers:
+      - name: init-inotify-limit
+        image: docker.io/busybox:latest
+        command: ['sysctl', '-w', 'fs.inotify.max_user_instances=200']
+        securityContext:
+          privileged: true
+      volumes:
+      - name: kubeconfig-volume
+        secret:
+          secretName: kubeconfig
+      - name: logs-volume
+        hostPath:
+          path: /var/log
+      containers:
+      - name: hollow-kubelet
+        image: {{kubemark_image_registry}}/kubemark:{{kubemark_image_tag}}
+        ports:
+        - containerPort: 4194
+        - containerPort: 10250
+        - containerPort: 10255
+        env:
+        - name: CONTENT_TYPE
+          valueFrom:
+            configMapKeyRef:
+              name: node-configmap
+              key: content.type
+        - name: NODE_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.name
+        command:
+        - /bin/sh
+        - -c
+        - /kubemark --morph=kubelet --name=$(NODE_NAME) --kubeconfig=/kubeconfig/kubelet.kubeconfig $(CONTENT_TYPE) --alsologtostderr --v=2
+        volumeMounts:
+        - name: kubeconfig-volume
+          mountPath: /kubeconfig
+          readOnly: true
+        - name: logs-volume
+          mountPath: /var/log
+        resources:
+          requests:
+            cpu: 20m
+            memory: 50M
+        securityContext:
+          privileged: true
+      - name: hollow-proxy
+        image: {{kubemark_image_registry}}/kubemark:{{kubemark_image_tag}}
+        env:
+        - name: CONTENT_TYPE
+          valueFrom:
+            configMapKeyRef:
+              name: node-configmap
+              key: content.type
+        - name: NODE_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.name
+        command:
+        - /bin/sh
+        - -c
+        - /kubemark --morph=proxy --name=$(NODE_NAME) --use-real-proxier=false --kubeconfig=/kubeconfig/kubeproxy.kubeconfig $(CONTENT_TYPE) --alsologtostderr --v=2
+        volumeMounts:
+        - name: kubeconfig-volume
+          mountPath: /kubeconfig
+          readOnly: true
+        - name: logs-volume
+          mountPath: /var/log
+        resources:
+          requests:
+            cpu: 20m
+            memory: 50M
+      tolerations:
+      - effect: NoExecute
+        key: node.kubernetes.io/unreachable
+        operator: Exists
+      - effect: NoExecute
+        key: node.kubernetes.io/not-ready
+        operator: Exists
diff --git a/contributors/devel/sig-scalability/kubemark-setup-guide.md b/contributors/devel/sig-scalability/kubemark-setup-guide.md
new file mode 100644
index 00000000..f2f5a81f
--- /dev/null
+++ b/contributors/devel/sig-scalability/kubemark-setup-guide.md
@@ -0,0 +1,75 @@
+## Introduction
+This document serves to understand how to set up kubemark cluster given that a base cluster (to run hollow-node pods) and separate master (to act as master for the hollow nodes) are already present.
+
+## Precondition
+You need kubemark master and external cluster to set up a kubemark cluster.
+
+The functions are as follows:
+
+- kubemark master: can be StandAlone or HA, used to be the kubemark cluster's master
+- external cluster: used to create hollow nodes for the kubemark cluster
+
+## Steps:
+1. Build kubemark image
+
+If you want to build/use your own kubemark image, do as follows. Otherwise skip this section and just use the latest image `staging-k8s.gcr.io/kubemark:latest` from public repo.
+
+- i. pull kubernetes code
+
+```
+cd $GOPATH/src/k8s.io/
+git clone git@github.com:kubernetes/kubernetes.git
+```
+
+- ii. build kubemark binary 
+
+```
+./hack/build-go.sh cmd/kubemark/
+cp $GOPATH/src/k8s.io/kubernetes/_output/bin/kubemark $GOPATH/src/k8s.io/kubernetes/cluster/images/kubemark/
+```
+
+- iii. build kubemark image
+
+```
+cd $GOPATH/src/k8s.io/kubernetes/cluster/images/kubemark/
+make build
+```
+
+Then you can get the image named `staging-k8s.gcr.io/kubemark:latest` locally.
+
+- iv. push kubemark image
+
+```
+docker tag staging-k8s.gcr.io/kubemark:latest {{kubemark_image_registry}}/kubemark:{{kubemark_image_tag}}
+docker push {{kubemark_image_registry}}/kubemark:{{kubemark_image_tag}}
+```
+
+2. Create hollow nodes
+
+- i. create namespace, configmap and secret
+
+Copy kubemark master's kubeconfig which is used to configure access, put it on a master of external cluster, rename it as config.
+
+```
+kubectl create ns kubemark
+kubectl create configmap node-configmap -n kubemark --from-literal=content.type="test-cluster"
+kubectl create secret generic kubeconfig --type=Opaque --namespace=kubemark --from-file=kubelet.kubeconfig=config --from-file=kubeproxy.kubeconfig=config
+```
+
+- ii. apply yaml to create hollow nodes
+
+You can use `hollow-node_simplified_template.yaml` in the current directory, or use `hollow-node_template.yaml` in `kubernetes/test/kubemark/resources/`.
+
+Note: 
+
+- the parameters `{{numreplicas}}` means the number of hollow nodes in the kubemark cluster
+- the parameters `{{numreplicas}}`, `{{kubemark_image_registry}}` and `{{kubemark_image_tag}}` need to be filled in the simplified template
+- your external cluster should have enough resources to be able to run `{{numreplicas}}` no. of hollow-node pods
+
+```
+kubectl create -f hollow-node_simplified_template.yaml
+```
+
+Waiting for these hollow-node pods to be running. Then you can see these pods register as kubemark master's nodes.
+
+Finally, kubemark master and external cluster set up the kubemark cluster.
diff --git a/contributors/devel/sig-scheduling/scheduler.md b/contributors/devel/sig-scheduling/scheduler.md
index 486b04a9..03df88fe 100644
--- a/contributors/devel/sig-scheduling/scheduler.md
+++ b/contributors/devel/sig-scheduling/scheduler.md
@@ -84,7 +84,7 @@ scheduling policies to apply, and can add new ones.
 The policies that are applied when scheduling can be chosen in one of two ways.
 The default policies used are selected by the functions `defaultPredicates()` and `defaultPriorities()` in
 [pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/HEAD/pkg/scheduler/algorithmprovider/defaults/defaults.go).
-However, the choice of policies can be overridden by passing the command-line flag `--policy-config-file` to the scheduler, pointing to a JSON file specifying which scheduling policies to use. See [examples/scheduler-policy-config.json](https://git.k8s.io/examples/staging/scheduler-policy-config.json) for an example
+However, the choice of policies can be overridden by passing the command-line flag `--policy-config-file` to the scheduler, pointing to a JSON file specifying which scheduling policies to use. See [examples/scheduler-policy-config.json](https://git.k8s.io/examples/staging/scheduler-policy/scheduler-policy-config.json) for an example
 config file. (Note that the config file format is versioned; the API is defined in [pkg/scheduler/api](http://releases.k8s.io/HEAD/pkg/scheduler/api/)).
 Thus to add a new scheduling policy, you should modify  [pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/HEAD/pkg/scheduler/algorithm/predicates/predicates.go) or add to the directory  [pkg/scheduler/algorithm/priorities](http://releases.k8s.io/HEAD/pkg/scheduler/algorithm/priorities/), and either register the policy in `defaultPredicates()` or `defaultPriorities()`, or use a policy config file.
 
diff --git a/contributors/devel/sig-scheduling/scheduler_benchmarking.md b/contributors/devel/sig-scheduling/scheduler_benchmarking.md
index dc456e21..1c08b5d8 100644
--- a/contributors/devel/sig-scheduling/scheduler_benchmarking.md
+++ b/contributors/devel/sig-scheduling/scheduler_benchmarking.md
@@ -11,7 +11,7 @@ To run integration benchmarks use the following command from inside a Kubernetes
 directory. 
 
 ```sh
-make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=xxx -bench=."
+make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=^$$ -bench=."
 ```
 
 You can also provide a benchmark name in order to run a specific set of
@@ -19,9 +19,11 @@ benchmarks. Please refer to [Go documentation on benchmarks](https://golang.org/
 for more information.
 
 ```sh
-make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=xxx -bench=BenchmarkScheduling"
+make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=^$$ -bench=BenchmarkScheduling"
 ```
 
+> To display benchmark output only, you can append `-alsologtostderr=false -logtostderr=false` to `KUBE_TEST_ARGS`.
+
 These benchmarks are located in `./test/integration/scheduler_perf/scheduler_bench_test.go`. 
 The function names start with `BenchmarkScheduling`. At the beginning of each
 function there are a few lines in the form of:
@@ -51,7 +53,7 @@ it in the `-bench` argument. For example, the following will run only those
 benchmarks with 5000 nodes and 1000 existing pods.
 
 ```sh
-make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=xxx -bench=BenchmarkScheduling/5000Nodes/1000Pods"
+make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=^$$ -bench=BenchmarkScheduling/5000Nodes/1000Pods"
 ```
 
 ## Profiling the scheduler
@@ -60,7 +62,7 @@ You can get CPU profiling information from the benchmarks by adding a `-cpuprofi
 to the command above. Example:
 
 ```sh
-make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=xxx -bench=BenchmarkScheduling -cpuprofile cpu.out"
+make test-integration WHAT=./test/integration/scheduler_perf KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-run=^$$ -bench=BenchmarkScheduling -cpuprofile cpu.out"
 ```
 
 After obtaining the CPU profile, you can use `pprof` to view the results. For
diff --git a/contributors/devel/sig-testing/bazel.md b/contributors/devel/sig-testing/bazel.md
index 6916c0be..4047a54f 100644
--- a/contributors/devel/sig-testing/bazel.md
+++ b/contributors/devel/sig-testing/bazel.md
@@ -2,22 +2,20 @@
 
 Building and testing Kubernetes with  Bazel is supported but not yet default.
 
-Bazel is used to run all Kubernetes PRs on [Prow](https://prow.k8s.io),
+Bazel is used to run all Kubernetes PRs on [Prow],
 as remote caching enables significantly reduced build and test times.
 
 Some repositories (such as kubernetes/test-infra) have switched to using Bazel
 exclusively for all build, test, and release workflows.
 
-Go rules are managed by the [`gazelle`](https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle)
-tool, with some additional rules managed by the [`kazel`](https://git.k8s.io/repo-infra/kazel) tool.
+Go rules are managed by the [`gazelle`][gazelle]
+tool, with some additional rules managed by the [`kazel`][kazel] tool.
 These tools are called via the `hack/update-bazel.sh` script.
 
-Instructions for installing Bazel
-can be found [here](https://www.bazel.io/versions/master/docs/install.html).
-Please note that until [this Bazel
-issue](https://github.com/bazelbuild/rules_docker/issues/454) is fixed,
-`/usr/bin/env python` must be python2 in order for all the Bazel commands listed
-below to succeed.
+Instructions for installing Bazel can be found [here][bazel-install].
+Note that older Bazel versions did not work with Python 3, so we recommend
+using version 0.27.0 or newer. If you still have Python-related problems,
+please take a look at [this FAQ][bazel-python-faq].
 
 Several convenience `make` rules have been created for common operations:
 
@@ -37,6 +35,12 @@ tests, run
 $ bazel test //pkg/kubectl/...
 ```
 
+[Prow]: https://prow.k8s.io
+[bazel-install]: https://www.bazel.io/versions/master/docs/install.html
+[kazel]: https://git.k8s.io/repo-infra/kazel
+[gazelle]: https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle
+[bazel-python-faq]: https://github.com/bazelbuild/bazel/issues/7899
+
 ## Planter
 If you don't want to install Bazel, you can instead try using the unofficial
 [Planter](https://git.k8s.io/test-infra/planter) tool,
diff --git a/contributors/devel/sig-testing/e2e-tests.md b/contributors/devel/sig-testing/e2e-tests.md
index 848662fc..45a2f11b 100644
--- a/contributors/devel/sig-testing/e2e-tests.md
+++ b/contributors/devel/sig-testing/e2e-tests.md
@@ -545,8 +545,9 @@ stragglers to finish.
 takes too many resources or restarts nodes), it is labeled `[Serial]`, and
 should be run in serial as part of a separate suite.
 
-  - `[Disruptive]`: If a test restarts components that might cause other tests
-to fail or break the cluster completely, it is labeled `[Disruptive]`. Any
+  - `[Disruptive]`: If a test may impact workloads that it didn't create,
+ it should be marked as `[Disruptive]`. Examples of disruptive behavior
+include, but are not limited to, restarting components or tainting nodes. Any
 `[Disruptive]` test is also assumed to qualify for the `[Serial]` label, but
 need not be labeled as both. These tests are not run against soak clusters to
 avoid restarting components.
diff --git a/contributors/devel/sig-testing/testing.md b/contributors/devel/sig-testing/testing.md
index ffe066c4..20562495 100644
--- a/contributors/devel/sig-testing/testing.md
+++ b/contributors/devel/sig-testing/testing.md
@@ -63,7 +63,7 @@ desire.
 If any unit test fails with a timeout panic (see [#1594](https://github.com/kubernetes/community/issues/1594)) on the testing package, you can increase the `KUBE_TIMEOUT` value as shown below.
 
 ```sh
-make test KUBE_TIMEOUT="-timeout 300s"
+make test KUBE_TIMEOUT="-timeout=300s"
 ```
 
 ### Set go flags during unit tests
diff --git a/contributors/devel/staging.md b/contributors/devel/staging.md
deleted file mode 100644
index 81bf52d8..00000000
--- a/contributors/devel/staging.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-architecture/staging.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/strategic-merge-patch.md b/contributors/devel/strategic-merge-patch.md
deleted file mode 100644
index a0240159..00000000
--- a/contributors/devel/strategic-merge-patch.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-api-machinery/strategic-merge-patch.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/testing.md b/contributors/devel/testing.md
deleted file mode 100644
index d904278d..00000000
--- a/contributors/devel/testing.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/testing.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-07-01 or the release of kubernetes 1.15, whichever comes first.
diff --git a/contributors/devel/writing-good-e2e-tests.md b/contributors/devel/writing-good-e2e-tests.md
deleted file mode 100644
index b39208eb..00000000
--- a/contributors/devel/writing-good-e2e-tests.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/devel/sig-testing/writing-good-e2e-tests.md.
-
-This file is a placeholder to preserve links.  Please remove by April 30, 2019 or the release of kubernetes 1.13, whichever comes first.
\ No newline at end of file
diff --git a/contributors/guide/README.md b/contributors/guide/README.md
index 9c2fcb80..d6040224 100644
--- a/contributors/guide/README.md
+++ b/contributors/guide/README.md
@@ -66,7 +66,7 @@ If you haven’t set up your environment, check the [developer resources](/contr
 Kubernetes is a community project.
 Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment.
 
-- Read and review the [Community Expectations](community-expectations.md) for an understanding of code and review expectations.
+- Read and review the [Community Expectations](expectations.md) for an understanding of code and review expectations.
 - See [Community Membership](/community-membership.md) for a list the various responsibilities of contributor roles. You are encouraged to move up this contributor ladder as you gain experience.  
 
 # Your First Contribution
@@ -103,8 +103,8 @@ Another good strategy is to find a documentation improvement, such as a missing/
 
 #### Issue Assignment in Github
 
-Often, new contributors ask to be assigned an issue they are willing to take on. Unfortunately, due to GitHub limitations we can only assign issues to [org members](#community) or repo collaborators. 
-Instead, please state in a comment that you intend to work on this issue and it will be assumed to be yours.
+When you are willing to take on an issue, you can assign it to yourself. Just reply with `/assign` or `/assign @yourself` on an issue, 
+then the robot will assign the issue to you and your name will present at `Assignees` list.
 
 ### Learn about SIGs
 
@@ -213,7 +213,7 @@ Common new contributor PR issues are:
 
 ## Code Review
 
-For a brief description of the importance of code review, please read [On Code Review](/contributors/guide/community-expectations.md#code-review).  
+For a brief description of the importance of code review, please read [On Code Review](/contributors/guide/expectations.md#code-review).  
 There are two aspects of code review: giving and receiving.
 
 To make it easier for your PR to receive reviews, consider the reviewers will need you to:
@@ -223,7 +223,7 @@ To make it easier for your PR to receive reviews, consider the reviewers will ne
 * break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
 * label PRs with appropriate SIGs and reviewers: to do this read the messages the bot sends you to guide you through the PR process
 
-Reviewers, the people giving the review, are highly encouraged to revisit the [Code of Conduct](/code-of-conduct.md) and must go above and beyond to promote a collaborative, respectful community.  
+Reviewers, the people giving the review, are highly encouraged to revisit the [Code of Conduct](/code-of-conduct.md) as well as [community expectations](./expectations.md#expectations-of-reviewers-review-latency) and must go above and beyond to promote a collaborative, respectful community.
 When reviewing PRs from others [The Gentle Art of Patch Review](http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
 
 * Is the idea behind the contribution sound?
diff --git a/contributors/guide/contributor-cheatsheet.md b/contributors/guide/contributor-cheatsheet.md
deleted file mode 100644
index 1a1feb68..00000000
--- a/contributors/guide/contributor-cheatsheet.md
+++ /dev/null
@@ -1,3 +0,0 @@
-This file has moved to https://git.k8s.io/community/contributors/guide/contributor-cheatsheet/README.md.
-
-This file is a placeholder to preserve links.  Please remove after 2019-08-01 or the release of kubernetes 1.15, whichever comes first.
\ No newline at end of file
diff --git a/contributors/guide/contributor-cheatsheet/README-de.md b/contributors/guide/contributor-cheatsheet/README-de.md
new file mode 100644
index 00000000..ae742810
--- /dev/null
+++ b/contributors/guide/contributor-cheatsheet/README-de.md
@@ -0,0 +1,392 @@
+# Cheat-Sheet für Kubernetes-Beitragende
+
+
+Eine Liste von oft-genutzten Ressourcen zum Beitragen zu Kubernetes; Tipps, Tricks
+und allgemeine Best-Practices innerhalb des Kubernetes-Projekts. 
+Es ist als "TL;DR" (too long, didn't read - zu lang, nicht gelesen) oder Schnellreferenz
+nützlicher Informationen gedacht, um deine Beitragserfahrung auf GitHub besser zu machen. 
+
+**Inhaltsverzeichnis**
+- [Hilfreiche Ressourcen](#Hilfreiche-Ressourcen)
+  - [Wie man anfängt](#Wie-man-anfängt)
+  - [SIGs und andere Gruppen](#SIGS-und-andere-Gruppen)
+  - [Community](#Community)
+  - [Important Email Aliases](#Important-Email-Aliases)
+  - [Ablauf](#Ablauf)
+  - [Tests](#Tests)
+  - [Wichtige Email-Adressen](#Wichtige-Email-Adressen)
+  - [Andere nützliche Links](#Andere-Nützliche-Links)
+- [Effektive Kommunikation auf GitHub](#Effektive-Kommunikation-auf-GitHub)
+  - [Seid exzellent zueinander](#Seid-exzellent-zueinander)
+    - [Beispiele für gute/schlechte Kommunikation](#Beispiele-für-guteschlechte-Kommunikation)
+- [Einen Beitrag einreichen](#Einen-Beitrag-einreichen)
+  - [Das CLA unterzeichnen](#Das-CLA-unterzeichnen)
+  - [Erstellen von und Antworten auf Issues](#Erstellen-von-und-Antworten-auf-Issues)
+    - [Erstellen eines Issues](#Erstellen-eines-Issues)
+    - [Antworten auf Issues](#Antworten-auf-Issues)
+  - [Öffnen eines Pull-Requests](#Öffnen-eines-Pull-Requests)
+    - [Erstellen eines Pull-Requests](#Erstellen-eines-Pull-Requests)
+    - [Beispiel PR-Beschreibung](#Beispiel-PR-Beschreibung)
+    - [Troubleshooting eines Pull-Requests](#Troubleshooting-eines-Pull-Requests)
+  - [Labels](#Labels)
+- [Lokal arbeiten](#Lokal-arbeiten)
+  - [Branch-Strategie](#Branch-Strategie)
+    - [Upstream-hinzufügen](#Upstream-hinzufügen)
+    - [Synchron halten von Forks](#Synchron-halten-von-Forks)
+  - [Commits squashen](#Commits-squashen)
+
+---
+
+## Hilfreiche Ressourcen
+
+### Wie man anfängt
+
+- [Contributor Guide] - Anleitung zum Beginn des Beitragens zum Kubernetes-Projekt.
+- [Developer Guide] - Anleitung zum Beitragen von Code direkt zum Kubernetes-Projekt.
+- [Security and Disclosure Information] - Anleitung zum Melden von Schwachstellen und 
+  zur Sicherheit des Release-Prozesses.
+
+### SIGs und andere Gruppen
+
+- [Gruppenliste][SIGs]
+
+### Community
+
+- [Kalender] - Alle Kubernetes-Community-Events (SIG/WG Treffen, Events, usw.).
+- [kubernetes-dev] - Kubernetesentwicklung-Mailingliste.
+- [Kubernetes Forum] - Offizielles Kubernetes-Forum.
+- [Slack Channels] - Offizieller Kubernetes-Slackchannel.
+- [Stack-Overflow] - Zum Stellen von Kubernetes-Nutzerfragen.
+- [YouTube Channel] - Offizieller Kubernetes-Youtubechannel.
+
+
+### Ablauf
+
+- [Gubernator Dashboard] - Eingehende und Ausgehende Pull-Requests, die Aufmerksamkeit erfordern.
+- [Prow] - Kubernetes CI/CD-System.
+- [Tide] - Prow-Plugin das Merges und Tests verwaltet. [Tide Dashboard]
+- [Bot-Befehle] - Befehle zur Interaktion mit Kubernetes-Bots (zum Beispiel: `/cc`, `/lgtm`, und `/retest`)
+- [GitHub Labels] - Liste an Labels des ganzen Kubernets-Projekts.
+- [Kubernetes Code Search], von [@dims] maintained.
+
+
+### Tests
+
+- [Prow] - Kubernetes CI/CD-System.
+- [Test Grid] - Ansicht historischer Tests und den zugehörigen Informationen.
+- [Triage Dashboard] - Aggregiert ähnliche Fehler zur besseren Fehlerbehandlung.
+- [Velodrome] - Dashboard zur Überwachung der Job- und Testgesundheit.
+
+
+### Wichtige Email-Adressen
+
+- community@kubernetes.io - Maile jemandem im Community-Team (SIG Contributor
+  Experience) über ein Problem in der Community.
+- conduct@kubernetes.io - Kontaktiere das Code-of-Conduct-Board, private Mailingliste.
+- github@kubernetes.io - Maile dem [GitHub Administration Team] privat,
+  für heikle Themen.
+- steering@kubernetes.io - Maile der Leitungsgruppe. Öffentliche Adresse mit 
+  öffentlichem Archiv.
+- steering-private@kubernetes.io - Maile der Leitungsgruppe private, für heikle Themen.
+- social@cncf.io - Kontaktiere das CNCF Socal Media Team; Blog, Twitteraccount, und
+  andere soziale Bereiche.
+
+
+### Andere nützliche Links
+
+- [Developer Statistiken] - Entwicklerstatistiken für alle von CNCF gemanagten Projekte.
+
+---
+
+## Effektive Kommunikation auf GitHub
+
+
+### Seid exzellent zueinander
+
+Als ersten Schritt sollte man sich mit dem [Code of Conduct] bekannt machen. 
+
+
+#### Beispiele für gute/schlechte Kommunikation
+
+Wenn man ein Problem anspricht, oder Hilfe sucht, sollte man die Anfrage höflich
+formulieren:
+
+  🙂 “X kompiliert nicht, wenn ich Y mache, habt ihr Vorschläge dazu?
+
+  😞 “X geht nicht, fixt das!" 
+
+Beim Schließen eines PRs ist es sinnvoll eine freundliche und erklärende Nachricht
+hinzuzufügen weshalb dieser nicht die Mergeanforderungen erfüllt.
+
+🙂 “Ich schließe diesen PR, da dieses Feature nicht den Use-Case X unterstützt. In
+   der forgeschlagenen Form wäre es besser dies mit Y umzusetzen. Danke für deine 
+   Mitarbeit daran." 
+
+😞 “Warum folgt das nicht den API-Konventionen? Das sollte woanders gemacht werden!"
+
+---
+
+## Einen Beitrag einreichen
+
+### Das CLA unterzeichnen
+
+Bevor man einen Beitrag einreichen kann, muss das [Contributor License Agreement (CLA) unterzeichnet][cla] 
+werden. Das Kubernetes-Projekt kann _nur_ einen Beitrag annehmen, wenn du oder deine Firma 
+das CLA unterzeichnet haben.
+
+Solltest du Probleme beim Unterzeichnen des CLAs haben, folge den [CLA Troubleshooting Guidelines][CLA
+troubleshooting guidelines].
+
+
+### Erstellen von und Antworten auf Issues
+
+GitHub Issues sind der meistgenutzte Weg um Dinge wie Bugreports und Enhancementrequests
+zu verfolgen, oder andere Probleme wie fehlschlagende Tests zu melden.
+Sie sind **nicht** als [Anfragen für Usersupport][user support requests] gedacht. Für diese
+gibt es den [Troubleshooting Guide][troubleshooting guide], [Stack-Overflow] oder das
+[Kubernetes-Forum][Kubernetes Forum].
+
+**Referenzen:**
+- [Labels]
+- [Prow Commands][commands]
+
+
+#### Erstellen eines Issues
+
+- Nutze ein Issue-Template, wenn eines zur Verfügung steht. Das korrekte Template
+  hilft anderen Beitragenden auf deinen Issue zu antworten.
+  - Folge allen Anweisungen im Template selbst.
+- Beschreibe den Issue detailliert.
+- Füge sinnvolle [Labels][Labels] hinzu. Wenn du dir nicht sicher bist, hilft
+  der [K8s-ci-robot][Prow] Bot ([Kubernetes CI bot][Prow]) mit Antworten auf Issues,
+  damit diese effektive verwaltet werden. 
+- Sei selektiv beim Zuweisen von Issues zu Nutzern mit [`/assign @<username>`][assign] 
+  oder [`/cc @<username>`][cc]. Der Issue wird effektiver verwaltet, wenn sinnvolle
+  Labels zugewiesen werden und weniger Menschen.
+
+
+#### Antworten auf Issues
+
+- Wenn du an einem Issue arbeitest, hinterlasse einen Kommentar damit andere
+  wissen, dass du daran arbeitest und doppelte Arbeit vermieden wird.
+- Falls du selbst eine Lösung findest, kommentiere den Issue mit einer Erklärung
+  bevor du ihn schließt.
+- Referenzen auf andere PRs und Issues (oder andere Materialen) mit zum Beispiel: 
+  _"ref: #1234"_ sind sinnvoll. Diese helfen Bezüge darauf zu finden, die an
+  anderer Stelle bearbeitet wurden.
+
+
+### Öffnen eines Pull-Requests
+
+Pull-Requests (PR) sind die meistgenutzte Variante um Code, Dokumentation oder andere Arten
+von Arbeit beizutragen, die in einem Git-Repository gespeichert werden können.
+
+**Referenzen:**
+- [Labels]
+- [Prow Commands][commands]
+- [Pull-Request Prozess]
+- [GitHub Workflow]
+
+
+#### Erstellen eines Pull-Requests
+
+- Folge den Anweisungen des Pull-Request-Templates, falls eines zur Verfügung steht.
+  Es wird denen helfen, die auf den PR antworten.
+- Für [triviale Fixes][trivial fix] wie kaputte Links, Schreib- oder Grammatikfehler
+  durchsuche das gesamte Dokument für andere potentielle Fehler. Mehrere PRs für kleine
+  Fixes im gleichen Dokument sind unnötig.
+- Füge Referenzen auf verwandte Issues oder Issues die der PR lösen könnte hinzu.
+- Vermeide unnötig große Änderungen in einem einzelnen Commit. Zerteile stattdessen
+  den PR in mehrere kleine, logische Commits. Das erleichter Reviews.
+- Kommentiere deinen eigenen PR wenn du meinst weitere Erklärungen sind nötig.
+- Sei selektiv beim Erstellen des PRs mit [`/assign @<username>`][assign].
+  Zu viele Reviewer garantieren keinen schnelleren PR-Review.
+- Wenn der PR als _"Work in progress"_ angesehen wird, füge ein `[WIP]` am Anfang des
+  Titels hinzu oder nutze den [`/hold`][hold] Befehl. Das stellt sicher, dass der PR 
+  nicht gemerged wird bis das `[WIP]` oder hold aufgehoben worden sind.
+- Falls dein PR noch nicht reviewed wurde, bitte schließe ihn nicht und öffne einen Neuen 
+  mit den gleichen Änderungen. Pinge deine Reviewer stattdessen in einem Kommentar mit 
+  `@<github username>` an.
+
+
+#### Beispiel PR-Beschreibung
+
+```
+Ref. #3064 #3097
+Alle Dateien im Besitz von SIG testing wurden von `/devel` zum neuen Ordner `/devel/sig-testing`
+verschoben.
+
+/sig contributor-experience
+/cc @stakeholder1 @stakeholder2
+/kind cleanup
+/area developer-guide
+/assign @approver1 @approver2 @approver3
+```
+
+Was steht in diesem PR:
+- **Zeile 1** - Referenzen auf andere Issues oder PRs (#3064 #3097).
+- **Zeile 2** - Eine kurze Beschreibung was in diesem PR getan wird.
+- **Zeile 4** - [SIG][SIGs] Zuweisung mit dem [Befehl][commands]
+  `/sig contributor-experience`..
+- **Zeile 5** - Reviewer die Interesse an diesem spezifischen Issue oder PR 
+  haben könnten, werden mit [`/cc`][cc] markiert.
+- **Zeile 6** - Der [`/kind cleanup`][kind] Befehl fügt ein [Label][Labels] hinzu, das
+  Issues oder PRs als Aufräumen von Code, Prozessen oder technologischer Schuld kategorisiert.
+- **Zeile 7** - Der [`/area developer-guide`][kind] Befehl kategorisiert Issues oder PRs im Bezug
+  zum Developerguide. 
+- **Zeile 9** - Der Befehl [`/assign`][assign] fügt einen Approver zum PR hinzu. Ein Approver
+  wird vom [k8s-ci-robot][Prow] vorgeschlagen und wird von der Liste der Eingentümer in der
+  [OWNERS] Datei ausgewählt. file. Der Approver fügt das [`/approve`][approve] Label zum PR
+  hinzu nachdem dieser reviewed wurde.
+
+
+#### Troubleshooting eines Pull-Requests
+
+Nachdem ein PR vorgeschlagen wurde, wird eine Reihe an Test von der Kubernetes
+CL-Plattform [Prow] ausgeführt. Fall einer der Tests fehlschlägt, antwortet
+der [K8s-ci-robot][Prow] auf den PR mit Links zu den fehlgeschlagenen Tests und
+verfügbaren Logs.
+
+Neue Commits zu diesem PR sorgen dafür dass diese Tests erneut ausgeführt werden.
+
+Gelegentlich gibt es Probleme mit der Kubernetes CI-Plattform. Diese können aus 
+verschiedenen Gründen auftreten, selbst wenn der Beitrag alle lokalen Tests besteht.
+Man kann einen neuen Testdurchlauf mit dem `/retest` Befehl auslösen. 
+
+Für mehr Informationen zum Troubleshooting von spezifischen Test, siehe den [Testing Guide].
+
+
+### Labels
+
+Kubernetes nutzt [Labels][Labels] zum sichten und kategorisieren von Issues und Pull Requests.
+Die richtigen Labels helfen dabei den Issue oder PR sinnvoller einzusortieren.
+
+**Referenzen:**
+- [Labels]
+- [Prow Commands][commands]
+
+Oft genutzte Labels:
+- [`/sig <sig name>`][kind] Fügt eine [SIG][SIGs] als Eigentümer des Issues oder PRs hinzu.
+- [`/area <area name>`][kind] Verknüpft den Issue oder PR mit einem bestimmten [Bereich][labels].
+- [`/kind <category>`][kind] [Kategorisiert][labels] den Issue oder PR.
+
+---
+
+## Lokal arbeiten
+
+Bevor man einen Pull-Request vorschlagen kann, muss man lokal etwas Arbeit leisten.
+Für Neueinsteiger zu git ist das [Atlassian Git-Tutorial][Atlassian git tutorial] 
+ein guter Einstiegspunkt. Alternativ ist das [Git Magic Tutorical][Git magic] der
+Standford Uni eine gute multi-linguale Option.
+
+**Referenzen:**
+- [Atlassion Git-Tutorial][Atlassian git tutorial]
+- [Git magic]
+- [GitHub Workflow]
+- [Lokakes Testen][Testing locally]
+- [Developer guide]
+
+
+### Branch-Strategie
+
+Das Kubernetes-Projekt nutzt den Standardworkflow von GitHub, der sich _"Fork and Pull"_ 
+(auf Deutsch "abzweigen und ziehen") nennt.
+In Begriffen aus der Git-Welt wird dein persönlicher Fork als _"`origin`"_ 
+(auf Deutsch "Ursprung") und das eigentliche Projekt-Gitrepository als _"`upstream`"_
+(wörtlich "flussaufwärts") bezeichnet. 
+Um deinen persönlichen Branch (`origin`) mit dem Projekt (`upstream`) aktuell zu halten,
+muss das innerhalb der lokalen Kopie konfiguriert werden.
+
+
+#### Upstream hinzufügen
+
+Füge `upstream` als sogenanntes remote hinzu und konfiguriere es so, dass man nicht dorthin
+pushen kann.
+
+```
+# Ersetze <upstream git repo> mit der Upstreamrepo-URL
+# Beispiel:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+git remote set-url --push upstream no_push
+```
+
+Das kann via `git remote -v` verifiziert werden, indem alle konfigurierten Remote-Repos 
+aufgelistet werden.
+
+
+#### Synchron halten von Forks
+
+Hole alle Änderungen von `upstream` ab und _"rebase"_ diese auf deinem lokalen
+`Master` Branch. Das wird dein lokales Repo mit dem `upstream` Projekt synchronisieren.
+
+```
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+Das sollte minimal bevor der Erstellung eines neuen Branches für ein Feature oder
+einen Fix passieren. 
+
+```
+git checkout -b myfeature
+```
+
+#### Commits squashen
+
+Der Hauptzweck von [Commits squashen]("Commits zerquetschen") ist die Erstellung
+einer sauberen, lesbaren Githistorie oder eines Logs der Änderungen die gemacht wurden.
+Normal wird das in der letzten Phase einer PR Revision getan. Wenn du dir unsicher bist,
+ob du deine Commits squashen solltest, ist es besser mehrere zu lassen und es dem Urteil
+anderer Beitragenden zu überlassen, die als Reviewer und Approver für den PR zugeteilt wurden.
+
+
+[Contributor Guide]: /contributors/guide/README.md
+[Developer Guide]: /contributors/devel/README.md
+[Gubernator Dashboard]: https://gubernator.k8s.io/pr
+[Prow]: https://prow.k8s.io
+[Tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
+[Tide Dashboard]: https://prow.k8s.io/tide
+[Bot-Befehle]: https://go.k8s.io/bot-commands
+[GitHub Labels]: https://go.k8s.io/github-labels
+[Kubernetes Code Search]: https://cs.k8s.io/
+[@dims]: https://github.com/dims
+[Kalender]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com
+[kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
+[Slack Channels]: http://slack.k8s.io/
+[Stack-Overflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[Youtube Channel]: https://www.youtube.com/c/KubernetesCommunity/
+[Triage Dashboard]: https://go.k8s.io/triage
+[Test Grid]: https://testgrid.k8s.io
+[Velodrome]: https://go.k8s.io/test-health
+[Developer Statistiken]: https://k8s.devstats.cncf.io
+[Code of Conduct]: /code-of-conduct.md
+[user support requests]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
+[troubleshooting guide]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
+[Kubernetes Forum]: https://discuss.kubernetes.io/
+[Pull-Request Prozess]: /contributors/guide/pull-requests.md
+[GitHub Workflow]: /contributors/guide/github-workflow.md
+[Prow]: https://git.k8s.io/test-infra/prow#prow
+[cla]: /CLA.md#how-do-i-sign
+[CLA troubleshooting guidelines]: /CLA.md#troubleshooting
+[commands]: https://prow.k8s.io/command-help
+[kind]: https://prow.k8s.io/command-help#kind
+[cc]: https://prow.k8s.io/command-help#cc
+[hold]: https://prow.k8s.io/command-help#hold
+[assign]: https://prow.k8s.io/command-help#assign
+[SIGs]: /sig-list.md
+[Testing Guide]: /contributors/devel/sig-testing/testing.md
+[Labels]: https://git.k8s.io/test-infra/label_sync/labels.md
+[trivial fix]: /contributors/guide/pull-requests.md#10-trivial-edits
+[GitHub Workflow]: /contributors/guide/github-workflow.md#3-branch
+[Commits squashen]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles
+[OWNERS]: /contributors/guide/owners.md
+[Testing locally]: /contributors/guide/README.md#testing
+[Atlassian git tutorial]: https://www.atlassian.com/git/tutorials
+[Git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
+[Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
+[GitHub Administration Team]: /github-management#github-administration-team
diff --git a/contributors/guide/contributor-cheatsheet/README-fr.md b/contributors/guide/contributor-cheatsheet/README-fr.md
new file mode 100644
index 00000000..73175a91
--- /dev/null
+++ b/contributors/guide/contributor-cheatsheet/README-fr.md
@@ -0,0 +1,330 @@
+# Cheat Sheet pour contributeur Kubernetes
+
+Une liste des ressources communes pour contribuer à Kubernetes, des trucs, des astuces et des bonnes pratiques communes utilisées dans le projet Kubernetes.
+C'est un "TL;DR" ou une référence rapide d'informations utiles pour améliorer votre expérience de contribution sur GitHub.
+
+**Table des matières**
+
+- [Ressources utiles](#Ressources-utiles)
+  - [Commencer](#Commencer)
+  - [SIGs et autres groupes](#SIGs-et-autres-groupes)
+  - [Communauté](#Communauté)
+  - [Alias de messagerie importants](#Alias-de-messagerie-importants)
+  - [Workflow](#Workflow)
+  - [Tests](#Tests)
+  - [Autres liens utiles](#Autres-liens-utiles)
+- [Communiquer efficacement sur GitHub](#Communiquer-efficacement-sur-GitHub)
+  - [Comment être excellent les uns envers les autres](#Comment-être-excellent-les-uns-envers-les-autres)
+    - [Exemples de bonne mauvaise communication](#Exemples-de-bonne-mauvaise-communication)
+- [Soumettre une contribution](#Soumettre-une-contribution)
+  - [Signature de la CLA](#Signature-de-la-CLA)
+  - [Ouverture et réponse aux Issues](#Ouverture-et-réponse-aux-Issues)
+    - [Créer une Issue](#Créer-une-Issue)
+    - [Répondre à une Issue](#Répondre-à-une-Issue)
+  - [Ouverture d'une Pull Request](#Ouverture-d-une-Pull-Request)
+    - [Créer une Pull Request](#Créer-une-Pull-Request)
+    - [Exemple d'une description de Pull Request](#Exemple-d'une-description-de-Pull-Request)
+    - [Dépannage d'une Pull Request](#Dépannage-d'une-Pull-Request)
+  - [Labels](#Labels)
+- [Travailler localement](#Travailler-localement)
+  - [Stratégie de branche](#Stratégie-de-branche)
+    - [Ajouter Upstream](#Ajouter-Upstream)
+    - [Garder votre Fork synchronisé](#Garder-votre-Fork-synchronisé)
+  - [Squashing Commits](#Squashing-Commits)
+
+---
+
+## Ressources utiles
+
+### Commencer
+
+- [Contributor Guide] - Guide sur la façon de commencer à contribuer au projet Kubernetes.
+- [Developer Guide] - Guide pour contribuer du code directement au projet Kubernetes.
+
+### SIGs et autres groupes
+
+- [Liste principale des groupes][sigs]
+
+### Communauté
+
+- [Calendar] - Voir tous les événements de la communauté Kubernetes (réunions SIG / WG, événements, etc.)
+- [kubernetes-dev] - La liste de diffusion sur le développement de Kubernetes
+- [Kubernetes Forum] - Forum officiel de Kubernetes.
+- [Slack channels] - Slack officiel de Kubernetes.
+- [StackOverflow] - Un endroit pour poser vos questions d'utilisateur final de Kubernetes.
+- [YouTube Channel] - Chaine officielle de la communauté Kubernetes.
+
+### Workflow
+
+- [Gubernator Dashboard] - Voir les Pull Requests entrantes et sortantes qui nécessitent votre attention.
+- [Prow] - Kubernetes CI/CD System.
+- [Tide] - Prow plugin that manages merges and tests. [Tide Dashboard]
+- [Bot commands] - Commands used to interact with Kubernetes Bots (examples:
+  `/cc`, `/lgtm`, and `/retest`)
+- [GitHub labels] - Liste des labels utilisées dans le projet Kubernetes
+- [Kubernetes Code Search], maintenu par [@dims]
+
+### Tests
+
+- [Prow] - Kubernetes CI/CD System.
+- [Test Grid] - Afficher les tests historiques et leurs informations associées.
+- [Triage Dashboard] - Regroupe les défaillances similaires pour un meilleur dépannage.
+- [Velodrome] - Tableau de bord pour suivre le travail et tester la santé.
+
+### Alias de messagerie importants
+
+| Alias                          | Description                                                                                                                     |   |
+|--------------------------------|---------------------------------------------------------------------------------------------------------------------------------|---|
+| community@kubernetes.io        | Envoyez un courrier électronique à l’équipe de la communauté (SIG Contributor Experience) au sujet d’un problème de communauté. |   |
+| conduct@kubernetes.io          | Contactez le comité du code de conduite, liste de diffusion privée.                                                             |   |
+| steering@kubernetes.io         | Postez le comité de pilotage. Adresse publique avec archive publique.                                                           |   |
+| steering-private@kubernetes.io | Contacter le steering comité en privé, pour les sujets sensibles.                                                               |   |
+| social@cncf.io                 | Contacter l'équipe sociale de la CNCF; blog, compte twitter et autres réseaux sociaux.                                          |   |
+
+### Autres liens utiles
+
+- [Statistiques de développeur] - Consultez les statistiques des développeurs pour tous les projets gérés par le CNCF.
+
+---
+
+## Communiquer efficacement sur GitHub
+
+### Comment être excellent les uns envers les autres
+
+Dans un premier temps, familiarisez-vous avec le [code de conduite].
+
+#### Exemples de bonne / mauvaise communication
+
+Quand on ouvre une issue, ou si vous avez besoin d’aide, soyez poli avec votre demande:
+
+  🙂 "X ne compile pas quand je fais le Y, avez-vous des suggestions?"
+
+  😞 «X ne marche pas! Réparez-ça, s'il vous plait!"
+
+Lors de la fermeture d'une PR, transmettez un message explicatif et cordial expliquant pourquoi elle ne remplit pas les conditions requises pour être mergé.
+
+🙂 «Je ferme ce PR car cette fonctionnalité ne peut pas prendre en charge le cas d’utilisation X. Dans le contexte proposé, il serait préférable de l’implémenter avec l’outil Y. Merci d'avoir travaillé sur cela. "
+
+😞 «Pourquoi cela ne suit-il pas les conventions de l’API? Cela devrait être fait ailleurs!
+
+---
+
+## Soumettre une contribution
+
+### Signature de la CLA
+
+Avant de pouvoir soumettre une contribution, vous devez [signer le Contributor License Agreement(CLA)][cla].
+Le projet Kubernetes ne peut accepter une contribution que si vous ou votre entreprise avez signé le CLA.
+
+Si vous rencontrez des problèmes pour signer le CLA, suivez les [consignes de dépannage du CLA].
+
+### Ouverture et réponse aux Issues
+
+Les GitHub Issues sont le principal moyen de suivre des éléments tels que les rapports de bogues, les demandes d'amélioration ou de signaler d'autres problèmes tels que l'échec des tests.
+Les issues ne sont **pas** destinées à être des [demandes de support utilisateur].
+Pour ceux-ci, veuillez consulter le [guide de dépannage], signaler le problème à [stackOverflow] ou faire un suivi sur le [forum Kubernetes].
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+
+#### Créer un Issue
+
+- Utilisez un Issuee template s'il en existe un. Utiliser le bon aidera d'autres contributeurs à répondre à votre problème.
+  - Suivez les instructions décrites dans le template d'issue lui-même.
+- Soyez descriptif avec la question que vous soulevez.
+- Attribuer les [labels] appropriés. Si vous n'êtes pas sûr, le [k8s-ci-robot][prow] bot ([Kubernetes CI bot][prow]) répondra à votre problème avec les étiquettes nécessaires à son tri efficace.
+- Soyez sélectif lorsque vous attribuez des Issues à l'aide de [`/assign @<username>`][assign] ou
+  [`/cc @<username>`][cc]. Votre Issue sera triée plus efficacement en appliquant les labels corrects sur l'affectation de plus de personnes à la question.
+
+#### Responding to an Issue
+
+- Lorsque vous abordez un problème, laissez-le savoir aux autres sur lesquels vous travaillez cela pour éviter le travail en double.
+- Lorsque vous avez résolu quelque chose par vous-même à un moment ultérieur, commentez la question de faire savoir aux gens avant de la fermer.
+- Inclure des références à d’autres demandes PullRequests ou Issues (ou à tout matériel accessible),
+  Exemple: _"ref: #1234"_. Il est utile d’identifier que des travaux connexes ont été résolu quelque part ailleurs.
+
+### Ouverture d'une Pull Request
+
+Les Pull requests (PR) sont les principaux moyens de contribuer au code, à la documentation ou à d’autres formes de travail qui seraient stockés dans un dépôt git.
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+- [Pull request process]
+- [Github workflow]
+
+#### Création d'une Pull Request
+
+- Follow the directions of the pull request template if one is available. Cela aidera ceux qui répondent à votre PullRequest.
+- Si un [correctif trivial] tel qu'un lien brisé, une faute de frappe ou une faute de grammaire, examinez l'ensemble du document pour rechercher d'autres erreurs potentielles. Ne pas ouvrir plusieurs PullRequests pour les petites corrections dans le même document.
+- Référencez tous les problèmes liés à votre PullRequest ou les problèmes que PullRequest peut résoudre.
+- Évitez de créer des modifications trop volumineuses dans un seul commit. Au lieu de cela, divisez votre PullRequest en plusieurs petits commits logiques. Cela facilite la révision de votre PullRequest.
+- Commentez votre propre PullRequest lorsque vous pensez que quelque chose peut nécessiter une explication.
+- Soyez sélectif lorsque vous affectez votre PullRequest avec [`/assign @<username>`][assign].
+  L'affectation d'un nombre excessif de réviseurs ne donnera pas une révision plus rapide de PullRequest.
+- Si votre PR est considéré comme un _"Work in progress"_ ajoutez un prefixe dans son nom avec `[WIP]` ou utilisez la commande [`/hold`][hold]. Ceci empêchera le merge de la PR jusqu'à la levée du `[WIP]` ou le retrait du hold.
+- Si votre demande PullRequest n'a pas été relue, ne la fermez pas et n'ouvrez pas une nouvelle demande PullRequest avec les mêmes modifications. Notifiez les relecteurs dans un commentaire avec `@<github username>`.
+
+#### Example PR Description
+
+```text
+Ref. #3064 #3097
+All files owned by SIG testing were moved from `/devel` to the new folder `/devel/sig-testing`.
+
+/sig contributor-experience
+/cc @stakeholder1 @stakeholder2
+/kind cleanup
+/area developer-guide
+/assign @approver1 @approver2 @approver3
+```
+
+Quel est le contenu de cette PR:
+
+- **Line 1** - Référence à d'autres issues ou PRs (#3064 #3097).
+- **Line 2** - Une brève description de ce qui se fait dans la PR.
+- **Line 4** - Assignement au [SIG][sigs] avec la [commande][commands]
+  `/sig contributor-experience`..
+- **Line 5** - Les examinateurs qui peuvent avoir un intérêt sur cette issue ou PR sont spécifiés avec la commande [`/cc`][cc].
+- **Line 6** - La commande [`/kind cleanup`][kind] ajoute un [label][labels] qui catégorise l'issue ou la PR en rapport avec le nettoyage du code, du processus ou de la dette technique.
+- **Line 7** - La commande [`/area developer-guide`][kind] catégorise une issue ou PR en relation avec le guide du développeur.
+- **Line 8** - La commande [`/assign`][assign] assigne un approbateur à la PR.
+  Un approbateur sera suggéré par le [k8s-ci-robot][prow] est sélectionné dans la liste des propriétaires définis dans le fichier [OWNERS]. Ils vont ajouter le label [`/approve`][approve] à la PR après l'avoir passé en revue.
+
+#### Troubleshooting a Pull Request
+
+Après la proposition de votre PR, une série de tests est exécutée par la plateforme Kubernetes CI, [Prow].
+Si l’un des tests échoue, le [k8s-ci-robot][prow] répondra à la PR avec des liens vers les tests ayant échoué et les journaux disponibles.
+
+Pousser de nouveaux commits vers votre PR va automatiquement déclencher la ré-exécution des tests.
+
+Il peut parfois y avoir des problèmes avec la plate-forme Kubernetes CI.
+Celles-ci peuvent survenir pour diverses raisons même si votre contribution réussit tous les tests locaux.
+Vous pouvez déclencher une nouvelle exécution des tests avec la commande `/retest`.
+
+Pour plus d'informations sur le dépannage de tests spécifiques, voir le [Guide de test].
+
+### Labels
+
+Kubernetes utilise [étiquettes] pour catégoriser et trier les Issues et PullRequests.
+L'application de labels appropriées aidera votre Issue ou PullRequest à être triée plus efficacement.
+
+**References:**
+
+- [Labels]
+- [Prow commands][commands]
+
+Labels fréquemment utilisés:
+
+- [`/sig <sig name>`][kind] Attribuer un [SIG][SIGs] à la propriété de l'issue ou de la PR.
+- [`/area <area name>`][kind] Associate the issue or PRs to a specific [area][labels].
+- [`/kind <category>`][kind] [Categorizes][labels] the issue or PR.
+
+---
+
+## Travailler localement
+
+Avant d'ouvrir une Pull Request, vous devrez effectuer préparer votre travail localement.
+Si vous êtes nouveau sur git, le [tutoriel Atlassian git] est un bon point de départ.
+En guise d'alternative, le didacticiel [Git magic] de Stanford est une bonne option multilingue.
+
+**References:**
+
+- [Atlassian git tutorial]
+- [Git magic]
+- [Github workflow]
+- [Testing locally]
+- [Developer guide]
+
+### Stratégie de branche
+
+Le projet Kubernetes utilise un workflow _"Fork and Pull"_ standard pour GitHub.
+Dans le vocabulaire de git, votre fork personnel est appellée _"`origin`"_ et le dépôt git de référence du projet est appellé _"`upstream`"_.
+Garder votre branche personnelle (`origin`) à jour avec le projet (`upstream`), il doit être configuré dans votre dépôt local.
+
+#### Ajouter Upstream
+
+Ajoutez `upstream` en tant que remote et configurez-le afin que vous ne puissiez pas y accéder.
+
+```shell
+# replace <upstream git repo> with the upstream repo url
+# example:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+git remote set-url --push upstream no_push
+```
+
+Cela peut être vérifié en exécutant `git remote -v` qui listera vos remotes configurées.
+
+#### Garder votre dépôt synchronisé
+
+Récupérez toutes les modifications de `upstream` et _"rebase"_ sur votre branche `master` locale.
+Cela synchronisera votre dépôt local avec le projet `upstream`.
+
+```text
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+Effectuez cette opération au minimum avant de créer une nouvelle branche pour travailler sur votre fonctionnalité ou votre correctif.
+
+```text
+git checkout -b myfeature
+```
+
+#### Squashing Commits
+
+Le but principal de [squashing commits] est de créer un historique git lisible.
+Cela se fait généralement dans la dernière phase d'une PullRequest.
+Si vous ne savez pas si vous devez faire un squash de vos commits, il est préférable de préférer avoir plus de commits et de laisser le soin aux autres contributeurs de réviser et d’approuver vos PullRequests.
+
+[guide du contributeur]: /contributors/guide/README.md
+[guide du développeur]: /contributors/devel/README.md
+[gubernator dashboard]: https://gubernator.k8s.io/pr
+[prow]: https://prow.k8s.io
+[tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
+[tide dashboard]: https://prow.k8s.io/tide
+[bot commands]: https://go.k8s.io/bot-commands
+[gitHub labels]: https://go.k8s.io/github-labels
+[Kubernetes Code Search]: https://cs.k8s.io/
+[@dims]: https://github.com/dims
+[calendar]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com
+[kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
+[slack channels]: http://slack.k8s.io/
+[stackOverflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[youtube channel]: https://www.youtube.com/c/KubernetesCommunity/
+[triage dashboard]: https://go.k8s.io/triage
+[test grid]: https://testgrid.k8s.io
+[velodrome]: https://go.k8s.io/test-health
+[statistiques de développeur]: https://k8s.devstats.cncf.io
+[code of conduct]: /code-of-conduct.md
+[user support request]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
+[troubleshooting guide]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
+[stack overflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[kubernetes forum]: https://discuss.kubernetes.io/
+[pull request process]: /contributors/guide/pull-requests.md
+[github workflow]: /contributors/guide/github-workflow.md
+[prow]: https://git.k8s.io/test-infra/prow#prow
+[cla]: /CLA.md#how-do-i-sign
+[cla troubleshooting guidelines]: /CLA.md#troubleshooting
+[commands]: https://prow.k8s.io/command-help
+[kind]: https://prow.k8s.io/command-help#kind
+[cc]: https://prow.k8s.io/command-help#hold
+[hold]: https://prow.k8s.io/command-help#hold
+[assign]: https://prow.k8s.io/command-help#assign
+[SIGs]: /sig-list.md
+[Guide de test]: /contributors/devel/sig-testing/testing.md
+[labels]: https://git.k8s.io/test-infra/label_sync/labels.md
+[solution triviale]: /contributors/guide/pull-requests.md#10-trivial-edits
+[Github workflow]: /contributors/guide/github-workflow.md#3-branch
+[squashing commits]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles
+[owners]: /contributors/guide/owners.md
+[tester localement]: /contributors/guide/README.md#testing
+[developer guide]: /contributors/devel/README.md
+[Atlassian git tutorial]: https://www.atlassian.com/git/tutorials
+[git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
diff --git a/contributors/guide/contributor-cheatsheet/README-id.md b/contributors/guide/contributor-cheatsheet/README-id.md
index 94e0247b..04628dcd 100644
--- a/contributors/guide/contributor-cheatsheet/README-id.md
+++ b/contributors/guide/contributor-cheatsheet/README-id.md
@@ -7,32 +7,33 @@ yang bermanfaat untuk meningkatkan pengalaman kamu ketika berkontribusi
 di GitHub menjadi lebih baik.
 
 **Daftar Isi**
-- [_Resources_](#Resources)
-  - [Mulai Berkontribusi](#Mulai-Berkontribusi)
-  - [_SIG_ dan Grup Lainnya](#SIG-dan-Grup-lainnya)
-  - [Komunitas](#Komunitas)
-  - [Alamat Email Penting](#Alamat-Email-Penting)
-  - [_Workflow_](#Workflow)
-  - [Tes](#Testing)
-  - [Tautan Lain](#Tautan-Lain)
-- [Berkomunikasi Secara Efektif di GitHub](#Berkomunikasi-Secara-Efektif-di-GitHub)
-  - [Bagaimana Cara Bekerja Sama dengan Baik](#Bagaimana-Cara-Bekerja-Sama-dengan-Baik)
-    - [Contoh Komunikasi Yang Baik/Buruk](#Contoh-Komunikasi-yang-BaikBuruk)
-- [Langkah Berkontribusi](#Langkah-Berkontribusi)
-  - [Menyetujui CLA](#Menyetujui-CLA)
-  - [Membuka dan Menanggapi Isu](#Membuka-dan-Menanggapi-Isu)
-    - [Membuat sebuah Isu](#Membuat-sebuah-Isu)
-    - [Menanggapi sebuah Isu](#Menaggapi-sebuah-Isu)
-  - [Membuka _Pull Request_](#Membuka-Pull-Request)
-    - [Membuat a _Pull Request_](#Membuat-Pull-Request)
-    - [Contoh Deskripsi _Pull Request_](#Contoh-Deskripsi-Pull-Request)
-    - [_Troubleshoot_ sebuah _Pull Request_](#Troubleshooting-sebuah-Pull-Request)
-  - [Label](#Label)
-- [Mekanisme Pengerjaan Lokal](#Mekanisme-Pengerjaan-Lokal)
-  - [Mekanisme Penggunaan _Branch_](#Mekanisme-Penggunaan-Branch)
-    - [Menambahkan _Upstream_](#Menambahkan-Upstream)
-    - [Memastikan _Fork_ Kamu tetap Sinkron](#Memastikan-Fork-Kamu-Tetap-Sinkron)
-  - [Melakukan _Commit_ _Squashing_](#Squashing-Commits)
+- [_Cheat Sheet_ Kontributor Kubernetes](#cheat-sheet-kontributor-kubernetes)
+  - [_Resources_](#resources)
+    - [Mulai Berkontribusi](#mulai-berkontribusi)
+    - [_SIG_ dan Grup Lainnya](#sig-dan-grup-lainnya)
+    - [Komunitas](#komunitas)
+    - [_Workflow_](#workflow)
+    - [_Testing_](#testing)
+    - [Alamat Email Penting](#alamat-email-penting)
+    - [Tautan Lain](#tautan-lain)
+  - [Berkomunikasi Secara Efektif di GitHub](#berkomunikasi-secara-efektif-di-github)
+    - [Bagaimana Cara Bekerja Sama dengan Baik](#bagaimana-cara-bekerja-sama-dengan-baik)
+      - [Contoh Komunikasi Yang Baik/Buruk](#contoh-komunikasi-yang-baikburuk)
+  - [Mengumpulkan Kontribusi](#mengumpulkan-kontribusi)
+    - [Signing the CLA](#signing-the-cla)
+    - [Membuka dan Menanggapi Isu](#membuka-dan-menanggapi-isu)
+      - [Membuat Sebuah Isu](#membuat-sebuah-isu)
+      - [Menanggapi sebuah Isu](#menanggapi-sebuah-isu)
+    - [Membuka sebuah Pull Request (PR)](#membuka-sebuah-pull-request-pr)
+      - [Membuat sebuah Pull Request (PR)](#membuat-sebuah-pull-request-pr)
+      - [Contoh Deskripsi PR](#contoh-deskripsi-pr)
+      - [_Troubleshooting_ sebuah PR](#troubleshooting-sebuah-pr)
+    - [Label](#label)
+  - [Bekerja pada Mesin Lokal](#bekerja-pada-mesin-lokal)
+    - [Mekanisme _Branch_](#mekanisme-branch)
+      - [Menambahkan _Upstream_](#menambahkan-upstream)
+      - [Menjaga agar _Fork_ Kamu tetap Sinkron](#menjaga-agar-fork-kamu-tetap-sinkron)
+      - [Melakukan _Commit_ _Squashing_](#melakukan-commit-squashing)
 
 
 ---
@@ -68,10 +69,9 @@ di GitHub menjadi lebih baik.
 - [Tide] - _Plugin_ Prow yang melakukan manajemen _merge_ dan _test_. [Dashbor Tide]
 - [Perintah Bot] - Perintah yang dapat kamu gunakan untuk berinteraksi dengan Bot Kubernetes (contoh:
   `/cc`, `/lgtm`, dan `/retest`)
-- [_Label_ GitHub] - _List_ _label_ yang digunakan pada proyek Kubernetes
+- [Label GitHub] - _List_ _label_ yang digunakan pada proyek Kubernetes
 - [Pencarian Kode Kubernetes], di-_maintain_ oleh [@dims]
 
-
 ### _Testing_
 
 - [Prow] - Mekanisme CI/CD Kubernetes.
@@ -95,6 +95,7 @@ di GitHub menjadi lebih baik.
 ### Tautan Lain
 
 - [Statistik Pengembang] - Melihat statistik pengembang untuk semua proyek yang dikelola oleh CNCF.
+- [Rilis Patch Kubernetes] Jadwal dan informasi kontak tim untuk rilis _patch_ Kubernetes
 
 ---
 
@@ -150,7 +151,7 @@ atau ikuti [forum Kubernetes].
 - [Perintah Prow][perintah bot]
 
 
-#### Mmebuat Sebuah Isu
+#### Membuat Sebuah Isu
 
 - Gunakan templat isu (jika tersedia). Menggunakan templat yang tersedia akan 
   memudahkan kontributor lain ketika menanggapi isu yang kamu buat.
@@ -288,7 +289,7 @@ pembelajaran yang baik. Sebagai alternatif lain, juga terdapat tutorial [_Stanfo
 - [Git magic]
 - [GitHub workflow]
 - [Testing locally]
-- [Developer guide]
+- [Panduan Pengembang]
 
 
 ### Mekanisme _Branch_
@@ -353,8 +354,8 @@ _squashing_ perlu dilakukan atau tidak.
 [tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
 [asbor tide]: https://prow.k8s.io/tide
 [perintah bot]: https://go.k8s.io/bot-commands
-[gitHub labels]: https://go.k8s.io/github-labels
-[Kubernetes Code Search]: https://cs.k8s.io/
+[Label GitHub]: https://go.k8s.io/github-labels
+[Pencarian Kode Kubernetes]: https://cs.k8s.io/
 [@dims]: https://github.com/dims
 [kalender]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com
 [kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
@@ -364,7 +365,7 @@ _squashing_ perlu dilakukan atau tidak.
 [dasbor triase]: https://go.k8s.io/triage
 [test grid]: https://testgrid.k8s.io
 [velodrome]: https://go.k8s.io/test-health
-[developer statistics]: https://k8s.devstats.cncf.io
+[Statistik Pengembang]: https://k8s.devstats.cncf.io
 [code of conduct]: /code-of-conduct.md
 [_user support request_]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
 [petunjuk _troubleshooting_]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
@@ -390,3 +391,5 @@ _squashing_ perlu dilakukan atau tidak.
 [Tutorial git Atlassian]: https://www.atlassian.com/git/tutorials
 [git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [_Security_ dan _Disclosure_ Informasi]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
+[Rilis Patch Kubernetes]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
\ No newline at end of file
diff --git a/contributors/guide/contributor-cheatsheet/README-ja.md b/contributors/guide/contributor-cheatsheet/README-ja.md
new file mode 100644
index 00000000..ab39c1c1
--- /dev/null
+++ b/contributors/guide/contributor-cheatsheet/README-ja.md
@@ -0,0 +1,339 @@
+# Kubernetesコントリビューターチートシート
+
+Kubernetesにコントリビュートする際のtipsや、Kubernetesプロジェクト内で使用されているベストプラクティスなどの共通リソースのリストです。
+これらのまとめや便利な情報へのクイックリファレンスはGitHubでのコントリビューションの体験をよりよいものにすることでしょう。
+
+**目次**
+- [便利なリソース](#便利なリソース)
+  - [はじめに](#はじめに)
+  - [SIGとその他のグループ](#SIGとその他のグループ)
+  - [コミュニティ](#コミュニティ)
+  - [重要なEメールエイリアス](#重要なEメールエイリアス)
+  - [ワークフロー](#ワークフロー)
+  - [テスト](#テスト)
+  - [その他の便利なリンク](#その他の便利なリンク)
+- [GitHub上での効率的なコミュニケーション](#GitHub上での効率的なコミュニケーション)
+  - [お互いに良くあるためにはどうしたらよいか](#お互いに良くあるためにはどうしたらよいか)
+    - [良いまたは悪いコミュニケーションの例](#良いまたは悪いコミュニケーションの例)
+- [貢献する](#貢献する)
+  - [CLAにサインする](#CLAにサインする)
+  - [Issueを開いたり返事をしたりする](#Issueを開いたり返事をしたりする)
+    - [Issueを作る](#Issueを作る)
+    - [Issueに返事をする](#Issueに返事をする)
+  - [Pull Requestを開く](#Pull-Requestを開く)
+    - [Pull Requestを作成する](#Pull-Requestを作成する)
+    - [PRの説明文の例](#PRの説明文の例)
+    - [Pull Requestのトラブルシューティング](#Pull-Requestのトラブルシューティング)
+  - [ラベル](#ラベル)
+- [ローカルでの作業](#ローカルでの作業)
+  - [ブランチ戦略](#ブランチ戦略)
+    - [Upstreamを追加する](#Upstreamを追加する)
+    - [フォークを最新に保つ](#フォークを最新に保つ)
+  - [コミットをまとめる](#コミットをまとめる)
+
+---
+
+## 便利なリソース
+
+### はじめに
+
+- [コントリビューターガイド] - Kubernetesプロジェクトへコントリビュートする方法のガイド
+- [開発者ガイド] - Kubernetesプロジェクトへコードを直接コントリビュートする方法のガイド
+- [セキュリティと情報開示] - 脆弱性の報告とセキュリティリリースプロセスのガイド
+
+### SIGとその他のグループ
+
+- [グループのリスト][sigs]
+
+### コミュニティ
+
+- [カレンダー] - Kubernetesコミュニティでのイベントの一覧(SIG/WGのミーティングやイベントなど)
+- [kubernetes-dev] - Kubernetes開発メーリングリスト
+- [Kubernetesフォーラム] - Kubernetesの公式フォーラム
+- [Slackチャンネル] - Kubernetesの公式Slack
+- [Stack Overflow] - Kubernetesのエンドユーザーとしての質問を聞く場所
+- [YouTubeチャンネル] - Kubernetesコミュニティの公式チャンネル
+
+
+### ワークフロー
+
+- [Gubernatorダッシュボード] - 注意して見ておくべきPull Requests
+- [Prow] - KubernetesのCI/CDシステム
+- [Tide] - mergeやtestを管理するためのProw用プラグイン [Tideダッシュボード]
+- [Botコマンド] - KubernetesのBotとコミュニケーションをとるためのコマンド (例: `/cc`、`/lgtm`や`/retest`)
+- [GitHubラベル] - Kubernetesプロジェクトで使用されるラベルのリスト
+- [@dims]によって保守されている[Kubernetes Code Search]
+
+
+### テスト
+
+- [Prow] - KubernetesのCI/CDシステム
+- [Test Grid] - 歴史的なテストや関連した情報を見る
+- [Triageダッシュボード] - よりよくトラブルシューティングをするために、似たような失敗をまとめる
+- [Velodrome] - ジョブやテスト結果を追跡するためのダッシュボード
+
+
+### 重要なEメールエイリアス
+
+- community@kubernetes.io - コミュニティの問題について、コミュニティチーム(SIG Contributor Experience)の誰かにメールするアドレス
+- conduct@kubernetes.io - 行動規範委員会へ連絡を取るためのプライベートメーリングリスト
+- steering@kubernetes.io - 運営委員会へメールするアドレスで、公開アーカイブのある公開アドレス
+- steering-private@kubernetes.io - 運営委員会へセンシティブなことを伝えるためのプライベートアドレス
+- social@cncf.io - CNCFソーシャルチームへの連絡先(blogやtwitterアカウントなど)
+
+
+### その他の便利なリンク
+
+- [開発者統計] - CNCFが管理するプロジェクトの開発者統計情報
+
+---
+
+## GitHub上での効率的なコミュニケーション
+
+
+### お互いに良くあるためにはどうしたらよいか
+
+まず最初に[Code of Conduct]をよく読んでください。
+
+
+#### 良いまたは悪いコミュニケーションの例
+
+issueをあげる時や助けを求める時、礼儀正しくしてください:
+
+  🙂 「Yをやった時にXがコンパイルできませんでした。なにかいい方法はありませんか？」
+
+  😞 「Xが動かない！直して！」
+
+PRを閉じるとき、どうしてmergeできないのか、誠心誠意説明し、伝えてください。
+
+🙂 「この機能はXというユースケースをサポートしていないのでこのPRを閉じます。提案された形であれば、Yツールで実装される方がよりよいと思います。」
+
+😞 「どうしてAPI規約に従っていないんですか？これは他でやるべきです！」
+
+---
+
+## 貢献する
+
+### CLAにサインする
+
+コントリビューションを提出する前に、[Contributor License Agreement(CLA)にサインする](cla)必要があります。Kubernetesプロジェクトは、あなたもしくはあなたの会社がCLAにサイン済みの場合にのみコントリビューションの受け入れを行います。
+
+CLAのサインで何か問題があった場合、[CLAトラブルシューティングガイドライン]を参照してください。
+
+
+### Issueを開いたり返事をしたりする
+
+GitHub Issueはバグレポートや改善要求、あるいはテスト失敗のようなその他の問題を追跡するための最初の手段です。[ユーザーによるサポート要求]の方法としては使用**されていません**。そのような場合は[トラブルシューティングガイド]をみて、[Stack Overflow]や[Kubernetesフォーラム]に問題を報告してください。
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+
+
+#### Issueを作る
+
+- もし用意されているなら、Issue templateを使用してください。適切なテンプレートを使用することで、他のコントリビューターが返信しやすくなります。
+  - Issue template自体に書かれている手順に従ってください。
+- 詳細な説明をIssueに記述してください。
+- 適切な[ラベル]を設定してください。よくわからなければ、[k8s-ci-robot][prow]([Kubernetes CI bot][prow])というボットが、重要度を適切に判断するために必要なラベルを提案します。
+- [`/assign @<username>`][assign]か[`/cc @<username>`][cc]を使用して担当者をアサインする場合は選択的に行ってください。より多くの人にアサインをするより、適切なラベルを付ける方が効果的です。
+
+
+#### Issueに返事をする
+
+- Issueに取り組む時は、他の人とバッティングしないように、コメントを残してください。
+- 自己解決した場合には、Issueを閉じる前に他の人にわかるようコメントしてください。
+- 他のPRやIssue(あるいはその他アクセス可能なもの)への参照を含めてください(例えば、 _"ref: #1234"_ のように)。他の場所にある関連した作業を特定するのに便利です。
+
+
+### Pull Requestを開く
+
+Pull request(PR)はコード、ドキュメント、あるいはgitリポジトリに格納されているその他のものに対してコントリビュートする際の主な手段です。
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+- [Pull request process]
+- [GitHub workflow]
+
+
+#### Pull Requestを作成する
+
+- 利用可能な場合、Pull Requestテンプレートの指示に従います。 それはあなたのPRに対応する人々の助けになります。
+- リンク切れやタイプミス、文法の間違いなどの[簡単な修正]の場合、他の可能性のある間違いについてドキュメント全体を見直してください。
+  同じドキュメントの小さな修正で複数のPRを作成しないでください。
+- PRに関連するIssueやPRで解決する可能性があるIssueを参照してください。
+- 一度のコミットで過大な変更を加えないでください。代わりに、PRを複数の小さなコミットに分割してください。
+  これによりPRのレビューが容易になります。
+- 何か説明を加える必要があると思われる場合は、PRにコメントしてください。
+- [`/assign @<username>`][assign]でPRに割り当てるときは選択的にしてください。
+  過剰なレビュー担当者を割り当てたからといって、 迅速なレビューが得られるわけではありません。
+- あなたのPRが _"進行中"_ とされる場合、名前の前に `[WIP]` を付けるか、[`/hold`][hold]コマンドを使用してください。これは `[WIP]` またはHoldが解除されるまでPRがマージされるのを防ぎます。
+- あなたのPRがレビューされてない場合に、閉じて同じ変更のPRを新しく作成しないでください。`@<github username>` とコメントでレビュアーにPingしてください。
+
+
+
+#### PRの説明文の例
+
+```
+Ref. #3064 #3097
+All files owned by SIG testing were moved from `/devel` to the new folder `/devel/sig-testing`.
+
+/sig contributor-experience
+/cc @stakeholder1 @stakeholder2
+/kind cleanup
+/area developer-guide
+/assign @approver1 @approver2 @approver3
+```
+
+PRの内容:
+- **1行目** - 他のIssueやPRへの参照(#3064 #3097)
+- **2行目** - PRで行われていることの簡単な説明
+- **4行目** - `/sig contributor-experience` [コマンド]での[SIG][sigs]の割り当て
+- **5行目** - この特定のIssueやPRに関心があるレビュアーを[`/cc`][cc]コマンドで指定
+- **6行目** - [`/kind cleanup`][kind]コマンドでコードやプロセス、技術的負債の整理に関してIssueやPRを分類する[ラベル][ラベル]を追加
+- **7行目** - [`/area developer-guide`][kind]コマンドで開発者ガイドに関してIssueやPRを分類
+- **8行目** - [`/assign`][assign]コマンドでPRにApproverを割り当て。
+  Approverは[k8s-ci-robot][prow]によって提案され、[OWNERS]ファイルのオーナーのリストから選択されます。
+  Approverはレビューされた後のPRに[`/approve`][approve]ラベルを追加します
+
+#### Pull Requestのトラブルシューティング
+
+PRが作成された後、KubernetesのCIプラットフォームの[Prow]によって一連のテスト
+が実行されます。テストのいずれかが失敗した場合、[k8s-ci-robot][prow]は
+失敗したテストへのリンクと有効なログをPRに返信します。
+
+新しいコミットをPRにがプッシュすると、自動的にテストが再実行されます。
+
+時折KubernetesのCIプラットフォームに問題がある場合があります。
+あなたの貢献が全てのローカルテストに合格したとしても、
+これらは様々な理由で発生する場合があります。`/retest` コマンドでテストを
+再実行することができます。
+
+特定のテストのトラブルシューティングの詳細については[テストガイド]を参照してください。
+
+### ラベル
+
+KubernetesはIssueとPull Requestを分類し、優先順位を付けるために[ラベル]を使用します。
+正しいラベルを付けることであなたのIssueやPRをより効果的に処理することができます。
+
+
+**参考:**
+- [ラベル]
+- [Prowコマンド][コマンド]
+
+よく使われるラベル:
+- [`/sig <sig name>`][kind]はIssueやPRのアサインを[SIG][SIGs]に割り当てます。
+- [`/area <area name>`][kind]はIssueやPRを特定の[分野][ラベル]に関連付けます。
+- [`/kind <category>`][kind]はIssueやPRを[分類][ラベル]します。
+
+---
+
+## ローカルでの作業
+
+Pull Requestを作成する前に、ローカルである程度の作業を行う必要があります。
+もしあなたがgitに慣れていない場合、[Atlassian gitチュートリアル]は良い出発点です。
+他に、Stanfordの[Git magic]チュートリアルは多言語に対応しています。
+
+**参考:**
+- [Atlassian gitチュートリアル]
+- [Git magic]
+- [GitHub workflow]
+- [ローカルでのテスト]
+- [開発者ガイド]
+
+
+### ブランチ戦略
+
+KubernetesプロジェクトはGitHubの標準である _"Fork and Pull"_ ワークフローを使います。
+gitの用語で、あなたの個人的なフォークは _"`origin`"_ と呼ばれ、実際のプロジェクトの
+gitリポジトリのことを _"`upstream`"_ と呼ばれます。
+あなたの個人的なブランチ(`origin`)をプロジェクト(`upstream`)の最新に保つために、
+ローカルの作業コピー内で設定されてなければなりません。
+
+
+#### Upstreamを追加する
+
+`upstream` をリモートとして追加し、プッシュできないように設定してください。
+
+```
+# replace <upstream git repo> with the upstream repo url
+# example:
+#  https://github.com/kubernetes/kubernetes.git
+#  git@github.com/kubernetes/kubernetes.git
+
+git remote add upstream <upstream git repo>
+git remote set-url --push upstream no_push
+```
+
+これは設定したリモートを一覧表示する `git remote -v` を実行して確認することができます。
+
+
+#### フォークを最新に保つ
+
+`upstream` から全ての変更を取得し、ローカルの `master` ブランチに _"rebase"_ します。
+これはローカルのリポジトリを `upstream` プロジェクトと同期させます。
+
+```
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+あなたは機能への取り組みや修正をするためにブランチを作成する前に、最低限これをやるべきです。
+
+```
+git checkout -b myfeature
+```
+
+#### コミットをまとめる
+
+[スカッシュコミット]の主な目的はきれいに読めるgitの履歴や加えられた変更のログを作成することです。通常これはPRの改定の最終段階に行われます。
+コミットをスカッシュするべきかわからない場合は、作業を止めてPRのレビューと承認を担当する他のコントリビューターの判断に任せることをおすすめします。
+
+
+[コントリビューターガイド]: /contributors/guide/README.md
+[開発者ガイド]: /contributors/devel/README.md
+[gubernatorダッシュボード]: https://gubernator.k8s.io/pr
+[prow]: https://prow.k8s.io
+[tide]: http://git.k8s.io/test-infra/prow/cmd/tide/pr-authors.md
+[tideダッシュボード]: https://prow.k8s.io/tide
+[botコマンド]: https://go.k8s.io/bot-commands
+[GitHubラベル]: https://go.k8s.io/github-labels
+[Kubernetes Code Search]: https://cs.k8s.io/
+[@dims]: https://github.com/dims
+[カレンダー]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com
+[kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
+[slackチャンネル]: http://slack.k8s.io/
+[Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes
+[youtubeチャンネル]: https://www.youtube.com/c/KubernetesCommunity/
+[triageダッシュボード]: https://go.k8s.io/triage
+[test grid]: https://testgrid.k8s.io
+[velodrome]: https://go.k8s.io/test-health
+[開発者統計]: https://k8s.devstats.cncf.io
+[code of conduct]: /code-of-conduct.md
+[ユーザーによるサポート要求]: /contributors/guide/issue-triage.md#determine-if-its-a-support-request
+[トラブルシューティングガイド]: https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/
+[kubernetesフォーラム]: https://discuss.kubernetes.io/
+[pull request process]: /contributors/guide/pull-requests.md
+[github workflow]: /contributors/guide/github-workflow.md
+[prow]: https://git.k8s.io/test-infra/prow#prow
+[cla]: /CLA.md#how-do-i-sign
+[claトラブルシューティングガイドライン]: /CLA.md#troubleshooting
+[コマンド]: https://prow.k8s.io/command-help
+[kind]: https://prow.k8s.io/command-help#kind
+[cc]: https://prow.k8s.io/command-help#cc
+[hold]: https://prow.k8s.io/command-help#hold
+[assign]: https://prow.k8s.io/command-help#assign
+[SIGs]: /sig-list.md
+[テストガイド]: /contributors/devel/sig-testing/testing.md
+[ラベル]: https://git.k8s.io/test-infra/label_sync/labels.md
+[簡単な修正]: /contributors/guide/pull-requests.md#10-trivial-edits
+[GitHub workflow]: /contributors/guide/github-workflow.md#3-branch
+[スカッシュコミット]: /contributors/guide/pull-requests.md#6-squashing-and-commit-titles
+[owners]: /contributors/guide/owners.md
+[ローカルでのテスト]: /contributors/guide/README.md#testing
+[Atlassian gitチュートリアル]: https://www.atlassian.com/git/tutorials
+[git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
+[セキュリティと情報開示]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-ko.md b/contributors/guide/contributor-cheatsheet/README-ko.md
index 2d33bda9..9a541dd5 100644
--- a/contributors/guide/contributor-cheatsheet/README-ko.md
+++ b/contributors/guide/contributor-cheatsheet/README-ko.md
@@ -394,3 +394,4 @@ PR을 검토하고 승인하도록 지정된 다른 참여자의 판단에 맡�
 [Atlassian git 튜토리얼]: https://www.atlassian.com/git/tutorials
 [git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [보안과 정보 공개]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-pt.md b/contributors/guide/contributor-cheatsheet/README-pt.md
index a66ffaa0..1388f404 100644
--- a/contributors/guide/contributor-cheatsheet/README-pt.md
+++ b/contributors/guide/contributor-cheatsheet/README-pt.md
@@ -375,3 +375,4 @@ fase de uma revisão do PR. Se você não tem certeza se deve efetuar o squashin
 [Tutorial git Atlassian]: https://www.atlassian.com/git/tutorials
 [Tutorial git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [Informações de Segurança e Divulgações]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README-zh.md b/contributors/guide/contributor-cheatsheet/README-zh.md
index 8c86dfcb..65ef556e 100644
--- a/contributors/guide/contributor-cheatsheet/README-zh.md
+++ b/contributors/guide/contributor-cheatsheet/README-zh.md
@@ -326,3 +326,4 @@ git checkout -b myfeature
 [Atlassian git 教程]: https://www.atlassian.com/git/tutorials
 [git 魔法]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [安全和披露信息]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
diff --git a/contributors/guide/contributor-cheatsheet/README.md b/contributors/guide/contributor-cheatsheet/README.md
index bef061d0..d5e2f460 100644
--- a/contributors/guide/contributor-cheatsheet/README.md
+++ b/contributors/guide/contributor-cheatsheet/README.md
@@ -1,6 +1,6 @@
 # Kubernetes Contributor Cheat Sheet
 
-[Bahasa Indonesia](README-id.md) | [한국어](README-ko.md) | [Português](README-pt.md) | [中文](README-zh.md)
+[Deutsch](README-de.md) | [Français](README-fr.md) | [Bahasa Indonesia](README-id.md) | [日本語](README-ja.md) | [한국어](README-ko.md) | [Português](README-pt.md) | [中文](README-zh.md)
 
 A list of common resources when contributing to Kubernetes, tips, tricks, and
 common best practices used within the Kubernetes project. It is a "TL;DR" or
@@ -8,32 +8,33 @@ quick reference of useful information to make your GitHub contribution experienc
 better.
 
 **Table of Contents**
-- [Helpful Resources](#Helpful-Resources)
-  - [Getting Started](#Getting-Started)
-  - [SIGs and other Groups](#SIGS-and-Other-Groups)
-  - [Community](#Community)
-  - [Important Email Aliases](#Important-Email-Aliases)
-  - [Workflow](#Workflow)
-  - [Tests](#Tests)
-  - [Other Useful Links](#Other-Useful-Links)
-- [Communicating effectively on GitHub](#Communicating-Effectively-on-GitHub)
-  - [How to be Excellent to Each Other](#How-to-be-Excellent-to-Each-Other)
-    - [Examples of Good/Bad Communication](#Examples-of-GoodBad-Communication)
-- [Submitting a Contribution](#Submitting-a-Contribution)
-  - [Signing the CLA](#signing-the-CLA)
-  - [Opening and Responding to Issues](#Opening-and-Responding-to-Issues)
-    - [Creating an Issue](#Creating-an-Issue)
-    - [Responding to an Issue](#Responding-to-an-Issue)
-  - [Opening a Pull Request](#Opening-a-pull-Request)
-    - [Creating a Pull Request](#Creating-a-Pull-Request)
-    - [Example PR Description](#Example-PR-Description)
-    - [Troubleshooting a Pull Request](#Troubleshooting-a-Pull-Request)
-  - [Labels](#Labels)
-- [Working Locally](#Working-Locally)
-  - [Branch Strategy](#Branch-Strategy)
-    - [Adding Upstream](#Adding-Upstream)
-    - [Keeping Your Fork in Sync](#Keeping-Your-Fork-in-Sync)
-  - [Squashing Commits](#Squashing-Commits)
+- [Kubernetes Contributor Cheat Sheet](#kubernetes-contributor-cheat-sheet)
+  - [Helpful Resources](#helpful-resources)
+    - [Getting Started](#getting-started)
+    - [SIGs and Other Groups](#sigs-and-other-groups)
+    - [Community](#community)
+    - [Workflow](#workflow)
+    - [Tests](#tests)
+    - [Important Email Aliases](#important-email-aliases)
+    - [Other Useful Links](#other-useful-links)
+  - [Communicating Effectively on GitHub](#communicating-effectively-on-github)
+    - [How to be Excellent to Each Other](#how-to-be-excellent-to-each-other)
+      - [Examples of Good/Bad Communication](#examples-of-goodbad-communication)
+  - [Submitting a Contribution](#submitting-a-contribution)
+    - [Signing the CLA](#signing-the-cla)
+    - [Opening and Responding to Issues](#opening-and-responding-to-issues)
+      - [Creating an Issue](#creating-an-issue)
+      - [Responding to an Issue](#responding-to-an-issue)
+    - [Opening a Pull Request](#opening-a-pull-request)
+      - [Creating a Pull Request](#creating-a-pull-request)
+      - [Example PR Description](#example-pr-description)
+      - [Troubleshooting a Pull Request](#troubleshooting-a-pull-request)
+    - [Labels](#labels)
+  - [Working Locally](#working-locally)
+    - [Branch Strategy](#branch-strategy)
+      - [Adding Upstream](#adding-upstream)
+      - [Keeping Your Fork in Sync](#keeping-your-fork-in-sync)
+      - [Squashing Commits](#squashing-commits)
 
 ---
 
@@ -90,6 +91,8 @@ better.
   Experience) about a community issue.
 - conduct@kubernetes.io - Contact the Code of Conduct committee, private mailing
   list.
+- github@kubernetes.io - Mail the [GitHub Administration Team] privately,
+  for sensitive items.
 - steering@kubernetes.io - Mail the steering committee. Public address with
   public archive.
 - steering-private@kubernetes.io - Mail the steering committee privately, for
@@ -102,6 +105,7 @@ better.
 
 - [Developer Statistics] - View developer statistics for all CNCF managed
   projects.
+- [Kubernetes Patch Release] Schedule and team contact information for Kubernetes patch releases.
 
 ---
 
@@ -395,3 +399,6 @@ the other contributors assigned to review and approve your PR.
 [Atlassian git tutorial]: https://www.atlassian.com/git/tutorials
 [git magic]: http://www-cs-students.stanford.edu/~blynn/gitmagic/
 [Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/
+[approve]: https://prow.k8s.io/command-help#approve
+[GitHub Administration Team]: /github-management#github-administration-team
+[Kubernetes Patch Release]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
\ No newline at end of file
diff --git a/contributors/guide/community-expectations.md b/contributors/guide/expectations.md
index 6a7922fc..dabbb248 100644
--- a/contributors/guide/community-expectations.md
+++ b/contributors/guide/expectations.md
@@ -54,6 +54,8 @@ to them.  Reviewers are expected to respond to an *active* PRs with reasonable
 latency, and if reviewers fail to respond, those PRs may be assigned to other
 reviewers.
 
+If reviewers are unavailable to review for some time, they are expected to set their [user status](https://help.github.com/en/articles/personalizing-your-profile#setting-a-status) to "busy" so that the bot will not request reviews from them on new PRs automatically. If they are unavailable for a longer period of time, they are expected to remove themselves from the OWNERS file and potentially nominate someone else.
+
 *Active* PRs are considered those which have a proper CLA (`cla:yes`) label
 and do not need rebase to be merged.  PRs that do not have a proper CLA, or
 require a rebase are not considered active PRs.
diff --git a/contributors/guide/github-workflow.md b/contributors/guide/github-workflow.md
index 48a67fa3..8174aaf8 100644
--- a/contributors/guide/github-workflow.md
+++ b/contributors/guide/github-workflow.md
@@ -107,7 +107,7 @@ in a few cycles.
 
 ### 6 Push
 
-When ready to review (or just to establish an offsite backup or your work),
+When ready to review (or just to establish an offsite backup of your work),
 push your branch to your fork on `github.com`:
 
 ```sh
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md
index 04f30950..cbd18677 100644
--- a/contributors/guide/issue-triage.md
+++ b/contributors/guide/issue-triage.md
@@ -71,8 +71,8 @@ If you see support questions on kubernetes-dev@googlegroups.com or issues asking
 support try to redirect them to Stack Overflow. Example response:
 
 ```code
-Please re-post your question to [Stack Overflow]
-(http://stackoverflow.com/questions/tagged/kubernetes).
+Please re-post your question to [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+or our [Discussion Forums](https://discuss.kubernetes.io).
 
 We are trying to consolidate the channels to which questions for help/support
 are posted so that we can improve our efficiency in responding to your requests,
@@ -84,8 +84,8 @@ thread only in one place or, worse, spread across multiple forums. Also, the
 large volume of support issues on GitHub is making it difficult for us to use
 issues to identify real bugs.
 
-Members of the Kubernetes community use Stack Overflow to field support
-requests. Before posting a new question, please search Stack Overflow for answers
+Members of the Kubernetes community use Stack Overflow and Discussion Forums to field
+support requests. Before posting a new question, please search these for answers
 to similar questions, and also familiarize yourself with:
 
   * [user documentation](https://kubernetes.io/docs/home/)
diff --git a/contributors/guide/non-code-contributions.md b/contributors/guide/non-code-contributions.md
index a110090a..43fd10e2 100644
--- a/contributors/guide/non-code-contributions.md
+++ b/contributors/guide/non-code-contributions.md
@@ -14,7 +14,7 @@ slug: "non-code"
 
 The list below is meant to help non-code contributors find areas of the Kubernetes project where their expertise can be best utilized. The goal of this is to both provide a starting guide for anyone looking to become a contributor not necessarily writing code, and also to fill any needs that the SIGs have that might not currently be filled by code-focused contributors.
 
-This list is meant to be used by both new contributors looking for a good entrance into the project, and current contributors who would live to do something different.
+This list is meant to be used by both new contributors looking for a good entrance into the project, and current contributors who would like to do something different.
 
 Are you interested in any of the roles below? Come chat with us [on Slack](https://kubernetes.slack.com/messages/sig-contribex)!
 
diff --git a/contributors/guide/pull-requests.md b/contributors/guide/pull-requests.md
index 1b5f6fc7..d2e252c8 100644
--- a/contributors/guide/pull-requests.md
+++ b/contributors/guide/pull-requests.md
@@ -1,10 +1,10 @@
 ---
 title: "Pull Request Process"
 weight: 1
-slug: "pull-requests" 
+slug: "pull-requests"
 ---
 
-This doc explains the process and best practices for submitting a pull request to the [Kubernetes project](https://github.com/kubernetes/kubernetes) and its associated subrepositories. It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
+This doc explains the process and best practices for submitting a pull request to the [Kubernetes project](https://github.com/kubernetes/kubernetes) and its associated sub-repositories. It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
 
 - [Before You Submit a Pull Request](#before-you-submit-a-pull-request)
   * [Run Local Verifications](#run-local-verifications)
@@ -33,7 +33,7 @@ This doc explains the process and best practices for submitting a pull request t
 
 This guide is for contributors who already have a pull request to submit. If you're looking for information on setting up your developer environment and creating code to contribute to Kubernetes, see the [development guide](/contributors/devel/development.md).
 
-First time contributors should head to the [Contributor Guide](/contributors/guide/README.md) to get started.
+First-time contributors should head to the [Contributor Guide](/contributors/guide/README.md) to get started.
 
 **Make sure your pull request adheres to our best practices. These include following project conventions, making small pull requests, and commenting thoroughly. Please read the more detailed section on [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) at the end of this doc.**
 
@@ -54,7 +54,7 @@ Merging a pull request requires the following steps to be completed before the p
 - [Open a pull request](https://help.github.com/articles/about-pull-requests/)
   - *For kubernetes/kubernetes repository only:* Add [release notes](/contributors/guide/release-notes.md) if needed.
 - Pass all e2e tests
-- Get all necessary approvals from reviewers and code owners 
+- Get all necessary approvals from reviewers and code owners
 
 ## The Testing and Merge Workflow
 
@@ -82,7 +82,7 @@ Here's the process the pull request goes through on its way from submission to m
 
 1. Reviewer suggests edits
 1. Push edits to your pull request branch
-1. Repeat the prior two steps as needed until reviewer(s) add `/lgtm` label. The `/lgtm` label, when applied by someone listed as an `reviewer` in the corresponding project `OWNERS` file, is a signal that the code has passed review from one or more trusted reviewers for that project
+1. Repeat the prior two steps as needed until the reviewer(s) add `/lgtm` label. The `/lgtm` label, when applied by someone listed as a `reviewer` in the corresponding project `OWNERS` file, is a signal that the code has passed review from one or more trusted reviewers for that project
 1. (Optional) Some reviewers prefer that you squash commits at this step
 1. Follow the bot suggestions to assign an OWNER who will add the `/approve` label to the pull request. The `/approve` label, when applied by someone listed as an `approver` in the corresponding project `OWNERS`, is a signal that the code has passed final review and is ready to be automatically merged
 
@@ -119,7 +119,7 @@ The GitHub robots will add and remove the `do-not-merge/hold` label as you use t
 
 ## Pull Requests and the Release Cycle
 
-If a pull request has been reviewed, but held or not approved, it might be due to the current phase in the [Release Cycle](/contributors/devel/sig-release/release.md). Occasionally, a SIG may freeze their own code base when working towards a specific feature or goal that could impact other development. During this time, your pull request could remain unmerged while their release work is completed.
+If a pull request has been reviewed but held or not approved, it might be due to the current phase in the [Release Cycle](/contributors/devel/sig-release/release.md). Occasionally, a SIG may freeze their own code base when working towards a specific feature or goal that could impact other development. During this time, your pull request could remain unmerged while their release work is completed.
 
 If you feel your pull request is in this state, contact the appropriate [SIG](https://git.k8s.io/community/sig-list.md) or [SIG-Release](https://git.k8s.io/sig-release) for clarification.
 
@@ -167,7 +167,7 @@ things you can do to move the process along:
 
    * Ping the assignee by email (many of us have publicly available email addresses).
 
-   * If you're a member of the organization ping the [team](https://github.com/orgs/kubernetes/teams) (via @team-name) that works in the area you're submitting code.
+   * If you're a member of the organization ping the [team](https://github.com/orgs/kubernetes/teams) (via @team-name) that works in the area you're submitting code to.
 
    * If you have fixed all the issues from a review, and you haven't heard back, you should ping the assignee on the comment stream with a "please take another look" (`PTAL`) or similar comment indicating that you are ready for another review.
 
@@ -193,7 +193,7 @@ Are you sure Feature-X is something the Kubernetes team wants or will accept? Is
 
 It's better to get confirmation beforehand.
 
-When you want to make a large or otherwise significant change, you should follow the [Kubernetes Enhancement Proposal process](/keps/0001-kubernetes-enhancement-proposal-process.md).
+When you want to make a large or otherwise significant change, you should follow the [Kubernetes Enhancement Proposal process](https://git.k8s.io/enhancements/keps/0001-kubernetes-enhancement-proposal-process.md).
 
 Even for small changes, it is often a good idea to gather feedback on an issue you filed, or even simply ask in the appropriate SIG's Slack channel to invite discussion and feedback from code owners. Here's a [list of SIGs](/sig-list.md).
 
@@ -253,7 +253,7 @@ Read up on [GoDoc](https://blog.golang.org/godoc-documenting-go-code) - follow t
 
 ## 5. Test
 
-Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few pull requests can touch code and NOT touch tests.
+Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few pull requests can touch the code and NOT touch tests.
 
 If you don't know how to test Feature-X, please ask!  We'll be happy to help you design things for easy testing or to suggest appropriate test cases.
 
@@ -302,10 +302,9 @@ Each incoming Pull Request needs to be reviewed, checked, and then merged.
 
 While automation helps with this, each contribution also has an engineering cost. Therefore it is appreciated if you do NOT make trivial edits and fixes, but instead focus on giving the entire file a review.
 
-If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file.
+If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking the formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file.
 
 **Some questions to consider:**
 
 * Can the file be improved further?
 * Does the trivial edit greatly improve the quality of the content?
-
diff --git a/contributors/guide/style-guide.md b/contributors/guide/style-guide.md
index babb8eb3..38acb36c 100644
--- a/contributors/guide/style-guide.md
+++ b/contributors/guide/style-guide.md
@@ -21,7 +21,7 @@ These are **guidelines**, not rules. Use your best judgement.
   - [Punctuation](#punctuation)
   - [Quotation](#quotation)
 - [Markdown formatting](#markdown-and-formatting)
-  - [Code Blocks](code-blocks)
+  - [Code Blocks](#code-blocks)
   - [Emphasis](#emphasis)
   - [Headings](#headings)
   - [Horizontal Lines](#horizontal-lines)
@@ -176,7 +176,7 @@ These are **guidelines**, not rules. Use your best judgement.
 - When inserting a code block into an ordered list, indent (space) an additional
   two times.
 
-**[Metadata:](metadata)**
+**[Metadata:](#metadata)**
 - If the document is intended to be surfaced on the Contributor Site; include a
   yaml metadata header at the beginning of the document.
 - Metadata must include the `title` attribute.