Add Issue Lifecycle and update Contributing (#131)

Author: lucacome

CONTRIBUTING.md

@@ -14,12 +14,15 @@ The following is a set of guidelines for contributing to the NGINX Plus Go Clien
   * [Git Style Guide](#git-style-guide)
   * [Go Style Guide](#go-style-guide)
 
-[Code of Conduct](https://github.com/nginxinc/nginx-plus-go-client/blob/main/CODE_OF_CONDUCT.md)
+[Code of Conduct](CODE_OF_CONDUCT.md)
 
 ## 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-plus-go-client/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
 
@@ -39,16 +42,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
-* You will be asked to fill in [our pull request template](.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

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