I think more visibility is always good, since it makes decisions more transparent and potential issues easier to spot.
Many things end up being discussed only on Github issues or even PRs, which, while still openly available, feels like we’re sometimes ducking away from longer discussions.
So +1 on defaulting to starting a topic on Discourse if there’s something to discuss w/r to backwards compatibility or new features which could potentially disrupt existing applications or scripts. It’s better to err on the side of transparency than not and more feedback is helpful in deciding whether or not a change warrants breakage or not.
The role of RMs could certainly be defined in a clearer way. AFAIK, we don’t have any documentation on the role in our PEPs, except for some guidelines in Development cycle and the more technical guide in PEP 101 – Doing Python Releases 101 | peps.python.org.
My understanding is that RMs are tasked with coordinating and creating stable and bug free releases – not with steering the Python language development.
Of course, if an RM finds that a particular change causes major downstream problems during alphas or betas, they can choose to back out and delay the change to the next release, or send it back to the SC for additional review, but RMs should not have BDFL sort of powers. The SC should always have the final say.
I think the above already is our common understanding; it’s just not documented anywhere.
FWIW: I’m watching that document closely, since I need to know whether there’s going to be potential breakage or not – often in areas regular users are not involved in, since I’m doing some low level things with CPython.
I also think that things are constantly improving on the document. It’s probably the most useful resource for Python change monitoring we have.