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 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.

We recently discuss such a checklist and to make a PR for this. I saw that @ArturoAmorQ started first with some documentation for minimal reproducer https://github.com/scikit-learn/scikit-learn/pull/22401, but it should be the next step.

Indeed, we thought to add this checklist in order to help contributors to check the failing CI (and where to click) for code and documentation rendering.

@Micky774 I acknowledge that we have certainly had issues organizing the entire issue tracker and PR. I would be open to suggestions. The difficulty will always be how to translate some of those into something that will work reasonably in practice. But if we don't try anything, we will never improve :)

Labels: Documentation