|
| 1 | +# Contributing Guidelines |
| 2 | + |
| 3 | +The following is a set of guidelines for contributing to the NGINX Supportpkg for k8s. We really appreciate that you are |
| 4 | +considering contributing! |
| 5 | + |
| 6 | +<!-- START doctoc generated TOC please keep comment here to allow auto update --> |
| 7 | +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
| 8 | +## Table of Contents |
| 9 | + |
| 10 | +- [Ask a Question](#ask-a-question) |
| 11 | +- [Getting Started](#getting-started) |
| 12 | +- [Contributing](#contributing) |
| 13 | + - [Report a Bug](#report-a-bug) |
| 14 | + - [Suggest an Enhancement](#suggest-an-enhancement) |
| 15 | + - [Open a Pull Request](#open-a-pull-request) |
| 16 | + - [Issue lifecycle](#issue-lifecycle) |
| 17 | + - [F5 Contributor License Agreement (CLA)](#f5-contributor-license-agreement-cla) |
| 18 | +- [Style Guides](#style-guides) |
| 19 | + - [Git Style Guide](#git-style-guide) |
| 20 | + - [Go Style Guide](#go-style-guide) |
| 21 | + |
| 22 | +<!-- END doctoc generated TOC please keep comment here to allow auto update --> |
| 23 | + |
| 24 | +## Ask a Question |
| 25 | + |
| 26 | +To ask a question please use [Github Discussions](https://github.com/nginxinc/nginx-supportpkg-for-k8s/discussions). |
| 27 | + |
| 28 | +You can also join our [Community Slack](https://community.nginx.org/joinslack) which has a wider NGINX audience. |
| 29 | + |
| 30 | +Please reserve GitHub issues for feature requests and bugs rather than general questions. |
| 31 | + |
| 32 | +## Getting Started |
| 33 | + |
| 34 | +Read the usage and testing steps in the [README](README.md). |
| 35 | + |
| 36 | +## Contributing |
| 37 | + |
| 38 | +### Report a Bug |
| 39 | + |
| 40 | +To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please |
| 41 | +ensure the issue has not already been reported. |
| 42 | + |
| 43 | +### Suggest an Enhancement |
| 44 | + |
| 45 | +To suggest an enhancement, please create an issue on GitHub with the label `enhancement` using the available feature |
| 46 | +issue template. |
| 47 | + |
| 48 | +### Open a Pull Request |
| 49 | + |
| 50 | +- Fork the repo, create a branch, submit a PR when your changes are tested and ready for review |
| 51 | +- Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md) |
| 52 | + |
| 53 | +> **Note** |
| 54 | +> |
| 55 | +> If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion |
| 56 | +> about the feature. |
| 57 | +
|
| 58 | +### Issue lifecycle |
| 59 | + |
| 60 | +- When an issue or PR is created, it will be triaged by the core development team and assigned a label to indicate the |
| 61 | + type of issue it is (bug, feature request, etc) and to determine the milestone. Please see the [Issue |
| 62 | + Lifecycle](ISSUE_LIFECYCLE.md) document for more information. |
| 63 | + |
| 64 | +### F5 Contributor License Agreement (CLA) |
| 65 | + |
| 66 | +F5 requires all external contributors to agree to the terms of the F5 CLA (available [here](https://github.com/f5/.github/blob/main/CLA/cla-markdown.md)) |
| 67 | +before any of their changes can be incorporated into an F5 Open Source repository. |
| 68 | + |
| 69 | +If you have not yet agreed to the F5 CLA terms and submit a PR to this repository, a bot will prompt you to view and |
| 70 | +agree to the F5 CLA. You will have to agree to the F5 CLA terms through a comment in the PR before any of your changes |
| 71 | +can be merged. Your agreement signature will be safely stored by F5 and no longer be required in future PRs. |
| 72 | + |
| 73 | +## Style Guides |
| 74 | + |
| 75 | +### Git Style Guide |
| 76 | + |
| 77 | +- Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before |
| 78 | + submitting a PR |
| 79 | +- Follow the guidelines of writing a good commit message as described here <https://chris.beams.io/posts/git-commit/> |
| 80 | + and summarized in the next few points |
| 81 | + - In the subject line, use the present tense ("Add feature" not "Added feature") |
| 82 | + - In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...") |
| 83 | + - Limit the subject line to 72 characters or less |
| 84 | + - Reference issues and pull requests liberally after the subject line |
| 85 | + - Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in |
| 86 | + your text editor to write a good message instead of `git commit -am`) |
| 87 | + |
| 88 | +### Go Style Guide |
| 89 | + |
| 90 | +- Run `gofmt` over your code to automatically resolve a lot of style issues. Most editors support this running |
| 91 | + automatically when saving a code file. |
| 92 | +- Run `go lint` and `go vet` on your code too to catch any other issues. |
| 93 | +- Follow this guide on some good practice and idioms for Go - <https://github.com/golang/go/wiki/CodeReviewComments> |
| 94 | +- To check for extra issues, install [golangci-lint](https://github.com/golangci/golangci-lint) and run `make lint` or |
| 95 | + `golangci-lint run` |
0 commit comments