summaryrefslogtreecommitdiff
path: root/contributors/guide
diff options
context:
space:
mode:
authorKubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>2020-06-17 04:26:40 -0700
committerGitHub <noreply@github.com>2020-06-17 04:26:40 -0700
commite3dcfc386982e9c858ed361c50f33dbd659d26ab (patch)
treee92451987da9cb0370b449d07c95d9be25744143 /contributors/guide
parent41a249060ae9a32afee4a0aea1be5c5bd12358fd (diff)
parentad6f50497200983dc6d3f0ffe2dde8f427d88ac2 (diff)
Merge pull request #4866 from mrbobbytables/remove-collab
Remove outdated collaboration doc
Diffstat (limited to 'contributors/guide')
-rw-r--r--contributors/guide/collab.md32
1 files changed, 0 insertions, 32 deletions
diff --git a/contributors/guide/collab.md b/contributors/guide/collab.md
deleted file mode 100644
index 4c80ff88..00000000
--- a/contributors/guide/collab.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: "Collaborative Development"
-weight: 7
-slug: "collab"
----
-
-## Code reviews
-
-All changes must be code reviewed. For non-maintainers this is obvious, since
-you can't commit anyway. But even for maintainers, we want all changes to get at
-least one review, preferably (for non-trivial changes obligatorily) from someone
-who knows the areas the change touches. For non-trivial changes we may want two
-reviewers. The primary reviewer will make this decision and nominate a second
-reviewer, if needed. Except for trivial changes, PRs should not be committed
-until relevant parties (e.g. owners of the subsystem affected by the PR) have
-had a reasonable chance to look at PR in their local business hours.
-
-Most PRs will find reviewers organically. If a maintainer intends to be the
-primary reviewer of a PR they should set themselves as the assignee on GitHub
-and say so in a reply to the PR. Only the primary reviewer of a change should
-actually do the merge, except in rare cases (e.g. they are unavailable in a
-reasonable timeframe).
-
-If a PR has gone 2 work days without an owner emerging, please poke the PR
-thread and ask for a reviewer to be assigned.
-
-Except for rare cases, such as trivial changes (e.g. typos, comments) or
-emergencies (e.g. broken builds), maintainers should not merge their own
-changes.
-
-Expect reviewers to request that you avoid [common go style
-mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.