Conversation
|
Review requested:
|
nodejs-github-bot
added
the
meta
avivkeller
force-pushed
the
broaden-stale-bot
branch
from
3184085 to
d79d8b4
Compare
There was a problem hiding this comment.
Pull request overview
Broadens and unifies the repository’s stale-item automation by expanding the stale workflow beyond feature-request-only issues and folding PR staleness handling into the same workflow, while removing now-obsolete feature-request automation documentation and a dedicated PR-stale workflow.
Changes:
- Updates
.github/workflows/stale.ymlto runactions/stalefor both issues and pull requests (and removes the “feature request only” targeting). - Removes the standalone PR stale workflow (
close-stale-pull-requests.yml) in favor of the unified stale workflow. - Simplifies
feature-request-management.mdby removing the automated feature request handling section.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
doc/contributing/feature-request-management.md |
Removes documented automated feature-request stale/close process and related never-stale guidance. |
.github/workflows/stale.yml |
Broadens stale bot to apply to both issues and PRs, updates messages, and adds PR configuration. |
.github/workflows/close-stale-pull-requests.yml |
Deletes the older, separate PR stale-closure workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| days-before-stale: 210 | ||
| days-before-close: 30 |
There was a problem hiding this comment.
The PR description proposes marking items stale after 150 days of inactivity and closing after 240 days total, but this workflow is configured for days-before-stale: 180 and days-before-close: 30 (210 days total). Either update these values to match the intended 150/90 split (or 240 total), or adjust the PR description/messages so the implemented policy is accurate.
| stale-issue-label: stale | ||
| exempt-issue-labels: never-stale, confirmed-bug | ||
| close-issue-message: ${{ env.CLOSE_MESSAGE }} |
There was a problem hiding this comment.
Per the PR description, issues labeled confirmed-bug should also be exempt from staleness/closure, but exempt-issue-labels only includes never-stale. Consider adding confirmed-bug here (comma-separated) if that’s the intended behavior.
| CLOSE_MESSAGE: > | ||
| This issue has been automatically closed after 30 days of inactivity | ||
| following its stale status (no activity for a total of 240 days). | ||
| If this is still relevant, feel free to reopen it or leave a comment | ||
| with additional details so we can continue the discussion. | ||
| WARN_MESSAGE: > | ||
| This issue has been marked as stale due to 210 days of inactivity. | ||
| It will be automatically closed in 30 days if no further activity occurs. | ||
| If this is still relevant, please leave a comment or update it to keep it open. |
There was a problem hiding this comment.
CLOSE_MESSAGE/WARN_MESSAGE are written as "This issue…" but they are also used for PRs via close-pr-message/stale-pr-message, so the bot will post issue-specific wording on pull requests. Consider making the text neutral (e.g., "issue or pull request") or using separate env vars/messages for issues vs PRs.
| If you come across a feature request and want to add your | ||
| support for that feature please express your support | ||
| with the thumbs up emoji as a reaction. At some point in the | ||
| future we may use this as additional input in the automated | ||
| handling of feature requests. |
There was a problem hiding this comment.
This section still mentions using thumbs-up as input in the "automated handling of feature requests", but the PR removes the entire "Automated feature request handling" section below. Consider rewording to avoid referencing a process that is no longer documented here (or link to the new stale policy docs if applicable).
| ## Triage of feature requests | ||
|
|
||
| There is no set process for triaging/handling feature requests. | ||
| Individual collaborators review issues marked as `feature request` | ||
| along with other issues and may or may not decide to | ||
| work on an implementation or advocate on their behalf. | ||
|
|
||
| If a collaborator believes a feature request must be implemented | ||
| they can add the `never-stale` label to the issue and it will | ||
| be excluded from the automated feature request handling | ||
| as outlined below. | ||
|
|
||
| ## Expressing support for a feature request |
There was a problem hiding this comment.
This doc removed the guidance about using the never-stale label to exclude feature requests from automated closure, but the repo still uses never-stale as an exemption label in the stale workflow. Consider keeping a short note here (or linking to the relevant policy) so feature request authors know how to prevent automated stale/close when appropriate.
As it currently stands, in order for an issue or PR to be marked as stale, the following conditions must be true:
(For issues)
feature requestnever-stale(For PRs)
never-staleI propose we change this to cover more issues and pull requests, following this new configuration:
never-stale. If an issue, this also includesconfirmed-bug.I understand this will likely incur a little bit of noise for the next run, but in the end, I think it'll help not just clean up the issue tracker, but draw attention to PRs that may have fallen through the cracks.