Workflow Improvement/Clarification: Issue vs. PR

## Problem
~The scikit-learn [contribution docs](https://scikit-learn.org/stable/developers/contributing.html) do not address the relationship between issues and PRs at all~. While the docs _do_ indeed mention the [relationship](https://scikit-learn.org/stable/developers/contributing.html#pull-request-checklist) between PRs and Issues it doesn't require issues for any type of PR. I've observed that there are many PRs with no issues attached to them. This is obviously fine (and probably preferred) for small-scope transient PRs such as grammatical/spelling corrections, and CI/CD fixes, however it becomes problematic when the PR is larger in scope or more invasive, and may require significant discussion. The core problems are that:

1. If a PR does **not** have an associated issue where discussion is tracked, then once the PR is closed -- either due to completion or due to stalling and failure-to-complete -- then the thread of discussion is lost.
2. There is no "central" forum for discussion for such problems, since there may be several PRs working on similar -- or even the same -- problems and thus discussion will be fragmented across them.  This makes it harder to follow, _especially_ for new contributors who may not be comfortable searching and following discussion across multiple different sources
4. Many PRs are opened _before_ it is confirmed that the work being done is necessary/wanted in the current state of scikit-learn. This is most apparent when new features are proposed directly through the creation of a PR rather than through an issue, potentially wasting/stalling the efforts of contributors. 
5. Following point 3. such workflow makes it harder for reviewers to efficiently do their job, since there is an incredible variability in what may need to be done on PRs -- some may be pre-approved after thorough discussion, requiring only code-review, while others may not have had any discussion yet at all.

## Proposed solution
Develop a recommended workflow and clearly state it in the scikit-learn docs for contributors. Specifically, this may look like requiring issues for sufficiently complex topics, before a PR should be opened for the work. The threshold for what is a "sufficiently complex topic" is arbitrary and can be discussed more precisely by the core members, but for example all new features, bug fixes, and enhancements may meet this requirement, while minor doc corrections and rapid CI/CD fixes can go straight to PRs.

## Drawbacks and considerations
1. This may create a greater barrier to entry for some new contributors.
2. This will increase the number of live issues and potentially require more work triaging -- however I don't think this really introduces _new_ work, but rather shifts it to the venue of issues, rather than triaging PRs directly.

I would love to hear everyone's thoughts on this. Obviously there's a lot of ambiguity surrounding this topic, but I thought it was worth discussing.

COMMENT:
Hi @Micky774, thanks for bringing up this point about documentation.
> The scikit-learn [contribution docs](https://scikit-learn.org/stable/developers/contributing.html) do not address the relationship between issues and PRs at all.

The contribution guide [explicitly asks](https://scikit-learn.org/stable/developers/contributing.html#pull-request-checklist) for linking pull requests to existent and relevant issues or pull requests. I agree with you this is not always applied by contributors.
> Many PRs are opened before it is confirmed that the work being done is necessary/wanted in the current state of scikit-learn. This is most apparent when new features are proposed directly through the creation of a PR rather than through an issue, potentially wasting/stalling the efforts of contributors.

Indeed this is not clarified in the documentation: I think this is worth an item in the pull request checklist in the documentation.
However my personal experience is that
- even when explicitly asked to wait, some contributors rather open a PR, because they are particularly interested in the feature
- sometimes this is a worthy strategy because reviewers are interested in reviewing the implementation more than in contributing to a general discussion.

More generally, I find the scikit-learn contributing guide detailed and complete.... perhaps too detailed sometimes, with the risk that people does not read it (I plead guilty, I have missed some clearly stated items in my contribution history).

Some projects add a checklist in the pull request template, so the contributors can check themselves if all necessary steps have been covered. This can help, but the human factor (contributor discipline and reviewer availability) is the critical issue, anyway.

Labels: Documentation