From 6453dbe575eeea92c5d40a9898a24a22b517b780 Mon Sep 17 00:00:00 2001 From: Martin Hickey Date: Mon, 21 Jan 2019 11:49:43 +0000 Subject: [PATCH] Add content on how community members can help review PRs Updated text to better elaborate on he process and also some small other nits/updates. Signed-off-by: Martin Hickey --- CONTRIBUTING.md | 47 +++++++++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 20 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index aba3388a6..7736cbd6b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -84,12 +84,12 @@ your PR will be rejected by the automated DCO check. Whether you are a user or contributor, official support channels include: -- GitHub [issues](https://github.com/helm/helm/issues/new) -- Slack [Kubernetes Slack](http://slack.kubernetes.io/): - - User: #helm-users - - Contributor: #helm-dev +- [Issues](https://github.com/helm/helm/issues) +- Slack: + - User: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/) + - Contributor: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/) -Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. +Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. It is also worth asking on the Slack channels. ## Milestones @@ -180,33 +180,33 @@ contributing to Helm. All issue types follow the same general lifecycle. Differe Coding conventions and standards are explained in the official developer docs: [Developers Guide](docs/developers.md) -The next section contains more information on the workflow followed for PRs +The next section contains more information on the workflow followed for Pull Requests. ## Pull Requests -Like any good open source project, we use Pull Requests to track code changes +Like any good open source project, we use Pull Requests (PRs) to track code changes. ### PR Lifecycle 1. PR creation + - PRs are usually created to fix or else be a subset of other PRs that fix a particular issue. - We more than welcome PRs that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a PR is a work in progress, it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from the title. - - It is preferred, but not required, to have a PR tied to a specific issue. + - It is preferred, but not required, to have a PR tied to a specific issue. There can be + circumstances where if it is a quick fix then an issue might be overkill. The details provided + in the PR description would suffice in this case. 2. Triage - The maintainer in charge of triaging will apply the proper labels for the issue. This should include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied. - See the [Labels section](#labels) for full details on the definitions of labels + See the [Labels section](#labels) for full details on the definitions of labels. - Add the PR to the correct milestone. This should be the same as the issue the PR closes. 3. Assigning reviews - Once a review has the `awaiting review` label, maintainers will review them as schedule permits. The maintainer who takes the issue should self-request a review. - - Reviews from others in the community, especially those who have encountered a bug or have - requested a feature, are highly encouraged, but not required. Maintainer reviews **are** required - before any merge - Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be - merged. Those with `size/medium` are per the judgement of the maintainers + merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers. 4. Reviewing/Discussion - Once a maintainer begins reviewing a PR, they will remove the `awaiting review` label and add the `in progress` label so the person submitting knows that it is being worked on. This is @@ -214,17 +214,24 @@ Like any good open source project, we use Pull Requests to track code changes - All reviews will be completed using Github review tool. - A "Comment" review should be used when there are questions about the code that should be answered, but that don't involve code changes. This type of review does not count as approval. - - A "Changes Requested" review indicates that changes to the code need to be made before they will be merged. - - Reviewers should update labels as needed (such as `needs rebase`) -5. Address comments by answering questions or changing code + - A "Changes Requested" review indicates that changes to the code need to be made before they will be + merged. + - Reviewers (maintainers) should update labels as needed (such as `needs rebase`). + - Reviews are also welcome from others in the community, especially those who have encountered a bug or + have requested a feature. In the code review, a message can be added, as well as `LGTM` if the PR is + good to merge. It’s also possible to add comments to specific lines in a file, for giving context + to the comment. +5. PR owner should try to be responsive to comments by answering questions or changing code. If the + owner is unsure of any comment, reach out to the person who added the comment in + [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/). Once all comments have been addressed, + the PR is ready to be merged. 6. Merge or close - PRs should stay open until merged or if they have not been active for more than 30 days. This will help keep the PR queue to a manageable size and reduce noise. Should the PR need to stay open (like in the case of a WIP), the `keep open` label can be added. - - If the owner of the PR is listed in `OWNERS`, that user **must** merge their own PRs - or explicitly request another OWNER do that for them. - - If the owner of a PR is _not_ listed in `OWNERS`, any core committer may - merge the PR once it is approved. + - If the owner of the PR is listed in `OWNERS`, that user **must** merge their own PRs or explicitly + request another OWNER do that for them. + - If the owner of a PR is _not_ listed in `OWNERS`, any maintainer may merge the PR once it is approved. #### Documentation PRs