Add Issue Lifecycle and update Contributing (#431)

Co-authored-by: Michael Pleshakov <[email protected]>

Author: lucacome

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).
+
+[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.
 
 ## 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 [email protected].
 Please include your github handle in the CLA email.

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`:  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 (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 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`.