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:
One thing that we could think about and, if we find an answer, take into account when designing a pathway for new contributors is helping the person figure out what their motivation is for contributing.

There is a difference between "I want to make a code contribution so I can add the project to my GitHub CV" and "I want to make a lasting contribution to the project that I am proud of" - the latter not only includes work that is not code but probably several units of contribution. It means repeat interaction between maintainers and contributor. Something a potential employer might recognise (I assume a mini, one time, drive by PR isn't going to get you many plus points from a potential employer).

---

In one of the JupyterHub projects we asked people in the "new feature" issue template "who can work on this issue?". The goal was not to get a list of names or roles. Though that is what people often took it as. The goal was to make new feature requesters think about about the fact that it will require actual humans to implement the feature. Anecdotally it worked? It was certainly interesting to see what people wrote.

The point of the story is: what indirect/leading question can we ask that makes people think about their motivation/reasons for contributing? Would that (minimal) self-reflection improve things?

Labels: RFC