kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
This commit is contained in:
Bob Killen 2020-06-16 18:29:00 -04:00
parent 4ae5e6fafd
commit ad6f504972
No known key found for this signature in database
GPG Key ID: 850FEB9A6356D2F6
2 changed files with 1 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
community-membership.md
View File

@ -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

32
contributors/guide/collab.md
View File

@ -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.