Update labels

Author: lucacome

.github/labels.yml

@@ -1,3 +1,9 @@
+- color: 77BC7C
+  description: Pull requests/issues that are backlog items
+  name: backlog
+- color: A90EA3
+  description: Pull requests/issues that are candidates to be backlog items
+  name: backlog-candidate
 - color: fc2929
   description: An issue reporting a potential bug
   name: bug
@@ -25,9 +31,24 @@
 - color: 16e2e2
   description: Pull requests that update Go code
   name: go
+- color: 5319E7
+  description: Issues identified as good for first-time contributors
+  name: good first issue
+- color: 0e8a16
+  description: Pull requests that update the Helm Chart
+  name: helm_chart
+- color: FBCA04
+  description: Issues identified as good community contribution opportunities
+  name: help wanted
 - color: c5def5
   description: Gathering information
-  name: in_review
+  name: in review
+- color: 68E39B
+  description: Issues that require more information
+  name: needs more info
+- color: F345AD
+  description: Issues that are not in scope
+  name: out of scope
 - color: db754c
   description: An issue that proposes a feature request
   name: proposal
@@ -52,6 +73,3 @@
 - color: ffffff
   description: An issue that does not need to be fixed
   name: wontfix
-- color: 0e8a16
-  description: Pull requests that update the Helm Chart
-  name: helm_chart

CONTRIBUTING.md

@@ -24,7 +24,6 @@ You can also join our [Community Slack channel](https://community.nginx.org/join
 
 Please reserve Github issues for feature requests and bugs rather than general questions.
 
-
 ## Getting Started
 
 Follow our [Installation Guide](https://github.com/nginxinc/kubernetes-ingress/blob/main/docs/content/installation) to get the NGINX Ingress Controller up and running.
@@ -37,9 +36,9 @@ Read the [documentation](https://github.com/nginxinc/kubernetes-ingress/tree/mai
 * The project follows a standard Go project layout
     * The main code is found at `cmd/nginx-ingress/`
     * The internal code is found at `internal/`
-    * Build files for Docker and CI are found under `build/`
+    * Build files for Docker are found at `build/`
+    * CI files are found at `.github/workflows/`
     * Deployment yaml files, and Helm files are found at `deployments/`
-    * The project dependencies are found at `vendor/`. We use [Go Modules](https://github.com/golang/go/wiki/Modules) for managing dependencies.
 
 ## Contributing
 
@@ -59,12 +58,16 @@ To suggest an new feature or other improvement, create an issue on Github and ch
 
 **Note**: Remember to create a feature request / bug report issue first to start a discussion about the proposed change.
 
+### Issue lifecycle
+
+* 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](https://github.com/nginxinc/kubernetes-ingress/blob/main/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

@@ -10,7 +10,7 @@ To ensure a balance between work carried out by the NGINX engineering team while
 
 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.
+   `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.
 
@@ -21,17 +21,17 @@ To ensure a balance between work carried out by the NGINX engineering team while
 
 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: 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.
+    `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:
+   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`.
+   - Closed as `out of scope`.