RFC: Proposal for autoclose option for non-compliant PRs

Following up on the discussion in #31679 about low-effort contributions (like ai-generated with low human supervision), @lucyleeow and me worked out an idea: We would like to propose introducing an autoclose option for PRs that gets triggered when setting an "autoclose" label that can be removed if the PR is improved.

The idea is to provide a structured way to handle PRs that don't yet meet our contribution standards and facilitate the reviewing process. This will be transparent and fair for new contributors.

**Suggested process**
1. A contributor opens a PR that looks low-effort, fly-by, not supervised ai-generated, or otherwise not yet ready for review.
2. A reviewer sets an "autoclose" label. This would automatically add a polite, standardised comment explaining:
    - The PR will be autoclosed after _n_ weeks (e.g. _4_).
    - A list of common quality issues (similar to what we used in #31822) that outlines what the contributor needs to address in order to avoid the PR being autoclosed (can contain links to the docs and the FAQs where we explain those things in detail).
    - An encouragement to comment on the PR and ping the person who set the "autoclose" once they believe they have met the quality standards and addressed the issues, or when they struggle or need clarification in a specific point.
    - A note that reviewer time is limited and we cannot provide detailed guidance.
3. Possible outcomes:
    - If the author doesn't respond or pushes commits that don't address the issues → PR is autoclosed after the timeout.
    - If the author states problems → reviewers can offer guidance at their discretion, based on capacity and fit.
    - If the author makes the required improvements:
        - ideally either the reviewer who set the label or the person on triage removes the label, which stops the autoclose action, and the PR can be reviewed and move forward as usual
        - in some cases (hopefully not too often) we might miss the deadline and the author would need to open a new PR (that's a downside on applying an the autoclose policy)

**Benefits**
- For maintainers: avoids the implicit obligation to fully review low-quality PRs and allows to focus on genuine contributions.
- For contributors: sets clear expectations from the start, and thoughtful contributors benefit because reviewers have more time for their PRs. 
- For the project: helps keep the PR queue manageable and signals that quality and preparation are expected.

The key point is that this wouldn't reduce our support for new contributors. It only shifts the expectation: authors are responsible for bringing their PRs to a reviewable state, and reviewers can decide how much help to give along the way.

**Technical feasibility**
This should be achievable with a GitHub Action, similar to those used in many open source projects to autoclose stale issues or PRs, but triggered by a label instead of inactivity.

COMMENT:
Thanks for your comments, @betatim. I will try to answer to unclear points:

> Can someone explain how the autoclosing mechanism will work then? 

The idea is to close PRs automatically  _n_ weeks after the `"autoclose"` label has been set if no project member decides the remove the label in the meantime. If the author of an autoclose-marked PR wants us to remove the label, they need to improve the quality of the PR and ping the person who set the label in a comment. (Also, the person on triage can filter for the `"autoclose"` label, which would be quick, since these can only accumulate for _n_ weeks, but there would be no obligation to do so.)

I think we can implement this by using a GitHub Action. See [this example](https://github.com/twbs/bootstrap/blob/main/.github/workflows/issue-close-require.yml) from another project, but I have seen that more projects have set an autoclose action for issues and PRs that have gone stale. Only in this case, we would not use an autoclose action on stale PRs, but on bad quality PRs.

> One question about how the "don't close this" mechanism will work: will it be enough for the PR creator to push more commits after it being labelled? 

No, pushing a new commit is not enough to get the label removed. There are three steps: 1. Author needs to push quality improving commits, 2. Author needs to comment on that they think the PR is compliant on our quality standards now, 3. Only then, reviewers need to check if the PR is now in a reviewable state and then can decide to remove the label or not to and there is no obligation to write down all the exact reasons or to lead the contributor step by step into getting their PR in a reviewable state. (Reviewers can auf cause still do that, if they chose to.) 

The main point is that the autoclose action shifts the dynamics around. Authors will be responsible to fix low quality PRs, not maintainers.

Labels: Needs Decision, RFC