Hi,
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?
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 
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] 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.
[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:
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:
when significant discussion has taken place outside of the meeting and the meeting decision is only making the final decision.
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.
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 
% 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?â).