Python Steering Council 3.0
Written by Barry Warsaw in technology on Thu 05 November 2020. Tags: python,
With the release of Python 3.9, the first of its kind on the new annual release cadence, it is time once again for Python Steering Council elections. This will be the third edition of the Steering Council under the new governance model adopted by the Python core developers after Guido retired as BDFL.
I have served on both previous Steering Councils, and am self-nominating for a third term.
I have been deeply involved in Python since 1994. In fact, I learned that I was the first non-Dutch contributor to Python! I attended the first workshop (long before Pycons) back in November 1994 along with 20 other early enthusiasts. I met Guido at that workshop; I've loved Python as a language and community ever since, and I value Guido as a close personal friend. Somehow, I was immortalized as the Friendly Language Uncle For Life (the FLUFL), and that being a title that comes with no responsibilities, it's good to see that humor has never really left the language named after a British comedy troop.
The Python Steering Council (SC) has an important constitutional role in the evolution of the language, and works closely with the Python Software Foundation to ensure the ongoing health and vibrancy of the larger Python community. The five members of the SC meet weekly, and are usually joined by Ewa Jodlowska, the PSF's Executive Director. Although not required by the bylaws, Ewa's attendance is highly valued by the SC. She represents the PSF and graciously takes meeting notes, which eventually get submitted to the SC's private git repo, and distilled into public reports to the community. Occasionally we'll invite guests to come and chat with us about various topics.
We have a fairly wide agenda. A core constitutional requirement is to adjudicate on Python Enhancement Proposals (PEPs). PEPs are the way that the Python community proposes changes to the language, standard library, processes, and so on. A PEP is like a mini-RFC. I designed the original PEP process (and named it as a backronym) after the IETF's RFC process, but with a much more lightweight format. In general, the SC receives requests from PEP authors to accept or reject a particular PEP. It's important to understand that while the SC members can individually propose PEPs, they do so as any other Python community member. Also, PEPs are grassroots affairs; they are written by and proposed by members of the Python community, and do not have to be core Python developers to do so, although PEPs proposed by non-core members must be sponsored by a core developer.
Sometimes the SC delegates the final decision on a PEP to an expert who is not also a PEP author. The scope of PEPs is vast, so it's often more efficient to name an expert as the PEP Delegate. Such a delegate needs no other authority from the SC to accept or reject the PEP they are the delegate of.
The SC can also retain final decision authority for any PEP. Usually the SC reserves this right for PEPs that propose changes to the language, such as new syntactic features. But other types of changes, e.g. to the standard library, can be reserved for final decision by the SC. The SC likes to delegate when it makes sense, but it takes seriously its responsibility to shepherd changes to the language in a deliberate way, always with an eye on the big picture. We have to determine how this feature will interact with other features, since syntax changes are near-impossible to undo.
The SC also has the constitutional duty for final approval of new core developers. The process of adding new members involved conducting a vote of the core developers, and if the new member passes the vote, the SC gets final veto power. I can't remember a time when we've ever vetoed the membership of a new core developer who has passed the vote.
Another very important responsibility of the SC is to take action on Code of Conduct (CoC) violations. Python has an effective CoC working group that investigates CoC reports, and provides recommendations to the SC, but it is the SC that makes a final determination of the action, if any, to be taken. It's a testament to community that in our first council, we never had a CoC violation recommendation to review. Unfortunately, in our second term, we had two cases to decide on.
These kinds of issues are never fun for anyone involved, and there isn't an SC member who wouldn't prefer to spend their time thinking about how to decide on new language features, or how better to fund the continued growth and evolution of the language and its community.
It's incredibly difficult to balance the privacy and concerns of both accusers and the accused of CoC violations, along with transparency and the right for the community to know. We also have to keep in mind that we are establishing precedence in both process and outcome. Regardless of that outcome, are we providing the appropriate guidance to the rest of the community, so that they have a clear understanding of what behavior is inappropriate? Are we being too harsh or too lenient? Are we delivering the right action that matches the severity of the violation? These are such difficult decisions, but I believe the 2020 group of SC members has deliberated these questions with all the seriousness they deserve, and I'm proud of the way we've handled them. Every single member truly wants what's best for the Python community, and that includes ensuring the health and safety of its members. The checks and balances we have in place help drive us to decisions made with the best intentions.
The other major decision facing the 2020 SC is the structural pattern matching feature proposed for Python 3.10. This is a highly complex and powerful feature, with many proponents, detractors, and cooks-in-the-kitchen. The proposed syntax and semantics are enough of a departure from the existing Python language that we not only have to determine whether the feature is as good as possible and worth the new complexity, but also whether it's easy to teach, easy to read, doesn't break Python coders expectations of the language, and doesn't preclude any future features. The 2020 SC has announced that it will make a strong decision on the slate of structural pattern matching PEPs, but will leave the final determination to the 2021 Steering Council. My own feelings at this time are positive, but with concerns over some of the details. We'll see how this falls out once the new SC is seated.
Ultimately, I've been proud and honored to serve on the SC, and would like to continue on the 2021 committee. I think I bring a valuable continuity to the governance of Python. I hope the core developer community agrees and re-elects me to this position. Whatever happens, I will continue to work as hard for the next 25 years of Python success as I have the previous 25.