Release manager position and steering council seat

governance

(Christian Heimes) #1

Hi,

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


(Jack Jansen) #2

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.


(Antoine Pitrou) #3

I don’t think so. We’re not trying to build a sovereign political system here, just a reasonable governance system for an open source project.


(Senthil) #4

And this is not the case too.

Personally, I do not see any conflict here. A person from Steering Committee donning the role of RM seems just fine to me.


(Nathaniel J. Smith) #5

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.

PS: compose, /, L


(Donald Stufft) #6

People are free not to vote for whomever the Release Manager is if the possible conflict bothers them.


(Nick Coghlan) #7

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.


(Carol Willing) #8

Hi,

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.


#9

:sweat_smile: I installed Polish keyboard on my Mac and Android phone, just so I can type ł and Ł …#truestory


(Victor Stinner) #10

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.


(Ned Deily) #11

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


(Christian Heimes) #12

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.


(Victor Stinner) #13

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 :slight_smile: And I can that it’s a deliberate choice of @njs and @dstufft to not have arbitrary limits but remain flexible.

In the worst case, if a release manager becomes part of the Steering Committee and abuses its accumulated power, there is still an emergency exit: https://www.python.org/dev/peps/pep-0013/#vote-of-no-confidence