Add Issue Lifecycle and update Contributing (#308)

Author: lucacome

CONTRIBUTING.md

@@ -14,23 +14,27 @@ The following is a set of guidelines for contributing to the NGINX AWS Auto-Scal
   * [Git Style Guide](#git-style-guide)
   * [Go Style Guide](#go-style-guide)
 
-[Code of Conduct](https://github.com/nginxinc/nginx-asg-sync/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-asg-sync/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
 
-Read the installation, configuration and building steps in the [README](https://github.com/nginxinc/nginx-asg-sync/blob/main/README.md).
+Read the installation, configuration and building steps in the [README](README.md).
 
 ### Project Structure
 
 * nginx-asg-sync is a service written in Go that works with NGINX Plus.
 * The main code is found under `/cmd/sync/`
 * Tools for building the service for supported Operating Systems are found under `/build/package`
-* The project dependencies reside in the `/vendor`. We use [dep](https://github.com/golang/dep) for managing dependencies.
+* We use [Go modules](https://github.com/golang/go/wiki/Modules) for managing dependencies.
 * There is a Makefile at the project root used in the build steps.
 
 ## Contributing
@@ -46,16 +50,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-asg-sync/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

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

README.md

@@ -14,7 +14,9 @@ nginx-asg-sync is an agent process that runs on the same instance as NGINX Plus.
 
 When it sees that a scaling event has happened, it adds or removes the corresponding backend instances from the NGINX Plus configuration via the NGINX Plus API.
 
-**Note:** nginx-asg-sync does not scale cloud scaling groups, it only gets the IP addresses of the instances in the groups.
+> **Note**
+>
+> nginx-asg-sync does not scale cloud scaling groups, it only gets the IP addresses of the instances in the groups.
 
 In the example below (AWS), NGINX Plus is configured to load balance among the instances of two AWS Auto Scaling groups -- Backend One and Backend Two.
 nginx-asg-sync, running on the same instance as NGINX Plus, ensures that whenever you scale the Auto Scaling groups, the corresponding instances are added (or removed) from the NGINX Plus configuration.
@@ -24,7 +26,9 @@ nginx-asg-sync, running on the same instance as NGINX Plus, ensures that wheneve
 Below you will find documentation on how to use nginx-asg-sync.
 
 ## Documentation
-**Note:** the documentation for **the latest stable release** is available via a link in the description of the release. See the [releases page](https://github.com/nginxinc/nginx-asg-sync/releases).
+> **Note**
+>
+> The documentation for **the latest stable release** is available via a link in the description of the release. See the [releases page](https://github.com/nginxinc/nginx-asg-sync/releases).
 
 **Contents:**
 - [NGINX Plus Integration with Cloud Autoscaling -- nginx-asg-sync](#nginx-plus-integration-with-cloud-autoscaling----nginx-asg-sync)
@@ -134,7 +138,9 @@ Small timeouts ensure that a health check will fail fast if the backend instance
 
 When using AWS it's possible to filter out the instances that are not in a `InService` state of the [Lifecycle](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html) with the parameter `in_service` set to `true`. This will ensure that the IP won't be added until the instance is ready to accept requests.
 This also works when an instance is being terminated: the asg-sync will remove the IP of an instance that went from  the `InService` state to one of the terminating states.
-**Note**: because the asg-sync works on a polling-based model, there will be a delay between the instance  going to a terminating state and the asg-sync removing its IP from NGINX Plus. To guarantee that NGINX Plus doesn't send any requests to a terminated instance, make sure the instance goes to the `Terminating:Wait` state for a period greater than the interval `sync_interval_in_seconds`.
+> **Note**
+>
+> Because the asg-sync works on a polling-based model, there will be a delay between the instance  going to a terminating state and the asg-sync removing its IP from NGINX Plus. To guarantee that NGINX Plus doesn't send any requests to a terminated instance, make sure the instance goes to the `Terminating:Wait` state for a period greater than the interval `sync_interval_in_seconds`.
 
 ### Configuration for Cloud Providers
 
@@ -164,7 +170,9 @@ To build the binaries and packages for all the supported architectures, run `$ m
 
 To build the binaries and packages for all the supported architectures in Docker, run `$ make build-goreleaser-docker`.
 
-**Note: When building with GoReleaser the resulting binaries and packages are located in the `dist` folder.**
+> **Note**
+>
+> When building with GoReleaser the resulting binaries and packages are located in the `dist` folder.
 
 ## Contacts