I think this is something we got fairly wrong with the first couple of in-person Language Summits, since critical decisions were made, and then not written down (the specific case I’m aware is the original decision to attempt to incorporate distribute/distutils2/etc into the standard library). Cue a few years of “Why did we decide to do that again?” questions, even from those of us that were there at the time.
That experience then turned into the general principle of “Discuss & deliberate, but don’t decide” when it came to in-person meetings - the requirement to take the decision-making process outside the in-person meeting ensures that the decision itself, as well as the pros and cons on either side, will actually get written down (at least as a mailing list post or issue tracker item, and potentially as a full PEP).
At the same time, in-person meetings are incredibly valuable for discussing deep technical issues, and we can make still make smaller decisions there, just as we can make some decisions entirely in a pull request or tracker issue discussion without involving the whole of python-dev. (e.g. this is how CPython 3.7 ended up with opcode tracing support - at one of the core dev sprints, Greg Smith and I were trying to solve a resource cleanup problem in with statements that Nathaniel reported, and while we still haven’t figured out a solution for the original problem, we decided that the feature we built to let us inject exceptions between arbitrary opcodes would likely be useful to other folks interested in stress-testing their resource management code)