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.
