Clarify policy regarding 1 issue per pull request

[Mariatta]

In python-dev mailing list, it was asked what to do when a PR will address multiple issues.
https://mail.python.org/archives/list/python-dev@python.org/thread/74FS2DW2L4MDJXRREAABXYRWNI6INMBA/

From few answers from the core devs, seems like we prefer keeping only one issue open (the oldest one), and mark the rest as duplicates. Also, our workflow (bots and blurb) kinda expects 1 bpo issue per 1 pull request.

It would be great to clarify all of the above in either the pull request life cycle page, or in the triaging page.

[tiran]

+1

I see "the oldest one" more like a guideline or preference than a hard rule. Sometimes there is another ticket with more or better information on the issue. It's a judgement call

[ncoghlan]

The other technique I've used is to keep the additional issue open, but have the associated PR be purely a docs change. That was for https://bugs.python.org/issue30661, where changing the default behaviour in the tarfile module also changed the default behaviour in shutil. It doesn't apply for pure bug fixes though - only cases that call for a versionchanged entry in the documentation.

That would make the two possible resolutions be:

1. For multiple bug reports with a common underlying cause, choose the one that best reflects the underlying fault (often, but not always, the oldest one), mark the other issues as duplicates of that one, and then associate the PR and NEWS entry with the selected issue
2. If it seems appropriate to have more than one NEWS entry for multiple affected APIs, then some of the issues may be converted to documentation issues rather than being closed as duplicates