From 774750b5d22b16203a0ea18d352821cb0aa7d43a Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Mon, 22 Jan 2018 10:34:16 -0500 Subject: Moving and revising community expectations --- contributors/devel/community-expectations.md | 81 --------------------------- contributors/guide/README.md | 17 +++--- contributors/guide/community-expectations.md | 84 ++++++++++++++++++++++++++++ 3 files changed, 91 insertions(+), 91 deletions(-) delete mode 100644 contributors/devel/community-expectations.md create mode 100644 contributors/guide/community-expectations.md diff --git a/contributors/devel/community-expectations.md b/contributors/devel/community-expectations.md deleted file mode 100644 index 45200bc1..00000000 --- a/contributors/devel/community-expectations.md +++ /dev/null @@ -1,81 +0,0 @@ -## Community Expectations - -Kubernetes is a community project. Consequently, it is wholly dependent on -its community to provide a productive, friendly and collaborative environment. - -The first and foremost goal of the Kubernetes community to develop orchestration -technology that radically simplifies the process of creating reliable -distributed systems. However a second, equally important goal is the creation -of a community that fosters easy, agile development of such orchestration -systems. - -We therefore describe the expectations for -members of the Kubernetes community. This document is intended to be a living one -that evolves as the community evolves via the same PR and code review process -that shapes the rest of the project. It currently covers the expectations -of conduct that govern all members of the community as well as the expectations -around code review that govern all active contributors to Kubernetes. - -### Code of Conduct - -The most important expectation of the Kubernetes community is that all members -abide by the Kubernetes [community code of conduct](../../governance.md#code-of-conduct). -Only by respecting each other can we develop a productive, collaborative -community. - -### Code review - -As a community we believe in the [value of code review for all contributions](collab.md). -Code review increases both the quality and readability of our codebase, which -in turn produces high quality software. - -However, the code review process can also introduce latency for contributors -and additional work for reviewers that can frustrate both parties. - -Consequently, as a community we expect that all active participants in the -community will also be active reviewers. - -We ask that active contributors to the project participate in the code review process -in areas where that contributor has expertise. Active -contributors are considered to be anyone who meets any of the following criteria: - * Sent more than two pull requests (PRs) in the previous one month, or more - than 20 PRs in the previous year. - * Filed more than three issues in the previous month, or more than 30 issues in - the previous 12 months. - * Commented on more than five pull requests in the previous month, or - more than 50 pull requests in the previous 12 months. - * Marked any PR as LGTM in the previous month. - * Have *collaborator* permissions in the Kubernetes github project. - -In addition to these community expectations, any community member who wants to -be an active reviewer can also add their name to an *active reviewer* file -(location tbd) which will make them an active reviewer for as long as they -are included in the file. - -#### Expectations of reviewers: Review comments - -Because reviewers are often the first points of contact between new members of -the community and can significantly impact the first impression of the -Kubernetes community, reviewers are especially important in shaping the -Kubernetes community. Reviewers are highly encouraged to review the -[code of conduct](../../governance.md#code-of-conduct) and are strongly encouraged to go above -and beyond the code of conduct to promote a collaborative, respectful -Kubernetes community. - -#### Expectations of reviewers: Review latency - -Reviewers are expected to respond in a timely fashion to PRs that are assigned -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. - -*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. - -## Thanks - -Many thanks in advance to everyone who contributes their time and effort to -making Kubernetes both a successful system as well as a successful community. -The strength of our software shines in the strengths of each individual -community member. Thanks! diff --git a/contributors/guide/README.md b/contributors/guide/README.md index a66c3aa0..341e9fca 100644 --- a/contributors/guide/README.md +++ b/contributors/guide/README.md @@ -43,24 +43,21 @@ Welcome to Kubernetes! This document is the single source of truth for how to co Before you can contribute, you will need to sign the [Contributor License Agreement](/CLA.md). -## Setting up your development environment +## Code of Conduct + +Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). -If you haven’t set up your environment, please find resources [here](/contributors/devel). These resources are not well organized currently; please have patience as we are working on it. +## Setting up your development environment +If you haven’t set up your environment, please find resources [here](/contributors/devel). ## Community Expectations Kubernetes is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment. -The first and foremost goal of the Kubernetes community to develop orchestration technology that radically simplifies the process of creating reliable distributed systems. However a second, equally important goal is the creation of a community that fosters easy, agile development of such orchestration systems. - -We therefore describe the expectations for members of the Kubernetes community. This document is intended to be a living one that evolves as the community evolves via the same pull request and code review process that shapes the rest of the project. It currently covers the expectations of conduct that govern all members of the community as well as the expectations around code review that govern all active contributors to Kubernetes. - -### Code of Conduct - -Please make sure to read and observe our [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) +Read and review the [Community Expectations](/community-expectations.md) for an understand of code and review expectations. -### Thanks +## Thanks Many thanks in advance to everyone who contributes their time and effort to making Kubernetes both a successful system as well as a successful community. The strength of our software shines in the strengths of each individual community member. Thanks! diff --git a/contributors/guide/community-expectations.md b/contributors/guide/community-expectations.md new file mode 100644 index 00000000..39d2da73 --- /dev/null +++ b/contributors/guide/community-expectations.md @@ -0,0 +1,84 @@ +# Community Expectations + +Kubernetes is a community project. Consequently, it is wholly dependent on +its community to provide a productive, friendly and collaborative environment. + +The first and foremost goal of the Kubernetes community to develop orchestration +technology that radically simplifies the process of creating reliable +distributed systems. However a second, equally important goal is the creation +of a community that fosters easy, agile development of such orchestration +systems. + +We therefore describe the expectations for +members of the Kubernetes community. This document is intended to be a living one +that evolves as the community evolves via the same PR and code review process +that shapes the rest of the project. It currently covers the expectations +of conduct that govern all members of the community as well as the expectations +around code review that govern all active contributors to Kubernetes. + +## Code review + +As a community we believe in the value of code review for all contributions. +Code review increases both the quality and readability of our codebase, which +in turn produces high quality software. + +However, the code review process can also introduce latency for contributors +and additional work for reviewers that can frustrate both parties. + +Consequently, as a community we expect that all active participants in the +community will also be active reviewers. The +[community membership](../community-membership.md) outlines the responsibilities +of the different contributor roles. + +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. + +## Expectations of reviewers: Review comments + +Because reviewers are often the first points of contact between new members of +the community and can significantly impact the first impression of the +Kubernetes community, reviewers are especially important in shaping the +Kubernetes community. Reviewers are highly encouraged to review the +[code of conduct](../../governance.md#code-of-conduct) and are strongly +encouraged to go above and beyond the code of conduct to promote a collaborative, +respectful Kubernetes community. + +## Expectations of reviewers: Review latency + +Reviewers are expected to respond in a timely fashion to PRs that are assigned +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. + +*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. + +## Thanks + +Many thanks in advance to everyone who contributes their time and effort to +making Kubernetes both a successful system as well as a successful community. +The strength of our software shines in the strengths of each individual +community member. Thanks! -- cgit v1.2.3 From 6d51ca785dadf530ff833d2d3c015a226e09f29e Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Tue, 23 Jan 2018 09:13:57 -0500 Subject: Remove duplicate content and fix links --- contributors/guide/community-expectations.md | 30 ++++------------------------ 1 file changed, 4 insertions(+), 26 deletions(-) diff --git a/contributors/guide/community-expectations.md b/contributors/guide/community-expectations.md index 39d2da73..eaa1787d 100644 --- a/contributors/guide/community-expectations.md +++ b/contributors/guide/community-expectations.md @@ -22,36 +22,14 @@ As a community we believe in the value of code review for all contributions. Code review increases both the quality and readability of our codebase, which in turn produces high quality software. -However, the code review process can also introduce latency for contributors -and additional work for reviewers that can frustrate both parties. +See the [pull request documentation](/devel/pull-requests.md) for more information +on code review. Consequently, as a community we expect that all active participants in the community will also be active reviewers. The -[community membership](../community-membership.md) outlines the responsibilities +[community membership](/community-membership.md) outlines the responsibilities of the different contributor roles. -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. @@ -61,7 +39,7 @@ Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Kubernetes community, reviewers are especially important in shaping the Kubernetes community. Reviewers are highly encouraged to review the -[code of conduct](../../governance.md#code-of-conduct) and are strongly +[code of conduct](/governance.md#code-of-conduct) and are strongly encouraged to go above and beyond the code of conduct to promote a collaborative, respectful Kubernetes community. -- cgit v1.2.3 From bf0fcc7c5da96752a4d13321cba2111cdd35ace3 Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Tue, 23 Jan 2018 13:20:49 -0500 Subject: Fix broken url --- contributors/guide/community-expectations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributors/guide/community-expectations.md b/contributors/guide/community-expectations.md index eaa1787d..fa4f951f 100644 --- a/contributors/guide/community-expectations.md +++ b/contributors/guide/community-expectations.md @@ -22,7 +22,7 @@ As a community we believe in the value of code review for all contributions. Code review increases both the quality and readability of our codebase, which in turn produces high quality software. -See the [pull request documentation](/devel/pull-requests.md) for more information +See the [pull request documentation](/contributors/devel/pull-requests.md) for more information on code review. Consequently, as a community we expect that all active participants in the -- cgit v1.2.3