You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/PULL_REQUEST_TEMPLATE.md
+16-1Lines changed: 16 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,22 @@
1
1
### Proposed changes
2
-
Describe the use case and detail of the change. If this PR addresses an issue on GitHub, make sure to include a link to that issue here in this description (not in the title of the PR).
2
+
3
+
Write a clear and concise description that helps reviewers understand the purpose and impact of your changes. Use the
4
+
following format:
5
+
6
+
Problem: Give a brief overview of the problem or feature being addressed.
7
+
8
+
Solution: Explain the approach you took to implement the solution, highlighting any significant design decisions or
9
+
considerations.
10
+
11
+
Testing: Describe any testing that you did.
12
+
13
+
Please focus on (optional): If you any specific areas where you would like reviewers to focus their attention or provide
14
+
specific feedback, add them here.
15
+
16
+
Closes #ISSUE
3
17
4
18
### Checklist
19
+
5
20
Before creating a PR, run through this checklist and mark each as complete.
6
21
7
22
-[ ] I have read the [CONTRIBUTING](https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/CONTRIBUTING.md) doc
To ask a question please use [Github Discussions](https://github.com/nginxinc/nginx-kubernetes-gateway/discussions).
28
+
To ask a question, use [Github Discussions](https://github.com/nginxinc/nginx-kubernetes-gateway/discussions).
24
29
25
-
[NGINX Community Slack](https://community.nginx.org/joinslack) has a dedicated channel for this project -- `#nginx-kubernetes-gateway`.
30
+
[NGINX Community Slack](https://community.nginx.org/joinslack) has a dedicated channel for this
31
+
project -- `#nginx-kubernetes-gateway`.
26
32
27
-
Please reserve GitHub issues for feature requests and bugs rather than general questions.
33
+
Reserve GitHub issues for feature requests and bugs rather than general questions.
28
34
29
35
## Getting Started
30
36
31
-
Follow our [Installation Instructions](README.md#run-nginx-gateway) to get the NGINX Kubernetes Gateway up and running.
37
+
Follow our [Installation Instructions](/docs/installation.md) to get the NGINX Kubernetes Gateway up and running.
32
38
33
39
### Project Structure
34
40
@@ -40,52 +46,80 @@ Follow our [Installation Instructions](README.md#run-nginx-gateway) to get the N
40
46
* Deployment yaml files are found at `deploy/`
41
47
* External APIs, clients, and SDKs can be found under `pkg/`
42
48
* We use [Go Modules](https://github.com/golang/go/wiki/Modules) for managing dependencies.
43
-
* We use [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) for our BDD style unit tests.
49
+
* We use [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) for our BDD style unit
50
+
tests.
44
51
45
52
## Contributing
46
53
47
-
### Report a Bug
54
+
### Issues and Discussions
55
+
56
+
#### Open a Discussion
57
+
58
+
If you have any questions, ideas, or simply want to engage in a conversation with the community and maintainers, we
59
+
encourage you to open a [discussion](https://github.com/nginxinc/nginx-kubernetes-gateway/discussions) on GitHub. We
60
+
highly recommend that you open a discussion about a potential enhancement before opening an issue. This enables the
61
+
maintainers to gather valuable insights regarding the idea and its use cases, while also giving the community an
62
+
opportunity to provide valuable feedback.
63
+
64
+
#### Report a Bug
48
65
49
-
To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please ensure the issue has not already been reported.
66
+
To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Before
67
+
reporting a bug, make sure the issue has not already been reported.
50
68
51
-
### Suggest an Enhancement
69
+
####Suggest an Enhancement
52
70
53
-
To suggest an enhancement, please create an issue on GitHub with the label `enhancement` using the available feature issue template.
71
+
To suggest an enhancement, create an issue on GitHub with the label `proposal` using the available feature issue
72
+
template.
54
73
55
-
###Open a Pull Request
74
+
#### Issue lifecycle
56
75
57
-
* Fork the repo, create a branch, submit a PR when your changes are tested and ready for review
58
-
* Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md)
76
+
When an issue or PR is created, it will be triaged by the maintainers and assigned a label to indicate the type of issue
77
+
it is (bug, feature request, etc) and to determine the milestone. See the [Issue Lifecycle](/ISSUE_LIFECYCLE.md) document
78
+
for more information.
59
79
60
-
> **Note**
61
-
>
62
-
> If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature.
80
+
### Development Guide
63
81
64
-
### Issue lifecycle
82
+
Before beginning development, familiarize yourself with the following documents:
65
83
66
-
* When an issue or PR is created, it will be triaged by the core development team and assigned a label to indicate the type of issue it is (bug, feature request, etc) and to determine the milestone. Please see the [Issue Lifecycle](ISSUE_LIFECYCLE.md) document for more information.
84
+
-[Developer Quickstart](/docs/developer/quickstart.md): This guide provides a quick and easy walkthrough of setting up
85
+
your development environment and executing tasks required when submitting a pull request.
86
+
-[Branching and Workflow](/docs/developer/branching-and-workflow.md): This document outlines the project's specific
87
+
branching and workflow practices, including instructions on how to name a branch.
88
+
-[Implement a Feature](/docs/developer/implementing-a-feature.md): A step-by-step guide on how to implement a feature or
89
+
bug.
90
+
-[Testing](/docs/developer/testing.md): The project's testing guidelines, includes both unit testing and manual testing
91
+
procedures. This document explains how to write and run unit tests, and how to manually verify changes.
92
+
-[Pull Request Guidelines](/docs/developer/pull-request.md): A guide for both pull request submitters and reviewers,
93
+
outlining guidelines and best practices to ensure smooth and efficient pull request processes.
67
94
68
95
## Style Guides
69
96
70
97
### Git Style Guide
71
98
72
-
* Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before submitting a PR
73
-
* Follow the guidelines of writing a good commit message as described [here](https://chris.beams.io/posts/git-commit/) and summarized in the next few points
99
+
* Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before
100
+
submitting a PR
101
+
* Follow the guidelines of writing a good commit message as described [here](https://chris.beams.io/posts/git-commit/)
102
+
and summarized in the next few points
74
103
* In the subject line, use the present tense ("Add feature" not "Added feature")
75
104
* In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...")
76
105
* Limit the subject line to 72 characters or less
77
106
* Reference issues and pull requests liberally after the subject line
78
-
* Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in your text editor to write a good message instead of `git commit -am`)
107
+
* Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in
108
+
your text editor to write a good message instead of `git commit -am`)
79
109
80
110
### Go Style Guide
81
111
82
-
* Run `gofmt` over your code to automatically resolve a lot of style issues. Most editors support this running automatically when saving a code file.
112
+
* Run `gofmt` over your code to automatically resolve a lot of style issues. Most editors support this running
113
+
automatically when saving a code file.
83
114
* Run `go lint` and `go vet` on your code too to catch any other issues.
84
115
* Follow this guide on some good practice and idioms for Go - https://github.com/golang/go/wiki/CodeReviewComments
85
-
* To check for extra issues, install [golangci-lint](https://github.com/golangci/golangci-lint) and run `make lint` or `golangci-lint run`
116
+
* To check for extra issues, install [golangci-lint](https://github.com/golangci/golangci-lint) and run `make lint`
117
+
or `golangci-lint run`
86
118
87
119
## Contributor License Agreement
88
120
89
-
Individuals or business entities who contribute to this project must have completed and submitted the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf) prior to their code submission being included in this project.
90
-
To submit, please print out the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf), fill in the required sections, sign, scan, and send executed CLA to kubernetes@nginx.com.
91
-
Please include your github handle in the CLA email.
121
+
Individuals or business entities who contribute to this project must have completed and submitted
122
+
the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf) prior to their code submission being included
123
+
in this project. To submit, print out the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf), fill
124
+
in the required sections, sign, scan, and send executed CLA to kubernetes@nginx.com. Make sure to include your github
This document provides guidance on implementing new features in the project. Follow the recommended steps and best
4
+
practices to ensure a successful feature development process.
5
+
6
+
> **Note**
7
+
>
8
+
> If you’d like to implement a new feature, please open a discussion about the feature before creating an issue or opening a PR.
9
+
10
+
1.**Assign yourself to the GitHub issue for the feature**: Each feature must have a corresponding GitHub issue to track
11
+
its progress.
12
+
2.**Post any questions or comments about the feature on the corresponding issue**: This allows for better tracking and
13
+
visibility. If any discussions regarding the issue occur outside the issue thread, provide a summary of the
14
+
conversation as a comment on the issue itself. This ensures that all relevant information and discussions are
15
+
consolidated in one place for easy reference.
16
+
3.**Fork the repo**: NKG follows a fork workflow, which you can learn more about in
17
+
the [branching and workflow](/docs/developer/branching-and-workflow.md) documentation.
18
+
4.**Branch**: Create a branch following
19
+
the [naming conventions](/docs/developer/branching-and-workflow.md#branch-naming-conventions).
20
+
5.**Make changes**: Make the necessary changes for the feature.
21
+
6.**Consider opening a draft PR**: If your feature involves substantial architecture changes, or you would like to
22
+
receive early feedback, consider opening a draft PR and requesting reviews from the maintainers. Draft PRs are an
23
+
effective means to solicit feedback and ensure that major architectural changes align with the project's goals and
24
+
standards.
25
+
7.**Add or update unit tests** All features **must** be accompanied by unit tests that verify the functionality. Make
26
+
sure to thoroughly test the different scenarios and edge cases related to the feature to ensure robustness and
27
+
reliability. Additionally, open the code coverage report to ensure that the code you added has sufficient test
28
+
coverage. For instructions on writing and running unit tests, refer to
29
+
the [testing](/docs/developer/testing.md#unit-test-guidelines) documentation.
30
+
8.**Manually verify your changes**: Refer to the [manual testing](/docs/developer/testing.md#manual-testing) section of
31
+
the testing documentation for instructions on how to manually test your changes.
32
+
9.**Update any relevant documentation**: Here are some guidelines for updating documentation:
33
+
-**Gateway API Feature**: If you are implementing a Gateway API feature, make sure to update
34
+
the [Gateway API Compatibility](/docs/gateway-api-compatibility.md) documentation.
35
+
-**New Use Case:** If your feature introduces a new use case, add an example of how to use it in
36
+
the [examples](/examples) directory. This example will help users understand how to leverage the new feature.
37
+
-**Installation Changes**: If your feature involves changes to the installation process of NKG, update
38
+
the [installation](/docs/installation.md) documentation.
39
+
-**Command-line Changes**: If your feature introduces or changes a command-line flag or subcommand, update
40
+
the [cli help](/docs/cli-help.md) documentation.
41
+
-**Other Documentation Updates**: For any other changes that affect the behavior, usage, or configuration of NKG,
42
+
review the existing documentation and update it as necessary. Ensure that the documentation remains accurate and
43
+
up to date with the latest changes.
44
+
10.**Lint code**: See the [run the linter](/docs/developer/quickstart.md#run-the-linter) section of the quickstart
45
+
guide for instructions.
46
+
11.**Open pull request**: Open a pull request targeting the `main` branch of
47
+
the [nginx-kubernetes-gateway](https://github.com/nginxinc/nginx-kubernetes-gateway/tree/main) repository. The
48
+
entire `nginx-kubernetes-gateway` group will be automatically requested for review. If you have a specific or
49
+
different reviewer in mind, you can request them as well. Refer to
50
+
the [pull request](/docs/developer/pull-request.md) documentation for expectations and guidelines.
51
+
12.**Obtain the necessary approvals**: Work with code reviewers to maintain the required number of approvals.
52
+
13.**Squash and merge**: Squash your commits locally, or use the GitHub UI to squash and merge. Only one commit per
53
+
pull request should be merged. Make sure the first line of the final commit message includes the pull request
54
+
number. For example, Fix supported gateway conditions in compatibility doc (#674).
55
+
> **Note**:
56
+
When you squash commits, make sure to not include any commit messages related to the code review
57
+
(for example, Fixed a typo). If you changed the code as a result of the code review in way that the original commit message no longer describes it well, make sure to update the message.
58
+
59
+
60
+
61
+
## Fixing a Bug
62
+
63
+
When fixing a bug, follow the same process as [implementing a feature](#implementing-a-feature) with one additional
64
+
requirement:
65
+
66
+
All bug fixes should be reproduced with a unit test before submitting any code. Once the bug is reproduced in a unit
67
+
test, make the necessary code changes to address the issue and ensure that the unit test passes successfully. This
68
+
systematic approach helps ensure that the bug is properly understood, effectively resolved, and prevents regression.
0 commit comments