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:
> 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.

Ah, thank you for bringing that up! That's entirely correct, and I've updated the original comment to reflect this.

> * 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.

These are very good points. If a strict pipeline of issue --> PR isn't maintainable for these reasons, then I think even just strongly encouraging that issues be opened up for sufficiently complex PRs if they don't already have one would go a long way towards addressing some of the problems I mentioned regarding recording and centralizing discussion.

Regarding your second point in particular, it is one that I obviously don't have any experience regarding, so I really appreciate your insight on this, as well as any opinions of other scikit-learn members.
> 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).

The contributor docs are indeed one of the things that sets this project apart in my opinion. It's a wonderful body of work that's helped me immensely, as well as many other contributors!
> 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.

Ultimately while we can't control the contributor compliance aspect of the problem, if there's something to be done to _encourage_ a net beneficial behavior (without significant cost), I believe its worth pursuing.

Overall, thank you @cmarmo for your thoughtful feedback. I'm still new to this environment and so some of my ideas do come from a lack of experience, and consequently comments like yours are immensely helpful.

Labels: Documentation