Talip7/scikit-learn-issues-multilabel huggingface dataset:
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
@anntzer The issue is that we get the list of valid metrics from different sources, and listing all metrics in the docs can very easily make them out of sync with what's actually valid. We've had this issue before and that's why we've tried to have a standard text for all places where we have a metric.

If you have a suggestion on how to do this nicely, I'm all ears.

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
At least, the docs should not link to a page that provides a wrong list.

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
Thanks @anntzer and @adrinjalali, after reviewing the current documentation for both links, I can see the confusion clearly:

-- The KDTree page lists “See ... distance_metrics” but the linked distance_metrics
function returns the valid metrics for pairwise_distances, which include entries like cosine, haversine, and nan_euclidean that KDTree doesn’t actually support.
-- Meanwhile, the KDTree page itself refers to KDTree.valid_metrics, which correctly lists the real set (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).

To keep the docs consistent and avoid drift, I’d suggest:
-- Removing the hyperlink to distance_metrics (since it’s for pairwise_distances, not KDTree).
-- Updating the text to point users directly to the runtime attribute, for example:
“For the exact list of metrics supported by KDTree, please refer to the KDTree.valid_metrics attribute in this release.”

And converting the inline “Note:” into a proper .. note:: directive for formatting consistency.
This keeps the section accurate without hardcoding lists or creating maintenance overhead.

If that approach sounds reasonable, I’d be happy to prepare a small PR once maintainers approve the direction.

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
The [KDTrree and BallTree Classes user guide](https://scikit-learn.org/stable/modules/neighbors.html#kdtree-and-balltree-classes) prints the `KDTree.valid_metrics` attribute out. A simple fix would be referencing that.

Edit: typo

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
I think I'd be okay for these two classes the docstring to point to the attribute for users to check the valid values. @anntzer would you like to open a PR for this?

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
I'll leave that to you.

Labels: Documentation
Clarify docs for allowable KDTree metrics

### Describe the issue linked to the documentation

https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html currently states, for the metrics kwarg: "Metric to use for distance computation. Default is “minkowski”, which results in the standard Euclidean distance when p = 2. A list of valid metrics for KDTree is given by the attribute valid_metrics. See the documentation of [scipy.spatial.distance](https://docs.scipy.org/doc/scipy/reference/spatial.distance.html) and the metrics listed in [distance_metrics](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html#sklearn.metrics.pairwise.distance_metrics) for more information on any distance metric."

Yet clicking on `distance_metrics` yields the following list of metrics: cityblock, cosine, euclidean, haversine, l1, l2, manhattan, nan_euclidean, which is different from the actual list of supported metrics (euclidean, l2, minkowski, p, manhattan, cityblock, l1, chebyshev, infinity).  I could not find this list other than by actually printing out the value of `KDTree.valid_metrics`.

### Suggest a potential alternative/fix

Explicitly list the actually supported metrics in the docs (or at least, not link to a list that is different).

A few minor related possible improvements:
- There's a formatting issue immediately after the `metric` kwarg in https://scikit-learn.org/stable/modules/generated/sklearn.neighbors.KDTree.html; likely the "Note:" should be moved to a real rst note (or indented as part of the doc for the metric kwarg).
- The list in https://scikit-learn.org/stable/modules/generated/sklearn.metrics.pairwise.distance_metrics.html could group together equivalent metrics ("'l1', 'cityblock', 'manhattan': metrics.pairwise.manhattan_distance; 'l2', 'euclidean': ..., )

COMMENT:
HI @anntzer ,i want to work on this issue

Labels: Documentation
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:
Good points. Should we encourage people to start contributing in an area that they are already interested in or knowledgable on, or part of scikit-learn they are already using regularly, instead of more 'generic' good first issues?

> We can just stop using the label, no need to delete it.

Happy with amending guidance on usage of this label instead of deleting, we don't seem to use it very often now anyway.

Labels: RFC
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:
These days I wouldn't use the label anymore, and in practice we also don't really have many of those issues except for sprints.

I hear @betatim 's point, and to me in practice, these days we've become a lot more of a project where it's harder to contribute if you don't have a mentor / a stable contact point.

To me the goal is to keep having a healthy and growing contributor pool, and if in an imaginary world, we had each core contributor helping two new-ish contributors, that'll help with the issue.

Numpy does regular new contributor meetings, and triage meetings where they are open to everyone. Those to me are better tools than a "good first issue" kinda thing.

Labels: RFC
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:
Thanks for your input all.

Let's keep the label. I have opened a PR to update our guide for new contributors #32715

Labels: RFC