Dan, thanks for the clarification on backporting and for your continual improvement of stable branches. As the release manager for Joule, I know all too well the delicate balance between functionality and stability, not to mention the time commitment on "older" branches (fortunately, we have very few of those). It is a difficult conversation to make end-users wait for the right time to receive updates. Unfortunately for hosts, when that conversation refers to a 6 month timeline to fix a "bug" that has been listed as an improvement (the antithesis of your polite note), the conversation becomes immensely more challenging. Moodlerooms and many other partners/institutions cannot simply update to the latest-and-greatest release immediately after its launch as there are months worth of work to upgrade internally developed code and 3rd party dependencies. Nor can every institution completely understand the impact of a change 2 months after it lands in master. I fear (maybe unjustly) that hosts may be put in an awkward position when a fix is not backported, and I'd like to make sure we make all attempts to pass the option down the line.
Your Stable releases are similar to our Maintenance Packs, and we have similar policies for what can and cannot be included. Our goal is to have zero unwanted impact to end-users as it will almost definitely cause extra work - increased support inquiries, documenation updates, etc. But we counter that appropriately with risk. We do everything to ensure that clients have the option to move at their pace. Ultimately, this ensures backward compatibility while still giving individual administrators the ability to decide. If they want to wait until an "improvement" has come out of beta, they can wait. If the improvement is mission critical and they cannot wait, they have the option to expedite. And at the end of the day we have informed users who understand the implications of their decision, and are knowledgeable about the situtation if they run into problems.
We do this almost exclusively through the use of $CFG options because we can control the configuration files. It may not be the best option for fixes from Core, but I think if we got into a habit of communicating experimental backports through release notes it would be comfortable to site admins. And there are always Global Settings, particularly Experimental Settings which by definition scream use-at-your-own-risk. It's not a silver bullet in all cases, but it does gives us better control over rolling out impactful changes, and our clients are extremely happy as a result. Because at the end of the day, no one wants to be in the unfortunate position of telling their end-users (or paying customers) that a critical backport is unavailable because they missed the review window, or because it was reviewed and ultimately denied (in a smoke filled room no doubt )
Here's what I'd like to see (the TL;DR version):
1. Think creatively how impactful changes can still be backported using toggles/settings to control backwards compatibility.
2. Remove the 2 month "window" for backporting. Requests should be considered based on need, feasibility and effort.
3. If a backport is reviewed and denied, please give an appropriate reason behind the decision (e.g. potential data loss, unavoidable backward compatibility break, etc.). I assume you would do so, but it wasn't listed in the policy.
4. Mitigate regression testing with increased automated functional testing!