Hi all At the sprints this last week, probably unsurprisingly, we had some discussions relating to the future of Python's governance. Since not everyone could be involved, I'm going to be posting the notes from these meetings (taken by an independent note-taken, and reviewed/redacted by the participants before being made public).
I want to be very clear that no final decisions were made at these meetings, but they were very helpful in helping those of us working on concrete proposals. You should start seeing PEPs 80xx filling out with content over the next few weeks. *Those* are the reference documents - these notes are simply a record of what came out. If you want to reply to and discuss particular points from these, *please* reply to the list, change the subject line, and clearly quote only the relevant part. There is a lot of content here and nothing to be gained by repeating it endlessly. (Also, if you want to thank me for copy-pasting into an email, it really is unnecessary but please do it off-list. We've already passed on our thanks to the note-taker as well.) For this first meeting, roughly 30 of us sat/stood in a circle and briefly answered two questions: * what are you most concerned about right now? * in one word, what do you like most about Python? These notes are an anonymised, paraphrased, reorganised summary of the responses. Responses that deserved an immediate follow up have (as far as I'm aware) received it already. So take this as a bit more insight into community sentiment than could otherwise be obtained over email, but as nothing more significant than that. Cheers, Steve --- Python's Benevolent-Dictator-For-Life (BDFL) Guido has stepped down, which raises the question of how Python's core development team should proceed when making decisions about changes to Python. The attendees of the sprint had a meeting to sit down and all concisely express their biggest concerns. I took notes as people were speaking; hopefully I captured the gist of what they were saying if not their exact words. I'll start with a quick summary and the plan for immediate next steps, and then give individual points loosely grouped by broad area of concern. Executive summary: The biggest areas of concern are: * Choosing how to choose a new governance model * The principles that will guide the future of python * Effective, respectful communication and related social factors * related: Code of conduct issues, which already have a PSF working group looking into them. We went around the room and asked people to give a one or two word summary of what they like about Python. * community * people * elegance * consistency * ease for non-experts * good taste * accessibility * opportunity * productivity * trust * zen * fun * openness * thoughtfulness * Monty :-) Next steps: * Digest what we've discussed overnight * Meet in the morning and organize by areas of particular concern * Discuss further * Report back Specific concerns raised by individuals follow. These have been anonymized and rearranged, and are individual contributions and do not reflect any official position, or even necessarily a majority position of the core development team. Introductory thoughts: * Complexity is real * Any number of plans could work * What behaviours help communities be effective? * Which produce roadblocks and challenges? * What do we value about Python? Choosing how to choose: * There will be various proposals for governance models. How do we pick one? Can we get to consensus on that? * There's a PEP out to discuss how this process works in other languages. * Vote on a committee that makes governance recommendations * Give a small group of people a mandate to study and make recommendations * Can we determine what are roles that need to be filled? * Do not get bogged down in the meta-question of how to choose how to choose. * Any important change requires a working group of experts in the specific area affected by the change. How to choose members of this group? * Can we define the scope of problems that we need to bring to a higher authority? * Having working groups with autonomy is great, but there will be things where all the threads come together. Changes to the C API, changes to the core syntax. * We have always appealed to Guido's sensibilities, and that's where the power vacuum is now. Think about something like the Debian technical committee, where they make decisions that affect everyone in that community. * Some people will be unhappy with whatever decision is made, but we want people to agree that there is a clear authority and a process that is respected and legitimate. * Our existing model has BDFL delegates for specific issues. How should power be delegated to make specific decisions about features? Who can say "this will not happen"? * It's pretty nice to have a dictatorship when you have a good dictator. A democracy does not guarantee that the best choice will be made, or even that the will of the majority is carried out. * The language is now sufficiently complex that it may be difficult to have any individual that understands the whole thing enough to make decisions unilaterally. * Without a way to make the decision it is all talk; how do we have a consensus? * We should accept that we're not going to get to unanimity * What is the externally visible legitimacy of any decision process? If 52% say yes and the other 48% say no, is the decision legitimate? * The state we're in now is scary but many other projects have been here, like numpy. We need to shift from our respect for Guido to a shared sense of what's the right process, even if we don't agree on every detail. A 51% vote is not a good thing. * We are experts on programming languages, not on governance and decision making. Maybe bring in an expert on decision making models if this meta problem is going to get really thorny. * There are models of decision making that have been studied by experts and their characteristics are known. These models are all pretty good; pick a decision-making model and discuss it. * Think about what has worked well in the past and has not worked well. We've had a successful process delegating issues before. Maybe we don't need to worry too much about the fine details of delegation. We could fall into the trap of making this process too complicated, too overspecified and too legalistic. * The core development community is not as diverse as the broader Python community. Attitudes of the people making these governance decisions may not be aligned with those of the communities they're intending to serve. How can we address this? * People are too afraid of changes; we don't need a PEP or a formal process or a decision from Guido for everything. Some changes can just be made by people we trust to make good decisions. * Continue to rely on experts when making decisions about their areas of expertise. * There are disruption risks of changing too quickly but there are existential risks in changing too slowly. * The model so far is that the patriarch lets the kids run around but keeps them from running over the cliff. * Making one person or a small group an oracle for what is good is unfair and unrealistic, particularly if they have to not only understand and make decisions about every aspect of the language but also police bad process outcomes. * Consider models of projects that work; get people involved who are experts on project management and process. We need a Counsellor Troi for this project. Get a professional coach involved, who is already involved in successfully governed Python projects, for example the Jupyter project and the Django project. * If someone does not aspire to be leadership but still has something to offer, are they shut out of the decision-making process? If important things come up, people with depth of experience need to be heard and feel that they are heard. * No one really wants decision by committee and what that entails. * Historically we see that when there is a change in governance model and power structure, there will be a challenge. Hopefully there will not be a villain that brings us together. * Whatever we do, hopefully it will not require more effort by the volunteers of the core team; we like to work on technical issues rather than navigating political organizations and heavyweight processes. * Our work is founded on trust; take that into account and keep it from falling apart * Every core developer should have an idea of what they want to see from Python in the next five years. That will motivate choice of governance model. * Keep moving forward and get a governance decision made. We don't want to make a panic decision, but we don't want to sit and wait either. Figure out what we want and execute on it. * This is a human factors problem; burnout exists everywhere in an organization. Understand the roles that we are trying to refactor. * Things will not be the same, some changes will go smoothly, and some will not, and then they'll say that in the old days, things were great. * Define what roles need to be filled; that affects everything. * We should choose how we're going to choose before we leave, while being considerate of people who are not here. * Be clear that any new model of governance is specifically for core devs, not for the Python community as a whole What's important? * Python is a popular language; anything we change has a large impact and we need to take that seriously. Can we agree on how impactful decisions can be, and make sure that a governance process takes impact seriously? * Explicit is better than implicit; Guido is a mountain of implicit knowledge, and there is no one close to that. * We need a set of slogans or principles that summarize our design values; the Zen of Python is poetic and aspirational, but we should decide more specifically what Python should be or we will end up with C++ * What are the goals of Python as a language? Do we value stability, or evolving to achieve feature parity with other languages? Do we want to evolve fast or slow? Do we value performance or compatibility? It's easy to say "both", but design is about making compromises. The relationship between the PSF board and the core dev community * The role of a board member is to fulfill the mission of the organization in accordance with its guiding principles. * What are those guiding principles? Consistency, stability? What else? * What specific communities of users and developers are served? * Where does the PSF and its board of directors fit in to this decision? * Core developers don't see the PSF very often, and non-core-dev board members don't see much of what the developers are doing. * Does the board want to be involved in this process? * We should make sure that the board and the core devs are on the same track and share common goals * There is a clear difference between how the board sees the core developers and what the core developers do. New board members often ask how much influence they have on how core developers do their work. Very little. * The PSF owns the trademark and therefore what is done with the codebase. * Core developers are expected to participate in language development and writing code, not, say, raising money. The foundation manages that. Communicating decisions * How will this decision be communicated to the world? * People don't like to read long governance documents. * Get this sorted out well before the next pycon. The decision should be formally announced there, but it should be well known and accepted throughout the community long before that. Email is terrible, except when it isn't * The email list mechanism is both boring and annoying. Can we find another tool? * Python dev mailing list has 20K subscribers which is a scarily large number given the level of discussion. * The mailing list used to function better: * The participants were not necessarily nicer; some were mean, but the problem solving was effective. * How did those people interact together? * Get old timers out of retirement to participate and model effective problem solving. * What communication techniques can be used for problem solving that have intellectual depth while ensuring that everyone is heard? * It's easy to criticize the email lists but remember that these lists do in general work pretty well. Process suggestions and concerns * When someone exits a role, consider an exit interview. How do we not repeat mistakes of the past? (Not to put Guido on the spot.) * We took Guido for granted, and now need codification of those processes. * The PEP process is the biggest part of how we design python and it needs to be redesigned. We need a tighter PEP process with stages and rules. * The PEP process is more difficult than it needs to be. Conduct, and its code * The forum process dismisses and belittles people. That's not OK on the face of it, but worse, the people who are bullied are allies, contributors and advocates for this language. * The code of conduct feels like it is ostensibly there to protect people from abuse, but in fact can be used as a weapon against people who want to contribute * Python dev doesn't feel like a safe forum. We can't continue to let that happen. Women with deep knowledge and industry experience have real serious reasons to avoid this forum. * We need to change our interactions before a change of governance has a chance to work * There are "hot" topics that people are overly "active" in their participation; the code of conduct should be applied there. But let's remember that in general our communication mechanisms work well most of the time. We're capable of making good decisions. * If you see something that doesn't seem right on a list, mail a moderator; moderators don't see everything. * Maybe apologize once in a while. We have a responsibility to each other and to owning our mistakes. * Being a core developer is as much about establishing trust with each other as it does with technical ability. Work on establishing trust. * The metric of a successful technical decision is not its technical merit; it's whether everyone feels like they were heard. If it's a hard technical decision then you need a diverse set of opinions to get confidence that you've arrived at a good decision. And making people feel heard keeps them around and wanting to participate. * The code of conduct is supposed to make people feel more included but can make people feel excluded. * There are experts on this; get them involved. They're sensitive to being humane through this process. Pycon brought in consultants for this. * There is a conduct working group taking a holistic view, the board has approved getting help on this. * How does this affect core devs? We need buy-in. * The process is not far involved yet; just got budget. * Code of conduct enforcement should be prompt, kind and firm; don't get into a state where everyone is screaming at each other. _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
