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:
> 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 agree that sometimes it is easy to overlook the documentation. Maybe the simplest solution in this case is to edit the PR template to briefly mention what @Micky774 proposes. Something similar to:

```
#### Reference Issues/PRs
<!--
Example: Fixes #1234. See also #3456.
Please use keywords (e.g., Fixes) to create link to the issues or pull requests
you resolved, so that they will automatically be closed when your pull request
is merged. See https://github.com/blog/1506-closing-issues-via-pull-requests
For other than small-scope PRs such as grammatical/spelling corrections, and
CI/CD fixes, if there are no related Issues, try to create one where discussions
can be held.
-->
```

What do you think?

Labels: Documentation