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: #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!