github.com/openshift/source-to-image@v1.4.1-0.20240516041539-bf52fc02204e/CONTRIBUTING.md (about)

     1  # Contributing Guide
     2  
     3  ## Filing Bugs
     4  
     5  Bug reports may be filed as an issue on GitHub, with the label `kind/bug`.
     6  The label can be added by placing the [Prow](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image)
     7  command `/kind bug` in your issue.
     8  
     9  A well-written bug report has the following format:
    10  
    11  ```markdown
    12  **Is this a feature request or bug?**
    13  
    14  /kind bug
    15  
    16  **What went wrong?**
    17  
    18  Enter a description of what went wrong.
    19  
    20  **Steps to reproduce:**
    21  
    22  1. Step 1
    23  2. Step 2
    24  3. Step 3
    25  
    26  **Expected results:**
    27  
    28  Enter what you expected to happen.
    29  
    30  **Actual results:**
    31  
    32  Enter what actually occurred, including command line output
    33  
    34  **Version:**
    35  
    36  s2i: Enter output of `s2i version`
    37  docker: Enter the output of `docker version` if you are using docker to build container images.
    38  
    39  **Additional info:**
    40  
    41  Add any relevant context here.
    42  ```
    43  
    44  ## Submitting Feature Requests
    45  
    46  Feature requests are likewise submitted as GitHub issues, with the `kind/feature` label.
    47  The label can be added by placing the [Prow](https://prow.svc.ci.openshift.org/command-help?repo=openshift%2Fsource-to-image)
    48  command `/kind feature` in your issue.
    49  
    50  A well-written feature request has the following format:
    51  
    52  ```markdown
    53  **Is this a feature request or bug?**
    54  
    55  /kind feature
    56  
    57  **User Stories**
    58  
    59  As a developer using source-to-image
    60  I would like ...
    61  So that ...
    62  
    63  (you may add more than one story to provide further use cases to consider)
    64  
    65  **Additional info:**
    66  
    67  Add any relevant context or deeper description here.
    68  ```
    69  
    70  ## Submitting a Pull Request
    71  
    72  You can contribute to source-to-image by submitting a pull request ("PR").
    73  Any member of the OpenShift organization can review your PR and signal their approval with the
    74  `/lgtm` command. Only approvers listed in the [OWNERS](OWNERS) file may add the `approved` label to
    75  your PR. In order for PR to merge, it must have the following:
    76  
    77  1. The `approved` label
    78  2. The `lgtm` label
    79  3. All tests passing in CI, which is managed by Prow.
    80  
    81  If you are not a member of the OpenShift GitHub organization, an OpenShift team member will need to
    82  add the `ok-to-test` label to your PR for our CI tests to run.
    83  
    84  ### Feature or Bugfix PRs
    85  
    86  Pull requests which implement a feature or fix a bug should consist of a single commit with the
    87  full code changes. Commit messages should have the following structure:
    88  
    89  ```text
    90  <Title - under 50 characters>
    91  
    92  <Body - under 100 characters per line>
    93  
    94  <Footer>
    95  ```
    96  
    97  The title is required, and should be under 50 characters long. This is a short description of your
    98  change.
    99  
   100  The body is optional, and may contain a longer description of the changes in the commit. Lines
   101  should not exceed 100 characters in length for readability.
   102  
   103  The footer is optional, and may contain information such as sign-off lines. If your code is related
   104  to a GitHub issue, add it here with the text `Fixes xxx`.
   105  
   106  ### Work In Progress PRs
   107  
   108  Contributors who would like feedback but are still making code modifications can create "work in
   109  progress" PRs by adding "WIP" to the PR title. Once work is done and ready for final review, please
   110  remove "WIP" from your PR title and [squash your commits](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec).
   111  
   112  ### Updating dependencies
   113  
   114  Pull requests which update dependencies are an exception to the "one commit" rule.
   115  To better track dependency changes, PRs with dependency updates should have the following structure:
   116  
   117  1. A commit with changes to `go.mod` and `go.sum` declaring the new or updated dependencies.
   118  2. A commit with updates to vendored code, with `bump(<modules>)` in the title:
   119     1. If only a small number of modules are updated, list them in the parentheses.
   120        Example: `bump(containers/image/v5):`
   121     2. If several modules are updated, use `bump(*)` as the title.
   122     3. Include a reason for updating dependencies in the commit body.
   123  3. If necessary, add a commit with reactions to vendored code changes (ex - method signature
   124     updates).
   125  4. If necessary, add a commit with code that takes advantage of the newly vendored code.
   126  
   127  See [HACKING.md](docs/HACKING.md#dependency-management) for more information on how to update dependencies.