I think both Language Summits & Core Sprints are extremely valuable. Last year’s sprint was easily one of the highlights of my year; I personally was able to accomplish a lot having direct access to Andrew, Nathaniel, Carol, Łukasz, Victor, and Guido. I’m all for supporting these kind of events, and trying to make them as accessible to core devs as possible. I’m very lucky that I’m so flexible with my business and personal schedule that I can attend these events. Not everybody is, unfortunately.
To answer your question directly: I think we can break down “project-wide” decisions in the following buckets:
- affects an important standard library module;
- affects the interpreter/core implementation details;
- affects the Python API or C API;
- affects the workflow;
- affects a policy, the CoC, governance, or the decision making.
 is easy, if the maintainer of the module is at the sprint. If they are not, a Skype call can be arranged. If it’s not possible to communicate with the maintainer, do it via the regular python-dev discussion.
 I see a lot of discussions about refactoring the core at the sprints. Whiteboard is used all the times, Neil and Victor are busy explaining and brainstorming their ideas. Some minor decisions can be made at the spot, however, even they are usually discussed on python-dev to include everyone.
 This one is simple too: it’s always discussed on python-dev (and if not and some stakeholders disagree, the change can be reverted and properly discussed).
 This is the tricky one. Let’s take Discourse for example. At the last sprint we decided to try Discourse, and [disclaimer] I was one of the active supporters of the effort. It was announced as an experiment (and I believe it still is), and I did feel uneasy that it wasn’t thoroughly discussed on python-committers. There was a quick poll at the end of the sprint, it looked like most of the core devs were OK to try and now we are trying to use Discourse.
- Do I think it was a wrong decision? No.
- Do I think it was executed perfectly? No. I think there were a lot of miscommunication; some people felt that the decision was made by 2-3 individuals (it wasn’t). A lot of people complained that using Discourse is uncomfortable for them (btw that happened with GitHub too). At the same time I see Łukasz, Pablo, Donald, and Nathaniel spending truly enormous amount of time to make our experience here better, so the situation will improve.
- Would I vote/approve such move again? Next time I think we should call a vote and require at least 60% of all core devs’ votes to change the workflow. I hope that the Council will establish a clear procedure for workflow changes.
 It’s inevitable that discussions about these topics will happen at any event with more than one participants. We now have PEP 13 which has a clear guideline on changing policies/governance: core developers will have to vote.