diff options
| author | Bob Killen <bob.killen@linux.com> | 2020-06-16 18:29:00 -0400 |
|---|---|---|
| committer | Bob Killen <bob.killen@linux.com> | 2020-06-16 18:29:00 -0400 |
| commit | ad6f50497200983dc6d3f0ffe2dde8f427d88ac2 (patch) | |
| tree | 55b50cf85aa3f00d30175daddec90a23f03272e8 | |
| parent | 4ae5e6fafde894d3728ebf68a71da5d824406d7e (diff) | |
Remove outdated collaboration doc
The contents of collab.md are out of date and the intent of the document
is better captured in some of the other docs such as expectations.md[1],
pull-requests.md[2] and review-guidelines.md[3].
[1] https://git.k8s.io/community/contributors/guide/expectations.md
[2] https://git.k8s.io/community/contributors/guide/pull-requests.md
[3] https://git.k8s.io/community/contributors/guide/review-guidelines.md
| -rw-r--r-- | community-membership.md | 2 | ||||
| -rw-r--r-- | contributors/guide/collab.md | 32 |
2 files changed, 1 insertions, 33 deletions
diff --git a/community-membership.md b/community-membership.md index 5dd538da..4b5143e5 100644 --- a/community-membership.md +++ b/community-membership.md @@ -227,7 +227,7 @@ The following apply to the subproject for which one would be an owner. The Maintainer role has been removed and replaced with a greater focus on [OWNERS]. -[code reviews]: /contributors/guide/collab.md +[code reviews]: /contributors/guide/expectations.md#code-review [community expectations]: /contributors/guide/expectations.md [contributor guide]: /contributors/guide/README.md [Kubernetes GitHub Admin team]: /github-management/README.md#github-administration-team 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. |