From e4312597a7f690fe5e0214148cb848d49fda274e Mon Sep 17 00:00:00 2001 From: Luca Comellini Date: Tue, 14 Feb 2023 16:34:10 -0800 Subject: [PATCH 1/2] Add Issue Lifecycle and update Contributing --- CONTRIBUTING.md | 24 +++++++++++++++++------- ISSUE_LIFECYCLE.md | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 7 deletions(-) create mode 100644 ISSUE_LIFECYCLE.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 89a97bd8de..b83e0899f7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,13 +14,17 @@ The following is a set of guidelines for contributing to NGINX Kubernetes Gatewa * [Git Style Guide](#git-style-guide) * [Go Style Guide](#go-style-guide) -[Code of Conduct](https://github.com/nginxinc/nginx-kubernetes-gateway/blob/master/CODE_OF_CONDUCT.md) +[Code of Conduct](CODE_OF_CONDUCT.md) [Contributor License Agreement](#contributor-license-agreement) ## Ask a Question -We will have a public forum soon where you can come and ask questions and have a discussion. For now please open an Issue on GitHub with the label `question`. +To ask a question please use [Github Discussions](https://github.com/nginxinc/nginx-kubernetes-gateway/discussions). + +You can also join our [Community Slack](https://community.nginx.org/joinslack) which has a wider NGINX audience. + +Please reserve GitHub issues for feature requests and bugs rather than general questions. ## Getting Started @@ -36,7 +40,7 @@ Follow our [Installation Instructions](README.md#run-nginx-gateway) to get the N * Deployment yaml files are found at `deploy/` * External APIs, clients, and SDKs can be found under `pkg/` * We use [Go Modules](https://github.com/golang/go/wiki/Modules) for managing dependencies. -* We use [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) for our BDD style unit tests. +* We use [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) for our BDD style unit tests. ## Contributing @@ -51,16 +55,22 @@ To suggest an enhancement, please create an issue on GitHub with the label `enha ### Open a Pull Request * Fork the repo, create a branch, submit a PR when your changes are tested and ready for review -* Fill in [our pull request template](https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/.github/PULL_REQUEST_TEMPLATE.md) +* Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md) + +> **Note** +> +> If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature. + +### Issue lifecycle -Note: if you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature. +* 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. ## Style Guides ### Git Style Guide * Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before submitting a PR -* Follow the guidelines of writing a good commit message as described [here](https://chris.beams.io/posts/git-commit/) and summarised in the next few points +* 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 * In the subject line, use the present tense ("Add feature" not "Added feature") * In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...") * Limit the subject line to 72 characters or less @@ -76,6 +86,6 @@ Note: if you’d like to implement a new feature, please consider creating a fea ## Contributor License Agreement -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. +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. 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. Please include your github handle in the CLA email. diff --git a/ISSUE_LIFECYCLE.md b/ISSUE_LIFECYCLE.md new file mode 100644 index 0000000000..c57bc03775 --- /dev/null +++ b/ISSUE_LIFECYCLE.md @@ -0,0 +1,37 @@ +# Issue Lifecycle + +To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue lifecycle.) + +1. New issue created by community member. + + +2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the issue through the subsequent stages in the issue lifecycle. + + +3. Determine issue type: This is done with automation where possible, and manually by the owner where necessary. The associated label is applied to the issue. + #### Possible Issue Types + `needs more info`: The owner should use the issue to request information from the creator. If we don't receive the needed information within 7 days, automation closes the issue. + + `bug`: The implementation of a feature is not correct. + + `proposal`: Request for a change. This can be a new feature, tackling technical debt, documentation changes, or improving existing features. + + `question`: The owner converts the issue to a github discussion and engages the creator. + + +4. Determine milestone: The owner, in collaboration with the wider team (PM & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two 'magic' milestones with special meanings (not tied to a specific release): + + - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes clear that they do not align with our evolving roadmap. + + - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in the issue and wants the community to weigh in before we make our final decision. + + `backlog` issues can be labeled by the owner as `help wanted` and/or `good first issue` as appropriate. + + +5. Promotion of `backlog candidate` issue to `backlog` issue: If an issue labelled `backlog candidate` receives more than 30 upvotes within 60 days, we promote the issue by applying the `backlog` label. While issues promoted in this manner have not been committed to a particular release, we welcome PRs from the community on them. + + If an issue does not make our roadmap and has not been moved to a discussion, it is closed with the label `out of scope`. The goal is to get every issue in the issues list to one of the following end states: + + - An assigned release. + - The `backlog` label. + - Closed as `out of scope`. From 6c67e01c1375d5a8cbcb2c1da139b3e8fecf83b5 Mon Sep 17 00:00:00 2001 From: Luca Comellini Date: Thu, 16 Feb 2023 09:44:30 -0800 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Michael Pleshakov --- CONTRIBUTING.md | 2 +- ISSUE_LIFECYCLE.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b83e0899f7..0e854e6f52 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,7 +22,7 @@ The following is a set of guidelines for contributing to NGINX Kubernetes Gatewa To ask a question please use [Github Discussions](https://github.com/nginxinc/nginx-kubernetes-gateway/discussions). -You can also join our [Community Slack](https://community.nginx.org/joinslack) which has a wider NGINX audience. +[NGINX Community Slack](https://community.nginx.org/joinslack) has a dedicated channel for this project -- `#nginx-kubernetes-gateway`. Please reserve GitHub issues for feature requests and bugs rather than general questions. diff --git a/ISSUE_LIFECYCLE.md b/ISSUE_LIFECYCLE.md index c57bc03775..479884baa0 100644 --- a/ISSUE_LIFECYCLE.md +++ b/ISSUE_LIFECYCLE.md @@ -14,14 +14,14 @@ To ensure a balance between work carried out by the NGINX engineering team while `bug`: The implementation of a feature is not correct. - `proposal`: Request for a change. This can be a new feature, tackling technical debt, documentation changes, or improving existing features. + `proposal`: A new feature, tackling technical debt, documentation changes, or improving existing features. `question`: The owner converts the issue to a github discussion and engages the creator. -4. Determine milestone: The owner, in collaboration with the wider team (PM & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two 'magic' milestones with special meanings (not tied to a specific release): +4. Determine milestone: The owner, in collaboration with the wider team (product management & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two special milestones not tied to a specific release: - - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes clear that they do not align with our evolving roadmap. + - Issues assigned to `backlog`: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes clear that they do not align with our evolving roadmap. - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in the issue and wants the community to weigh in before we make our final decision.