github.com/ndeloof/helm@v3.0.0-beta.3+incompatible/CONTRIBUTING.md (about) 1 # Contributing Guidelines 2 3 The Kubernetes Helm project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted. 4 5 ## Reporting a Security Issue 6 7 Most of the time, when you find a bug in Helm, it should be reported 8 using [GitHub issues](https://github.com/helm/helm/issues). However, if 9 you are reporting a _security vulnerability_, please email a report to 10 [helm-security@deis.com](mailto:helm-security@deis.com). This will give 11 us a chance to try to fix the issue before it is exploited in the wild. 12 13 ## Contributor License Agreements 14 15 We'd love to accept your patches! Before we can take them, we have to jump a 16 couple of legal hurdles. 17 18 The Cloud Native Computing Foundation (CNCF) CLA [must be signed](https://github.com/kubernetes/community/blob/master/CLA.md) by all contributors. 19 Please fill out either the individual or corporate Contributor License 20 Agreement (CLA). 21 22 Once you are CLA'ed, we'll be able to accept your pull requests. For any issues that you face during this process, 23 please add a comment [here](https://github.com/kubernetes/kubernetes/issues/27796) explaining the issue and we will help get it sorted out. 24 25 ***NOTE***: Only original source code from you and other people that have 26 signed the CLA can be accepted into the repository. This policy does not 27 apply to [third_party](third_party/) and [vendor](vendor/). 28 29 ## Support Channels 30 31 Whether you are a user or contributor, official support channels include: 32 33 - GitHub [issues](https://github.com/helm/helm/issues/new) 34 - Slack: #Helm room in the [Kubernetes Slack](http://slack.kubernetes.io/) 35 36 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. 37 38 ## Milestones 39 40 We use milestones to track progress of releases. There are also 2 special milestones 41 used for helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major` 42 43 `Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific 44 release but could easily be addressed in a minor release. `Upcoming - Major` keeps track 45 of issues that will need to be addressed in a major release. For example, if the current 46 version is `3.2.0` an issue/PR could fall in to one of 4 different active milestones: 47 `3.2.1`, `3.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a 48 specific upcoming bug or minor release, it would go into `3.2.1` or `3.3.0`. If the issue/PR 49 does not have a specific milestone yet, but it is likely that it will land in a `3.X` release, 50 it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change 51 and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone. 52 An issue that we are not sure we will be doing will not be added to any milestone. 53 54 A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone. 55 56 ## Semver 57 58 Helm maintains a strong commitment to backward compatibility. All of our changes to protocols and formats are backward compatible from Helm 3.0 until Helm 4.0. No features, flags, or commands are removed or substantially modified (other than bug fixes). 59 60 We also try very hard to not change publicly accessible Go library definitions inside of the `pkg/` directory of our source code. 61 62 For a quick summary of our backward compatibility guidelines for releases between 3.0 and 4.0: 63 64 - Command line commands, flags, and arguments MUST be backward compatible 65 - File formats (such as Chart.yaml) MUST be backward compatible 66 - Any chart that worked on a previous version of Helm 3 MUST work on a new version of Helm 3 (barring the cases where (a) Kubernetes itself changed, and (b) the chart worked because it exploited a bug) 67 - Chart repository functionality MUST be backward compatible 68 - Go libraries inside of `pkg/` SHOULD remain backward compatible, though code inside of `cmd/` and `internal/` may be changed from release to release without notice. 69 70 ## Issues 71 72 Issues are used as the primary method for tracking anything to do with the Helm project. 73 74 ### Issue Types 75 76 There are 5 types of issues (each with their own corresponding [label](#labels)): 77 78 - `question/support`: These are support or functionality inquiries that we want to have a record of for 79 future reference. Generally these are questions that are too complex or large to store in the 80 Slack channel or have particular interest to the community as a whole. Depending on the discussion, 81 these can turn into `feature` or `bug` issues. 82 - `proposal`: Used for items (like this one) that propose a new ideas or functionality that require 83 a larger community discussion. This allows for feedback from others in the community before a 84 feature is actually developed. This is not needed for small additions. Final word on whether or 85 not a feature needs a proposal is up to the core maintainers. All issues that are proposals should 86 both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become 87 a `feature` and does not require a milestone. 88 - `feature`: These track specific feature requests and ideas until they are complete. They can evolve 89 from a `proposal` or can be submitted individually depending on the size. 90 - `bug`: These track bugs with the code 91 - `docs`: These track problems with the documentation (i.e. missing or incomplete) 92 93 ### Issue Lifecycle 94 95 The issue lifecycle is mainly driven by the core maintainers, but is good information for those 96 contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below. 97 98 1. Issue creation 99 2. Triage 100 - The maintainer in charge of triaging will apply the proper labels for the issue. This 101 includes labels for priority, type, and metadata (such as "good first issue"). The only issue 102 priority we will be tracking is whether or not the issue is "critical." If additional 103 levels are needed in the future, we will add them. 104 - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure 105 that proposals are prefaced with "Proposal: [the rest of the title]". 106 - Add the issue to the correct milestone. If any questions come up, don't worry about 107 adding the issue to a milestone until the questions are answered. 108 - We attempt to do this process at least once per work day. 109 3. Discussion 110 - issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it. 111 - Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from 112 the community), should either assign the issue to themself or make a comment in the issue 113 saying that they are taking it. 114 - `proposal` and `support/question` issues should stay open until resolved or if they have not been 115 active for more than 30 days. This will help keep the issue queue to a manageable size and 116 reduce noise. Should the issue need to stay open, the `keep open` label can be added. 117 4. Issue closure 118 119 ## How to Contribute a Patch 120 121 1. If you haven't already done so, sign a Contributor License Agreement (see details above). 122 2. Fork the desired repo, develop and test your code changes. 123 3. Submit a pull request. 124 125 Coding conventions and standards are explained in the [official developer docs](https://helm.sh/docs/developers/). 126 127 ## Pull Requests 128 129 Like any good open source project, we use Pull Requests to track code changes. 130 131 ### PR Lifecycle 132 133 1. PR creation 134 - We more than welcome PRs that are currently in progress. They are a great way to keep track of 135 important work that is in-flight, but useful for others to see. If a PR is a work in progress, 136 it **must** be prefaced with "WIP: [the rest of the title]". Once the PR is ready for review, 137 remove "WIP" from the title. 138 - It is preferred, but not required, to have a PR tied to a specific issue. 139 2. Triage 140 - The maintainer in charge of triaging will apply the proper labels for the issue. This should 141 include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied. 142 See the [Labels section](#labels) for full details on the definitions of labels 143 - Add the PR to the correct milestone. This should be the same as the issue the PR closes. 144 3. Assigning reviews 145 - Once a review has the `awaiting review` label, maintainers will review them as schedule permits. 146 The maintainer who takes the issue should self-request a review. 147 - Reviews from others in the community, especially those who have encountered a bug or have 148 requested a feature, are highly encouraged, but not required. Maintainer reviews **are** required 149 before any merge 150 4. Reviewing/Discussion 151 - All reviews will be completed using Github review tool. 152 - A "Comment" review should be used when there are questions about the code that should be 153 answered, but that don't involve code changes. This type of review does not count as approval. 154 - A "Changes Requested" review indicates that changes to the code need to be made before they will be merged. 155 - Reviewers should update labels as needed (such as `needs rebase`) 156 5. Address comments by answering questions or changing code 157 6. LGTM (Looks good to me) 158 - Once a Reviewer has completed a review and the code looks ready to merge, an "Approve" review is used 159 to signal to the contributor and to other maintainers that you have reviewed the code and feel that it is 160 ready to be merged. 161 7. Merge or close 162 - PRs should stay open until merged or if they have not been active for more than 30 days. 163 This will help keep the PR queue to a manageable size and reduce noise. Should the PR need 164 to stay open (like in the case of a WIP), the `keep open` or `WIP` label can be added. 165 - Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if 166 the PR requires more than one LGTM to merge. 167 - If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs 168 or explicitly request another OWNER do that for them. 169 - If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR. 170 171 #### Documentation PRs 172 173 Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the 174 `docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity 175 (whereas those things don't matter *as* much for comments in code). 176 177 ## The Triager 178 179 Each week, one of the core maintainers will serve as the designated "triager" starting after the 180 public standup meetings on Thursday. This person will be in charge triaging new PRs and issues 181 throughout the work week. 182 183 ## Labels 184 185 The following tables define all label types used for Helm. It is split up by category. 186 187 ### Common 188 189 | Label | Description | 190 | ----- | ----------- | 191 | `bug` | Marks an issue as a bug or a PR as a bugfix | 192 | `critical` | Marks an issue or PR as critical. This means that addressing the PR or issue is top priority and must be addressed as soon as possible | 193 | `docs` | Indicates the issue or PR is a documentation change | 194 | `feature` | Marks the issue as a feature request or a PR as a feature implementation | 195 | `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity | 196 | `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality | 197 198 ### Issue Specific 199 200 | Label | Description | 201 | ----- | ----------- | 202 | `help wanted` | Marks an issue needs help from the community to solve | 203 | `proposal` | Marks an issue as a proposal | 204 | `question/support` | Marks an issue as a support request or question | 205 | `good first issue` | Marks an issue as a good starter issue for someone new to Helm | 206 | `wont fix` | Marks an issue as discussed and will not be implemented (or accepted in the case of a proposal) | 207 208 ### PR Specific 209 210 | Label | Description | 211 | ----- | ----------- | 212 | `awaiting review` | Indicates a PR has been triaged and is ready for someone to review | 213 | `breaking` | Indicates a PR has breaking changes (such as API changes) | 214 | `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet | 215 | `needs rebase` | Indicates a PR needs to be rebased before it can be merged | 216 | `needs pick` | Indicates a PR needs to be cherry-picked into a feature branch (generally bugfix branches). Once it has been, the `picked` label should be applied and this one removed | 217 | `picked` | This PR has been cherry-picked into a feature branch | 218 219 #### Size labels 220 221 Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the 222 labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes 223 30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/L` 224 because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires 225 another 150 lines of tests to cover all cases, could be labeled as `size/S` even though the number of 226 lines is greater than defined below. 227 228 PRs submitted by a core maintainer, regardless of size, only requires approval from one additional 229 maintainer. This ensures there are at least two maintainers who are aware of any significant PRs 230 introduced to the codebase. 231 232 | Label | Description | 233 | ----- | ----------- | 234 | `size/XS` | Denotes a PR that changes 0-9 lines, ignoring generated files. Very little testing may be required depending on the change. | 235 | `size/S` | Denotes a PR that changes 10-29 lines, ignoring generated files. Only small amounts of manual testing may be required. | 236 | `size/M` | Denotes a PR that changes 30-99 lines, ignoring generated files. Manual validation should be required. | 237 | `size/L` | Denotes a PR that changes 100-499 lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. | 238 | `size/XL` | Denotes a PR that changes 500-999 lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. | 239 | `size/XXL` | Denotes a PR that changes 1000+ lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. |