Flaw in PEP 8015 vote for Steering Committee if two candidates work the same company?

Hi,

In the Rationale of my PEP 8015, I wrote:

To keep most of the decision power within the hands of the community, the Python Steering Committee has very limited roles. The idea is to reduce the risk that a group of people or companies “takes over” the Python project through just a couple individuals. The project must remain autonomous and open to everybody.

I added a strict condition on Steering Committee members:

It is important that the members of the committee reflect the diversity of Python’ users and contributors. A small step to ensure that is to enforce that two members cannot work for the same company (or subsidiaries of the same company).

Creation of this committee:

To bootstrap the process, 3 members will be elected at the committee creation. The first members will stay for 1, 2 or 3 years (3 years for the candidate ranked at the first position, 1 year for the candidate ranked at the third position).

=> Problem: My PEP doesn’t explain what happens if 2 vote winners work for the same company.

I see two options:

  • If two winners work for the same company, the second (ex: #2 or #3 rank) loses and the next winner is picked instead (ex: #4 rank).
  • Replace the requirement to work for different companies with a recommendation.

I have a preference for the first option. To me it’s important that the Steering Committee remains “autonomous”.

I already heard that the “don’t work for the same company” rule can be an issue if two colleagues would like to apply for the Steering Committee. Right, but I’m not sure that it’s a blocker issue especially if we handle it as part of the voting rules.

Note: My employer Red Hat (12K people) is being acquired by IBM (380K people) :slight_smile: All these rules are becoming more real for me :slight_smile: (even if I don’t know any core developer working for IBM, do you know any?). Extract of Election of Python Steering Committee Members:

If a committee member steps down, a new vote is organized to replaced them. If the situation of a committee member changes in a way that no longer satisfies the committee constraint (eg: they move to the same company as another committee members), they have to resign.

Given this reading for example, Brett and I could not both serve at the same time, since my company is owned by his company, even though they are independently operating businesses. I think an outright ban is too strict, but I am in favor of full disclosure of corporate connections. Then votes could decide whether they trust our employers and ourselves to remain independent. This could also cover other relationships, like one person works for a vendor/supplier for another’s employer, or someone serves on the board, etc.

1 Like

I think trying to codify a rule is not the way. It would be possible to game it anyhow. E.g. setup separate corporations for your minions and claim each one of them are employed by a separate company. Disclosure and then allowing the voters to decide seems more flexible and less easy to game.

2 Likes

Is that a problem? I mean, sure, that restricts the choice of possible Committee combinations, but that’s the whole purpose. We should not tweak the rules just to please you or Brett (or Steve or…).

That sounds like a strawman. Let’s focus on actual concrete situations (such as several core developers being employed, directly or indirectly, by Microsoft), not fantasy conspiracies with elaborate legal scaffolding to take over Python.

For full transparency, I think disclosure should apply to the candidates and the voters, but perhaps that’s what you meant.

If one company has e.g. 20% of the voters, there’s a certain influence.

I’d be more comfortable with one candidate per company and secret ballots.

1 Like

In my PEP 8015, the Steering Committee is only made of 3 people. If two members are working for the same company, it can send the wrong signal, as if the company has the full control on the Python project even if it is not true.

Guido van Rossum had a single employer. But here we are trying to design a new better governance, so it’s the opportunity to codify such rules.

Trust is subjective.

I’m working for Red Hat. Our business is on Linux servers. I have a limited amount of time to contribute to Python. If I have to choose to work on fixing a bug only affect Linux servers or a bug affecting Python embedded on Android, I will pick the Linux server. I wouldn’t feel comfortable regarding to my manager if I spend a whole week on a platform which is very far from our business. In practice, I do work on Android, macOS, Windows, FreeBSD, AIX, etc. changes. But well, I know that I am biased.

To be successful, the Python project has to fill most markets, very different use cases.

It’s the meaning of the sentence that I added in my PEP:

It is important that the members of the committee reflect the diversity of Python’ users and contributors.

By the way, Red Hat currently has 3 core developers: Christian Heimes, Petr Viktorin and me. Deny two committee members to work for the same company does not only affect Microsoft, but also Red Hat :slight_smile: I dont’t recall how many core developers have Facebook/Instagram? (Lukasz, who else?)

I would prefer to see 3 people from a small company, a large company and an independent.

In my PEP, being part of the Steering Committee doesn’t give you much power. There are many other ways to have a significant impact on Python, like writing PEPs. You don’t have to be a core developer to propose a PEP. Just one example, Chris Angelico got 2 PEPs approved (479 and 572, and 1 rejected: 463) and he is not a core developer.

So I’m not sure of the need to be two members of the same company in the Steering Committee of my PEP 8015.

Well, this question is maybe even more important in Mariatta’s PEP 8011 and Steve’s PEP 8013 where the “Trio” and “Council of Auditors” have more more power.

I wrote a change to fix the flaw in my PEP: I explained how to deal with two winners working for the same company :slight_smile: The question matters the most for the very first vote electing 3 members of the Steering Committee at once.

Another way to look at this is that no company can hold >50% of the council. That makes it difficult with three members. Four or five members on the council allows for two individuals from the same company. If the size of the council grows over time, the number would not need to be renegotiated as >50% could still apply.

1 Like

Yes, I agree to require less or less or equal than 50% of members from the same company. For example, with 5 members, I would be fine with 2 members from the same company.

But I decided to have a small group of 3 people. IMHO it’s just enough, and a larger Committee would require more organization to take decisions, people outside the committee may require more transparency, etc. As the Steering Committee (of my PEP 8015) don’t have many decisions to take, I think that 3 members is fine. But I’m open to discuss the size :slight_smile:

1 Like

I think a diversity of talents and competences makes for a better Board / Council / Committee, so I’d favour some amount between 5 and 9.

1 Like

Sounds good. I figured that you had a reason for 3. Just wanted to throw the concept out as a suggestion should the company be a sticky point later.

I fixed the flaw in my PEP 8015: I explained how to handle the case of two candidates that should be elected but work for the same company. I also explained how to handle a company acquisition.

While Barry dislike this restriction, it seems like other like it.

I also dislike the restriction, on the basis that it shows you don’t trust voters and think they need to be controlled by rules to produce the outcome you want, rather than outcomes that they may want.

My proposal doesn’t offer more power, it just doesn’t restrict the electors or electees except to ensure that there is no overlap between the council and those who can remove the council when they don’t like their behaviour.

(FWIW, I’m not planning on running for any of these councils. I barely have enough time for keeping Python running well on Microsoft operating systems to get myself subversively elected to a council so I can…make Python run well on Microsoft operating systems? :joy:)

I don’t think that’s a fair characterization… none of these voting methods have any way to express the preference “I like all of X, Y, and Z as individuals, but I think it’s better if they take turns instead of all serving at the same time”. Maybe some sufficiently clever voting system could do that, but I don’t know of any where I can vote for “any two of X, Y, Z”.

Yeah, part of what makes this tricky is that when you know and trust the individuals involved it often looks silly, but that’s not really the point, and policies like this aren’t at all an attack on the integrity of the individuals involved. The issue is, like… suppose there’s some decision that the whole core team unanimously agrees is a good idea, that happens to benefit Microsoft, and that this happens at a time when the steering committee happens to have a majority of MS employees on it. We all know that the outcome would be the same regardless of who happened to be on the steering committee, but that doesn’t mean that there won’t be news site headlines by ignorant reporters about how MS is taking over Python or something. It’s just better for everyone – especially Microsoft! – if the steering committee doesn’t have a majority of employees from any single company, because it means this kind of situation never arises in the first place and when there’s a question about supporting Python on Microsoft operating systems the committee can consider it purely on the merits, without having to worry about political nonsense interfering.

Yes, it’s a problem. It limits the choices people can make, and it assumes that someone’s employer is actually up to something nefarious and that the employee is complicit in that purpose. Full disclosure without a ban solves those problems in the general case, while leaving individual voters to decide whether it’s a valid concern (i.e. don’t vote for a slate that has corporate representation you don’t approve of).

Which is why disclosure without a ban appropriate, IMHO. If all three Redhat employees wanted to run on the same trio, why shouldn’t I get to decide whether I trust the company they work for, and their candidate employees? If I don’t, fine, I don’t vote for that trio.

How does the corporate restriction give you a way to express that preference?

This thread isn’t about 8011, where trios run together as a single slate. This is about 8015, where we vote for individuals, and then the council is composed of the top-N individuals. So it would be entirely possible to end up with an all-Redhat-employee council, even if every single voter wanted to avoid that.

1 Like

Perhaps it would be better (since many of these have a revote at some point in time) to simply have affiliations disclosed prior to voting and then let the voting population decide what seems best at any given point in time.

1 Like

I agree with having candidates disclose their affiliations. That needn’t be exclusive from having a rule to prevent over-affiliation with a single company in the council, though.

Nick Coghlan @ncoghlan suggested to core developers to fill their affiliations in the devguide: https://devguide.python.org/motivations/ Aha, mine is still up to date, good :slight_smile: