Update labels, Issue Lifecycle and Contributing

.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
@@ -39,7 +60,7 @@
   name: question
 - color: FEF2C0
   description: Pull requests that don't need to be added to the changelog
-  name: skip-changelog
+  name: skip changelog
 - color: 8E7888
   description: Pull requests/issues with no activity
   name: stale
@@ -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

.github/release.yml

@@ -1,7 +1,7 @@
 changelog:
   exclude:
     labels:
-      - skip-changelog
+      - skip changelog
   categories:
     - title: 🚀 Features
       labels:

CONTRIBUTING.md

@@ -14,16 +14,15 @@ The following is a set of guidelines for contributing to the NGINX Ingress Contr
   * [Git Style Guide](#git-style-guide)
   * [Go Style Guide](#go-style-guide)
 
-[Code of Conduct](https://github.com/nginxinc/kubernetes-ingress/blob/main/CODE_OF_CONDUCT.md)
+[Code of Conduct](CODE_OF_CONDUCT.md)
 
 ## Ask a Question
 
 To ask a question please use [Github Discussions](https://github.com/nginxinc/kubernetes-ingress/discussions).
 
-You can also join our [Community Slack channel](https://community.nginx.org/joinslack) which has a wider NGINX audience.
-
-Please reserve Github issues for feature requests and bugs rather than general questions.
+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
 
@@ -37,9 +36,10 @@ 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.
+    * We use [Go modules](https://github.com/golang/go/wiki/Modules) for managing dependencies.
 
 ## Contributing
 
@@ -55,16 +55,22 @@ To suggest an new feature or other improvement, create an issue on Github and ch
 
 * Before working on a possible pull request, first open an associated issue describing the proposed change. This allows the core development team to discuss the potential pull request with you before you do the work.
 * 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/kubernetes-ingress/blob/main/.github/PULL_REQUEST_TEMPLATE.md)
+* Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md)
+
+> **Note**
+>
+> Remember to create a feature request / bug report issue first to start a discussion about the proposed change.
+
+### Issue lifecycle
 
-**Note**: Remember to create a feature request / bug report issue first to start a discussion about the proposed change.
+* 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

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