From 917c1a6b1169b28d0f4841d640f2cb13a5177b9f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Magnusson?= Date: Wed, 11 Jul 2018 23:03:16 +0200 Subject: [PATCH] CONTRIBUTING.md: Corrected slack channel/s in support channels --- CONTRIBUTING.md | 102 ++++++++++++++++++++++++------------------------ 1 file changed, 52 insertions(+), 50 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8fecb0479..81ed009d4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -31,7 +31,9 @@ apply to [third_party](third_party/) and [vendor](vendor/). Whether you are a user or contributor, official support channels include: - GitHub [issues](https://github.com/kubernetes/helm/issues/new) -- Slack: #Helm room in the [Kubernetes Slack](http://slack.kubernetes.io/) +- Slack [Kubernetes Slack](http://slack.kubernetes.io/): + - User: #helm-users + - Contributor: #helm-dev 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. @@ -40,15 +42,15 @@ Before opening a new issue or submitting a new pull request, it's helpful to sea We use milestones to track progress of releases. There are also 2 special milestones used for helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major` -`Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific +`Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific release but could easily be addressed in a minor release. `Upcoming - Major` keeps track -of issues that will need to be addressed in a major release. For example, if the current -version is `2.2.0` an issue/PR could fall in to one of 4 different active milestones: -`2.2.1`, `2.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a -specific upcoming bug or minor release, it would go into `2.2.1` or `2.3.0`. If the issue/PR -does not have a specific milestone yet, but it is likely that it will land in a `2.X` release, -it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change -and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone. +of issues that will need to be addressed in a major release. For example, if the current +version is `2.2.0` an issue/PR could fall in to one of 4 different active milestones: +`2.2.1`, `2.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a +specific upcoming bug or minor release, it would go into `2.2.1` or `2.3.0`. If the issue/PR +does not have a specific milestone yet, but it is likely that it will land in a `2.X` release, +it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change +and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone. An issue that we are not sure we will be doing will not be added to any milestone. A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone. @@ -75,42 +77,42 @@ Issues are used as the primary method for tracking anything to do with the Helm ### Issue Types There are 4 types of issues (each with their own corresponding [label](#labels)): -- Question: These are support or functionality inquiries that we want to have a record of for -future reference. Generally these are questions that are too complex or large to store in the -Slack channel or have particular interest to the community as a whole. Depending on the discussion, +- Question: These are support or functionality inquiries that we want to have a record of for +future reference. Generally these are questions that are too complex or large to store in the +Slack channel or have particular interest to the community as a whole. Depending on the discussion, these can turn into "Feature" or "Bug" issues. -- Proposal: Used for items (like this one) that propose a new ideas or functionality that require -a larger community discussion. This allows for feedback from others in the community before a -feature is actually developed. This is not needed for small additions. Final word on whether or -not a feature needs a proposal is up to the core maintainers. All issues that are proposals should -both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become +- Proposal: Used for items (like this one) that propose a new ideas or functionality that require +a larger community discussion. This allows for feedback from others in the community before a +feature is actually developed. This is not needed for small additions. Final word on whether or +not a feature needs a proposal is up to the core maintainers. All issues that are proposals should +both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Feature" and does not require a milestone. -- Features: These track specific feature requests and ideas until they are complete. They can evolve +- Features: These track specific feature requests and ideas until they are complete. They can evolve from a "Proposal" or can be submitted individually depending on the size. - Bugs: These track bugs with the code or problems with the documentation (i.e. missing or incomplete) ### Issue Lifecycle -The issue lifecycle is mainly driven by the core maintainers, but is good information for those +The issue lifecycle is mainly driven by the core maintainers, but is good information for those contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below. 1. Issue creation 2. Triage - - The maintainer in charge of triaging will apply the proper labels for the issue. This - includes labels for priority, type, and metadata (such as "starter"). The only issue - priority we will be tracking is whether or not the issue is "critical." If additional + - The maintainer in charge of triaging will apply the proper labels for the issue. This + includes labels for priority, type, and metadata (such as "starter"). The only issue + priority we will be tracking is whether or not the issue is "critical." If additional levels are needed in the future, we will add them. - - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure + - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal". - - Add the issue to the correct milestone. If any questions come up, don't worry about + - Add the issue to the correct milestone. If any questions come up, don't worry about adding the issue to a milestone until the questions are answered. - We attempt to do this process at least once per work day. 3. Discussion - - "Feature" and "Bug" issues should be connected to the PR that resolves it. - - Whoever is working on a "Feature" or "Bug" issue (whether a maintainer or someone from - the community), should either assign the issue to them self or make a comment in the issue + - "Feature" and "Bug" issues should be connected to the PR that resolves it. + - Whoever is working on a "Feature" or "Bug" issue (whether a maintainer or someone from + the community), should either assign the issue to them self or make a comment in the issue saying that they are taking it. - - "Proposal" and "Question" issues should stay open until resolved or if they have not been - active for more than 30 days. This will help keep the issue queue to a manageable size and + - "Proposal" and "Question" issues should stay open until resolved or if they have not been + active for more than 30 days. This will help keep the issue queue to a manageable size and reduce noise. Should the issue need to stay open, the `keep open` label can be added. 4. Issue closure @@ -133,36 +135,36 @@ Like any good open source project, we use Pull Requests to track code changes 1. PR creation - 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, + 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. 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. + - 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 - 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. + - 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 + - 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 + - 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 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 + - 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 especially helpful when the review may take awhile. - 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 + - 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 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 + - 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. @@ -171,14 +173,14 @@ Like any good open source project, we use Pull Requests to track code changes #### Documentation PRs -Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the -`docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity +Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the +`docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity (whereas those things don't matter *as* much for comments in code). ## The Triager -Each week, one of the core maintainers will serve as the designated "triager" starting after the -public standup meetings on Thursday. This person will be in charge triaging new PRs and issues +Each week, one of the core maintainers will serve as the designated "triager" starting after the +public standup meetings on Thursday. This person will be in charge triaging new PRs and issues throughout the work week. ## Labels @@ -222,11 +224,11 @@ The following tables define all label types used for Helm. It is split up by cat #### Size labels -Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the -labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes -30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/large` -because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires -another 150 lines of tests to cover all cases, could be labeled as `size/small` even though the number +Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the +labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes +30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/large` +because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires +another 150 lines of tests to cover all cases, could be labeled as `size/small` even though the number lines is greater than defined below. | Label | Description |