Hey @jacobtylerwalls.
I’m interested that you don’t mention the improved story for Python version support as a key positive. 
As a maintainer, I’m on the hook for three years of
support for the LTS. Nothing changes here. The recommendation would be to support all three active versions, dropping support as they reach EOL. The stability and depreciation policies would continue to operate as now. As ever, when opting into a new feature, I’d just add a shim where needed, and drop that when the time came. This is how we’ve been doing it… well… forever.
I have more to say about innovation. That’s the final piece, but I’ve already spoken to it lots of times (e.g.): tl;dr innovation in Django doesn’t happen in Django itself. It’s in third-party packages, that can make their way to core where appropriate. I believe very strongly in a small core for Django, and then good stories for how you extend for your particular use case. In my DjangoCon Europe talk last year I coined the term “Battery Packs” to try and capture this. It’s giving concrete demonstrations of that which remains in order to put the full story in place.
There are always going to be different possibilities of how we try to grow (and continue to maintain) Django. My vision is going to be just one. I’d love to see other concrete proposals! I think many of the half-thoughts reduce to ideas that are not going to be feasible if fully spelled out — but until that’s done we’ll not know. That’s a kind of general, if not this then what?
Historically, we’ve carried on with the status quo for lack of an answer. Increasingly people express dissatisfaction with that. It works. But the lingering problems get slowly more serious. Years pass. Nothing happens. We stagnate.
… which is why I’m proposing this change. Because I don’t think continuing as we are is actually the way.