Update from the Python Steering Council about CPython Development (2019-02-26 meeting)

willingc · March 1, 2019, 6:36am

The Python Steering Council is pleased to provide an update to the Python community about Steering Council activity and CPython development. We’ve created a GitHub repo for Steering Council updates and helpful documents: https://github.com/python/steering-council

Here’s the latest update written after our meeting on February 26th:

github.com

python/steering-council/blob/master/updates/2019-02-26_steering-council-update.md

# Steering Council Update

Date: 2019-02-26

_Steering Council updates will be posted twice a month (shortly after
Steering Council meetings). We provide these updates to foster open and
transparent communication about Steering Council activity._

## Message from the Steering Council

**Ready to steer.** We've just wrapped up our first Steering Council video conference. To keep things moving forward, we've scheduled biweekly calls to discuss items under the Steering Council's mandate. To keep you informed about what we're working on, we'll publish updates, similar to this one, twice a month.

Our highest priority is **restarting the PEP review process**. We are taking a
look at all open and draft PEPs by our next meeting in mid-March. After this meeting, we'll update you on next steps for PEP 580 and others.

We're very pleased to see **contributing becoming more inclusive and accessible**. Thanks Terry and Victor for mentoring and supporting Cheryl Sabella, our newest core developer. Congratulations!

-- Barry, Brett, Carol, Guido, Nick

---

This file has been truncated. show original

We’ll be posting updates after each steering council meeting which will be roughly twice a month.

pitrou · March 1, 2019, 8:29am

Thanks for the update! Does it mean you’re not going to formalize the PEP decision process?

steve.dower · March 1, 2019, 1:15pm

RE: Requesting PEP reviews on GitHub - yet another communication method?

brettcannon · March 1, 2019, 8:06pm

PEP 1 was already updated so it’s as formalized as we plan to make it.

If people want to propose changes to the PEP process then we’re happy to see that discussion happen, but do realize we’re in an odd spot of trying to figure out how much people want us to just do stuff on our own versus having things driven by the dev team overall. My personal expectation is we’re not going to proactively try and make drastic changes on our own while we catch up with the glut of work since July (I do have a small idea, though), but if others want to start a conversation I bet we would be happy to hear how people want to change things.

brettcannon · March 1, 2019, 8:08pm

GitHub is not exactly new for the dev team. Plus GitHub is actually neutral in terms of communication as GitHub is not going away regardless of the whole ML/Discourse discussion gets resolved.

Obviously we can re-visit this if it doesn’t work out or a better solution ends up presenting itself.

steve.dower · March 1, 2019, 8:43pm

True, but we still discuss bugs elsewhere and we’ve never done PEPs there. I guess we’ll see how it goes.

willingc · March 1, 2019, 9:15pm

Perhaps I could have worded it better in the update. What I meant to convey was that the issues on the Steering Council repo (not the PEP repo) could be used to request the Steering Council consider a PEP.

steve.dower · March 2, 2019, 3:41am

You worded it fine, for me at least.

I guess if discussion on the issue is absolutely minimal it’ll be fine, but I don’t really want to have to track discussion in a third place (mailing lists and here, since I already ignore the PEPs repo and don’t count Twitter or in-person). That’s all

pitrou · March 2, 2019, 2:50pm

Hmm… did I miss the announcement? A bit surprised…

pitrou · March 2, 2019, 2:51pm

Right. Though there was a governance vote sometimes in January

brettcannon · March 4, 2019, 11:03pm

The closest we had to an announcement is this update we’re replying to. Otherwise there was nothing to announce since it was just bringing PEP 1 in line with PEP 13.

pitrou · March 17, 2019, 6:44pm

That’s not how I understood PEP 13 (or its predecessor PEP 8016). AFAIU, it deliberately didn’t choose a specific governance model and instead intended for the elected Steering Council to choose one. One of the themes during the PEP 8016 discussion was that the governance model chosen by the SC was expected to be in line with the governance vote results, in which PEP 8012 (@ambv’s Community Governance Model) came as the second winner.

I may have entirely misunderstood the whole thing, but updating PEP 1 without announcing your intentions beforehand is not what I expected to happen.

brettcannon · March 18, 2019, 11:36pm

PEP 13 specifically gave the steering council the power to pronounce on PEPs. If you read the PEP 1 update it should just reflect that fact along w/ Guido not acting as BDFL (if it doesn’t then please let us know how it is confusing as we can update it).

willingc · March 19, 2019, 12:10am

Perhaps what is causing confusion is the paragraph in PEP 13 (which was carried forward from PEP 8016): https://github.com/python/peps/blame/master/pep-0013.rst#L85. Corresponds to italics below.

Powers

The council has broad authority to make decisions about the project. For example, they can:

Accept or reject PEPs

Enforce or update the project’s code of conduct

Work with the PSF to manage any project assets

Delegate parts of their authority to other subcommittees or processes

However, they cannot modify this PEP, or affect the membership of the core team, except via the mechanisms specified in this PEP.

The council should look for ways to use these powers as little as possible. Instead of voting, it’s better to seek consensus. Instead of ruling on individual PEPs, it’s better to define a standard process for PEP decision making (for example, by accepting one of the other 801x series of PEPs). It’s better to establish a Code of Conduct committee than to rule on individual cases. And so on.

To use its powers, the council votes. Every council member must either vote or explicitly abstain. Members with conflicts of interest on a particular vote must abstain. Passing requires a strict majority of non-abstaining council members.

Whenever possible, the council’s deliberations and votes shall be held in public.

The italicized wording provides possible, though hypothetical, examples. The rest of the text outlines the powers of the Steering Council.

The updates to PEP 1 were to bring as @brettcannon mentions in line with PEP 13. All steering council members voted to accept the PR 896.

pitrou · March 21, 2019, 8:14pm

Yes, I agree that defining a process for PEP decision making was part of the SC mandate as per PEP 8016. I’m just surprised it was done without any prior announcement or discussion with core developers. But as @brettcannon says, perhaps other core developers wanted it to happen that way…