three days ago @ambv posted his nomination by @guido and @brettcannon for the steering council. It took me until today to realize, what was bugging me about the nomination.
Łukasz is a fantastic person (although I have to copy and paste his name every time ) and he makes a darn good candidate for the steering council. However he is also the release manager for Python 3.8. The combination is bugging me. In my opinion it would be more beneficial to have the RM independent from the SC, so she/he can act independently from decisions of the SC without a conflict of interest – a bit like checks and balances in modern democracy.
I don’t recall a formal definition of powers of a release manager. Except for PEP 8011, no governance PEP even mentions RM. Personally I see the RM a bit like a product manager: the SC decides what major changes land in the next Python version. Traditionally the RM has acted as a gate keeper to ensure, that last minute changes do not break the release or give exceptions to changes during beta freeze. And here lies the potential conflict: the SC may want to land a feature while the RM considers the feature as non-ready yet.
What do you think? Should the RM always be independent of the SC?
Christian
PS: Łukasz, I’m sorry that I’m speaking up against your nomination.
PPS: I really should look into compose key combination for the polish L with a stroke.
I disagree. I think this is taking separation of power much too far. Release manager is basically a technical job: apply common sense to what can still go in and what has to wait for the next release, and put the decision power for this in the hands of a single person so there isn’t any discussion (or at least so that if there is discussion there’s a well-defined way to get at an answer: the release manager is always right).
I really think we shouldn’t go for any exclusion for steering council members. Even the per-company-limit I don’t really like (I think we don’t need it, given the type of people we would elect to the steering council), but I guess we need it just so the outside world doesn’t get any incorrect ideas about the influence of companies on Python.
Formally, there is no mechanism included in PEP 13/PEP 8016 for the release manager to override the council. I always assumed that the release managers had a delegation from the BDFL, and presumably will continue to have a delegation from the SC, but either way if there’s a disagreement that means the BDFL/SC can override or even replace the RM.
I have trouble imagining a situation where the SC would ever want to do this though. And even less so if the RM is on the steering council!
It would possible to come up with some amendments to change this, but it’d be non-trivial and I’m not worried about it myself.
I agree with @dstufft here - if folks want to see the RM & SC roles be independent, then they can choose not to vote for the RM in this election.
I don’t think it will make much difference in practice though, as I’d expect the Steering Council to always take the RM’s opinion seriously regardless of whether the RM is a member of the Steering Council or not, and similarly, the RM will always be able to ask the (rest of the) Steering Council for help in resolving a question.
For the future, we’ll probably ask the new steering council to put together a governance PEP that describes the process for picking RMs, but that isn’t something we need to address right now.
A reasonable question to raise, Christian, re: conflict of interest.
A few things are important when looking at conflicts of interest: trust, powers, organization best interests, and personal gain.
Any board member will have affiliation or roles that may result in a conflict of interest on a particular board decision.
Ultimately, an organization must trust its judgment in selecting board members on whom it can depend on to do the right thing: be loyal to the organization and promote its best interests rather than their own personal agendas.
reference: The Non-Profit Board Answer Book
While the Release Manager may have viewpoints that differ than the other Steering Council members, it’s important to trust that collectively the members and the Release Manager work together to build consensus for any decision.
The key to determining if a Conflict of Interest exists is whether the board member or Release Manager is acting for personal gain.
That’s not really my experience of past release managers. In my experience, their main role was during the last weeks (days) before a release, to decide to create a new branch or not, and sometimes to cherry-pick individual changes. It don’t recall a release manager blocking a feature early during the development cycle of a new Python version, because its not in their personal agenda. Scheduling a feature for a specific Python version is usually a collective decision.
(On current versions of macOS, from the English keyboard just press and hold the “L” key to see other options, like Ł. Likewise for many other keys like A, C, E, I, O, S, U, Y. A similar behavior is available on iOS devices.)
Now you are insinuating something that I never said or meant. I haven’t presumed that a RM does something malicious intentionally. IMHO the RM should be independent, so that the RM does not even appear to be biased.
While it’s our collective decision to schedule a feature, it’s ultimately the RM’s decision to permit a change, when the feature does not land in time before beta freeze. In the past RMs like Ned, Larry, and Benjamin permitted some changes to land after the beta freeze. RM also decide which bugs are important enough to land after a branch has reached security-only mode.
I wouldn’t qualify “having a personal agenda” something malicious. As you wrote, RM decide what’s go in or not just before cutting a release. In the past, they were not personal preferences but more tradeoff between the risk of introducing regressions and the benefit of getting a new shiny feature.
I pushed hard @larry with very late asyncio changes before Python 3.4.0 release because I really wanted to get a “mostly-working” implementation of asyncio for the first Python release including asyncio in the stdlib. I pushed hard to get asynchronous subprocess in asyncio. Maybe it wasn’t a killer feature, but it was really great to have it!
IMHO it’s perfectly fine to have a RM in the Steering Committee. Maybe it’s even better to get a “better” release. If the RM becomes part of the committee, I expect more exchanges with other members of the committee, not less. More discussions should help to have a better schedule and better organize releases, no?
At the end, I’m not really for or against having the next release manager part of the Steering Committee. But at least, I don’t see a good reason to exclude the RM from the Committee. Moreover, the PEP 13 doesn’t say anything which means that it’s allowed by default And I can that it’s a deliberate choice of @njs and @dstufft to not have arbitrary limits but remain flexible.
Think about a situation where there’s a critical security flaw that can only be fixed by a backward incompatible change. You could certainly argue on both sides of such a decision, and yet a decision must be made. Is it the RM’s decision, or the SC’s? I could imagine that you’d have conflicting opinions here, but to me, the SC is the ultimate arbiter.
I’m thinking about PEP 524 and Guido’s pronouncement. IMHO, these are the types of decisions where only a final arbiter can make the decision, since you can argue persuasively either way.
As a release manager I always assumed the BDFL outranked me. There was one incident–the blocking urandom call in Python 3.4–where I felt like deciding it exceeded my authority as RM and I asked the BDFL to make the call. There were others in the discussion (e.g. Antoine iirc) who thought I was well within my rights to simply decide it, and that calling in the BDFL was unnecessary.
Hm, I would think the issue is a bit differently. Sure, the BDFL or SC in theory outranks everyone. But that doesn’t mean they want to be involved in every decision! (Maybe in the early '90s I wanted to. But not in the last two decades.)
Presumably in the urandom case (my memory of this is a bit hazy) it wasn’t that you didn’t have the right to decide – it was that you yourself weren’t sure of the right decision. In general those are the cases where the BDFL/SC gets invoked, whether they want to or not.
There’s also another thing to consider with decisions. If it’s easy to roll back, there’s less pressure to make the perfect decision, and the RM (or lower ranks in general) are more likely to make a decision. So the BDFL/SC ends up with the most difficult cases. As it should be.
One of the things leading to my retirement might have been that I felt that as the BDFL I had to be involved in more things than I wanted to. Instead of retiring I might just have made it clear that I wasn’t going to be involved in most things. That’s how it’s ended up anyway, so presumably the whole governance exercise was good for something.
My memory is hazy on this now, but did the urandom change happen in a major release or a minor release? If it happened in a 3.4.x point release, then with Guido’s criteria, that’s harder to revert. We definitely want to avoid situations where 3.y.1 has a different API than 3.y.2. In fact, this is the case with 3.5.1 vs 3.5.3, but that change is in typing which is provisional.
The other thing to think about is the likelihood that such a change will actually be tested. It seems like we don’t really get much real world experience with new releases until the final release.
) and he makes a darn good candidate for the steering council. However he is also the release manager for Python 3.8. The combination is bugging me. In my opinion it would be more beneficial to have the RM independent from the SC, so she/he can act independently from decisions of the SC without a conflict of interest – a bit like checks and balances in modern democracy.
I installed Polish keyboard on my Mac and Android phone, just so I can type ł and Ł …
And I can that it’s a deliberate choice of