ISTM, committing changes to the devguide is fundamentally different from committing a change to Python itself.  The devguide has a much smaller and focused audience, does not have compatibility considerations, it's continuously releasable etc etc.  So there's no need to have exactly the same stringent criteria for changes to the devguide.  That doesn't mean that there shouldn't be any review of those changes or that the process devolves to a change storm.  But, surely at this point, it would be easier to get meaningful additional review after the current set of changes are committed rather than continually redoing a large set of patches.  Then others are free to propose their own further changes for review.  I guess the lesson I would take from this is to limit the size and scope of individual changes to the devguide where possible, e.g. "ship" frequently.  This doesn't need to be difficult.