Talip7/scikit-learn-issues-multilabel huggingface dataset:
RFC: Should we remove the 'good first issue' label?

Related to other discussions on low effort PRs #31679 and #32207

Should we remove the 'good first issue' label?

Note that we mention this label in the "[Issues for new contributors](https://github.com/numpy/numpy/pull/21355)" section of the docs. It is also mentioned briefly at the end of the "[A typical workflow for triaging issues](https://scikit-learn.org/dev/developers/bug_triaging.html#a-typical-workflow-for-triaging-issues)" section.

Reasons for:

* currently there are no open issues with this label (https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22)
* it is rare for good first issues to occur naturally. Often it requires maintainers specifically trying to think of one and spending time writing thorough details and guidance in an issue, probably what happens when searching for issues for people to work on in sprints, and even then, during the sprint, guidance is often required.
* it often attracts *many* low quality PRs - this is possibly because it's aggregated on sites such as https://goodfirstissue.dev/. It's difficult to find examples as we often remove the label but maybe #31318 and #30352 are examples of how much interest the label often attracts.
* it may be better for a user to start work on something that they use themselves and are familiar with, or something they already have background knowledge of. This would of course vary between people, making it a difficult label to use.
   * related, as described in @betatim's [post](https://discuss.scientific-python.org/t/what-does-it-mean-to-be-a-project-that-is-welcoming-to-newcomers/2127/3) on scientific-python, the type of users attracted to this label may be simply interested in getting a PR merged in a 'big' project. From Ralf: 'Promising new contributors are almost always motivated by a problem/topic, not by “getting on the scoreboard”'  
* for reference NumPy does not have a good first issue label (https://github.com/numpy/numpy/pull/21355) they do have a 'sprintable' label

This is just a request for comment, I understand if we decide to keep this label in the end.

cc @scikit-learn/core-devs

COMMENT:
> he says not many people watch but the people that do are dedicated and will message him to check in if he misses one

Btw, how cool is that that people actually check in? 😀

Labels: RFC
load_iris example does not match text

### Describe the issue linked to the documentation

In https://scikit-learn.org/stable/modules/generated/sklearn.datasets.load_iris.html the example is introduced as "Let’s say you are interested in the samples 10, 25, and 50, and want to know their class name." 

However, the data indices are not used to index data.target_names in the code, so the code does not match the introduction.

Suggest changing the code to use the indices with output which is obviously what is expected.

### Suggest a potential alternative/fix

_No response_

COMMENT:
<img width="835" height="298" alt="Image" src="https://github.com/user-attachments/assets/f91cbb58-e4aa-4bba-b9f7-eaa66e80eaee" />

The way I read this is for samples 10, 25 and 50, target is `[0, 0, 1]` which means `['setosa', 'setosa', 'versicolor']`.

If you can find a way to say to clarify the intent without complicating the code, a PR would be more than welcome!

Labels: Documentation
load_iris example does not match text

### Describe the issue linked to the documentation

In https://scikit-learn.org/stable/modules/generated/sklearn.datasets.load_iris.html the example is introduced as "Let’s say you are interested in the samples 10, 25, and 50, and want to know their class name." 

However, the data indices are not used to index data.target_names in the code, so the code does not match the introduction.

Suggest changing the code to use the indices with output which is obviously what is expected.

### Suggest a potential alternative/fix

_No response_

COMMENT:
Yes, that's my interpretation too, but that's not what the text above says to expect. I think changing the last line and output to 

```
>>> data.target_names[data.target[[10, 25, 50]]]
array(['setosa', 'setosa', 'versicolor'], dtype='<U10')
```
matches what the text says to expect.

Labels: Documentation
load_iris example does not match text

### Describe the issue linked to the documentation

In https://scikit-learn.org/stable/modules/generated/sklearn.datasets.load_iris.html the example is introduced as "Let’s say you are interested in the samples 10, 25, and 50, and want to know their class name." 

However, the data indices are not used to index data.target_names in the code, so the code does not match the introduction.

Suggest changing the code to use the indices with output which is obviously what is expected.

### Suggest a potential alternative/fix

_No response_

COMMENT:
That's fine with me anyway! It's a good first pr.

On Sat 8 Nov 2025, 05:00 Arpan Mukherjee, ***@***.***> wrote:

> *arpanmukherjee38* left a comment (scikit-learn/scikit-learn#32671)
> <https://github.com/scikit-learn/scikit-learn/issues/32671#issuecomment-3505972425>
>
> Hi! I’m new to contributing and would like to work on this issue. May I
> take it?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/scikit-learn/scikit-learn/issues/32671#issuecomment-3505972425>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAJE3UUXZ46GUVWGF2FYYL33V2G5AVCNFSM6AAAAACLPJYJA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMBVHE3TENBSGU>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>

Labels: Documentation
StandardScaler raises unclear error with empty feature names

### Describe the bug

When using StandardScaler with a pandas DataFrame that has empty strings as feature names (which can happen with certain data processing pipelines), the scaler raises a confusing error message that doesn't clearly indicate the root cause of the problem.

The error message should be more descriptive and guide users to fix the issue with their feature names.

### Steps/Code to Reproduce

```py
import pandas as pd
import numpy as np
from sklearn.preprocessing import StandardScaler

# Create DataFrame with empty string as column name
df = pd.DataFrame(np.random.randn(10, 3), columns=['feature1', '', 'feature3'])

# Try to fit StandardScaler
scaler = StandardScaler()
scaler.fit(df)  # This raises an unclear error
```

### Expected Results

Either:
1. StandardScaler should raise a clear, informative error message like: "Feature names must be non-empty strings. Found empty string in column 1."
2. Or it should work by automatically handling empty feature names
3. Or raise a ValueError with a helpful message during validation

### Actual Results

KeyError: ''

The error message is not informative about what went wrong. It just shows that an empty string key was not found, without explaining that empty feature names are problematic.

### Versions

```shell
scikit-learn: 1.5.2
pandas: 2.2.0
numpy: 1.26.4
Python: 3.11.5
```

COMMENT:
Thanks for the issue!

Can you try with the latest released version i.e. 1.7.2. You are using scikit-learn 1.5.2.

I can not reproduce with scikit-learn 1.7.2, i.e. the snippet runs fine without error.

Labels: Needs Reproducible Code
StandardScaler raises unclear error with empty feature names

### Describe the bug

When using StandardScaler with a pandas DataFrame that has empty strings as feature names (which can happen with certain data processing pipelines), the scaler raises a confusing error message that doesn't clearly indicate the root cause of the problem.

The error message should be more descriptive and guide users to fix the issue with their feature names.

### Steps/Code to Reproduce

```py
import pandas as pd
import numpy as np
from sklearn.preprocessing import StandardScaler

# Create DataFrame with empty string as column name
df = pd.DataFrame(np.random.randn(10, 3), columns=['feature1', '', 'feature3'])

# Try to fit StandardScaler
scaler = StandardScaler()
scaler.fit(df)  # This raises an unclear error
```

### Expected Results

Either:
1. StandardScaler should raise a clear, informative error message like: "Feature names must be non-empty strings. Found empty string in column 1."
2. Or it should work by automatically handling empty feature names
3. Or raise a ValueError with a helpful message during validation

### Actual Results

KeyError: ''

The error message is not informative about what went wrong. It just shows that an empty string key was not found, without explaining that empty feature names are problematic.

### Versions

```shell
scikit-learn: 1.5.2
pandas: 2.2.0
numpy: 1.26.4
Python: 3.11.5
```

COMMENT:
I tried to reproduce with the exact same versions as the OP and I could not.

This is the output of `sklearn.show_versions()`

```
System:
    python: 3.11.14 | packaged by conda-forge | (main, Oct 22 2025, 22:46:25) [GCC 14.3.0]
executable: /home/lesteve/micromamba/envs/bla2/bin/python3.11
   machine: Linux-6.17.6-arch1-1-x86_64-with-glibc2.42

Python dependencies:
      sklearn: 1.5.2
          pip: 25.2
   setuptools: 80.9.0
        numpy: 1.26.4
        scipy: 1.16.3
       Cython: None
       pandas: 2.2.0
   matplotlib: None
       joblib: 1.5.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/lesteve/micromamba/envs/bla2/lib/libopenblasp-r0.3.30.so
        version: 0.3.30
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libgomp
       filepath: /home/lesteve/micromamba/envs/bla2/lib/libgomp.so.1.0.0
        version: None
```

@Savithru7142 for further reference can you put the output of `sklearn.show_versions()` in your bug reports 🙏!

Labels: Needs Reproducible Code
StandardScaler raises unclear error with empty feature names

### Describe the bug

When using StandardScaler with a pandas DataFrame that has empty strings as feature names (which can happen with certain data processing pipelines), the scaler raises a confusing error message that doesn't clearly indicate the root cause of the problem.

The error message should be more descriptive and guide users to fix the issue with their feature names.

### Steps/Code to Reproduce

```py
import pandas as pd
import numpy as np
from sklearn.preprocessing import StandardScaler

# Create DataFrame with empty string as column name
df = pd.DataFrame(np.random.randn(10, 3), columns=['feature1', '', 'feature3'])

# Try to fit StandardScaler
scaler = StandardScaler()
scaler.fit(df)  # This raises an unclear error
```

### Expected Results

Either:
1. StandardScaler should raise a clear, informative error message like: "Feature names must be non-empty strings. Found empty string in column 1."
2. Or it should work by automatically handling empty feature names
3. Or raise a ValueError with a helpful message during validation

### Actual Results

KeyError: ''

The error message is not informative about what went wrong. It just shows that an empty string key was not found, without explaining that empty feature names are problematic.

### Versions

```shell
scikit-learn: 1.5.2
pandas: 2.2.0
numpy: 1.26.4
Python: 3.11.5
```

COMMENT:
@lesteve  is this still open ??

Labels: Needs Reproducible Code
StandardScaler raises unclear error with empty feature names

### Describe the bug

When using StandardScaler with a pandas DataFrame that has empty strings as feature names (which can happen with certain data processing pipelines), the scaler raises a confusing error message that doesn't clearly indicate the root cause of the problem.

The error message should be more descriptive and guide users to fix the issue with their feature names.

### Steps/Code to Reproduce

```py
import pandas as pd
import numpy as np
from sklearn.preprocessing import StandardScaler

# Create DataFrame with empty string as column name
df = pd.DataFrame(np.random.randn(10, 3), columns=['feature1', '', 'feature3'])

# Try to fit StandardScaler
scaler = StandardScaler()
scaler.fit(df)  # This raises an unclear error
```

### Expected Results

Either:
1. StandardScaler should raise a clear, informative error message like: "Feature names must be non-empty strings. Found empty string in column 1."
2. Or it should work by automatically handling empty feature names
3. Or raise a ValueError with a helpful message during validation

### Actual Results

KeyError: ''

The error message is not informative about what went wrong. It just shows that an empty string key was not found, without explaining that empty feature names are problematic.

### Versions

```shell
scikit-learn: 1.5.2
pandas: 2.2.0
numpy: 1.26.4
Python: 3.11.5
```

COMMENT:
Closing this one, since we don't have a way to reproduce. If someone finds a reproducer, feel free to comment below and we may decide to reopen.

Labels: Needs Reproducible Code
DOC Create triage guide in maintainer documentation

As part of talking about triaging at the Scientific Python Summit I realised that we have quite some cumulative experience with triaging. There are also different approaches to things.

As a result I think it would be useful if we create a triaging guide as part of our developer/maintainer documentation. The goal of the guide would be to serve as a reference for what to do as a triager, what tools we have available to help with the process and so on.

Some initial things I can think of including:
* list of labels we have for triaging and what to use them for
* "please don't open a PR before the discussion has converged" as a policy (triagers should close these "early PRs" to help enforce this)
* bookmarked search queries/lists of issues
  * [needs triage](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20label%3A%22Needs%20Triage%22)
  * [new PR without reviews](https://github.com/scikit-learn/scikit-learn/pulls?q=is%3Apr+is%3Aopen+review%3Anone+sort%3Acreated-desc)
  * [new PR without reviews by a maintainer](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+is%3Apr+is%3Aopen+author%3Abetatim+author%3Aogrisel+author%3Aglemaitre+author%3Alesteve+review%3Anone&type=pullrequests&s=created&o=desc)
     * needs more maintainer usernames in the query
     * we could have a similar query for recurring contributors, but how?
  * [PRs waiting for second reviewer](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+review%3Anone+label%3A%22Waiting+for+Second+Reviewer%22)
  * [Open PRs that you have reviewed in the past](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+reviewed-by%3A%40me+)
  * look at PRs marked with "autoclose" and decide to potentially remove the label or re-open if the PR has significantly improved [scikit-learn/scikit-learn/issues (sort:updated-desc label:autoclose)](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20label%3Aautoclose)
* integrate with https://scikit-learn.org/dev/developers/bug_triaging.html#triaging-operations-for-members-of-the-core-and-contributor-experience-teams

Can you think of more search queries that would be useful @lesteve?



xref https://github.com/scientific-python/summit-2025-nov/issues/6

COMMENT:
Can I take this issue? @betatim @lesteve

Labels: Documentation
DOC Create triage guide in maintainer documentation

As part of talking about triaging at the Scientific Python Summit I realised that we have quite some cumulative experience with triaging. There are also different approaches to things.

As a result I think it would be useful if we create a triaging guide as part of our developer/maintainer documentation. The goal of the guide would be to serve as a reference for what to do as a triager, what tools we have available to help with the process and so on.

Some initial things I can think of including:
* list of labels we have for triaging and what to use them for
* "please don't open a PR before the discussion has converged" as a policy (triagers should close these "early PRs" to help enforce this)
* bookmarked search queries/lists of issues
  * [needs triage](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20label%3A%22Needs%20Triage%22)
  * [new PR without reviews](https://github.com/scikit-learn/scikit-learn/pulls?q=is%3Apr+is%3Aopen+review%3Anone+sort%3Acreated-desc)
  * [new PR without reviews by a maintainer](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+is%3Apr+is%3Aopen+author%3Abetatim+author%3Aogrisel+author%3Aglemaitre+author%3Alesteve+review%3Anone&type=pullrequests&s=created&o=desc)
     * needs more maintainer usernames in the query
     * we could have a similar query for recurring contributors, but how?
  * [PRs waiting for second reviewer](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+review%3Anone+label%3A%22Waiting+for+Second+Reviewer%22)
  * [Open PRs that you have reviewed in the past](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+reviewed-by%3A%40me+)
  * look at PRs marked with "autoclose" and decide to potentially remove the label or re-open if the PR has significantly improved [scikit-learn/scikit-learn/issues (sort:updated-desc label:autoclose)](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20label%3Aautoclose)
* integrate with https://scikit-learn.org/dev/developers/bug_triaging.html#triaging-operations-for-members-of-the-core-and-contributor-experience-teams

Can you think of more search queries that would be useful @lesteve?



xref https://github.com/scientific-python/summit-2025-nov/issues/6

COMMENT:
No you can not, this issue is meant for maintainers.

Thanks for your interest! I would suggest you look at the GitHub's [How to contribute to Open-Source guide](https://opensource.guide/how-to-contribute/), which gives a good generic overview about how open-source works.

Please have a look at our [contributing doc](https://scikit-learn.org/dev/developers/contributing.html) and in particular the section [Issues for new contributors](https://scikit-learn.org/dev/developers/contributing.html#new-contributors).

Labels: Documentation
DOC Create triage guide in maintainer documentation

As part of talking about triaging at the Scientific Python Summit I realised that we have quite some cumulative experience with triaging. There are also different approaches to things.

As a result I think it would be useful if we create a triaging guide as part of our developer/maintainer documentation. The goal of the guide would be to serve as a reference for what to do as a triager, what tools we have available to help with the process and so on.

Some initial things I can think of including:
* list of labels we have for triaging and what to use them for
* "please don't open a PR before the discussion has converged" as a policy (triagers should close these "early PRs" to help enforce this)
* bookmarked search queries/lists of issues
  * [needs triage](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20label%3A%22Needs%20Triage%22)
  * [new PR without reviews](https://github.com/scikit-learn/scikit-learn/pulls?q=is%3Apr+is%3Aopen+review%3Anone+sort%3Acreated-desc)
  * [new PR without reviews by a maintainer](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+is%3Apr+is%3Aopen+author%3Abetatim+author%3Aogrisel+author%3Aglemaitre+author%3Alesteve+review%3Anone&type=pullrequests&s=created&o=desc)
     * needs more maintainer usernames in the query
     * we could have a similar query for recurring contributors, but how?
  * [PRs waiting for second reviewer](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+review%3Anone+label%3A%22Waiting+for+Second+Reviewer%22)
  * [Open PRs that you have reviewed in the past](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+reviewed-by%3A%40me+)
  * look at PRs marked with "autoclose" and decide to potentially remove the label or re-open if the PR has significantly improved [scikit-learn/scikit-learn/issues (sort:updated-desc label:autoclose)](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20label%3Aautoclose)
* integrate with https://scikit-learn.org/dev/developers/bug_triaging.html#triaging-operations-for-members-of-the-core-and-contributor-experience-teams

Can you think of more search queries that would be useful @lesteve?



xref https://github.com/scientific-python/summit-2025-nov/issues/6

COMMENT:
Another useful search to mention is this one to look at autoclose PRs and decide to potentially remove the label or re-open if the PR has significantly improved https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20label%3Aautoclose. I left on purpose open and closed PRs to potentially re-open closed ones (maintainer with high motivation use case 😅).

Labels: Documentation
DOC Create triage guide in maintainer documentation

As part of talking about triaging at the Scientific Python Summit I realised that we have quite some cumulative experience with triaging. There are also different approaches to things.

As a result I think it would be useful if we create a triaging guide as part of our developer/maintainer documentation. The goal of the guide would be to serve as a reference for what to do as a triager, what tools we have available to help with the process and so on.

Some initial things I can think of including:
* list of labels we have for triaging and what to use them for
* "please don't open a PR before the discussion has converged" as a policy (triagers should close these "early PRs" to help enforce this)
* bookmarked search queries/lists of issues
  * [needs triage](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20label%3A%22Needs%20Triage%22)
  * [new PR without reviews](https://github.com/scikit-learn/scikit-learn/pulls?q=is%3Apr+is%3Aopen+review%3Anone+sort%3Acreated-desc)
  * [new PR without reviews by a maintainer](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+is%3Apr+is%3Aopen+author%3Abetatim+author%3Aogrisel+author%3Aglemaitre+author%3Alesteve+review%3Anone&type=pullrequests&s=created&o=desc)
     * needs more maintainer usernames in the query
     * we could have a similar query for recurring contributors, but how?
  * [PRs waiting for second reviewer](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+review%3Anone+label%3A%22Waiting+for+Second+Reviewer%22)
  * [Open PRs that you have reviewed in the past](https://github.com/scikit-learn/scikit-learn/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+reviewed-by%3A%40me+)
  * look at PRs marked with "autoclose" and decide to potentially remove the label or re-open if the PR has significantly improved [scikit-learn/scikit-learn/issues (sort:updated-desc label:autoclose)](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20label%3Aautoclose)
* integrate with https://scikit-learn.org/dev/developers/bug_triaging.html#triaging-operations-for-members-of-the-core-and-contributor-experience-teams

Can you think of more search queries that would be useful @lesteve?



xref https://github.com/scientific-python/summit-2025-nov/issues/6

COMMENT:
I know probably very few people do it (other than me, I am fascinated by CI errors I guess 😅) but looking at the automated issues opened by scikit-learn bot [GitHub search](https://github.com/scikit-learn/scikit-learn/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20author%3Ascikit-learn-bot) and add a comment about the failure maybe a good idea?

Labels: Documentation