Question for Steering Council candidates : Physical meetings


Just another question for candidates (if you are not, please refrain from answering or posting here).

What is your take on project-wide decisions made at physical core developer meetings (such as Language Summits or Core Developer Sprints). Do you approve of them? Should there be a permanent ban on such decision-making?

1 Like

I’m feeling lucky to be able to attend these two physical meetings. I’m usually sponsored by Pycon, PSF and/or my employer. But sometimes, it causes me troubles with my family. For example, I’m not sure that I’m going to attend the next sprint in London. (I wrote that the beginning of September doesn’t work well for me and my family, but they kept the date, well.)

I’m not fully comfortable with taking decisions only between people who are able to attend these meetings. Thankfully, the Language Summit isn’t really about making decisions, it’s more about discussions issues. But somehow, some decisions are taken.

There are a few exceptions of decisions taken during these events, and I would prefer to get an approval of people who weren’t able to travel… or weren’t invited, since Language Summit is more or less an invite-only event. Even if it has been said that anyone is free to join, it costs a lot of money for someone who doesn’t live in North America to buy the flight and for the lodging. So yeah, I’m well aware of these issues.

… On the other side… I think that it’s healthy and useless for the Python project to have physical meetings to be able to move more quickly on some topics. Even if not everybody is able to attend, many core developers can and are supposed to represent the Python diversity.

I’m not sure what is the best solution, but I wouldn’t simply deny people to take any kind of decisions. We can definitely do something to have a better process. I would suggest to open a discussion on that topic :wink:


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:

  1. affects an important standard library module;
  2. affects the interpreter/core implementation details;
  3. affects the Python API or C API;
  4. affects the workflow;
  5. affects a policy, the CoC, governance, or the decision making.

[1] 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.

[2] 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.

[3] 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).

[4] 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.

[5] 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.


Between Victor and Yury, I think they’ve done a great job covering the points.

While decision making at a meeting/sprint/etc. may be expedient, folks unable to attend the language summit should have a way to receive daily updates (which may be easier to do with Discourse in place) and an opportunity to give feedback / participate in decisions.


Victor and Yuri make excellent points. My take on it is that the appropriateness of a decision at a physical meeting depends on the history of the issue and global effects of the decision.

As one example, we’ve had PEPs that have been thoroughly discussed and maybe had one or two outstanding details that needed hashing out. The high bandwidth physical meeting can resolve those issues, and I have no problem with the BDFL (-delegate, or equivalent) being satisfied and pronouncing at the meeting. OTOH, I’m much less comfortable with a newer idea, an experiment, or more controversial decision being made in a forum that excludes the voice of those not able to travel to the meeting. The Discourse experiment decision is one that falls into this category, even though I think it’s been a good experiment.

I don’t think decisions at physical meetings should be banned, but I do think we need to be especially mindful of the participation and concern of the wider Python community.

That said, I think it will make a lot of sense for the SC to meet virtually to discuss topics in that kind of high bandwidth setting. Pronouncements coming out of such meetings should generally follow the same guidelines.


Being a remote (I am based in India) contributor to most of the projects I am involved with, I am very much in support of any physical meetings among the contributors. More than anything else, the face to face time helps to resolve any conflict (due to communication most of the time), merging different ideas into a solid one within a short time. The physical meetings also allow us to be human to all other contributors and vice versa, not just an email address or forum name.

But, saying that, I would love to see these physical meetings making more proposals which then can be submitted to the bigger group (over email, or the forum etc). That way we get all the benefits of being in a physical place to create/modify/update some overview of the ideas (or maybe a super technical detailed one), and at the same time the rest of the contributors (who are not present in the meeting) will feel that their input was heard/viewed. If there is any big controversy or heated argument, the council will be able to step in and resolve the issue.


I would like to see in-person meetings continue to make decisions, but to make them on a slightly tentative basis. That is, I think that those present at a Language Summit or Core Developer Sprint should present a brief write-up of the decisions arrived at during those in-person meetings to the SC. I would expect that in 90% of cases, the SC would do no more than rubber stamp their agreement with those conclusions. But that would allow a 10% of cases where the SC wished to direct more in depth or broader community consideration of the issues.

I like the Antoine asked this about “project-wide decisions” as those are the ones where this matters most. Smaller decisions usually have domain experts and do not impact everybody and are often the point of meetings.

For larger decisions I believe we’ve already been doing that “slightly tentative basis” (David’s words) thing in the last few years. Intentionally. We know not everyone interested will have had a chance to weigh in.

For project-wide decisions, those never really count as decided without being documented in PEP style with pros/cons/alternatives/rejections also described. I think our existing processes already encourage us to be inclusive so long as we’re conscious to capture the various alternative discussions in the room in the written PEPs to better inform further online discussion before making anything final. If we fail to capture all of that in a PEP being decided, I expect to rightfully hear objections.

I like Carol’s suggestion of daily updates for those who are online and able to chime in remotely. We need such notes in order to feed into PEP updates as is.

I don’t see a reason to try to actively ban project wide decisions from meetings, I think we’ll naturally avoid making such things final there.


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)


First princples:

  • In-person technical exchanges can often be MUCH higher bandwidth than online, and furthermore build a sense of personal trust and community amongst the rather distributed dev group.
  • Foster a spirit of inclusion, so that those who are not present can keep a general pulse on what’s going on
  • Be aware that process & procedural “decrees” oftentimes harm that organic spirit

Thus, I am strongly in favor of devs getting together in person on a regular basis, in various places. I would also be hesitant to issue a “blanket ban” on what kinds of decisions can be made at such events, unless there was a clear pattern of harm to group participation & viability of governance.

That being said, unless there is a quorum of attendees, then project-wide decisions really should go through the normal online documentation process. If it’s related to the language itself, this would be a PEP. If it’s around operations or administration, then it should be announced online and given a reasonable comment period.


Project-wide decisions at physical developer meetings should include 3 of the 5 steering council members at the physical meeting and should only be made in three circumstances:

  1. when significant discussion has taken place outside of the meeting and the meeting decision is only making the final decision.

  2. when the physical meeting consists of enough core developers that it is clear that a super-majority of core developers have weighed in already and enough “counter-voices” have been registered to get a sense of the opposition.

  3. The decision is accompanied by a written summary including any opposition. Then, if enough negative voices are registered in writing from core developers after the physical meeting (i.e. more than ~15% of the core devs) then the decision must be re-ratified.


I work at a company that’s :100:% remote employees, and twice a year we meet in person. I found these onsite physical meetings are important process and very valuable. Discussions are done quickly, and because of that, we can come to consensus and decision sooner.

Therefore I’m for physical meeting for the purpose of making decision, especially if the key decision makers are present in the meeting. For such meetings though, the rest of the team should be notified in way in advance that the council plan to meet (and to make decisions). Since one of the mandate of the council is to try to seek consensus, other stakeholders should also be invited to the onsite meetings (it should not be exclusive to steering council members/core developers).

Those unable to attend can bring up their argument/concern to the council, and the council need to take those into consideration in the meeting and decision making.


I think the candidates that have responded thus far have made excellent points; I agree that as a whole, project-wide decisions should be presented to everyone before making a final decision.

I also think there should be the ability for the SC to step in if a decision made in-person is over-stepping its bounds, since people may have different perspectives on what distinguishes a “project-wide” decision and a more specific decision.

@pitrou, were you the person who made a digital appearance at the 2018 Core Sprint? I would love to hear more from the people who haven’t been able to attend sprints (whether at PyCon or the Core Sprint) to see if there are other ways we can more effectively include people remotely if they desire, as well as if daily summaries or even a more formal compiled report from multiple people at the end of the sprint would help (a compiled report may also help with @ncoghlan’s mention of situations where people wondered “Why did we decide to do that again?”).