Improve guidelines when reviewing PRs with backward incompatible changes

[Mariatta]

Describe the enhancement or feature you'd like

In the python-dev thread, Victor expressed frustration over lack of documentation of how to port/migrate a function that was removed.

It would be great that going forward, when we introduce backward incompatible changes, the documentation on how to migrate is also included alongside the feature implementation.

When reviewing pull requests with such changes, e.g. when something is being deprecated or removed, reviewers should take notice and potentially block the pull request from getting merged, until the documentation gets updated too.

Currently we don't have such guideline or rule. It would be great to start recommending this practise.

We can probably add this to:

https://devguide.python.org/pullrequest/#how-to-review-a-pull-request

and/or

https://devguide.python.org/committing/#is-the-pr-ready-to-be-accepted

Thanks.

[jablonskidev]

@Mariatta I'm already working on the Accepting Pull Requests page, and it's being reviewed by @brettcannon. I can add a bit about making sure that documentation is up to date as well. Here's the PR for the other issue: https://github.com/python/devguide/pull/650

[jablonskidev]

@Mariatta Can this issue be closed? Here's a screenshot from the Accepting Pull Requests page:

Would it be helpful if I went through the list of open issues for the devguide and flagged ones that seem to have been addressed already or may be duplicates? It could help new contributors get situated more easily and see a clearer path towards making their first contribution.

[hugovk]

Yes, let's close this. We can re-open or create new issues as necessary. Thanks!