#1

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:

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

3 Likes
#2

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

#3

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

#4

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.

#5

GitHub is not exactly new for the dev team. :wink: 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.

#6

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

#7

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.

1 Like
#8

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 :slight_smile:

#9

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

#10

Right. Though there was a governance vote sometimes in January :wink:

#11

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.

1 Like
#12

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.

#13

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).

1 Like
#14

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.

#15

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…