Talip7/scikit-learn-issues-multilabel huggingface dataset:
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:
I forgot to ping @scikit-learn/communication-team sorry 😬

Labels: Needs Decision, RFC
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:
Sounds good to me. We can also re-open PRs, sos autoclosing is not that big of a deal.

Labels: Needs Decision, RFC
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:
We can also consider using these tools: https://github.com/github/ai-assessment-comment-labeler

Labels: Needs Decision, RFC
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:
This looks like it is only for issues, not PRs?

Labels: Needs Decision, RFC
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:
Would it be easy to configure it if it's designed to assess issues instead of PRs?
But also happy if you want to give it try!

Labels: Needs Decision, RFC
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:
I'm 👍 .

People in favor, do not hesitate to 👍  this

Labels: Needs Decision, RFC
DOC: add explanations about criterion="friedman_mse" in decision trees doc

### Describe the issue linked to the documentation

There is almost nothing in the doc about it. And you don't find informative ressources about it online easily. So it's probably really obscure for 99% of users.



### Suggest a potential alternative/fix

**In the params doc:** say that it's usually used for additive learning (e.g.when using decision trees as base learner for gradient boosting method).

**In the [Mathematical Formulation section](https://scikit-learn.org/stable/modules/tree.html#mathematical-formulation)**
Add the friedman MSE criterion. This will be awkard as friedman MSE criterion doesn't minimize the same thing than other criterion. Instead of minizing a $G(Q_m, \theta)$ that can be expressed as:

$$G(Q_m, \theta) = \frac{n_m^{left}}{n_m} H(Q_m^{left}(\theta)) + \frac{n_m^{right}}{n_m} H(Q_m^{right}(\theta))$$

like other criteria, it maximizes:

$$G(Q_m, \theta) = \frac{n_m^{left} n_m^{right}}{n_m} \left( \bar{y}_m^{left} - \bar{y}_m^{right} \right)^2$$

But impurity values of the nodes is the MSE... 

**In the random forest params doc**: maybe add someting here too.

COMMENT:
Note: This lacks of documentation for Friedman MSE was already mentioned 5 years ago in a PR: https://github.com/scikit-learn/scikit-learn/pull/17386#issuecomment-639079056

Labels: Documentation
DOC: add explanations about criterion="friedman_mse" in decision trees doc

### Describe the issue linked to the documentation

There is almost nothing in the doc about it. And you don't find informative ressources about it online easily. So it's probably really obscure for 99% of users.



### Suggest a potential alternative/fix

**In the params doc:** say that it's usually used for additive learning (e.g.when using decision trees as base learner for gradient boosting method).

**In the [Mathematical Formulation section](https://scikit-learn.org/stable/modules/tree.html#mathematical-formulation)**
Add the friedman MSE criterion. This will be awkard as friedman MSE criterion doesn't minimize the same thing than other criterion. Instead of minizing a $G(Q_m, \theta)$ that can be expressed as:

$$G(Q_m, \theta) = \frac{n_m^{left}}{n_m} H(Q_m^{left}(\theta)) + \frac{n_m^{right}}{n_m} H(Q_m^{right}(\theta))$$

like other criteria, it maximizes:

$$G(Q_m, \theta) = \frac{n_m^{left} n_m^{right}}{n_m} \left( \bar{y}_m^{left} - \bar{y}_m^{right} \right)^2$$

But impurity values of the nodes is the MSE... 

**In the random forest params doc**: maybe add someting here too.

COMMENT:
i would like to implement this can you assign me this?

Labels: Documentation
DOC: add explanations about criterion="friedman_mse" in decision trees doc

### Describe the issue linked to the documentation

There is almost nothing in the doc about it. And you don't find informative ressources about it online easily. So it's probably really obscure for 99% of users.



### Suggest a potential alternative/fix

**In the params doc:** say that it's usually used for additive learning (e.g.when using decision trees as base learner for gradient boosting method).

**In the [Mathematical Formulation section](https://scikit-learn.org/stable/modules/tree.html#mathematical-formulation)**
Add the friedman MSE criterion. This will be awkard as friedman MSE criterion doesn't minimize the same thing than other criterion. Instead of minizing a $G(Q_m, \theta)$ that can be expressed as:

$$G(Q_m, \theta) = \frac{n_m^{left}}{n_m} H(Q_m^{left}(\theta)) + \frac{n_m^{right}}{n_m} H(Q_m^{right}(\theta))$$

like other criteria, it maximizes:

$$G(Q_m, \theta) = \frac{n_m^{left} n_m^{right}}{n_m} \left( \bar{y}_m^{left} - \bar{y}_m^{right} \right)^2$$

But impurity values of the nodes is the MSE... 

**In the random forest params doc**: maybe add someting here too.

COMMENT:
Let's not fix this but rather deprecate this criterion entirely, as done in #32708.

Labels: Documentation
[FEAT] Let `importance_getter` from RFE accept test data for permutation importance

### Describe the workflow you want to enable

To recursively eliminate features, `permutation_importance` is a sensible method of feature importance as it satisfies $X_j \perp Y | X_{-j} \iff \texttt{PermutationImportance}(X_j) = 0$ (see [Reyero Lobo et al. (2025)](https://arxiv.org/pdf/2507.17306)).

However, with the current implementations of `RFE` and `RFECV`, it is not possible to use permutation importance. Indeed the `importance_getter` parameter, when a callable, can only be given a model, but as the features are removed from the dataset, the `permutation_importance` method needs to know which columns of `X_test` to use for predicting.

### Describe your proposed solution

Let the `sklearn.feature_selection._base._get_feature_importances` method accept column indices that are passed to the `importance_getter` callable so that it can extract the relevant columns of the its test dataset.

Notes:
- To be backward compatible, it needs to inspect the input parameters of `importance_getter` and only provide feature indices when it can accept them.
- The function `_get_feature_importances` is also used by `SelectFromModel` which could then also benefit from this change.

### Describe alternatives you've considered, if relevant

Let `RFE` and `RFECV` accept optional `X_test` and `y_test` parameters in the `fit` that are given to the `importance_getter` through the `sklearn.feature_selection._base._get_feature_importances` method.

### Additional context

We discussed it with @ogrisel and @glemaitre and think that it is a good thing to include but we are open to discussion/suggestions.

COMMENT:
Related to https://github.com/scikit-learn/scikit-learn/issues/21934

Labels: New Feature, module:inspection