Update stale workflow (nginx#1525)

Author: miledxz

.github/workflows/stale.yml

@@ -16,16 +16,14 @@ jobs:
       - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e # v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          stale-issue-message: "This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 10 days."
-          stale-pr-message: "This PR is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 10 days."
-          close-issue-message: "This issue was closed because it has been stalled for 10 days with no activity."
-          close-pr-message: "This PR was closed because it has been stalled for 10 days with no activity."
+          stale-issue-message: "This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days."
+          stale-pr-message: "This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days."
+          close-issue-message: "This issue was closed because it has been stalled for 14 days with no activity."
+          close-pr-message: "This PR was closed because it has been stalled for 14 days with no activity."
           stale-issue-label: "stale"
           stale-pr-label: "stale"
-          exempt-all-assignees: true
-          exempt-all-milestones: true
+          exempt-issue-milestones: true
           exempt-issue-labels: "backlog, backlog candidate"
-          exempt-pr-labels: "backlog, backlog candidate"
           operations-per-run: 100
-          days-before-stale: 90
-          days-before-close: 10
+          days-before-stale: 14
+          days-before-close: 14

ISSUE_LIFECYCLE.md

@@ -1,8 +1,8 @@
 # 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
+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.
@@ -15,12 +15,11 @@ lifecycle.)
 
    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.
 
    - `bug`: The implementation of a feature is not correct.
 
-   - `enhancement`:  An enhancement, tackling technical debt, documentation changes, or improving existing features.
+   - `enhancement`: An enhancement, tackling technical debt, documentation changes, or improving existing features.
 
    - `enhancement-proposal`: Enhancements that require an [Enhancement Proposal](/docs/proposals/README.md).
 
@@ -30,25 +29,27 @@ lifecycle.)
    what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two
    special milestones 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.
 
 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 has been open for 14 days and does not have a milestone or the `backlog`/`backlog candidate` label, it
+   will automatically be marked as `stale`. If no changes are made for 14 days after it was marked `stale`,
+   the automation will close it as `not planned`.
+   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`.
+   - An assigned milestone.
+   - The `backlog` label.
+   - Closed as `not planned`.