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

Merge pull request #3099 from eduartua/issue-3064-2 

File moved (k/community/contributors/devel/collab.md) - Created tombstone file and updated URL in other files
This commit is contained in:
Kubernetes Prow Robot 2019-01-15 18:23:03 -08:00 committed by GitHub
parent acf6259d43 a156dd1034
commit 06ff392d18
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 40 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
community-membership.md
View File

@ -223,7 +223,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/devel/collab.md
[code reviews]: /contributors/guide/collab.md
[community expectations]: /contributors/guide/community-expectations.md
[contributor guide]: /contributors/guide/README.md
[Kubernetes GitHub Admin team]: /github-management/README.md#github-administration-team

36
contributors/devel/collab.md
View File

@ -1,35 +1,3 @@
# On Collaborative Development
This document has moved to: [here](https://git.k8s.io/community/contributors/guide/collab.md).
## 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.
## Assigned reviews
Maintainers can assign reviews to other maintainers, when appropriate. The
assignee becomes the shepherd for that PR and is responsible for merging the PR
once they are satisfied with it or else closing it. The assignee might request
reviews from non-maintainers.
*This file is a redirect stub. It should be deleted within 3 months from the current date.*

2
contributors/guide/README.md
View File

@ -159,7 +159,7 @@ If you find that this is not the case, please complain loudly.
As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays.
Please do not ever hesitate to ask a question or send a pull request.
Check out our [community guiding principles](/contributors/devel/collab.md) on how to create great code as a big group.
Check out our [community guiding principles](/contributors/guide/collab.md) on how to create great code as a big group.
Beginner focused information can be found below in [Open a Pull Request](#open-a-pull-request) and [Code Review](#code-review).

35
contributors/guide/collab.md Normal file
View File

@ -0,0 +1,35 @@
# On Collaborative Development
## 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.
## Assigned reviews
Maintainers can assign reviews to other maintainers, when appropriate. The
assignee becomes the shepherd for that PR and is responsible for merging the PR
once they are satisfied with it or else closing it. The assignee might request
reviews from non-maintainers.

2
mentoring/group-mentee-guide.md
View File

@ -70,7 +70,7 @@ Suggested Activity
- k/community is your friend for upstream workflows, processes, and information around contributing
- This repo includes the community/devel folder which will be extra helpful that includes docs such as:
- [Code Review Expectations](/contributors/guide/community-expectations.md)
- [Collaboration on k8s](/contributors/devel/collab.md)
- [Collaboration on k8s](/contributors/guide/collab.md)
### Test Cohort Special Circumstances & Notes