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:
I'm sympathetic to people wanting to contribute to open source to help advance their career but I am not sure if this motivation results in long term contributors.

> I think running sprints is still a worthwhile activity because it's good to introduce people to open source and it's fun and interesting for people to connect with maintainers of a project. But I would only run sprints every now and then to see if there are people among the attendees who would be interested in joining the project on a longer-term basis. Otherwise the return on investment for the project is just too low.

Sprints are nice but I agree that the return on investment is low. It also excludes people who do not live near major city/somewhere where maintainers live.

I think online events may be interesting to explore, they are less work than a sprint and allows more people to join. E.g., numpys regular new contributor meetings, open triage meetings, Marco from Narwhals does regular development livestreams where people just watch him code for an hour or two (https://www.youtube.com/watch?v=AxYyyH6YvY0) - he says not many people watch but the people that do are dedicated and will message him to check in if he misses one 😅  (and maybe that is what we want, fewer but more dedicated people?)

Labels: RFC