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:
Thank you for opening this discussion. In an attempt to increase diversity in open source and in tech in general, I've been telling especially people who belong to underrepresented groups that they should look for the label "good first issue" or "easy" as an entry point to open source and I've also  been recommending to them to make some small contributions to open source to strengthen their CV. Especially with the rise of coding assistants and AI agents I've really been questioning myself in this context. I've been wondering whether I myself am contributing to maintainer burnout with these messages and whether I'm actually doing more harm than good.

I've run quite a number of community sprints and also reviewed quite a number of entry level PRs and so far I haven't seen much contributor retention. My main take away from all this work at this point is that for people to advance in a project, they need mentoring. I think there is no other way around it unless new contributors are already quite senior/ experienced. 

I'm not sure what the best way is to attract new contributors and to be friendly and welcoming to these people but at the same time prevent maintainers from being feeling overworked and burnt out. 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. 

cc @scikit-learn/contributor-experience-team @scikit-learn/documentation-team for visibility.

Labels: RFC