1# Contributing Guidelines
2
3The Helm project accepts contributions via GitHub pull requests. This document outlines the process
4to help get your contribution accepted.
5
6## Reporting a Security Issue
7
8Most of the time, when you find a bug in Helm, it should be reported using [GitHub
9issues](https://github.com/helm/helm/issues). However, if you are reporting a _security
10vulnerability_, please email a report to
11[cncf-helm-security@lists.cncf.io](mailto:cncf-helm-security@lists.cncf.io). This will give us a
12chance to try to fix the issue before it is exploited in the wild.
13
14## Sign Your Work
15
16The sign-off is a simple line at the end of the explanation for a commit. All commits need to be
17signed. Your signature certifies that you wrote the patch or otherwise have the right to contribute
18the material. The rules are pretty simple, if you can certify the below (from
19[developercertificate.org](https://developercertificate.org/)):
20
21```
22Developer Certificate of Origin
23Version 1.1
24
25Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
261 Letterman Drive
27Suite D4700
28San Francisco, CA, 94129
29
30Everyone is permitted to copy and distribute verbatim copies of this
31license document, but changing it is not allowed.
32
33Developer's Certificate of Origin 1.1
34
35By making a contribution to this project, I certify that:
36
37(a) The contribution was created in whole or in part by me and I
38 have the right to submit it under the open source license
39 indicated in the file; or
40
41(b) The contribution is based upon previous work that, to the best
42 of my knowledge, is covered under an appropriate open source
43 license and I have the right under that license to submit that
44 work with modifications, whether created in whole or in part
45 by me, under the same open source license (unless I am
46 permitted to submit under a different license), as indicated
47 in the file; or
48
49(c) The contribution was provided directly to me by some other
50 person who certified (a), (b) or (c) and I have not modified
51 it.
52
53(d) I understand and agree that this project and the contribution
54 are public and that a record of the contribution (including all
55 personal information I submit with it, including my sign-off) is
56 maintained indefinitely and may be redistributed consistent with
57 this project or the open source license(s) involved.
58```
59
60Then you just add a line to every git commit message:
61
62 Signed-off-by: Joe Smith <joe.smith@example.com>
63
64Use your real name (sorry, no pseudonyms or anonymous contributions.)
65
66If you set your `user.name` and `user.email` git configs, you can sign your commit automatically
67with `git commit -s`.
68
69Note: If your git config information is set properly then viewing the `git log` information for your
70 commit will look something like this:
71
72```
73Author: Joe Smith <joe.smith@example.com>
74Date: Thu Feb 2 11:41:15 2018 -0800
75
76 Update README
77
78 Signed-off-by: Joe Smith <joe.smith@example.com>
79```
80
81Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will be rejected by the
82automated DCO check.
83
84## Support Channels
85
86Whether you are a user or contributor, official support channels include:
87
88- [Issues](https://github.com/helm/helm/issues)
89- Slack:
90 - User: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/)
91 - Contributor: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/)
92
93Before opening a new issue or submitting a new pull request, it's helpful to search the project -
94it's likely that another user has already reported the issue you're facing, or it's a known issue
95that we're already aware of. It is also worth asking on the Slack channels.
96
97## Milestones
98
99We use milestones to track progress of specific planned releases.
100
101For example, if the latest currently-released version is `3.2.1`, an issue/PR which pertains to a
102specific upcoming bugfix or feature release could fall into one of two different active milestones:
103`3.2.2` or `3.3.0`.
104
105Issues and PRs which are deemed backwards-incompatible may be added to the discussion items for
106Helm 4 with [label:v4.x](https://github.com/helm/helm/labels/v4.x). An issue or PR that we are not
107sure we will be addressing will not be added to any milestone.
108
109A milestone (and hence release) can be closed when all outstanding issues/PRs have been closed
110or moved to another milestone and the associated release has been published.
111
112## Semantic Versioning
113
114Helm maintains a strong commitment to backward compatibility. All of our changes to protocols and
115formats are backward compatible from one major release to the next. No features, flags, or commands
116are removed or substantially modified (unless we need to fix a security issue).
117
118We also try very hard to not change publicly accessible Go library definitions inside of the `pkg/`
119directory of our source code.
120
121For a quick summary of our backward compatibility guidelines for releases between 3.0 and 4.0:
122
123- Command line commands, flags, and arguments MUST be backward compatible
124- File formats (such as Chart.yaml) MUST be backward compatible
125- Any chart that worked on a previous version of Helm 3 MUST work on a new version of Helm 3
126 (barring the cases where (a) Kubernetes itself changed, and (b) the chart worked because it
127 exploited a bug)
128- Chart repository functionality MUST be backward compatible
129- Go libraries inside of `pkg/` SHOULD remain backward compatible, though code inside of `cmd/` and
130 `internal/` may be changed from release to release without notice.
131
132## Support Contract for Helm 2
133
134With Helm 2's current release schedule, we want to take into account any migration issues for users
135due to the upcoming holiday shopping season and tax season. We also want to clarify what actions may
136occur after the support contract ends for Helm 2, so that users will not be surprised or caught off
137guard.
138
139After Helm 2.15.0 is released, Helm 2 will go into "maintenance mode". We will continue to accept
140bug fixes and fix any security issues that arise, but no new features will be accepted for Helm 2.
141All feature development will be moved over to Helm 3.
142
1436 months after Helm 3.0.0's public release, Helm 2 will stop accepting bug fixes. Only security
144issues will be accepted.
145
14612 months after Helm 3.0.0's public release, support for Helm 2 will formally end. Download links
147for the Helm 2 client through Google Cloud Storage, the Docker image for Tiller stored in Google
148Container Registry, and the Google Cloud buckets for the stable and incubator chart repositories may
149no longer work at any point. Client downloads through `get.helm.sh` will continue to work, and we
150will distribute a Tiller image that will be made available at an alternative location which can be
151updated with `helm init --tiller-image`.
152
153## Issues
154
155Issues are used as the primary method for tracking anything to do with the Helm project.
156
157### Issue Types
158
159There are 5 types of issues (each with their own corresponding [label](#labels)):
160
161- `question/support`: These are support or functionality inquiries that we want to have a record of
162 for future reference. Generally these are questions that are too complex or large to store in the
163 Slack channel or have particular interest to the community as a whole. Depending on the
164 discussion, these can turn into `feature` or `bug` issues.
165- `proposal`: Used for items (like this one) that propose a new ideas or functionality that require
166 a larger community discussion. This allows for feedback from others in the community before a
167 feature is actually developed. This is not needed for small additions. Final word on whether or
168 not a feature needs a proposal is up to the core maintainers. All issues that are proposals should
169 both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become
170 a `feature` and does not require a milestone.
171- `feature`: These track specific feature requests and ideas until they are complete. They can
172 evolve from a `proposal` or can be submitted individually depending on the size.
173- `bug`: These track bugs with the code
174- `docs`: These track problems with the documentation (i.e. missing or incomplete)
175
176### Issue Lifecycle
177
178The issue lifecycle is mainly driven by the core maintainers, but is good information for those
179contributing to Helm. All issue types follow the same general lifecycle. Differences are noted
180below.
181
1821. Issue creation
1832. Triage
184 - The maintainer in charge of triaging will apply the proper labels for the issue. This includes
185 labels for priority, type, and metadata (such as `good first issue`). The only issue priority
186 we will be tracking is whether or not the issue is "critical." If additional levels are needed
187 in the future, we will add them.
188 - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that
189 proposals are prefaced with "Proposal: [the rest of the title]".
190 - Add the issue to the correct milestone. If any questions come up, don't worry about adding the
191 issue to a milestone until the questions are answered.
192 - We attempt to do this process at least once per work day.
1933. Discussion
194 - Issues that are labeled `feature` or `proposal` must write a Helm Improvement Proposal (HIP).
195 See [Proposing an Idea](#proposing-an-idea). Smaller quality-of-life enhancements are exempt.
196 - Issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it.
197 - Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from the
198 community), should either assign the issue to themselves or make a comment in the issue saying
199 that they are taking it.
200 - `proposal` and `support/question` issues should stay open until resolved or if they have not
201 been active for more than 30 days. This will help keep the issue queue to a manageable size
202 and reduce noise. Should the issue need to stay open, the `keep open` label can be added.
2034. Issue closure
204
205## Proposing an Idea
206
207Before proposing a new idea to the Helm project, please make sure to write up a [Helm Improvement
208Proposal](https://github.com/helm/community/tree/master/hips). A Helm Improvement Proposal is a
209design document that describes a new feature for the Helm project. The proposal should provide a
210concise technical specification and rationale for the feature.
211
212It is also worth considering vetting your idea with the community via the
213[cncf-helm](mailto:cncf-helm@lists.cncf.io) mailing list. Vetting an idea publicly before going as
214far as writing a proposal is meant to save the potential author time. Many ideas have been proposed;
215it's quite likely there are others in the community who may be working on a similar proposal, or a
216similar proposal may have already been written.
217
218HIPs are submitted to the [helm/community repository](https://github.com/helm/community). [HIP
2191](https://github.com/helm/community/blob/master/hips/hip-0001.md) describes the process to write a
220HIP as well as the review process.
221
222After your proposal has been approved, follow the [developer's
223guide](https://helm.sh/docs/community/developers/) to get started.
224
225## How to Contribute a Patch
226
2271. Identify or create the related issue. If you're proposing a larger change to
228 Helm, see [Proposing an Idea](#proposing-an-idea).
2292. Fork the desired repo; develop and test your code changes.
2303. Submit a pull request, making sure to sign your work and link the related issue.
231
232Coding conventions and standards are explained in the [official developer
233docs](https://helm.sh/docs/developers/).
234
235## Pull Requests
236
237Like any good open source project, we use Pull Requests (PRs) to track code changes.
238
239### PR Lifecycle
240
2411. PR creation
242 - PRs are usually created to fix or else be a subset of other PRs that fix a particular issue.
243 - We more than welcome PRs that are currently in progress. They are a great way to keep track of
244 important work that is in-flight, but useful for others to see. If a PR is a work in progress,
245 it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP"
246 from the title.
247 - It is preferred, but not required, to have a PR tied to a specific issue. There can be
248 circumstances where if it is a quick fix then an issue might be overkill. The details provided
249 in the PR description would suffice in this case.
2502. Triage
251 - The maintainer in charge of triaging will apply the proper labels for the issue. This should
252 include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are
253 applied. See the [Labels section](#labels) for full details on the definitions of labels.
254 - Add the PR to the correct milestone. This should be the same as the issue the PR closes.
2553. Assigning reviews
256 - Once a review has the `awaiting review` label, maintainers will review them as schedule
257 permits. The maintainer who takes the issue should self-request a review.
258 - PRs from a community member with the label `size/S` or larger requires 2 review approvals from
259 maintainers before it can be merged. Those with `size/XS` are per the judgement of the
260 maintainers. For more detail see the [Size Labels](#size-labels) section.
2614. Reviewing/Discussion
262 - All reviews will be completed using GitHub review tool.
263 - A "Comment" review should be used when there are questions about the code that should be
264 answered, but that don't involve code changes. This type of review does not count as approval.
265 - A "Changes Requested" review indicates that changes to the code need to be made before they
266 will be merged.
267 - Reviewers should update labels as needed (such as `needs rebase`)
2685. Address comments by answering questions or changing code
2696. LGTM (Looks good to me)
270 - Once a Reviewer has completed a review and the code looks ready to merge, an "Approve" review
271 is used to signal to the contributor and to other maintainers that you have reviewed the code
272 and feel that it is ready to be merged.
2737. Merge or close
274 - PRs should stay open until merged or if they have not been active for more than 30 days. This
275 will help keep the PR queue to a manageable size and reduce noise. Should the PR need to stay
276 open (like in the case of a WIP), the `keep open` label can be added.
277 - Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if
278 the PR requires more than one LGTM to merge.
279 - If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs
280 or explicitly request another OWNER do that for them.
281 - If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR.
282
283#### Documentation PRs
284
285Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the
286`docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity
287(whereas those things don't matter *as* much for comments in code).
288
289## The Triager
290
291Each week, one of the core maintainers will serve as the designated "triager" starting after the
292public stand-up meetings on Thursday. This person will be in charge triaging new PRs and issues
293throughout the work week.
294
295## Labels
296
297The following tables define all label types used for Helm. It is split up by category.
298
299### Common
300
301| Label | Description |
302| ----- | ----------- |
303| `bug` | Marks an issue as a bug or a PR as a bugfix |
304| `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 |
305| `docs` | Indicates the issue or PR is a documentation change |
306| `feature` | Marks the issue as a feature request or a PR as a feature implementation |
307| `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity |
308| `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality |
309
310### Issue Specific
311
312| Label | Description |
313| ----- | ----------- |
314| `help wanted` | Marks an issue needs help from the community to solve |
315| `proposal` | Marks an issue as a proposal |
316| `question/support` | Marks an issue as a support request or question |
317| `good first issue` | Marks an issue as a good starter issue for someone new to Helm |
318| `wont fix` | Marks an issue as discussed and will not be implemented (or accepted in the case of a proposal) |
319
320### PR Specific
321
322| Label | Description |
323| ----- | ----------- |
324| `awaiting review` | Indicates a PR has been triaged and is ready for someone to review |
325| `breaking` | Indicates a PR has breaking changes (such as API changes) |
326| `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet |
327| `needs rebase` | Indicates a PR needs to be rebased before it can be merged |
328| `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 |
329| `picked` | This PR has been cherry-picked into a feature branch |
330
331#### Size labels
332
333Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign
334the labels, but ultimately this can be changed by the maintainers. For example, even if a PR only
335makes 30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as
336`size/L` because it requires sign off from multiple people. Conversely, a PR that adds a small
337feature, but requires another 150 lines of tests to cover all cases, could be labeled as `size/S`
338even though the number of lines is greater than defined below.
339
340Any changes from the community labeled as `size/S` or larger should be thoroughly tested before
341merging and always requires approval from 2 core maintainers. PRs submitted by a core maintainer,
342regardless of size, only requires approval from one additional maintainer. This ensures there are at
343least two maintainers who are aware of any significant PRs introduced to the codebase.
344
345| Label | Description |
346| ----- | ----------- |
347| `size/XS` | Denotes a PR that changes 0-9 lines, ignoring generated files. Very little testing may be required depending on the change. |
348| `size/S` | Denotes a PR that changes 10-29 lines, ignoring generated files. Only small amounts of manual testing may be required. |
349| `size/M` | Denotes a PR that changes 30-99 lines, ignoring generated files. Manual validation should be required. |
350| `size/L` | Denotes a PR that changes 100-499 lines, ignoring generated files. |
351| `size/XL` | Denotes a PR that changes 500-999 lines, ignoring generated files. |
352| `size/XXL` | Denotes a PR that changes 1000+ lines, ignoring generated files. |
View as plain text