Merge branch 'main' into support-custom-env-vars

CONTRIBUTING.md

@@ -18,7 +18,11 @@ The following is a set of guidelines for contributing to the NGINX Ingress Contr
 
 ## 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/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.
 
 
 ## Getting Started
@@ -41,18 +45,19 @@ Read the [documentation](https://github.com/nginxinc/kubernetes-ingress/tree/mai
 
 ### Report a Bug
 
-To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please ensure the issue has not already been reported.
+To report a bug, open an issue on GitHub and choose the type 'Bug report'. Please ensure the issue has not already been reported, and that you fill in the template as provided, as this can reduce turnaround time.
 
-### Suggest an Enhancement
+### Suggest a new feature or other improvement
 
-To suggest an enhancement, please create an issue on GitHub with the label `enhancement` using the available feature issue template.
+To suggest an new feature or other improvement, create an issue on Github and choose the type 'Feature request'. Please fill in the template as provided.
 
 ### Open a Pull Request
 
+* 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)
 
-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.
+**Note**: Remember to create a feature request / bug report issue first to start a discussion about the proposed change.
 
 ## Style Guides
 

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