github.com/pensu/helm@v2.6.1+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](github.com/kubernetes/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/kubenetes/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  We use milestones to track progress of releases. There are also 2 special milestones
    40  used for helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major`
    41  
    42  `Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific 
    43  release but could easily be addressed in a minor release. `Upcoming - Major` keeps track
    44  of issues that will need to be addressed in a major release. For example, if the current 
    45  version is `2.2.0` an issue/PR could fall in to one of 4 different active milestones: 
    46  `2.2.1`, `2.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a 
    47  specific upcoming bug or minor release, it would go into `2.2.1` or `2.3.0`. If the issue/PR 
    48  does not have a specific milestone yet, but it is likely that it will land in a `2.X` release, 
    49  it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change 
    50  and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone. 
    51  An issue that we are not sure we will be doing will not be added to any milestone.
    52  
    53  A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone.
    54  
    55  ## Issues
    56  Issues are used as the primary method for tracking anything to do with the Helm project.
    57  
    58  ### Issue Types
    59  There are 4 types of issues (each with their own corresponding [label](#labels)):
    60  - Question: These are support or functionality inquiries that we want to have a record of for 
    61  future reference. Generally these are questions that are too complex or large to store in the 
    62  Slack channel or have particular interest to the community as a whole. Depending on the discussion, 
    63  these can turn into "Feature" or "Bug" issues.
    64  - Proposal: Used for items (like this one) that propose a new ideas or functionality that require 
    65  a larger community discussion. This allows for feedback from others in the community before a 
    66  feature is actually  developed. This is not needed for small additions. Final word on whether or 
    67  not a feature needs a proposal is up to the core maintainers. All issues that are proposals should 
    68  both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become 
    69  a "Feature" and does not require a milestone.
    70  - Features: These track specific feature requests and ideas until they are complete. They can evolve 
    71  from a "Proposal" or can be submitted individually depending on the size.
    72  - Bugs: These track bugs with the code or problems with the documentation (i.e. missing or incomplete)
    73  
    74  ### Issue Lifecycle
    75  The issue lifecycle is mainly driven by the core maintainers, but is good information for those 
    76  contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below.
    77  1. Issue creation
    78  2. Triage
    79      - The maintainer in charge of triaging will apply the proper labels for the issue. This 
    80      includes labels for priority, type, and metadata (such as "starter"). The only issue 
    81      priority we will be tracking is whether or not the issue is "critical." If additional 
    82      levels are needed in the future, we will add them.
    83      - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure 
    84      that proposals are prefaced with "Proposal".
    85      - Add the issue to the correct milestone. If any questions come up, don't worry about 
    86      adding the issue to a milestone until the questions are answered.
    87      - We attempt to do this process at least once per work day.
    88  3. Discussion
    89      - "Feature" and "Bug" issues should be connected to the PR that resolves it. 
    90      - Whoever is working on a "Feature" or "Bug" issue (whether a maintainer or someone from 
    91      the community), should either assign the issue to them self or make a comment in the issue 
    92      saying that they are taking it.
    93      - "Proposal" and "Question" issues should stay open until resolved or if they have not been 
    94      active for more than 30 days. This will help keep the issue queue to a manageable size and 
    95      reduce noise. Should the issue need to stay open, the `keep open` label can be added.
    96  4. Issue closure
    97  
    98  ## How to Contribute a Patch
    99  
   100  1. If you haven't already done so, sign a Contributor License Agreement (see details above).
   101  2. Fork the desired repo, develop and test your code changes.
   102  3. Submit a pull request.
   103  
   104  Coding conventions and standards are explained in the official developer docs:
   105  https://github.com/kubernetes/helm/blob/master/docs/developers.md
   106  
   107  The next section contains more information on the workflow followed for PRs
   108  
   109  ## Pull Requests
   110  Like any good open source project, we use Pull Requests to track code changes
   111  
   112  ### PR Lifecycle
   113  1. PR creation
   114      - We more than welcome PRs that are currently in progress. They are a great way to keep track of
   115      important work that is in-flight, but useful for others to see. If a PR is a work in progress, 
   116      it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from
   117      the title.
   118      - It is preferred, but not required, to have a PR tied to a specific issue.
   119  2. Triage
   120      - The maintainer in charge of triaging will apply the proper labels for the issue. This should 
   121      include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied. 
   122      See the [Labels section](#labels) for full details on the definitions of labels
   123      - Add the PR to the correct milestone. This should be the same as the issue the PR closes.
   124  3. Assigning reviews
   125      - Once a review has the `awaiting review` label, maintainers will review them as schedule permits. 
   126      The maintainer who takes the issue should self-request a review.
   127      - Reviews from others in the community, especially those who have encountered a bug or have 
   128      requested a feature, are highly encouraged, but not required. Maintainer reviews **are** required 
   129      before any merge
   130      - Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be 
   131      merged. Those with `size/medium` are per the judgement of the maintainers
   132  4. Reviewing/Discussion
   133      - Once a maintainer begins reviewing a PR, they will remove the `awaiting review` label and add 
   134      the `in progress` label so the person submitting knows that it is being worked on. This is 
   135      especially helpful when the review may take awhile.
   136      - All reviews will be completed using Github review tool.
   137      - A "Comment" review should be used when there are questions about the code that should be 
   138      answered, but that don't involve code changes. This type of review does not count as approval.
   139      - A "Changes Requested" review indicates that changes to the code need to be made before they will be merged.
   140      - Reviewers should update labels as needed (such as `needs rebase`)
   141  5. Address comments by answering questions or changing code
   142  6. Merge or close
   143      - PRs should stay open until merged or if they have not been active for more than 30 days. 
   144      This will help keep the PR queue to a manageable size and reduce noise. Should the PR need 
   145      to stay open (like in the case of a WIP), the `keep open` label can be added.
   146  
   147  #### Documentation PRs
   148  Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the 
   149  `docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity 
   150  (whereas those things don't matter *as* much for comments in code).
   151  
   152  ## The Triager
   153  Each week, one of the core maintainers will serve as the designated "triager" starting after the 
   154  public standup meetings on Thursday. This person will be in charge triaging new PRs and issues 
   155  throughout the work week.
   156  
   157  ## Labels
   158  The following tables define all label types used for Helm. It is split up by category.
   159  
   160  ### Common
   161  | Label | Description |
   162  | ----- | ----------- |
   163  | `bug` | Marks an issue as a bug or a PR as a bugfix |
   164  | `critical` | Marks an issue or PR as critical. This means that addressing the PR or issue is top priority and will be handled first by maintainers |
   165  | `docs` | Indicates the issue or PR is a documentation change |
   166  | `duplicate` | Indicates that the issue or PR is a duplicate of another |
   167  | `feature` | Marks the issue as a feature request or a PR as a feature implementation |
   168  | `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity |
   169  | `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality |
   170  
   171  ### Issue Specific
   172  | Label | Description |
   173  | ----- | ----------- |
   174  | `help wanted` | This issue is one the core maintainers cannot get to right now and would appreciate help with |
   175  | `proposal` | This issue is a proposal |
   176  | `question/support` | This issue is a support request or question |
   177  | `starter` | This issue is a good for someone new to contributing to Helm |
   178  | `wont fix` | The issue has been discussed and will not be implemented (or accepted in the case of a proposal) |
   179  
   180  ### PR Specific
   181  | Label | Description |
   182  | ----- | ----------- |
   183  | `awaiting review` | The PR has been triaged and is ready for someone to review |
   184  | `breaking` | The PR has breaking changes (such as API changes) |
   185  | `cncf-cla: no` | The PR submitter has **not** signed the project CLA. |
   186  | `cncf-cla: yes` | The PR submitter has signed the project CLA. This is required to merge. |
   187  | `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet |
   188  | `needs pick` | Indicates that the PR needs to be picked into a feature branch (generally bugfix branches). Once it has been, the `picked` label should be applied and this one removed |
   189  | `needs rebase` | A helper label used to indicate that the PR needs to be rebased before it can be merged. Used for easy filtering |
   190  | `picked` | This PR has been picked into a feature branch |
   191  
   192  #### Size labels
   193  Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the 
   194  labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes 
   195  30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/large` 
   196  because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires 
   197  another 150 lines of tests to cover all cases, could be labeled as `size/small` even though the number 
   198  lines is greater than defined below.
   199  
   200  | Label | Description |
   201  | ----- | ----------- |
   202  | `size/small` | Anything less than or equal to 4 files and 150 lines. Only small amounts of manual testing may be required |
   203  | `size/medium` | Anything greater than `size/small` and less than or equal to 8 files and 300 lines. Manual validation should be required. |
   204  | `size/large` | Anything greater than `size/medium`. This should be thoroughly tested before merging and always requires 2 approvals. This also should be applied to anything that is a significant logic change. |