Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
On Wed, Jul 18, 2018, 18:09 Alex Martelli, wrote: > Hi Brett, > > On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: > >> [can I just say how much I've missed having both you and Tim around, >> Alex? ] > > > Heh, good to hear!-) > > Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) >> > > Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce > on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 > (at least not in the US with our `Imperial` system; does it work any > differently in Canada with Metric?-)... > Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I get for replying to emails on the bus after a very stressful day at work. -Brett > Alex > > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
Hi Brett, On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: > [can I just say how much I've missed having both you and Tim around, Alex? > ] Heh, good to hear!-) Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) > Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 (at least not in the US with our `Imperial` system; does it work any differently in Canada with Metric?-)... Alex ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
[can I just say how much I've missed having both you and Tim around, Alex?
]
On Wed, Jul 18, 2018, 17:28 Alex Martelli via python-committers, <
python-committers@python.org> wrote:
> There are plenty of precedents for mandatory voting, but the enforcement
> mechanisms (if any) appear not to be applicable to our case. Note the "if
> any": several countries declare voting a citizen's duty (in their
> Constitution or otherwise) but don't actually enforce this duty in any way.
> For example, that's the case in the United States: if you apply for
> naturalization you will be quizzed on many things, including "what are the
> duties of a citizen", and one of the latter is "participate in the
> democratic process" which includes voting -- but if you don't, no
> enforcement action is taken against you. In contrast, if you get a jury
> summons (jury duty being another of those citizen duties) and repeatedly
> fail to show up, you may end up in jail -- now THAT is enforcement of the
> duty (and no Python community organism has, nor should have, such power of
> enforcement.
>
And that lack of enforcement power is what makes me worry about mandatory
participation to make a vote considered legitimate.
> In Italy, where voting is declared to be a duty in the Constitution, at
> the start of the Republic you'd get (until next election) a stamp of "non
> ha votato" ("did not vote") in your publicly accessible judiciary record
> (it would come up in any background search -- and, in a country where
> firing employees was notoriously hard, some opined that such a flaw might
> be grounds for dismissal if the employer so wished, although I've never
> heard of it happening). That was abolished 25 years ago, in part because it
> was randomly/capriciously enforced (many judicial districts were too
> otherwise-busy to go through voting records and apply/remove the stamp!-).
> So, now, Italy is in the vast camp of countries declaring voting a duty
> (Italy's constitution was not changed on this subject) but not enforcing
> the "duty" at all (indeed, failing to show up to vote is now often
> advocated by adversaries of referendums, which have a 50% minimum
> participation threshold to be valid and may well be easier to defeat by
> getting people to just not show up -- since many others won't anyway for
> other reasons -- than by getting them to vote against).
>
> Since I originally brought up a parallel between "which BDFL" voting, and
> a Papal conclave, I would be remiss to fail to mention that since 1274 the
> Cardinals are locked up "with a key" ("cum clave") until a Pope does get
> elected -- usually a good-enough incentive to vote (though once the
> citizens of the town where the conclave was held had to decide after a few
> failed votes to only send in bread and water -- and later, said citizens
> removed the roof of the palace where the Cardinals were locked up, hoping
> that rain may speed up the proceedings). Colorful, but, again, not really
> applicable in our case.
>
> What's left? The "public naming and shaming" Italy used until a quarter
> century ago might work -- just make a little site listing the committers
> who, while having a right to vote, haven't voted (yet). A VERY long voting
> period might also help -- amendments to the US Constitution originally had
> unlimited times for ratification (the 27th amendment, originally the 2nd
> one proposed in 1789, was ratified 202 years after proposal), though these
> days 7 years is a more customary time limit for ratification. Not sure if
> these are good ideas.
>
> Another possibility is to avoid having separate thresholds for
> participation and approval (US constitution amendments work that way --
> with the specifics being a threshold only for approval out of all States,
> not how many States have voted for or against). I.e, if we decide 2/3 is
> OK, a proposal might be approved if 2/3 of *eligible* voters have voted
> for it -- no matter how many of the remaining 1/3 have voted against, or
> not (yet?) voted at all (since, if 100% of eligible voters could be
> bothered to vote, once the proposal gets 2/3 of the votes in favor, it does
> not matter whether the remaining 1/3 vote against, abstain, or whatever).
> This is not mutually exclusive with other ideas (of which, out of what I've
> mentioned, the viable ones -- though not necessarily wise! -- would be
> "public naming" of non-voters, and VERY long voting periods).
>
That is a good point of clarification. If we did super-majority, is it of
all counted *votes* or all possible *voters*? We might be surprised by the
participation levels, or we might be disappointed. So we might have to go
on what we think is reasonable, try it, and if there's a threshold
requirement then be prepared to have to vote again (and again ...) until
the threshold is met (or we lower the threshold ).
Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) to
have made a commit you have look back 7 years of commit
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
There are plenty of precedents for mandatory voting, but the enforcement
mechanisms (if any) appear not to be applicable to our case. Note the "if
any": several countries declare voting a citizen's duty (in their
Constitution or otherwise) but don't actually enforce this duty in any way.
For example, that's the case in the United States: if you apply for
naturalization you will be quizzed on many things, including "what are the
duties of a citizen", and one of the latter is "participate in the
democratic process" which includes voting -- but if you don't, no
enforcement action is taken against you. In contrast, if you get a jury
summons (jury duty being another of those citizen duties) and repeatedly
fail to show up, you may end up in jail -- now THAT is enforcement of the
duty (and no Python community organism has, nor should have, such power of
enforcement.
In Italy, where voting is declared to be a duty in the Constitution, at the
start of the Republic you'd get (until next election) a stamp of "non ha
votato" ("did not vote") in your publicly accessible judiciary record (it
would come up in any background search -- and, in a country where firing
employees was notoriously hard, some opined that such a flaw might be
grounds for dismissal if the employer so wished, although I've never heard
of it happening). That was abolished 25 years ago, in part because it was
randomly/capriciously enforced (many judicial districts were too
otherwise-busy to go through voting records and apply/remove the stamp!-).
So, now, Italy is in the vast camp of countries declaring voting a duty
(Italy's constitution was not changed on this subject) but not enforcing
the "duty" at all (indeed, failing to show up to vote is now often
advocated by adversaries of referendums, which have a 50% minimum
participation threshold to be valid and may well be easier to defeat by
getting people to just not show up -- since many others won't anyway for
other reasons -- than by getting them to vote against).
Since I originally brought up a parallel between "which BDFL" voting, and a
Papal conclave, I would be remiss to fail to mention that since 1274 the
Cardinals are locked up "with a key" ("cum clave") until a Pope does get
elected -- usually a good-enough incentive to vote (though once the
citizens of the town where the conclave was held had to decide after a few
failed votes to only send in bread and water -- and later, said citizens
removed the roof of the palace where the Cardinals were locked up, hoping
that rain may speed up the proceedings). Colorful, but, again, not really
applicable in our case.
What's left? The "public naming and shaming" Italy used until a quarter
century ago might work -- just make a little site listing the committers
who, while having a right to vote, haven't voted (yet). A VERY long voting
period might also help -- amendments to the US Constitution originally had
unlimited times for ratification (the 27th amendment, originally the 2nd
one proposed in 1789, was ratified 202 years after proposal), though these
days 7 years is a more customary time limit for ratification. Not sure if
these are good ideas.
Another possibility is to avoid having separate thresholds for
participation and approval (US constitution amendments work that way --
with the specifics being a threshold only for approval out of all States,
not how many States have voted for or against). I.e, if we decide 2/3 is
OK, a proposal might be approved if 2/3 of *eligible* voters have voted for
it -- no matter how many of the remaining 1/3 have voted against, or not
(yet?) voted at all (since, if 100% of eligible voters could be bothered to
vote, once the proposal gets 2/3 of the votes in favor, it does not matter
whether the remaining 1/3 vote against, abstain, or whatever). This is not
mutually exclusive with other ideas (of which, out of what I've mentioned,
the viable ones -- though not necessarily wise! -- would be "public naming"
of non-voters, and VERY long voting periods).
Lastly, I suspect two votes should be separated: (1) what model we adopt
(BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO
is going to serve (as BDFL, as triumvirate member, and so on)...
Alex
On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft wrote:
>
>
> > On Jul 18, 2018, at 6:18 PM, Łukasz Langa wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
> >>
> >> While I am totally fine with a super-majority of votes for something to
> be accepted, I don't think the minimum participation requirement will work.
> If people simply choose not to vote then they choose not to (we have no way
> to really compel people to vote).
> >
> > It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it
> happening often. There are countries where voting is mandatory.
>
> Given that we don’t have a lot of levers in our tool chest to compel
> voting, what would you
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
Excerpts from Łukasz Langa's message of 2018-07-18 17:31:40 -0500: > The PSF uses a good voting system where votes are secret. I see no reason not > to reuse this infra. > > -- > Best regards, > Łukasz Langa This feels like a case where a consensus-based voting system may be better than one that depends on amassing raw votes. https://civs.cs.cornell.edu is a hosted version of Condorcet that is reliable, easy to use, and allows for public review of the ballots (without associating them with the person casting them). Doug ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
On Wed, 18 Jul 2018 at 15:46 Donald Stufft wrote:
>
>
> > On Jul 18, 2018, at 6:18 PM, Łukasz Langa wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
> >>
> >> While I am totally fine with a super-majority of votes for something to
> be accepted, I don't think the minimum participation requirement will work.
> If people simply choose not to vote then they choose not to (we have no way
> to really compel people to vote).
> >
> > It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it
> happening often. There are countries where voting is mandatory.
>
> Given that we don’t have a lot of levers in our tool chest to compel
> voting, what would you propose we do if we get only a 35% participation
> rate? We can’t drag people to the polls, the most we can really do is
> either keep running elections and hope you hit whatever threshold you
> decide on, or you start removing people who can vote until you’ve removed
> enough people that the people who are participating now make up whatever
> your target participation rate is.
>
> The first choice there strikes me as unrealistic. Hope is not a strategy,
> and I fail to see why repeatedly offering the same vote multiple times is
> likely to increase the participation rate. In fact, I think it’s likely to
> decease it as people get tired of having to do it over again and just start
> giving up and viewing it as noise.
>
> The second choice seems… dishonest to me? You’re not really increasing the
> participation of the vote, you’re just juicing the numbers to make the
> participation rate higher. It’s selectively defining who is eligible to
> vote to make the numbers look better.
>
> Is there another option I’m missing to compel people to vote?
>
> >
> > Taking a step back, there are two reasons I stress the importance of
> (almost) everybody voicing their support:
> > - this makes the decision authoritative ("the committers have spoken”);
>
> I think this is largely a non-issue. In the US we do not have mandatory
> elections, and I don’t see very many people challenging the authority of
> said elections due to the large percentage of non-voters. The most I
> generally see if people scolding those who don’t vote.
>
> > - this ensures that we haven't omitted somebody due to poor timing ("I
> was on a sabbatical and couldn't vote”).
>
> Unless you require 100% voting participation, it doesn’t ensure this, it
> just makes it less likely. If you target 90%, then a full 10% of the people
> could have been excluded due to poor timing.
>
> I don’t think it’s possible to fully eliminate this risk, but I think the
> best possible way of handling it is to advertise the vote well in advance,
> and allow the vote itself to take place over a reasonable amount of time.
> The more advance notice, and the larger the window of time is to actually
> vote in, the less likely timing becomes an issue. Just to pluck some random
> times out of the air, if you advertise the voting for 3 months and allow
> voting to happen any time in a months time, that gives people a full 4
> months they will have to be completely unavailable to have no idea the
> voting is happening, and be unable to access a computer for a handful of
> minutes to actually do the vote at all in a month.
>
I think this is a reasonable way to deal with the situation.
We will also need to see how many proposals we have and how similar they
are, else we might have to talk about ranked ballot.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
2018-07-19 0:36 GMT+02:00 Antoine Pitrou : > Let's say I'm being asked if X should be a « next BDFL » (or Council > member, etc.) and I vote no publicly. What is my position if X is > elected? How will my vote be interpreted? Will I get discriminated > against (even unconsciously) just because I didn't choose that person? I see. I understood that we were more discussing the governance model than voting for a specific BDFL: I'm not convinced yet that we need a BDFL :-) Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
> On Jul 18, 2018, at 6:18 PM, Łukasz Langa wrote:
>
>
>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
>>
>> While I am totally fine with a super-majority of votes for something to be
>> accepted, I don't think the minimum participation requirement will work. If
>> people simply choose not to vote then they choose not to (we have no way to
>> really compel people to vote).
>
> It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it happening
> often. There are countries where voting is mandatory.
Given that we don’t have a lot of levers in our tool chest to compel voting,
what would you propose we do if we get only a 35% participation rate? We can’t
drag people to the polls, the most we can really do is either keep running
elections and hope you hit whatever threshold you decide on, or you start
removing people who can vote until you’ve removed enough people that the people
who are participating now make up whatever your target participation rate is.
The first choice there strikes me as unrealistic. Hope is not a strategy, and I
fail to see why repeatedly offering the same vote multiple times is likely to
increase the participation rate. In fact, I think it’s likely to decease it as
people get tired of having to do it over again and just start giving up and
viewing it as noise.
The second choice seems… dishonest to me? You’re not really increasing the
participation of the vote, you’re just juicing the numbers to make the
participation rate higher. It’s selectively defining who is eligible to vote to
make the numbers look better.
Is there another option I’m missing to compel people to vote?
>
> Taking a step back, there are two reasons I stress the importance of (almost)
> everybody voicing their support:
> - this makes the decision authoritative ("the committers have spoken”);
I think this is largely a non-issue. In the US we do not have mandatory
elections, and I don’t see very many people challenging the authority of said
elections due to the large percentage of non-voters. The most I generally see
if people scolding those who don’t vote.
> - this ensures that we haven't omitted somebody due to poor timing ("I was on
> a sabbatical and couldn't vote”).
Unless you require 100% voting participation, it doesn’t ensure this, it just
makes it less likely. If you target 90%, then a full 10% of the people could
have been excluded due to poor timing.
I don’t think it’s possible to fully eliminate this risk, but I think the best
possible way of handling it is to advertise the vote well in advance, and allow
the vote itself to take place over a reasonable amount of time. The more
advance notice, and the larger the window of time is to actually vote in, the
less likely timing becomes an issue. Just to pluck some random times out of the
air, if you advertise the voting for 3 months and allow voting to happen any
time in a months time, that gives people a full 4 months they will have to be
completely unavailable to have no idea the voting is happening, and be unable
to access a computer for a handful of minutes to actually do the vote at all in
a month.
>
> If you feel like this is unrealistic because most of our committers aren't
> currently active, I hear you. But what I like even less is claiming that "we,
> the core team" made a decision when, say, just 35% of us voted. In such case
> it would be easier for those of us who disagree to claim the decision doesn't
> really represent the views of the greater core team.
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
Le 19/07/2018 à 00:36, Antoine Pitrou a écrit : > > Le 19/07/2018 à 00:29, Victor Stinner a écrit : >> I hate cabals. I prefer to keep everything open and transparent, as >> this mailing list is public (even if only core developers are allowed >> to post). > > Even if posting is public, you won't know whether there is a cabal or > not (unless you are part of the cabal -- I hope you aren't, are you? ;-)). Sorry: s/posting/voting/ ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
Le 19/07/2018 à 00:29, Victor Stinner a écrit :
> I hate cabals. I prefer to keep everything open and transparent, as
> this mailing list is public (even if only core developers are allowed
> to post).
Even if posting is public, you won't know whether there is a cabal or
not (unless you are part of the cabal -- I hope you aren't, are you? ;-)).
> Which drawback do you see of making the votes public?
Let's say I'm being asked if X should be a « next BDFL » (or Council
member, etc.) and I vote no publicly. What is my position if X is
elected? How will my vote be interpreted? Will I get discriminated
against (even unconsciously) just because I didn't choose that person?
There are all kinds of pressures (or self-censorship phenomena) that can
occur with public voting.
(votes by elected representatives, conversely, are public, because being
elected it's important for the electors to know what the representatives
truly stand for)
Regards
Antoine.
>
> Victor
>
> 2018-07-19 0:26 GMT+02:00 Antoine Pitrou :
>>
>> By the way, should the vote be public or secret?
>> For such an important (and sensitive) matter, perhaps it would be wise
>> for it to be secret.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>>>
On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
While I am totally fine with a super-majority of votes for something to be
accepted, I don't think the minimum participation requirement will work.
If people simply choose not to vote then they choose not to (we have no
way to really compel people to vote).
>>>
>>> It could be easily added to the list of things expected from a core
>>> contributor. It's not like this is a laborious chore, neither is it
>>> happening often. There are countries where voting is mandatory.
>>>
>>> Taking a step back, there are two reasons I stress the importance of
>>> (almost) everybody voicing their support:
>>> - this makes the decision authoritative ("the committers have spoken");
>>> - this ensures that we haven't omitted somebody due to poor timing ("I was
>>> on a sabbatical and couldn't vote").
>>>
>>> If you feel like this is unrealistic because most of our committers aren't
>>> currently active, I hear you. But what I like even less is claiming that
>>> "we, the core team" made a decision when, say, just 35% of us voted. In
>>> such case it would be easier for those of us who disagree to claim the
>>> decision doesn't really represent the views of the greater core team.
>>>
>>> - Ł
>>> ___
>>> python-committers mailing list
>>> python-committers@python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
I hate cabals. I prefer to keep everything open and transparent, as
this mailing list is public (even if only core developers are allowed
to post).
Which drawback do you see of making the votes public?
Victor
2018-07-19 0:26 GMT+02:00 Antoine Pitrou :
>
> By the way, should the vote be public or secret?
> For such an important (and sensitive) matter, perhaps it would be wise
> for it to be secret.
>
> Regards
>
> Antoine.
>
>
> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>>
>>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
>>>
>>> While I am totally fine with a super-majority of votes for something to be
>>> accepted, I don't think the minimum participation requirement will work. If
>>> people simply choose not to vote then they choose not to (we have no way to
>>> really compel people to vote).
>>
>> It could be easily added to the list of things expected from a core
>> contributor. It's not like this is a laborious chore, neither is it
>> happening often. There are countries where voting is mandatory.
>>
>> Taking a step back, there are two reasons I stress the importance of
>> (almost) everybody voicing their support:
>> - this makes the decision authoritative ("the committers have spoken");
>> - this ensures that we haven't omitted somebody due to poor timing ("I was
>> on a sabbatical and couldn't vote").
>>
>> If you feel like this is unrealistic because most of our committers aren't
>> currently active, I hear you. But what I like even less is claiming that
>> "we, the core team" made a decision when, say, just 35% of us voted. In such
>> case it would be easier for those of us who disagree to claim the decision
>> doesn't really represent the views of the greater core team.
>>
>> - Ł
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
The PSF uses a good voting system where votes are secret. I see no reason not
to reuse this infra.
--
Best regards,
Łukasz Langa
> On Jul 18, 2018, at 5:26 PM, Antoine Pitrou wrote:
>
>
> By the way, should the vote be public or secret?
> For such an important (and sensitive) matter, perhaps it would be wise
> for it to be secret.
>
> Regards
>
> Antoine.
>
>
>> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>>
>>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
>>>
>>> While I am totally fine with a super-majority of votes for something to be
>>> accepted, I don't think the minimum participation requirement will work. If
>>> people simply choose not to vote then they choose not to (we have no way to
>>> really compel people to vote).
>>
>> It could be easily added to the list of things expected from a core
>> contributor. It's not like this is a laborious chore, neither is it
>> happening often. There are countries where voting is mandatory.
>>
>> Taking a step back, there are two reasons I stress the importance of
>> (almost) everybody voicing their support:
>> - this makes the decision authoritative ("the committers have spoken");
>> - this ensures that we haven't omitted somebody due to poor timing ("I was
>> on a sabbatical and couldn't vote").
>>
>> If you feel like this is unrealistic because most of our committers aren't
>> currently active, I hear you. But what I like even less is claiming that
>> "we, the core team" made a decision when, say, just 35% of us voted. In such
>> case it would be easier for those of us who disagree to claim the decision
>> doesn't really represent the views of the greater core team.
>>
>> - Ł
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
By the way, should the vote be public or secret?
For such an important (and sensitive) matter, perhaps it would be wise
for it to be secret.
Regards
Antoine.
Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>
>> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
>>
>> While I am totally fine with a super-majority of votes for something to be
>> accepted, I don't think the minimum participation requirement will work. If
>> people simply choose not to vote then they choose not to (we have no way to
>> really compel people to vote).
>
> It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it happening
> often. There are countries where voting is mandatory.
>
> Taking a step back, there are two reasons I stress the importance of (almost)
> everybody voicing their support:
> - this makes the decision authoritative ("the committers have spoken");
> - this ensures that we haven't omitted somebody due to poor timing ("I was on
> a sabbatical and couldn't vote").
>
> If you feel like this is unrealistic because most of our committers aren't
> currently active, I hear you. But what I like even less is claiming that "we,
> the core team" made a decision when, say, just 35% of us voted. In such case
> it would be easier for those of us who disagree to claim the decision doesn't
> really represent the views of the greater core team.
>
> - Ł
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
>
> While I am totally fine with a super-majority of votes for something to be
> accepted, I don't think the minimum participation requirement will work. If
> people simply choose not to vote then they choose not to (we have no way to
> really compel people to vote).
It could be easily added to the list of things expected from a core
contributor. It's not like this is a laborious chore, neither is it happening
often. There are countries where voting is mandatory.
Taking a step back, there are two reasons I stress the importance of (almost)
everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a
sabbatical and couldn't vote").
If you feel like this is unrealistic because most of our committers aren't
currently active, I hear you. But what I like even less is claiming that "we,
the core team" made a decision when, say, just 35% of us voted. In such case it
would be easier for those of us who disagree to claim the decision doesn't
really represent the views of the greater core team.
- Ł
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
