[python-committers] Re: Please make sure you're following good security practices with your GitHub account

[Donald Stufft]

> On Jun 14, 2021, at 5:27 PM, Tim Peters  wrote:
> 
> [Donald Stufft ]
>> You can a Yubikey for like $15? or so and use that for best in class 2fa.
>> 
>> You can also get an app for your desktop PC that can do TOTP codes
>> (1Password has it built in, I’ve never used any of these applications
>> though).
> 
> Thanks!  Alas, it's all utter gibberish to me.  I'm going to ignore
> this until GIthub refuses to talk to me ;-)
> 
> Their docs say "After you configure 2FA using a mobile app or via text
> message ...", neither of which I can do. If "Yubikey" requires some
> other kind of setup. their docs don't mention it.

The desktop apps I spoke of work instead of a Mobile app. 

I’ve never used these, but some googling suggests

https://www.microsoft.com/en-us/p/2-factor-authenticator/9nblggh5k7jn?activetab=pivot:overviewtab
 
<https://www.microsoft.com/en-us/p/2-factor-authenticator/9nblggh5k7jn?activetab=pivot:overviewtab>

Or 

https://www.microsoft.com/en-us/p/winotp-authenticator/9nf2rgqkx1mv?activetab=pivot:overviewtab
 
<https://www.microsoft.com/en-us/p/winotp-authenticator/9nf2rgqkx1mv?activetab=pivot:overviewtab>


Might work if you’re on windows. 

There’s some for every OS though.

> 
> yubico.com lists a ballfing variety of devices, from $24.50 to $90.00.
> If I buy one and plug it in, and that's the end of it, fine by me -
> happy to eat the cost. But I'm not keen to waste time wrestling with
> anything :-(

Sorry, the standard is called webauthn (or sometimes FIDO or U2F), and
yubikey is just the biggest supplier of them. Some information here:

https://github.blog/2019-08-21-github-supports-webauthn-for-security-keys/ 
<https://github.blog/2019-08-21-github-supports-webauthn-for-security-keys/>

 
I guess they’re more expensive than I last remembered them being. It’s been
a few years since I bought mine (or I got it on sale, I don’t remember’j. 
There’s
a review of some of the security keys available at

https://www.theverge.com/2019/2/22/18235173/the-best-hardware-security-keys-yubico-titan-key-u2f
 
<https://www.theverge.com/2019/2/22/18235173/the-best-hardware-security-keys-yubico-titan-key-u2f>

Or if you like wire cutter:

https://www.nytimes.com/wirecutter/reviews/best-security-keys/ 
<https://www.nytimes.com/wirecutter/reviews/best-security-keys/>


___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SDW2VO22ASDSVHWEJOUREQ6V7TFUEBCF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please make sure you're following good security practices with your GitHub account

[Donald Stufft]

> On Jun 14, 2021, at 5:02 PM, Tim Peters  wrote:
> 
> [Brett]
>> ...
>> Please make sure you have a unique password for your GitHub account
>> and that you have 2FA/MFA turned on (I honestly think we should start
>> requiring this ...
> 
> I use 2FA on sites that cater to my reality ;-) That is, I don't have
> a smartphone, or a cell phone of any kind, or any device capable of
> scanning QR codes, or, as far as I know, capable of receiving SMS msgs
> (unless there's some way of tricking a desktop PC into doing so).
> 
> In its infinite wisdom, the US Social Security system started
> requiring stuff like the above for recipients to log in to their SS
> web accounts. Which was a disaster. While they should have known this
> in advance, I'm not the only US senior content to live with a desktop
> PC and a landline ;-)
> 
> SS soon changed to send a "security code" to your account's registered
> email address instead. That works fine. Several other sites do the
> same. My bank has an automated system that calls my (landline) phone
> number, and a computer-generated voice tells me a one-time security
> code for me to type in. Also fine.
> 
> But reading the Github 2FA docs, they don't _appear_ to offer any
> method I could use. Things "I have" are a desktop PC, an email
> address, and a landline phone number. That's it.
> ___


You can a Yubikey for like $15? or so and use that for best in class 2fa.

You can also get an app for your desktop PC that can do TOTP codes (1Password 
has it built in, I’ve never used any of these applications though).

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/3OYGIZB3FYOT55FR34MKMU6QSCTMNQZA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Donald Stufft]

> On Jul 23, 2020, at 3:52 AM, Matthias Klose  wrote:
> 
> Apparently there was agreement to hide this kind of information, and that's
> worse than the original behavior that was acted on. Who will be next? For what
> reason?  I am not questioning the decision, at least we voted for our 
> delegates,
> so I have to respect that decision even if I would disagree.  If you don't 
> want
> to communicate in public, then email committers separately, or create a 
> private
> ML for committers.


I don’t think it’s unreasonable to allow the core developer the chance to come 
back in 3 months without all of their “colleagues” (for lack of a better word), 
knowing they’ve had disciplinary action taken against them. ___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TMYSNCP24BIEZQAUMLUPWTSWGZ72YHE3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 2019 Steering Council Election Results

[Donald Stufft]

Did voting require you to select 5 candidates? Or was it up to 5? I don’t 
recall, but if it was the latter that could explain it.

> On Feb 4, 2019, at 11:28 AM, Tim Peters  wrote:
> 
> [Ernest W. Durbin III ]
>> Of 96 eligible voters, 69 cast ballots.
> 
> FYI, the total number of votes Helios showed me summed to 340.  At 5
> approvals per ballot, I'd expect to see 5 * 69 = 345 for 69 ballots.
> Are we missing a 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/

___
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] IMPORTANT: Missing Email Addresses for Governance Election Voter Roll

[Donald Stufft]

> On Nov 6, 2018, at 5:14 AM, Nick Coghlan  wrote:
> 
> On Tue, 6 Nov 2018 at 08:17, Donald Stufft  <mailto:don...@stufft.io>> wrote:
>> 
>> We need a list of core developers email addresses to send ballot emails to. 
>> Since PEP 8001 states that we’re using inclusion in the ``python-core`` team 
>> on GitHub as the list of “registered voters”, I wrote up a quick script that 
>> compiled a list of GitHub usernames in that team *today* and any public 
>> email address on their GitHub profile if there is one.
>> 
>> That is located at https://github.com/python/voters (specifically the 
>> 2018-11-16-governance-election.csv file), which is a private repository.
>> 
>> Please everyone take a moment to find your GitHub username in that file 
>> (it’s in alphabetical order) and ensure that the email address there is a 
>> good email for you to send your ballot to. If it’s wrong or missing, update 
>> the CSV file (there is a .voters.csv file that will taken into effect for 
>> any future voter rolls we may generate from this script).
>> 
>> If you’re not a member of the python-core team on Github and you want to 
>> participate in the vote, please ask to be added to that team, then add 
>> yourself to the 2018-11-16-governance-election.csv file.
>> 
>> We particularly need the following people (GitHub usernames) to go fill in 
>> their email addresses, as we do not currently have an email address for 
>> them, and without an email address, we cannot send you a ballot.
> 
> You should have email addresses for us, they're just in
> bugs.python.org <http://bugs.python.org/> (which is necessarily linked on 
> GitHub usernames, as
> otherwise the CLA check wouldn't pass).
> 

If roundup has an API, feel free to submit a PR to generate-voter-roll.py in 
that same repository to have it pull from bugs.p.o as well. I already knew 
GitHub’s API so it was easy to spend 15 minutes tossing something together that 
would work. Clicking on the “tracker documentation” link doesn’t mention an API 
at all.

If there’s no API, well there was 40 names, even if I spent 5 minutes each 
doing it manually, that’s still like 3+ hours of clicking through bugs.p.o 
trying to converge the two lists, and I don’t have 3+ hours to burn at the 
moment, so I figured it was easier to ask each of those 40 people to spend 5  
minutes individually.

Sorry if you don’t feel that’s sufficient. I’m short on time leading up to 
Re:invent and trying to do the best I can with what time I can steal from 
elsewhere.

___
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] IMPORTANT: Missing Email Addresses for Governance Election Voter Roll

[Donald Stufft]

We need a list of core developers email addresses to send ballot emails to. 
Since PEP 8001 states that we’re using inclusion in the ``python-core`` team on 
GitHub as the list of “registered voters”, I wrote up a quick script that 
compiled a list of GitHub usernames in that team *today* and any public email 
address on their GitHub profile if there is one.

That is located at https://github.com/python/voters 
 (specifically the 
2018-11-16-governance-election.csv file), which is a private repository.

Please everyone take a moment to find your GitHub username in that file (it’s 
in alphabetical order) and ensure that the email address there is a good email 
for you to send your ballot to. If it’s wrong or missing, update the CSV file 
(there is a .voters.csv file that will taken into effect for any future voter 
rolls we may generate from this script).

If you’re not a member of the python-core team on Github and you want to 
participate in the vote, please ask to be added to that team, then add yourself 
to the 2018-11-16-governance-election.csv file.

We particularly need the following people (GitHub usernames) to go fill in 
their email addresses, as we do not currently have an email address for them, 
and without an email address, we cannot send you a ballot.

- [ ] @abalkin
- [ ] @akuchling
- [ ] @aleaxit
- [ ] @amauryfa
- [ ] @applio
- [ ] @avassalotti
- [ ] @brettcannon
- [ ] @doerwalter
- [ ] @doko42
- [ ] @eliben
- [ ] @ericsnowcurrently
- [ ] @ericvsmith
- [ ] @ezio-melotti
- [ ] @facundobatista
- [ ] @ilevkivskyi
- [ ] @jcea
- [ ] @jeremyhylton
- [ ] @larryhastings
- [ ] @lisroach
- [ ] @malemburg
- [ ] @Mariatta
- [ ] @markshannon
- [ ] @methane
- [ ] @mhammond
- [ ] @nascheme
- [ ] @ncoghlan
- [ ] @ned-deily
- [ ] @pfmoore
- [ ] @pitrou
- [ ] @pjenvey
- [ ] @rbtcollins
- [ ] @rhettinger
- [ ] @sandrotosi
- [ ] @serhiy-storchaka
- [ ] @sjoerdmullender
- [ ] @skrah
- [ ] @stevendaprano
- [ ] @taleinat
- [ ] @vadmium
- [ ] @willingc

This list of people is also available on Github at 
https://github.com/python/voters/issues/1 
 (primarily so people would get a 
GitHub notification as well).

Thanks!


___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 5, 2018, at 2:29 PM, Paul Moore  wrote:
> 
> Hmm, so voting opens immediately after the PEPs are finalised? No
> discussion/debate period before that? Maybe I misunderstood, I'd
> assumed that this would be more similar to an election process, with a
> period of canvassing support and/or debating the strengths and
> weaknesses of the proposals, leading up to a vote.


I don’t think there is anything stopping people from doing that right now (and 
honestly, right now seems like the *right* time to do that if it’s going to 
happen, so that the proposals can evolve based on any discussion that comes out 
of that). Waiting until the proposals are set in stone seems like a less useful 
implementation of that idea.

I suspect the reason that people aren’t doing that, is just nobody has started 
that discussion for one reason or another.___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 4, 2018, at 1:52 AM, Donald Stufft  wrote:
> 
>> 
>> On Nov 3, 2018, at 11:56 PM, Tim Peters > <mailto:tim.pet...@gmail.com>> wrote:
>> 
>> [Donald Stufft mailto:don...@stufft.io>>]
>>> So to avoid just complaining without an actionable suggestion, here’s a 
>>> suggestion:
>>> 
>>> Use https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> with the 
>>> following settings (x in the ones turned on):
>> 
>> Presumably someone is "running" this election, but I don't know who.
>> Do we believe they're paying attention to this list?  Or are they
>> focused on the Discourse site now?:  I'd hate to see this possibility
>> get lost:
> 
> I’ll mirror this over to discourse in a bit, or maybe tomorrow.


https://discuss.python.org/t/pep-8001-public-or-private-ballots/374___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 11:56 PM, Tim Peters  wrote:
> 
> [Donald Stufft ]
>> So to avoid just complaining without an actionable suggestion, here’s a 
>> suggestion:
>> 
>> Use https://civs.cs.cornell.edu with the following settings (x in the ones 
>> turned on):
> 
> Presumably someone is "running" this election, but I don't know who.
> Do we believe they're paying attention to this list?  Or are they
> focused on the Discourse site now?:  I'd hate to see this possibility
> get lost:

I’ll mirror this over to discourse in a bit, or maybe tomorrow.

> 
>> ...
>> - The results are computed, although none of the options are for “pure” 
>> condorcet,
>> we can use the CSV format to compute it how we like to verify that there was 
>> a
>> pure condorcet winner.
> 
> The test poll you constructed didn't have a Condorcet winner.  Looking
> at other public polls on that site, I noticed that when there _was_ a
> Condorcet winner, the results page said
> 
>(Condorcet winner: wins contests with all other choices)
> 
> next to the winning candidate.  Given that the results page also gives
> a color-coded matrix of pairwise preference counts, verifying this is
> trivial by eyeball (the winning candidate is in the top row, and is a
> Condorcet winner if and only if all the cells in the top row are
> colored green (excluding the extreme northwest cell, which is always
> blank) - which means the top-row candidate outright won against every
> other candidate - which is what "pure Condorcet winner" means).

You’re right. I simulated an election without a Condorcet winner, but where the 
voting mechanisms would otherwise select a winner (just using the example from 
the Schulze Wikipedia page), it says "(Not defeated in any contest vs. another 
choice)”, instead. An example can be found at: 
https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath
 
<https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath>.

Just for kicks I added enough ballots so that there would be a Condorcet 
winner, and I verified that the above is true, and an example can be found at 
https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath
 
<https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath>.

So that means if we go with it, we can let CIVS tally for us and we’ll just 
look for a Condorcet winner instead of another kind of winner. Of course since 
all of the anonymized ballots are public, people are free to compute it 
themselves as well.

> 
>> - As a downside, the list of people who voted are *not* made public (it
>> considers not participating at all to be something that deserves secret
>> as well).
> 
> Indeed, it appears that even the election supervisor has no way to
> find out who did and didn't vote.  Although, from the Security page:
> 
> """
> The election supervisor can determine whether a voter has voted only
> with the permission of the voter and only after the election has
> ended.
> “""

Maybe they mean that if you contact them they can look that information up? I’m 
looking and I don’t see any UI that lets me do that, so either it’s not 
implemented, it was removed, I’m missing it, or it requires contacting them.

> 
> 
>> - It doesn’t require you to make a total ranking of all the options (it 
>> allows you to
>> rank some items equal). This is fine with Condorcet (it just means a cycle is
>> more likely).
> 
> We can worry about that when it doesn't happen anyway ;-)

It can also optionally let people pick no opinion, though I’m not sure of the 
utility of that. It basically means, as I understand it, that in any pairwise 
contest that includes a option you had no opinion on, your ballot would just 
not be included. The FAQ on this says:


What does “no opinion” mean? It means you are providing no information about 
how this choice ranks with respect to the other choices. For example, if you 
give one choice the rank 1, and give all other choices the rank “no opinion”, 
your ballot becomes useless because it doesn't express any preferences. Voters 
often pick “no opinion” when what they mean is that they don't like the choice 
or that they don't have any information about it. In these situations, it is 
often better to give the choice a low rank rather than to select “no opinion”. 
A good reason for a voter to give a choice the rank “no opinion” is because the 
voter isn't supposed to express an opinion about that choice.

It sounds to me like no opinion is a bit of a footgun here, so

Re: [python-committers] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 8:41 PM, Donald Stufft  wrote:
> 
> As far as I am aware there is a topic per PEP on discourse that has had 
> discussion mostly related to the specific PEP. I’m not aware of any general 
> “weighing the options” topic on any discussion forum.  I think so far it’s 
> mostly just been people asking for refinements or changes to a specific PEP 
> to make it more clear and/or more tolerable to that person. 
> 


Incase unfamiliarity with discourse is causing an issue in people finding the 
topics, and that’s what folks are stumbling with, here are links to each of the 
PEP specific topics:

- PEP 8010 - The Singular Leader - 
https://discuss.python.org/t/pep-8010-the-singular-leader/188 
<https://discuss.python.org/t/pep-8010-the-singular-leader/188>
- PEP 8011 - Leadership by a Trio of Pythonistas - 
https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199
 
<https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199>
- PEP 8012 - The Community Model - 
https://discuss.python.org/t/pep-8012-the-community-model/156 
<https://discuss.python.org/t/pep-8012-the-community-model/156>
- PEP 8013 - The External Council Model - 
https://discuss.python.org/t/pep-8013-the-external-council-governance-model/181 
<https://discuss.python.org/t/pep-8013-the-external-council-governance-model/181>
- PEP 8014 - The Commons Model - 
https://discuss.python.org/t/pep-8014-the-commons-model/173 
<https://discuss.python.org/t/pep-8014-the-commons-model/173>
- PEP 8015 - “Organization of the Python Community” - 
https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193 
<https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193>
 
There is also a draft PEP, PEP 8016 - “The boringest possible steering 
committee model” - which is more of a proto-PEP at the moment, but discussion 
about it can be located at 
https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333
 
<https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333>.

Each thread seems to have somewhere between 30-50 total posts, so all in 
there’s maybe ~300 posts to read across all of them (and many of those posts 
are pretty short). 

___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 8:21 PM, Steven D'Aprano  wrote:
> 
> 
>> how can I trust that the decision will be one I can be comfortable 
>> with - and how do I influence the direction except by participating in 
>> the discussions I've been unable to locate?
> 
> That's a reasonable question. I wish I had a better answer, but I too
> have found it exceedingly hard to locate discussions. I know there has 
> been some here, and some on Discourse (which I find hard to navigate, 
> perhaps because of unfamiliarity).

As far as I am aware there is a topic per PEP on discourse that has had 
discussion mostly related to the specific PEP. I’m not aware of any general 
“weighing the options” topic on any discussion forum.  I think so far it’s 
mostly just been people asking for refinements or changes to a specific PEP to 
make it more clear and/or more tolerable to that person. 

I think maybe the idea of voting itself has stifled some of the back and forth 
between options though I could be wrong about that. I’m not sure that I would 
personally find much benefit in a general thread on the various options. I 
think understand them well enough and I have my opinions on the suitability of 
each. I don’t feel like there’s much more to be said that would benefit me. If 
you (or anyone) feels like a general thread would be useful— then I would 
encourage you to start one and see what sort of discussion happens.
___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 4:45 PM, Donald Stufft  wrote:
> 
> 
> 
> 
> One thing we need if we do go this route, is a single person to act as the 
> election supervisor. Their powers are limited basically they configure the 
> election, adding a description, the choices, etc and then they have the power 
> to start the election, add voters via email addresses, and then end the 
> election. All of these are manual action items, but the system automatically 
> generates result emails and voter emails and such.
> 
> So if we go this route, we’d have to pick that person. I poked Ernest Durbin 
> to see if he’d be willing to do that. I figure we’d make a good candidate for 
> election supervisor (again, if we go that route) since he’s a PSF employee, 
> he’s well known enough in the community and generally trusted (he has root on 
> all the boxes pretty much, so he can do a lot of damage if he wanted) and 
> he’s not a core developer, so he’s about as close to a trusted, but neutral 
> party as we’re likely to find. He said he’d absolutely be willing to handle 
> that if we want.
> 



Here is a PR that implements this https://github.com/python/peps/pull/830 
<https://github.com/python/peps/pull/830>. Not going to merge it myself, just 
figured I’d offer it as an alternative option.

___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 3:09 PM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 2:06 PM, Barry Warsaw > <mailto:ba...@python.org>> wrote:
>> 
>> I also prefer private ballots on principle, but I’ll still vote if they are 
>> public.  I don’t completely buy into the rationale in PEP 8001 on why they 
>> must be public.
> 
> 
> So to avoid just complaining without an actionable suggestion, here’s a 
> suggestion:
> 
> Use https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> with the 
> following settings (x in the ones turned on):
> 
> [x] Private
> [ ] Make this a test poll: read all votes from a file.
> [ ] Do not release results to all voters.
> [x] Enable detailed ballot reporting.
> [ ] In detailed ballot report, also reveal the identity of the voter with 
> each ballot.
> [ ] Allow voters to write in new choices.
> [ ] Present choices on voting page in exactly the given order.
> [ ] Allow voters to select “no opinion” for some choices.
> [ ] Enforce proportional representation
> 
> 
> This best represents the current behavior, while moving us to use a secret 
> ballot. Voting in this system looks like an email like 
> https://s.caremad.io/9i63IkqBppKMudh/ <https://s.caremad.io/9i63IkqBppKMudh/> 
> which includes in it a link to vote. Going to that link gives you a page like 
> https://s.caremad.io/TDQWB0wv4FDx3I9/ 
> <https://s.caremad.io/TDQWB0wv4FDx3I9/>. Which has some Ui affordances for 
> dragging/dropping to re-order or to allow you to use a drop down to select 
> your winner.  Once you submit your vote, you’re given a page like 
> https://s.caremad.io/HszGnDfDJQ725YX/ 
> <https://s.caremad.io/HszGnDfDJQ725YX/>. Once the election is over, the 
> results are available and look like https://s.caremad.io/4Wcy5InXoLjV7MU/ 
> <https://s.caremad.io/4Wcy5InXoLjV7MU/> (after you click a button to see more 
> results).
> 
> This has the following properties:
> 
> - People’s identities are kept secret.
>   - This assume that the people running that online system are discarding the 
> votes like they claim to be. I don’t think they’re likely to be lying and 
> it’s a popular online service so they’re unlikely to do anything about it.
> - The actual ballots are public, and available to be viewed and even 
> downloaded in CSV format.
> - The results are computed, although none of the options are for “pure” 
> condorcet, we can use the CSV format to compute it how we like to verify that 
> there was a pure condorcet winner.
> - As a downside, the list of people who voted are *not* made public (it 
> considers not participating at all to be something that deserves secret as 
> well).
> - As an upside, it will randomize the order ballots are in by default, and 
> there is science/evidence to suggest that when ballots are in the same order 
> for everyone, that items closer to the top of the ballot are more likely to 
> win. Randomizing ballot order helps with this.
> - It doesn’t require you to make a total ranking of all the options (it 
> allows you to rank some items equal). This is fine with Condorcet (it just 
> means a cycle is more likely). 
> - A single person has to act as the election administrator, which basically 
> only gives the power to start/stop the election and to add voters (you can’t 
> add the same email address twice, doing so just re-sends the email to that 
> person).



One thing we need if we do go this route, is a single person to act as the 
election supervisor. Their powers are limited basically they configure the 
election, adding a description, the choices, etc and then they have the power 
to start the election, add voters via email addresses, and then end the 
election. All of these are manual action items, but the system automatically 
generates result emails and voter emails and such.

So if we go this route, we’d have to pick that person. I poked Ernest Durbin to 
see if he’d be willing to do that. I figure we’d make a good candidate for 
election supervisor (again, if we go that route) since he’s a PSF employee, 
he’s well known enough in the community and generally trusted (he has root on 
all the boxes pretty much, so he can do a lot of damage if he wanted) and he’s 
not a core developer, so he’s about as close to a trusted, but neutral party as 
we’re likely to find. He said he’d absolutely be willing to handle that if we 
want.



___
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] [OT] email clients

[Donald Stufft]

> On Nov 3, 2018, at 3:27 PM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 3:19 PM, Donald Stufft > <mailto:don...@stufft.io>> wrote:
>> 
>> 
>> 
>>> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou >> <mailto:anto...@python.org>> wrote:
>>> 
>>> 
>>> Le 03/11/2018 à 20:15, Donald Stufft a écrit :
>>>> 
>>>> I’m the other way. I basically don’t participate in python-dev or 
>>>> python-ideas anymore because of the issues mailing lists have.
>>> 
>>> Just a question: which tool do you use to participate in distutils-sig
>>> discussions, then?
>>> 
>> 
>> It’s the only mailing list (well besides this one, but this one only because 
>> it’s low traffic enough normally I didn’t filter it out into a folder to 
>> ignore) I still actively participate in. Even there I’ve been consciously 
>> pushing more of my own traffic to GitHub, or avoiding doing things that 
>> would require discussion on distutils-sig instead working on things that I 
>> could discuss entirely on GitHub.
>> 
>> My experience with the Governance discussion lead me to post 
>> https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/
>>  
>> <https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/>
>>  last night, so I’m pulling myself generally out of distutils-sig as well.
>> 
> 
> 
> Oh yea, and I forgot to mention that I’ve been trying to advocate for pulling 
> the packaging tools out of the PEP process and into our own process, ideally 
> based on GitHub or Discourse or anything with modern UI affordances. That’s 
> not entirely due to the pain of mailing lists, but that’s part of it.
> 
> 

One last bit! 

I don’t mean to suggest that my participation is make or break for these lists. 
If I was the only one who felt this way, then I think it would be fair to say 
that I’m in the minority and while we want to encourage everyone, we can’t 
please everyone. I was merely trying to express that the choice isn’t move from 
mailing list to discourse and maybe exclude some people, or stay on mailing 
lists and exclude nobody. Either choice is going to be excluding some people.

___
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] [OT] email clients

[Donald Stufft]

> On Nov 3, 2018, at 3:19 PM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou > <mailto:anto...@python.org>> wrote:
>> 
>> 
>> Le 03/11/2018 à 20:15, Donald Stufft a écrit :
>>> 
>>> I’m the other way. I basically don’t participate in python-dev or 
>>> python-ideas anymore because of the issues mailing lists have.
>> 
>> Just a question: which tool do you use to participate in distutils-sig
>> discussions, then?
>> 
> 
> It’s the only mailing list (well besides this one, but this one only because 
> it’s low traffic enough normally I didn’t filter it out into a folder to 
> ignore) I still actively participate in. Even there I’ve been consciously 
> pushing more of my own traffic to GitHub, or avoiding doing things that would 
> require discussion on distutils-sig instead working on things that I could 
> discuss entirely on GitHub.
> 
> My experience with the Governance discussion lead me to post 
> https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/
>  
> <https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/>
>  last night, so I’m pulling myself generally out of distutils-sig as well.
> 


Oh yea, and I forgot to mention that I’ve been trying to advocate for pulling 
the packaging tools out of the PEP process and into our own process, ideally 
based on GitHub or Discourse or anything with modern UI affordances. That’s not 
entirely due to the pain of mailing lists, but that’s part of it.

___
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] [OT] email clients

[Donald Stufft]

> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou  wrote:
> 
> 
> Le 03/11/2018 à 20:15, Donald Stufft a écrit :
>> 
>> I’m the other way. I basically don’t participate in python-dev or 
>> python-ideas anymore because of the issues mailing lists have.
> 
> Just a question: which tool do you use to participate in distutils-sig
> discussions, then?
> 

It’s the only mailing list (well besides this one, but this one only because 
it’s low traffic enough normally I didn’t filter it out into a folder to 
ignore) I still actively participate in. Even there I’ve been consciously 
pushing more of my own traffic to GitHub, or avoiding doing things that would 
require discussion on distutils-sig instead working on things that I could 
discuss entirely on GitHub.

My experience with the Governance discussion lead me to post 
https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/
 
<https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/>
 last night, so I’m pulling myself generally out of distutils-sig as well.

___
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] [OT] email clients

[Donald Stufft]

> On Nov 3, 2018, at 3:04 PM, Ethan Furman  wrote:
> 
> On 11/03/2018 11:45 AM, Donald Stufft wrote:
> 
>> I would agree *if* that was the only axis that the two tools differed on.
> 
> It's enough for me.  My participation on Discourse is going to be so low you 
> might think I went emeritus. :/
> 
>> (Un)fortunately there is a laundry list of improvements over the traditional 
>> mailing list
> 
> Which are all irrelevant if we don't use the tool itself.  It's like my wife 
> wanting to reduce my sodium intake by buying reduced-sodium peanut butter -- 
> it worked!  I don't eat that peanut butter.  ;)
> 


I’m the other way. I basically don’t participate in python-dev or python-ideas 
anymore because of the issues mailing lists have. At best I occasionally peek 
at them, but I even do that so rarely any more because even when I find 
something I want to participate in, knowing how painful participation is going 
to be is enough to make me decide not to typically.

There’s also a bit of a confirmation bias here of course. The people who would 
have otherwise contributed to discussion but decided not to because the UI 
afforded provided by mailing lists are bad enough for them personally to not 
make it worth it, are unlikely going to be here discussion their preferences. 
So we’re a self selected group who are at least willing to tolerate mailing 
lists to some degree, but there’s a reasonable chance that we’re excluding 
otherwise valuable contributors who simply don’t want to deal with mailing 
lists.

I would posit that pretty much any choice we make here, including *not* making 
a choice is going to exclude some subset of population— even the population of 
people currently “here”. Thus the big question is which options are going to 
lose the fewest people and (ideally) contribute the least to burn out. I know 
for me personally, the python mailing lists are a non trivial amount of the 
source of burn out for me, and the only way I’ve managed to stay active in the 
community at all is by ignoring as many of our communities mailing lists as 
possible.

___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 2:06 PM, Barry Warsaw  wrote:
> 
> I also prefer private ballots on principle, but I’ll still vote if they are 
> public.  I don’t completely buy into the rationale in PEP 8001 on why they 
> must be public.


So to avoid just complaining without an actionable suggestion, here’s a 
suggestion:

Use https://civs.cs.cornell.edu with the following settings (x in the ones 
turned on):

[x] Private
[ ] Make this a test poll: read all votes from a file.
[ ] Do not release results to all voters.
[x] Enable detailed ballot reporting.
[ ] In detailed ballot report, also reveal the identity of the voter with each 
ballot.
[ ] Allow voters to write in new choices.
[ ] Present choices on voting page in exactly the given order.
[ ] Allow voters to select “no opinion” for some choices.
[ ] Enforce proportional representation


This best represents the current behavior, while moving us to use a secret 
ballot. Voting in this system looks like an email like 
https://s.caremad.io/9i63IkqBppKMudh/  
which includes in it a link to vote. Going to that link gives you a page like 
https://s.caremad.io/TDQWB0wv4FDx3I9/ . 
Which has some Ui affordances for dragging/dropping to re-order or to allow you 
to use a drop down to select your winner.  Once you submit your vote, you’re 
given a page like https://s.caremad.io/HszGnDfDJQ725YX/ 
. Once the election is over, the results 
are available and look like https://s.caremad.io/4Wcy5InXoLjV7MU/ 
 (after you click a button to see more 
results).

This has the following properties:

- People’s identities are kept secret.
  - This assume that the people running that online system are discarding the 
votes like they claim to be. I don’t think they’re likely to be lying and it’s 
a popular online service so they’re unlikely to do anything about it.
- The actual ballots are public, and available to be viewed and even downloaded 
in CSV format.
- The results are computed, although none of the options are for “pure” 
condorcet, we can use the CSV format to compute it how we like to verify that 
there was a pure condorcet winner.
- As a downside, the list of people who voted are *not* made public (it 
considers not participating at all to be something that deserves secret as 
well).
- As an upside, it will randomize the order ballots are in by default, and 
there is science/evidence to suggest that when ballots are in the same order 
for everyone, that items closer to the top of the ballot are more likely to 
win. Randomizing ballot order helps with this.
- It doesn’t require you to make a total ranking of all the options (it allows 
you to rank some items equal). This is fine with Condorcet (it just means a 
cycle is more likely). 
- A single person has to act as the election administrator, which basically 
only gives the power to start/stop the election and to add voters (you can’t 
add the same email address twice, doing so just re-sends the email to that 
person).___
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] [OT] email clients

[Donald Stufft]

> On Nov 3, 2018, at 1:57 PM, Antoine Pitrou  wrote:
> 
> I find it interesting that you are so disturbed by threaded discussion
> views, while for some other people it's the reverse.  That advocates for
> a system that allows both kinds of presentation, and Discourse isn't that.

I would agree *if* that was the only axis that the two tools differed on. 
(Un)fortunately there is a laundry list of improvements over the traditional 
mailing list this is available in modern mechanisms for facilitating discussion 
that mailing lists lack. Even something as simple as being able to decide on a 
topic by topic basis whether you want to receive emails on that topic. 
Unfortunately it’s hard to impossible to retrofit these items onto email, 
because email has a lowest common denominator problem where you can’t 
meaningfully improve it, because you can’t break support with the huge 
deployment base of every mail client ever.

If there were a system that offered even most of the benefits, but allowed 
someone switching between tree view and flat view, I’d be all for it. However 
all of the modern systems I’m aware of only allow one or the other.

To be honest, I’m not even sure how you’d represent some of these things in a 
threaded view. For instance within discourse I can multi quote different posts 
to tie multiple lines of discussion together. How would you present that in a 
threaded view? A merge? I’m not aware of any threaded system that actually 
allows it.___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 1:42 PM, Antoine Pitrou  wrote:
> 
>> Perhaps the difference is in that every mail client I’ve ever used
>> presents mailing list threads (or any thread) as a singular flat stream
>> anyways?
> 
> Er, really?  Generally they give you an option to turn on or off
> threaded display.  And that in itself is a huge advantage: you can
> change the setting at will, depending on your preference.  Often you can
> even do so on a per-folder or per-account basis (at least with
> Thunderbird you do).


GMail’s webmail and Mail.app are really the only two mail clients I’ve used in 
the past decade or so to be honest. I think I used thunderbird for a few weeks 
when I was a teenager but I honestly don’t even remember anything about it (and 
I barely got any email back then so I think I just used the default).

TBH I find threaded views nonsensical in every medium I’ve ever seen them in, 
even things like Reddit or the such feel really poor to me. Either the 
threading is so in your face that the same points end up getting repeated at 
different sub threads, or the threading is so minimal that people are replying 
to things cross sub-thread and treating it like a “flat” discussion.___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 1:24 PM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 11:22 AM, Antoine Pitrou  wrote:
>> 
>> 
>> Le 03/11/2018 à 16:19, Stefan Krah a écrit :
>>> On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
>>>> On 11/03/2018 03:55 AM, Paul Moore wrote:
>>>> 
>>>>> Frankly, I feel pretty disenfranchised by the process
>>>>> at the moment.
>>>> 
>>>> +1
>>> 
>>> I wouldn't go as far as disenfranchised, but just this thread made it clear
>>> to me that taking in information is at least 10x faster if presented on a
>>> mailing list.
>>> 
>>> Discourse feels like eating soup with a fork, especially now that the
>>> volume is higher.
>> 
>> Indeed.  As soon as a discussion is starting to become branchy,
>> Discourse just ruins readability compared to a normal threaded
>> discussion system.  The electoral system discussion is an example of that:
>> https://discuss.python.org/t/python-governance-electoral-system/290
>> 
> 
> Huh, I found the experience exactly the opposite. I was just remarking last 
> night how glad I was that the discussion happened in discourse instead of on 
> the mailing list, because of how poorly I felt the discussion would have gone 
> on a mailing list. The ability to trivially multi quote alone was a drastic 
> improvement, much less the ability to control, on a topic by topic basis, 
> what level of notification I wanted for that topic.
> 


Perhaps the difference is in that every mail client I’ve ever used presents 
mailing list threads (or any thread) as a singular flat stream anyways? To be 
honest, I find the threaded views on like hyper kitty or piper mail to be 
abysmal anyways :|

___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 11:22 AM, Antoine Pitrou  wrote:
> 
> 
> Le 03/11/2018 à 16:19, Stefan Krah a écrit :
>> On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
>>> On 11/03/2018 03:55 AM, Paul Moore wrote:
>>> 
 Frankly, I feel pretty disenfranchised by the process
 at the moment.
>>> 
>>> +1
>> 
>> I wouldn't go as far as disenfranchised, but just this thread made it clear
>> to me that taking in information is at least 10x faster if presented on a
>> mailing list.
>> 
>> Discourse feels like eating soup with a fork, especially now that the
>> volume is higher.
> 
> Indeed.  As soon as a discussion is starting to become branchy,
> Discourse just ruins readability compared to a normal threaded
> discussion system.  The electoral system discussion is an example of that:
> https://discuss.python.org/t/python-governance-electoral-system/290
> 

Huh, I found the experience exactly the opposite. I was just remarking last 
night how glad I was that the discussion happened in discourse instead of on 
the mailing list, because of how poorly I felt the discussion would have gone 
on a mailing list. The ability to trivially multi quote alone was a drastic 
improvement, much less the ability to control, on a topic by topic basis, what 
level of notification I wanted for that topic.

___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 12:38 AM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 12:20 AM, Tim Peters > <mailto:tim.pet...@gmail.com>> wrote:
>> 
>> [Tim]
>>>> Nevertheless, I probably won't vote - I object to public ballots on
>>>> principle.  That's been raised by others, so I won't repeat the
>>>> arguments, and I appear to be very much in a minority here.
>> 
>> [Eric Snow > <mailto:ericsnowcurren...@gmail.com>>]
>>> Would it help if we only published who voted, and kept their votes
>>> private?  Publishing the actual votes probably doesn't make a
>>> big difference here, relative to the broader Python/tech community.
>> 
>> That would probably be enough to convince me to vote, but I don't want
>> to hold things up either.  If I'm the only one, why bother?  It's not
>> like my vote will change the result ;-)
>> 
>> BTW, the years I was on the PSF Board, I always wanted everyone to
>> know how we voted on everything.  But I was elected to that position,
>> so was voting as a representative of those who elected me.
>> 
>> But nobody has any more business knowing how I vote on a PEP than,
>> say, how I vote for the local mayor.  That's between me and my
>> conscience.  Your vote is between you and yours, and I want actively
>> _not_ to be able to see how others voted.
>> 
>> Although I'm all in favor of making the PEP ballots public, if
>> stripped of personally identifying info.
>> ___
> 
> 
> FWIW I tend to agree with Tim on public vs private ballots, although unlike 
> him I don’t feel strongly enough to abstain from voting on this one 
> particular vote.
> 
> On a practical matter, keeping the ballots secret will rely on either having 
> a trusted person to tally the election results or using some software that 
> will do it for us. There is https://civs.cs.cornell.edu 
> <https://civs.cs.cornell.edu/> which we could use that does offer private 
> ballots and offers making the ballots (with or without a name attached to 
> them) public. It doesn’t support “pure” Condorcet but it should be easy 
> enough to take the public but anonymous ballots and compute to determine if 
> there was a condorcet winner or if one of the methods had to break a cycle, 
> and if there wasn’t a condorcet winner, just re-run the election. Beyond 
> that, I’m not sure what other options there are for anonymous ranked voting.

Oh, unfortunately this also doesn’t allow publishing *Who* voted without 
attaching them to a ballot, it’s either public, attached to the ballot, or 
private (if you’re not publishing the names, the system doesn’t even keep them, 
it just generates unique voter IDs for each).


___
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] Timeline to vote for a governance PEP

[Donald Stufft]

> On Nov 3, 2018, at 12:20 AM, Tim Peters  wrote:
> 
> [Tim]
>>> Nevertheless, I probably won't vote - I object to public ballots on
>>> principle.  That's been raised by others, so I won't repeat the
>>> arguments, and I appear to be very much in a minority here.
> 
> [Eric Snow ]
>> Would it help if we only published who voted, and kept their votes
>> private?  Publishing the actual votes probably doesn't make a
>> big difference here, relative to the broader Python/tech community.
> 
> That would probably be enough to convince me to vote, but I don't want
> to hold things up either.  If I'm the only one, why bother?  It's not
> like my vote will change the result ;-)
> 
> BTW, the years I was on the PSF Board, I always wanted everyone to
> know how we voted on everything.  But I was elected to that position,
> so was voting as a representative of those who elected me.
> 
> But nobody has any more business knowing how I vote on a PEP than,
> say, how I vote for the local mayor.  That's between me and my
> conscience.  Your vote is between you and yours, and I want actively
> _not_ to be able to see how others voted.
> 
> Although I'm all in favor of making the PEP ballots public, if
> stripped of personally identifying info.
> ___


FWIW I tend to agree with Tim on public vs private ballots, although unlike him 
I don’t feel strongly enough to abstain from voting on this one particular vote.

On a practical matter, keeping the ballots secret will rely on either having a 
trusted person to tally the election results or using some software that will 
do it for us. There is https://civs.cs.cornell.edu 
 which we could use that does offer private 
ballots and offers making the ballots (with or without a name attached to them) 
public. It doesn’t support “pure” Condorcet but it should be easy enough to 
take the public but anonymous ballots and compute to determine if there was a 
condorcet winner or if one of the methods had to break a cycle, and if there 
wasn’t a condorcet winner, just re-run the election. Beyond that, I’m not sure 
what other options there are for anonymous ranked 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] If you care about the voting method, please vote ; -)

[Donald Stufft]

> On Nov 2, 2018, at 8:22 PM, Chris Jerdonek  wrote:
> 
> On Fri, Nov 2, 2018 at 5:09 PM Tim Peters  wrote:
>> 
>> [Chris Jerdonek ]
>>> It would have been nice to know beforehand if the results of the poll
>>> were going to change the PEP.
>> 
>> Don't look at me ;-)  Like I said, "I'm not in charge of anything",
>> and I had no input in changing PEP 8001 beyond contributing to the
>> message thread, same as everyone else.
> 
> My reply was to Brett and not to you. If I had known the poll was
> going to be binding, I could have made an effort to participate in the
> discussion and try to sway people. As it was, the discussion was
> started and dominated by people who were against IRV. They are the
> most motivated to change things, and they're also the ones most
> motivated to participate in the poll. I couldn't afford to participate
> in such a discussion otherwise, as I said in the discussion. There are
> already 98 messages -- many of which are lengthy -- not to mention
> messages in other threads. It would take a lot of time and emotional
> energy to engage in such a discussion.
> 
> --Chris
> 


I don’t believe the poll *was* binding, certainly I suspect that if the results 
of the poll had been say, tied instead of a blowout that even if Condorcet had 
barely won out, that the PEP would not have changed (other than to update that 
while there were other methods, discussion around them compared to IRV was 
inconclusive). Rather I think that the poll and the entire discussion was 
weighed, both of which provide different signals (discussion tends to 
overweight people who are more passionate, whereas the poll takes very little 
effort to participate in, but tends to overweight people who don’t really care).

Honestly, I’m not sure what you thought the point of the discussion was if not 
to advocate that the PEP itself should change and thus a possible outcome of 
that was that the PEP would change. Why else would that discussion exist? I can 
sympathize with being unable to participate due to time constraints, but we 
also have to weigh in realities like we’re never going to be able to structure 
such a discussion such that 100% of people are able and willing to participate 
in it, the best you can do is try to structure it to give everyone as much 
chance as possible.

The selection of a voting mechanism ended up going through these layers:

1. In person discussion at an event in the West Coast USA.
2. Online discussion largely in discourse, but slightly on python-committers as 
well.
3. An online poll on discourse, with notification to python-committers.

Of those, (1) selected IRV and while I was not there, I get the send that there 
wasn’t a strong preference for IRV in that meeting, rather it was better than 
plurality and something the attendees were familiar with. (2) seemed to me (and 
I may be biased) to heavily weight towards a “Anything but Plurality or IRV” 
direction, and (3) ultimately confirmed that.

While not everyone might not have gotten to have their voice heard, the 
discussion and the poll was accessible to any committer who could participate 
via online (which I suspect is most of them) with the barest amount of 
investment being to vote in the poll and otherwise ignore the discussion.

I would also point out that while the poll itself was run via the Approval 
voting method [1], looking at the numbers it’s not hard to come to the 
conclusion that it’s hard to suggest that the *method* used by the poll gives 
us invalid results. For instance, if we had instead run the poll using IRV 
instead of Approval *and* we assume that every single person who approved of 
IRV would have ranked it first (and anyone who didn’t approve of IRV at all 
would have ranked it last)… then IRV still would have lost even if the poll was 
run via IRV. 

Unfortunately, It’s hard to know exactly how the voting mechanism would have 
affected the other results because while IRV was “disapproved” by a significant 
margin, the other ones were not.

However, since the poll was run using Approval, it’s hard for someone 
advocating for the Approval method to say that the results are invalid due to 
the method used, since it was their desired method that chose a method other 
than Approval.

I suspect folks who prefer Condorcet are not going to complain too much about 
the poll using Approval, since it fair and away preferred Condorcet (21 of the 
25 voters were OK with Condorcet) although it’s *possible* that the 20 people 
who were Condorcet voters would not have ranked it first, but that it was 
everyone’s second choice. Though if their first choice was Approval, see above!

Really, 3-2-1 is the only one that it feels to me like could really argue about 
the tally method of the poll. The poll wasn’t run with their preferred method 
(like anyone who preferred Approval), they didn’t win, their loss wasn’t so 
great that they would have, for sure, lost under their own method [2], and if 
everyone who approved 

Re: [python-committers] Vote on governance will happen between Nov 16 - Nov 30

[Donald Stufft]

> On Oct 23, 2018, at 1:14 PM, Tim Peters  wrote:
> 
> [Alex Martelli mailto:al...@google.com>>]
> While I suspect most participants are aware of this, just in care some don't 
> I thought I'd just point out that it's futile to look for a "perfect" voting 
> system -- Kenneth Arrow proved that long ago, see 
> https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem 
>  
> 
> Yup!  Ping's page acknowledges that explicitly:


Important to note that Arrow’s theorem applies only to ranked or ordinal 
systems, cardinal/rated systems are not covered by it (though the larger point 
of no perfect system still holds true).___
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] Vote on governance will happen between Nov 16 - Nov 30

[Donald Stufft]

> On Oct 23, 2018, at 7:56 AM, Antoine Pitrou  wrote:
> 
> 
> Le 23/10/2018 à 13:55, Donald Stufft a écrit :
>> 
>> We’re using IRV and I accept that, but I just want to point out that IRV
>> still has a form vote splitting (in electoral parlance, vote splitting
>> is the “favorite betrayal criterion”
>> - https://www.youtube.com/watch?v=JtKAScORevQ. IRV only protects against
>> vote splitting when you have a very weak or a very strong candidate
>> ranked first.
> 
> Do you have a non-video link to an explanation?
> 
> If some form of tactical voting is possible, as a voter I'd like to know
> about it.
> 


To be clear, *all* voting systems have some form of tactical voting as part of 
them, so this isn’t unique to IRV. I was mostly just pointing out that IRV 
isn’t a panacea, you can still get a vote splitting like effect. Interestingly, 
IRV also has the property that sometimes the simple act of voting your true 
preference *at all* can cause your true preference to lose, and sometimes you 
would have been better off not voting at all.

I’m struggling to find a resource besides that doesn’t also include shilling 
for another voting system or isn’t a lengthy paper but 
https://rangevoting.org/IRVpartic.html <https://rangevoting.org/IRVpartic.html> 
gives an example and https://rangevoting.org/TarrIrv.html 
<https://rangevoting.org/TarrIrv.html> is a more complex example.


___
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] Vote on governance will happen between Nov 16 - Nov 30

[Donald Stufft]

> On Oct 23, 2018, at 7:06 AM, Nick Coghlan  wrote:
> 
> On Tue, 23 Oct 2018 at 06:38, Łukasz Langa  wrote:
>> 
>> The voting procedure is described in PEP 8001. I flipped it from "Draft" to 
>> "Active" without further changes a few minutes ago. That's in the interest 
>> of giving everybody enough lead time as well as resolving the situation 
>> "well before PyCon 2019" as per Guido's and Carol's requests.
>> 
>> Please read all the governance PEPs, ask for clarifications, voice all your 
>> concerns now. Ideally we will make all of the required changes to the PEPs 
>> early and not last minute before the vote.
>> 
>> There were some suggestions on Discourse for changes to the selected model, 
>> the biggest being Stefan's suggestion to encrypt the votes and Donald's 
>> suggestion to use STAR instead of IRV for counting votes. We ended up not 
>> going with those suggestions. See Brett's comment here as to why:
>> https://discuss.python.org/t/pep-8001-python-governance-voting-process/233/46
> 
> My main concern was about the potential for vote-splitting with
> multiple "council" type proposals on the ballot, and IRV is enough to
> address that (having been an Australian voter for ~22 years, I'm also
> very familiar with it, and given the specific set of proposals we're
> voting on, I don't think the case where STAR would give a different
> answer is likely to come up - the various draft PEPs have too much in
> common with either each other or the status quo for it to be likely
> that a significant proportion of the folks voting will find any of
> them completely unacceptable)
> 


We’re using IRV and I accept that, but I just want to point out that IRV still 
has a form vote splitting (in electoral parlance, vote splitting is the 
“favorite betrayal criterion” - https://www.youtube.com/watch?v=JtKAScORevQ 
. IRV only protects against vote 
splitting when you have a very weak or a very strong candidate ranked first.___
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] Moderation of the Python community

[Donald Stufft]

> On Oct 17, 2018, at 11:34 AM, Brian Curtin  wrote:
> 
> I think this type of issue is better solved internally to our team, perhaps 
> via some form of mediator(s) I mentioned earlier, rather than involving a 
> wholly external group. Time is of course a finite resource in open source, 
> and people work is often/usually harder than code work, but I think we do 
> have some people around who care about the success of the project to spend 
> time mediating these kinds of conflicts so that we keep everyone involved and 
> solve whatever problem at hand in a satisfactory manner.
> 

Honestly, I think an independent group managing these issues is the right way 
to handle them. I’m loathe to bring it up because the situation was a long time 
ago, and has been resolved, but I’ve personally had to engage the CoC process 
in regards to another core developers behavior. At the time the way that was 
handled was contacting the PSF board, if the process was instead to contact 
python-committers or something I likely would’t have done it at all. I think it 
is important that if someone feels they’re having a problem in a particular 
space, that they feel they have an impartial and independent group of people to 
raise those concerns with.

With regards to whether the CoC can evict a core developer of Python.. I think 
it absolutely needs to be able to do that. Otherwise it’s basically stating 
that it’s fine for someone to harass someone else… as long as the person doing 
the harassing is a core developer. If anything, core developers should be held 
to a higher, not a lower standard. Obviously excommunication is not step 1 on 
any CoC, and such a thing would only be used after a history of repeated, on 
going unacceptable behavior, but if the CoC doesn’t have any teeth, than it’s 
not worth the metaphorical paper it’s written on.

So, when it comes to the conduct we expect from people, core developers should 
not be treated specially in either expectations nor process.___
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] Moderation of the Python community

[Donald Stufft]

> On Oct 17, 2018, at 10:03 AM, Victor Stinner  wrote:
> 
> Handling conflicts between core developers is the most difficult
> question. I don't think that it's the role of the conduct working
> group to handle that. Moreover, the Code of Conduct should be seen as
> a way to evict a core developer out of Python. The Code of Conduct is
> supposed to protect members of the Python community against people who
> misbehave. But I'm unable to describe the limit between "misbehave"
> and "conflict" between two developers.


I don’t think core developers are special here, the CoC and the enforcement 
mechanisms for it should apply to all interactions within our space equally, 
whether those people are core developers or not.___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

> On Oct 9, 2018, at 8:30 AM, M.-A. Lemburg  wrote:
> 
> On 09.10.2018 08:24, Donald Stufft wrote:
>> On a specific category page, in the top right you can select a watch level 
>> for the whole category, the two relevant ones for you will be either 
>> “Watching” which will default all new topics in a category to watching or 
>> “first post”, which won’t set them to watching, but will email you for 
>> *only* the first post in any new topic, unless you set a topic to watching 
>> after that.
> 
> Thanks, I'll give that a try.
> 


One thing to clarify— Changing that setting will only apply to *new* topics in 
that category. It basically lets you set a category specific default for the 
notification level of new topics. Once the topic has been created that setting 
has no effect which allows you to adjust your notification level on a per topic 
basis after the fact. If for instance you default to watching, but a noisy 
thread happens you don’t care about, you can just unwatch that particular 
thread.

___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

On a specific category page, in the top right you can select a watch level for 
the whole category, the two relevant ones for you will be either “Watching” 
which will default all new topics in a category to watching or “first post”, 
which won’t set them to watching, but will email you for *only* the first post 
in any new topic, unless you set a topic to watching after that.

> On Oct 8, 2018, at 9:29 PM, M.-A. Lemburg  wrote:
> 
> FYI: I did sign up on Discourse and have enabled email notifications,
> but it seems that you have to do this on a per forum entry basis,
> since I have not received any notifications for the newer entries
> (only ones for the ones which were already available at the time
> I subscribed).
> 
> Is there a way to get notifications for all new topics as well ?
> 
> Thanks,
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Experts
 Python Projects, Coaching and Consulting ...  http://www.egenix.com/
 Python Database Interfaces ...   http://products.egenix.com/
 Plone/Zope Database Interfaces ...   http://zope.egenix.com/
> 
> 
> ::: We implement business ideas - efficiently in both time and costs :::
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>   Registered at Amtsgericht Duesseldorf: HRB 46611
>   http://www.egenix.com/company/contact/
>  http://www.malemburg.com/
> 
> 
> On 08.10.2018 16:44, Victor Stinner wrote:
>> I saw some complains against Discourse (some people prefer emails,
>> some people didn't the bad timing with discussions on the new
>> governance, etc.), but I'm not sure about the conclusion. Where should
>> we discuss governance PEPs? Since it was unclear to me, I posted me
>> PEP 8015 to discuss.python.org and to python-committers... And now we
>> can enjoy discussions splitted between the two :-)
>> 
>> Victor
>> Le sam. 29 sept. 2018 à 09:50, M.-A. Lemburg  a écrit :
>>> 
>>> On 29.09.2018 03:21, Barry Warsaw wrote:
 On Sep 28, 2018, at 15:03, Victor Stinner  wrote:
 
> It seems like anyone can subscribe. Is the Committer group reserved to
> core developers? If yes, how do you know which accounts are linked to
> core developers?
 
 You must be approved to join python-committers, but its archive is public 
 for anyone to read.  Does Discourse provide the same level of access for 
 core developers and non-core developers?
>>> 
>>> I hope it does, since otherwise python-committers is not only moving
>>> to discourse, but also losing its functionality as forum for
>>> core developers. We'd just have another python-dev or python-ideas
>>> forum.
>>> 
>>> I've never used Discourse. Does it allow to subscribe in a way that
>>> I can still get emails for the discussions or is it browser only ?
>>> 
>>> If the latter, then I'm pretty much out of the game, since I live
>>> in email and cannot have 10 browser tabs open and regularly check
>>> these just to keep up with everything.
>>> 
>>> --
>>> Marc-Andre Lemburg
>>> eGenix.com
>>> 
>>> Professional Python Services directly from the Experts (#1, Sep 29 2018)
>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>> Python Database Interfaces ...   http://products.egenix.com/
>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/
>>> 
>>> 
>>> ::: We implement business ideas - efficiently in both time and costs :::
>>> 
>>>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>>   Registered at Amtsgericht Duesseldorf: HRB 46611
>>>   http://www.egenix.com/company/contact/
>>>  http://www.malemburg.com/
>>> 
>>> ___
>>> 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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

> On Sep 29, 2018, at 1:31 PM, Brett Cannon  wrote:
> 
> Another way to think about this is if we wait until after our governance 
> discussions and try this experiment the volume quite possibly won't be at a 
> level to stress test how the interaction on Discourse works. And while I 
> personally find day-to-day stuff manageable via email (but definitely not 
> ideal), it's when the volume spikes horribly that I typically find email 
> falls over the most. And I don't know about the rest  of you, but I have not 
> been looking forward to the governance discussions _because_ of the volume 
> and I am too familiar with how difficult those discussions become difficult 
> to manage via email.


I’d like to also point out that this isn’t a new idea, a year and a half ago we 
had the overload-sig whose idea was to solve this very thing (and Discourse was 
one of the options back then as well, as well as MM3, and uh… Github issues?). 
The results of the overload-sig were basically totally inconclusive because we 
never moved to the point of trying an *actual* list with *actual* traffic. So 
it just kind of fell to the wayside because we were never able to really test 
it out. 

Testing out a new medium for discussion is always hard, there is a fair amount 
of churn involved in getting everyone to move over to the new location, thus 
you tend to want to try it with a small group of people to limit the impact. 
Unfortunately the downside to a small group of people is that they tend not to 
produce a large amount of email (and when it’s invite only, are less likely to 
need some of the more advanced moderation facilities). 

So python-committers itself is still small enough that a mailing list doesn’t 
typically have the main problems that we’re trying to solve. However, the 
governance discussions give us a somewhat unique opportunity in that they’re 
likely going to increase the amount of discussion on this list by a fair 
amount. That gives us a chance to take an otherwise small list, and give it a 
more realistic test than it otherwise would be, without trying to tell the 
entirety of say, python-ideas, to switch to a new medium.

I do believe we have a problem though, and I think it is getting worse. I’ve 
personally more or less completely checked out of python-dev and python-ideas, 
in large parts because of the problems with email and mailing lists. We’re 
burning Brett out, and quite frankly I think that the nature of large mailing 
lists makes all of our discussions more likely to become heated.

With that, I urge everyone to give Discourse a fair shake for these next 3 
months, and try to move as much of the discussion over there as we can. We’re 
unlikely to use either medium as the actual voting mechanism so if some people 
don’t come over, they’ll largely just miss out on discussion but will still 
ultimately end up able to vote. I personally am going to try to make this my 
last message on the mailing list during the duration of the test. I hope that 
you’ll all try it out as well.___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

> On Sep 29, 2018, at 6:24 AM, Paul Moore  wrote:
> 
> But at least it was *possible*. Personally I do a Google search rather
> than using my MUA, but the point is that while it's clumsy, it's known
> technology. I don't even know how I'd find a link to an old message in
> Discourse, but I assume it's not searchable via Google? Sure, I can
> learn. But how about a member of the general public (after all,
> python-committers is supposed to be restricted for posting, but
> publicly visible)?

Discourse is perfectly searchable using Google in exactly the same way as 
Mailman archives. It also has built in search.___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

> On Sep 29, 2018, at 6:00 AM, Łukasz Langa  wrote:
> 
> 
>> On Sep 29, 2018, at 10:44, Stefan Krah  wrote:
>> 
>> Sorry if I misunderstand this, but is the plan to moderate *core developers*
>> on python-committers?
> 
> If you label it with an abstract term like this, it sounds like we just 
> formed the Python Thought Police ;-)
> 
> But think about the concrete examples of moderation and discussion flow that 
> are going to be useful:
> - ability to link between topics
> - ability to see if somebody is actively replying on something you are also 
> replying to
> - ability to edit your own post afterwards for clarity, typos, sending mishaps
> - ability to move topics around to where they belong better
> - ability to close a topic (no more replies) to indicate for example: "this 
> is about a resolved issue", "this is about an outdated version of the PEP"
> - ability to make multiple quotes in a single post (which correctly link back 
> for broader context)
> - ability to collapse out-of-band replies in a topic
> 
> I could go on. In other words, unless the conversation REALLY gets heated, I 
> doubt we will have to involve the code of conduct working group. But 
> moderation and flow control is much more than banning abuse.
> 


I’d also say that perhaps it’s less required on python-committers due to the 
invite only nature of the list (though I don’t think we’re immune here either). 
But as I understand it, one of the goals if the experiment works out well here, 
is to expand the lists that we move onto discourse to ones that are not invite 
only. In that regard, even if we never need the ability to manage inappropriate 
behavior on python-committers, we likey will at some point on the more public 
lists from time to time.

___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

> On Sep 29, 2018, at 6:03 AM, Paul Moore  wrote:
> 
> 1. Pull technology rather than push. The fact that email is
> *delivered* to me is a critical benefit for certain types of
> interaction, and one that's far too easily dismissed by people who
> promote pull solutions. It's baffling to me that such a fundamental
> difference is routinely treated as "minor".


FWIW, Discourse can be configured to be push or pull based on a personal level. 
Not only on a personal level, but you can control at at the category (similar 
to different lists), tag, or individual topic level. I’ve responded to you on 
Discourse in more detail, but I find the level of control quite nice in a way 
that lets you choose push or pull based upon how much you care about a 
particular topic.___
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] python-committers is dead, long live discuss.python.org

[Donald Stufft]

Log into your account, go into preferences, enable Mailing List Mode.

> On Sep 29, 2018, at 3:51 AM, Robert Collins  wrote:
> 
> +1
> 
> If someone can tell me how to configure discourse to work like a
> mailing list; specifically:
> 
> - email me messsages rather than 'X new messages" nuisance-mails
> - work sanely with replies-from-mail
> 
> then I'm certainly happy to adapt.
> 
> -Rob
> On Sat, 29 Sep 2018 at 13:19, Barry Warsaw  wrote:
>> 
>> On Sep 28, 2018, at 17:45, Łukasz Langa  wrote:
>> 
>>> Do you use NNTP? Like with IRC, you won't find the next generation of core 
>>> developers on it. And no, there is no support for it in Discourse.
>>> 
>>> We could probably figure something out with Gmane if there's interest.
>> 
>> Yes, I use NNTP to read many of the Python mailing lists.  Gmane, even in 
>> its current state, is fantastic.
>> 
>> I’m all for supporting the next generation of developers, but not 
>> necessarily at the expense of *decades* of established workflow for current 
>> developers.  Moving to Discourse breaks this and proliferates browser tab 
>> syndrome.  It’s an experiment worth conducting, but I do think it’s a bit 
>> cavalier to shut down python-committers without further discussion.
>> 
>> Cheers,
>> -Barry
>> 
>> ___
>> 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] Python 4.0 or Python 3.10?

[Donald Stufft]

> On Sep 25, 2018, at 6:39 PM, Yury Selivanov  wrote:
> 
> I think we all have seen code like that; it's a common pattern.  So by
> just bumping the version to 4.0 you would break the compatibility for
> some libraries and frameworks.  And maybe breaking it is fine if
> there's a very strong technical reason, but doing that just to make a
> statement isn't worth it, IMHO.


Breaking a bunch of software to make the statement that you’re not going to 
break backwards compatibility anymore sounds like something out of a Monty 
Python skit though ;)___
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] Council / board (Was: 1 week to Oct 1)

[Donald Stufft]

> On Sep 25, 2018, at 12:24 PM, Antoine Pitrou  wrote:
> 
> 
> Le 25/09/2018 à 18:10, Guido van Rossum a écrit :
>>To save us all trouble of discussing this particular issue, for
>>those of you who disagree completely, and have other ideas about how
>>you'd like Python to be governed and who should be in it, you can do
>>one or more of the following:
>> 
>>- not vote on my PEP
>>- vote on the other PEPs
>>- write their own PEP
>> 
>> 
>> I would remind people that it's well documented that diverse group make
>> better decisions.
> 
> Can you point us to such documentation?  It would be nice to know under
> which conditions the assertion holds, according to which metrics, etc.


https://hbr.org/2016/11/why-diverse-teams-are-smarter 
 includes links to 
several studies. There are a lot more results as well to the search “diverse 
teams make better decisions” or “diverse groups decision making” on Google as 
well if those studies are lacking to you.


___
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] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Donald Stufft]

> On Sep 21, 2018, at 8:59 AM, Paul Moore  wrote:
> 
> On Fri, 21 Sep 2018 at 13:30, Donald Stufft  wrote:
>> So part of being and open and welcoming community, is knowing and 
>> understanding that words, images, etc like that can make people feel like 
>> we’re either a group that will directly engage in those attacks that have 
>> been associated with them in the past, or at least won’t come to their aid 
>> if someone does initiate those kinds of attack.
> 
> I'm going to take this one comment and respond to it out of context.
> But generally, I agree with everything you said.
> 
> My biggest concern is that we're starting to build a community where
> people feel exposed to attack for "CoC violation" accusations over
> simple misunderstandings, or careless wordings. Or, for that matter,
> using terminology that they weren't aware was unacceptable. Not "being
> called out (by the offended party), apologising and moving on", but
> going straight to policy complaints by people (maybe even people not
> directly upset) assuming offense could be claimed. That's clearly
> nothing like the sort of problems people with real reason for
> sensitivity have to live under, but nevertheless it's not a
> comfortable place for people to learn how to interact.
> 
> Balance, forgiveness, and a mature level of empathy are what's
> *really* needed ("among the things that are needed...":-)). Not
> policies. Policies should be weapons of last resort.
> 
> Paul

So I don’t think that being called out by the aggrieved party is the right 
response generally for these sorts of things. I mean, ultimately it depends on 
the specific instance, but often times having the person who is feeling 
attacked call out the other person, what’s going to happen is that person is 
going to feel compelled to respond back in kind and “defend” themselves. Having 
a neutral third party there to mediate and calm the situation down is immensely 
helpful.

I mean, if you personally did something that made me feel uncomfortable, I’d 
probably personally handle it, because we have a  rapport already, but if 
someone else did there’s a chance I wouldn’t (either because there might be 
history there where a specific instance finally spilled over, or because I’m 
angry/hurt/whatever and I don’t trust myself to respond).

This also falls into the feeling exposed to attack bit. Generally what the CoC 
does should be private, though it’s tough to balance that out with being 
transparent too. For instance, we don’t really want to turn CoC enforcement 
into it’s own sort of shame. If you were to report me, ideally the way it would 
play out is some member of the moderation team / CoC team / whatever would 
privately contact me, and tell me to knock it off or whatever. Generally other 
people shouldn’t know (unless one of the two sides of the issues chooses to 
divulge it) that it happened (although it’s good to publish anonymized reports 
too). There should not be some sort of record that the dastardly Paul said 
something bad once and had to get reprimanded.

Where it gets harder is when more drastic measures are to be taken. If someone 
gets banned for a day in a sort of timeout, should that be public? Probably not 
since we want them to come back and ideally be positive contributors from that 
point out, and feeling like they’ve been put up on display is probably not 
conducive towards that, and being gone for a day is not likely to be something 
where other people notice the absence and start to question it. What about a 
week? A month? Permanent?

Personally I think that publicizing that a particular person had some action 
taken against them is probably the wrong path to take in all severity levels, 
and that the CoC team should probably publish some sort of anonymized reports. 
These reports basically serve to show people who are worried about feeling 
safe/welcome in the community, that if they have a problem they’re likely to be 
heard and helped, without putting particular people “on blast”.

Unfortunately our tooling and process isn’t really “here” yet, for instance in 
the specific case we’re talking about, if that person was jsut silently banned 
than it can feel a bit kafkaesque and since the record of his statement is 
permanent and can’t be hidden or something, people looking in from the outside 
don’t know that it wasn’t acceptable since they don’t see any action to have 
taken place. The ideal situation is probably that the original post ends up 
edited, marked,  or hidden in some fashion (but doesn’t just disappear) to say 
that it was inappropriate in some way (think what GitHub does here with hidden 
posts) but that doesn’t otherwise create some sort of notification. 

I however, think policies are great! Particularly in a diverse community where 
the cultural norms may vary wid

Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Donald Stufft]

> On Sep 21, 2018, at 8:01 AM, Paul Moore  wrote:
> 
> On Fri, 21 Sep 2018 at 12:38, Carol Willing  wrote:
> 
>> Much of the discussion here has focused on the use of a few words.
>> 
>> IMHO, discussing violence, assault, and implying that its okay to accept and 
>> trivialize this violence do not belong in posts about the Python language.
>> 
>> From the original post:
>> 
>> Being triggered by a word this simple is not exactly a
>> sign of mental stability. I know a girl who's been raped more than she can
>> count - but the word doesn't trigger her like this(only makes her want to
>> beat up rapists). If people can do that, then surely a playground insult
>> wont reduce you to tears, right ?
> 
> I agree - *but* there's a whole lot more I wish I could say, about
> context, and looking at how the conversation reached that point.
> 
> But I won't, because frankly I'm scared to do so. I don't trust myself
> to explain my feelings without doing so in a way that people find
> offensive, and suffering a backlash that I didn't intend to trigger,
> and which won't help the discussion.
> 
> I'm not sure that "I'm too scared to participate in this discussion"
> is where we want to be, though…

I think that this is being framed somewhat poorly. The idea that the problem is 
that someone might be “offended” is I think the wrong take away. People can 
choose all manner of things to be offended by and just because someone might 
take offense to a statement, doesn’t mean that the statement is inherently 
something that cannot be uttered here. For instance, someone might take offense 
if you say that you think it’s easier to write clean code in Python than 
Brainfuck (or perhaps that pip is the best or worst package installer ;) ), but 
that doesn’t mean that you can’t express that opinion.

What I think the real problem is, things that attack people, particularly for 
some inherent thing they are or something that has happened to them outside of 
their control or the like. 

Sometimes that can come across as “well someone might take offense to the use 
of this word”, and it’s important I think to remember why that word has that 
particular connotation. If you spent a lifetime having someone shout “Python!” 
and then a bucket of cold water dumped on you, you would likely start to get a 
bit afraid anytime you heard someone say “Python”, when you’d look for that 
next bucket.

That’s a really silly example, but there are groups of people who *to this day* 
are attacked in one form of another simply for who they are, and there are a 
lot of things associated with those attacks, be it words, or images, or what 
have you, and the mere use of those words, images, or whatever can make those 
groups of people feel like the space they’re in is one that is likely to attack 
them too. That’s not just about the specific word used in the original post, 
but also things like making joke of assault and similar as well. It’s 
particularly troublesome in a society that doesn’t entirely believe that those 
things are wrong.

So part of being and open and welcoming community, is knowing and understanding 
that words, images, etc like that can make people feel like we’re either a 
group that will directly engage in those attacks that have been associated with 
them in the past, or at least won’t come to their aid if someone does initiate 
those kinds of attack.

This is a bit different than say the use of Master/slave. Those words might 
make some people feel uncomfortable for sure, but they don’t have the same 
connotations. Because they make people feel uncomfortable, it’s generally a 
good idea to avoid using them (particularly when there are better, more 
descriptive terms available) but that you’re not going to be cast out into the 
wilderness if you happened to use them.

Overall, I think people are generally reasonable, and if you say something 
“bad”, but you weren’t aware or didn’t mean it that way, people generally 
accept an apology and then will move on [1]. They might be a bit less unsure of 
you after that, but if you don’t continue to repeat it, then most people will 
forget about it and look at it as an isolated incidence. Obviously if you keep 
doing it, and apologizing each time, at some point people are going to just 
assume the apology isn’t in earnest.


[1] I know this, because I’ve done it. I grew up in let’s say, a very rural 
setting, and I had expressions that were disparaging to groups of people, that 
I didn’t really intend to be, it was just something I had always said because 
it was a common idiom where I grew up. I got called out on it, apologized, and 
everyone went on their way.



___
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] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Donald Stufft]

> On Sep 21, 2018, at 6:55 AM, Christian Heimes  wrote:
> 
> I don't understand why you are drawing the reverse conclusion here. Can
> you give me one concrete example, in which a French, German, or any
> other non-US American taboo was violated and not counteracted with swift
> reaction?

Right, I would assume that if someone knowingly posted a similar post, but 
using say a French taboo, the same would have happened. The key thing is that 
the author obviously *knew* it was a taboo, it wasn’t an accident. If someone 
accidentally posted something like that, then I presume the outcome would be 
something more like a warning and telling them not to do it again— for any 
culture’s taboo.___
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] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Donald Stufft]

> On Sep 20, 2018, at 4:25 PM, Antoine Pitrou  wrote:
> 
> I think the action taken by Brett (apparently decided with Titus and a
> mysterious "conduct working group") is not the right one:


Just FTR, the conduct working group is the PSFs CoC Working Group, which I 
believe had an open call for membership at some point. I think it’s still 
getting setup so it hasn’t been added to the list of WGs yet or anything, but 
it was approved awhile back: 
https://www.python.org/psf/records/board/minutes/2017-08-22/#code-of-conduct-work-group
 


At least, I’m pretty sure that’s what Brett means.

With regards to the action, it seems reasonable to me, particularly since it 
was not a one-off done by one person, but was an action taken after discussion 
amongst the moderators and the CoC WG.

I do agree that our tools are bad, and we need to come up with new ones. With 
limited moderation tooling we have limited ability to head off unproductive 
discussions before they delve too far into the bad end of the world.

I think if there is concern about this, the best forum is probably discussion 
with the CoC WG, and probably not python-committers.


___
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] Automerge bot deployed

[Donald Stufft]

Maybe the merge bot should render the description and then extract plaintext out of that?On Sep 13, 2018, at 2:16 PM, Victor Stinner  wrote:Ah yes, it works and I agree that it's OK in plain text. But we have careful if a contributor uses "\_" or something like that in a description. Maybe always edit to see the "source" of the description?VictorLe jeu. 13 sept. 2018 à 16:54, Petr Viktorin  a écrit :On Wed, Sep 12, 2018, 23:30 Victor Stinner  wrote:Today I created a PR with a description containing "type.__format__()". To display it properly, I chose to edit the description and write "type.\_\_format\_\_()". I guess that the bot will merge a description like that unchanged, right? So we should also be careful of description using Markdown syntax.Use `type.__format__`, with backticks, for code. That looks OK in plain text.Or edit before merging :)VictorLe mer. 12 sept. 2018 à 18:52, Mariatta Wijaya  a écrit :Update to the automerge bot:It will not merge unless there is "CLA signed" label, and no "DO-NOT-MERGE" label.Again, please edit the PR title and description before adding the `🤖 automerge` label.The PR title and description will be used as the squashed commit message.Mariattaᐧᐧ
___
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 listpython-committers@python.orghttps://mail.python.org/mailman/listinfo/python-committersCode 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] List of all core developers

[Donald Stufft]

Yea to be clear. I just used csv and those fields as an example. I think TOML 
is a better choice, and we can add whatever fields are useful. 

Part of the devguide build step could be turning that into a nice human facing 
list (does that satisfy what Marc-Andre is looking for?). We could also have a 
cronjob that syncs github permissions with that list. 

Sent from my iPhone

> On Aug 4, 2018, at 12:51 PM, Brett Cannon  wrote:
> 
> 
> 
>> On Fri, Aug 3, 2018, 21:59 Donald Stufft,  wrote:
>> 
>> 
>>> On Aug 3, 2018, at 1:52 PM, Brett Cannon  wrote:
>>> 
>>> 
>>> 
>>> On Fri, 3 Aug 2018 at 00:44 Donald Stufft  wrote:
>>>> We should probably have a single source of truth for what a core developer 
>>>> is, and all other systems pull from that.
>>> 
>>> Ah, but I think there might be a terminology clash here. Using MALs 
>>> definition means that you can be a core developer but not have commit 
>>> privileges due to relinquishing those privileges at some point. So I'm not 
>>> sure what systems you are referring to that need to know if someone 
>>> historically happened to be a core developer.
>> 
>> We have that I am aware of right now:
>> 
>> - GitHub
>> - bugs.p.o
>> - python-committers
>> 
>> And it sounds like Marc-Andre is looking to add to it:
>> 
>> - A third party/user facing list of developers, regardless of the technical 
>> status of their ability to commit (e.g. even if they don’t have a GitHub 
>> account).
>> 
>> 
>> There may be other systems that I can’t recall off the top of my head (is 
>> anything still in hg.python.org? I dunno).
> 
> 
> For us, hg.python.org only has the b.p.o code.
> 
>> 
>> As of right now, I believe the list of who a core developer is and has 
>> historically been somewhat adhoc based upon who has permissions to commit 
>> things.
> 
> 
> Yep.
> 
>> Meaning that as we transition from one system to another we “lose” the 
>> ability to account for people over the years. This would also make it harder 
>> for someone to come back, because they’d have to track down someone who knew 
>> they were a core developer (and let’s be honest, human memory sucks so 
>> sometimes you’re just not sure if someone was or wasn’t).
> 
> 
> Yes, us old-timers aren't perfect. 😉 If someone couldn't remember we would 
> probably go into the mailing list archives.
> 
> 
>> 
>> So I think it would probably be a good thing if we had one central location 
>> that answers the question of who is and isn’t a core developer, that isn’t 
>> tied to the ACLs of one particular system that we happen to be using today. 
>> Ideally these other related systems (bugs.p.o, Github, etc) are then 
>> modified to pull from this thing as the singular source of truth. This could 
>> be as simple as a CSV/tom/yaml file sitting in a repository somewhere that 
>> lists all of the developers, their status etc, plus scripts that will 
>> synchronize access from that to the relevant places.
> 
> 
> It would probably sit in the devguide. The question is how to potentially 
> display this in a readable format? Or maybe we don't care as long as we use a 
> format that makes both humans and computers happy? Otherwise we would have to 
> add a build step to the site. (Personally I say we do it in TOML since it's 
> readable and can still be writable through the GitHub web UI since I am 
> typically the person adding new folks 😁; we can then just link to it for 
> people to peruse.)
> 
>> 
>> So for arguments sake, it could be a CSV file with the schema:
>> 
>> Name, Email, Active, bugs.p.o Username, GitHub username
> 
> 
> I would toss into the year joined. I know over in the GitHub issue about this 
> topic that people also don't want to lose mentor/voucher/proposer and any 
> notes about why the person got their commit privileges.
> 
>> 
>> And then a script that could be ran whenever that would check the 
>> permissions of the GitHub team for CPython, and ensure that anyone listed 
>> there has been added to the GitHub team (and probably anyone who isn’t, has 
>> been removed, to ensure that getting in this file is the _way_ you get 
>> access). Likewise bugs.p.o could pull from this, and Marc-Andre’s public 
>> facing list could as well.
>> 
>> Of course we can get fancier than a simple file somewhere, the key thing is 
>> that there is a single source of truth, that isn’t tied to one particular 
>> service or tool that we use (unless that tool is dedicated

Re: [python-committers] List of all core developers

[Donald Stufft]

> On Aug 3, 2018, at 1:52 PM, Brett Cannon  wrote:
> 
> 
> 
> On Fri, 3 Aug 2018 at 00:44 Donald Stufft  <mailto:don...@stufft.io>> wrote:
> We should probably have a single source of truth for what a core developer 
> is, and all other systems pull from that.
> 
> Ah, but I think there might be a terminology clash here. Using MALs 
> definition means that you can be a core developer but not have commit 
> privileges due to relinquishing those privileges at some point. So I'm not 
> sure what systems you are referring to that need to know if someone 
> historically happened to be a core developer.

We have that I am aware of right now:

- GitHub
- bugs.p.o
- python-committers

And it sounds like Marc-Andre is looking to add to it:

- A third party/user facing list of developers, regardless of the technical 
status of their ability to commit (e.g. even if they don’t have a GitHub 
account).


There may be other systems that I can’t recall off the top of my head (is 
anything still in hg.python.org <http://hg.python.org/>? I dunno).

As of right now, I believe the list of who a core developer is and has 
historically been somewhat adhoc based upon who has permissions to commit 
things. Meaning that as we transition from one system to another we “lose” the 
ability to account for people over the years. This would also make it harder 
for someone to come back, because they’d have to track down someone who knew 
they were a core developer (and let’s be honest, human memory sucks so 
sometimes you’re just not sure if someone was or wasn’t).

So I think it would probably be a good thing if we had one central location 
that answers the question of who is and isn’t a core developer, that isn’t tied 
to the ACLs of one particular system that we happen to be using today. Ideally 
these other related systems (bugs.p.o, Github, etc) are then modified to pull 
from this thing as the singular source of truth. This could be as simple as a 
CSV/tom/yaml file sitting in a repository somewhere that lists all of the 
developers, their status etc, plus scripts that will synchronize access from 
that to the relevant places.

So for arguments sake, it could be a CSV file with the schema:

Name, Email, Active, bugs.p.o Username, GitHub username

And then a script that could be ran whenever that would check the permissions 
of the GitHub team for CPython, and ensure that anyone listed there has been 
added to the GitHub team (and probably anyone who isn’t, has been removed, to 
ensure that getting in this file is the _way_ you get access). Likewise 
bugs.p.o could pull from this, and Marc-Andre’s public facing list could as 
well.

Of course we can get fancier than a simple file somewhere, the key thing is 
that there is a single source of truth, that isn’t tied to one particular 
service or tool that we use (unless that tool is dedicated to managing this 
list of people), because anytime we tie maintaining this list of people to the 
technical aspects of giving someone an ACL to a particular system, then our 
list is going to become outdated anytime we switch systems (and some % of 
people won’t ever make the jump to the new system).

> 
> Assuming what you mean is people with commit privileges, then we have the 
> "lovely" complication of usernames being inconsistent for people across 
> systems which is probably what is required to make any centralized list 
> useful for systems to interact with. We could solve this by using a table 
> instead of a list for people to list e.g. their GitHub and b.p.o usernames if 
> people wanted to go that route.
>  
> 
> > On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg  > <mailto:m...@egenix.com>> wrote:
> > 
> > Please note that the motivation for having a list similar to the
> > one we have for PSF Fellows is not to determine voting eligibility.
> > 
> > This is about having a record of the core developer status available
> > to show to 3rd parties, e.g. to (potential) employers, organizations,
> > government agencies, etc.
> > 
> > Having a place to also record the email addresses for internal
> > use such a voting or sending messages to the whole group
> > is a good idea nonetheless. This mailing list will likely already
> > serve that purpose.
> > 
> > 
> > On 02.08.2018 23:25, Brett Cannon wrote:
> >> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer  >> <mailto:stefan.richtho...@gmail.com>>
> >> wrote:
> >> 
> >>> Again, this was in the (poorly conveyed) context of getting email
> >>>> addresses for them, or at least being able to contact them.
> >>>> 
> >>> 
> >>> I always thought there were already at least three places containing the
> >>> necessary e

Re: [python-committers] List of all core developers

[Donald Stufft]

We should probably have a single source of truth for what a core developer is, 
and all other systems pull from that.

> On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg  wrote:
> 
> Please note that the motivation for having a list similar to the
> one we have for PSF Fellows is not to determine voting eligibility.
> 
> This is about having a record of the core developer status available
> to show to 3rd parties, e.g. to (potential) employers, organizations,
> government agencies, etc.
> 
> Having a place to also record the email addresses for internal
> use such a voting or sending messages to the whole group
> is a good idea nonetheless. This mailing list will likely already
> serve that purpose.
> 
> 
> On 02.08.2018 23:25, Brett Cannon wrote:
>> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer 
>> wrote:
>> 
>>> Again, this was in the (poorly conveyed) context of getting email
 addresses for them, or at least being able to contact them.
 
>>> 
>>> I always thought there were already at least three places containing the
>>> necessary email addresses.
>>> 
>>> * python-committers should be exactly this mailing list.
>>> 
>> 
>> The list also has email archiving services as well as duplicate emails for
>> people (e.g. I'm in it twice so that if I accidentally send an email from a
>> personal email address it doesn't get held up in moderation).
>> 
>> 
>>> * according to https://devguide.python.org/coredev/#issue-tracker it is
>>> mandatory for core developers to subscribe to the issue tracker which AFAIK
>>> requires a confirmed email address.
>>> 
>> * Every committer clearly must have signed the contributor agreement
>>> https://www.python.org/psf/contrib/contrib-form/ which also contains a
>>> mandatory email field
>>> 
>>> So why is it still necessary to get email addresses at all?
>>> 
>> 
>> Because none of those necessarily have accurate email addresses at this
>> point. E.g. even python-committers has had people dropped off due to too
>> many email rejections. And if we hold a vote for a governance model we will
>> need a place to send ballots.
>> 
>> Now if the vote is open to any core developer (using MAL's definition of it
>> being a lifetime title), then the subscription list for this mailing list
>> is probably good enough with some manual grooming as long we are okay with
>> long-dormant folk who predate this list not voting (which I'm personally
>> fine with). But if we wanted a way to reach just people with commit
>> privileges then that's a separate challenge.
>> 
>> -Brett
>> 
>> 
>>> 
>>> 2018-08-02 10:59 GMT+02:00 Eric V. Smith :
>>> 
 On 8/2/2018 3:32 AM, M.-A. Lemburg wrote:
 
> On 02.08.2018 03:24, Eric V. Smith wrote:
> 
>> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote:
>> 
>>> I think it would also be a good idea to include core developers
>>> of other Python implementations in such a document, in
>>> separate sections, e.g. for Jython, IronPython, PyPy,
>>> Stackless, etc
>>> 
>>> 
>>> Hmm, I don't think it is should be our (CPython) responsibility to
>>> keep track and maintain the list of the core devs of alternate Python
>>> implementations. Don't they have their own community / website? They
>>> have their own repo, bug tracker, governance model, and everything,
>>> right?
>>> 
>> 
>> Agreed. We have a hard enough time keeping track of our own core
>> developers.
>> 
> 
> I don't really think we have a hard time doing this. The only
> problem is that we never sat down and actually properly recorded
> this in one place.
> 
 
 I was specifically thinking of a way to stay in touch with core devs, or
 more specifically a way to send them email. In the past, before we moved to
 github, I took it upon myself to find email addresses (current or not) for
 all core devs, and I gave up without much success.
 
 I agree that we could probably come up with a list of names for people
 who have been given the "core dev" status.
 
 For our core devs, can't we just say that the CPython core devs are
>> those with commit bits on the CPython repo? I realize that will
>> eliminate some people who have been core developers and never moved to
>> github, but if they bring it to our attention, we can add them easily
>> enough.
>> 
> As discussed before, being a core developer is a status you
> gain and never lose. There is a clear difference between have
> commit rights to the (current) repo and this status.
> 
 
 Agreed. Again, this was in the (poorly conveyed) context of getting email
 addresses for them, or at least being able to contact them.
 
 Eric
 
 ___
 python-committers mailing list
 python-committers@python.org
 https://mail.python.org/mailman/listinfo/python-committers
 Code of Conduct: https://www.python.org

Re: [python-committers] And Now for Something Completely Different

[Donald Stufft]

> On Jul 25, 2018, at 2:01 PM, Brett Cannon  wrote:
> 
> Right, and your proposal means I now have to judge proposed core developers 
> on which side of popular opinion they will come down on in hopes that they 
> vote in ways I agree with and thus help take the language in a direction I 
> think is appropriate.

It makes me think a bit of the US Supreme Court, where judges who might someday 
want to be on that court, learn to be very careful about hiding their true 
opinions (without directly lying of course) on a number of very controversial 
topics, knowing that coming out for/against them is likely to blow up their 
changes of ever progressing to that point.___
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] And Now for Something Completely Different

[Donald Stufft]

> On Jul 19, 2018, at 7:47 PM, Victor Stinner  wrote:
> 
> It seems that the main question for a new governance is how to take a
> decision on PEPs (accept or reject them with some variants like
> Deferred). I read that core developers are unable to make a decision
> themselves (fail to reach a consensus) and that letting core
> developers decide would make Python "inconsistent" (as if only a
> single BDFL is able to keep Python consistent). I also read that the
> BDFL is required to make unpopular decisions to enhance Python.

I think the core difference behind all of the proposals, when you get down to
brass tacks, will be the vision for where the langauge goes. There are
independently good ideas that maybe should not be accepted, because they
compromise the vision for the worse, or ideas that seem poor on the tin but that
once they get added they mesh well with the overall language.

The further you scale up the number of people directly deciding the direction
of the language, the more likely you will find inconsistency. No two people have
the same design sense, and so if you ask two people you're likely to get at
least two answers.

Of course with many things, there are grey areas. If you have some sort of
council of N developers, with a small enough N you can arrive at a place where
the design sense for all of N are closely enough aligned that the inconsistency
produced by them are minor enough as to not be noticeable. However, the larger
you make that group, the more likely you are to introduce larger and larger
inconsitencies.

Now, that doesn't mean that focusing on consistency to the end of all other
things is the right choice. The laws of any democratic country tend to be
extremely inconsistent, due to that very reason, but most people would not argue
that we should revert democracy back to dictatorships in those countries.

Democracy brings with it more power to the "masses" and helps protect against
a sole leader drastically going against the will of "the people" over an
extended period of time.

So realistically, the choice comes down to whether we value consistency more
(in which case, we'd want to favor solutions that have a small N) or more
directly empowering people with a democracy.

Of course, you could try to do something that combines the two of them. You
could elect a BDFL, but have PEPs go through a vote process first where they
need to get a simple majority, and at which point the BDFL could approve or
veto, and if they veto, then the voting body gets an additional chance to vote
and if they're able to get a larger majority (2/3?) then they can override the
BDFL's veto. That provides some protections from both a "design by committee"
effect (since the BDFL can veto) but also provides very popular proposals a
chance to pass even if the BDFL is against them.

The big loss of that compromise is that you again, give up some of the
consistency, since a large enough group of developers can still introduce an
inconsistent vision and you remove the ability for the BDFL to accept unpopular
but long term necessary PEPs (since they'd have to get a simple majority first).


___
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] An alternative governance model

[Donald Stufft]

> On Jul 18, 2018, at 7:06 PM, Fred Drake  wrote:
> 
> PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> superseded, recycling the PEP number seems out of character with the
> RFC process from which we derived the PEP process.  Let's be cautious
> about recycling like that; integers are cheap.

Amusingly, I went through the low numbered PEPs as a result of this, and found 
https://www.python.org/dev/peps/pep-0010/ 
.___
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)

[Donald Stufft]

> 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] Changing commiter status

[Donald Stufft]

> On Jun 19, 2018, at 1:35 PM, Victor Stinner  wrote:
> 
> My intent is to maintain a list of active core developers. If an
> inactive core dev becomes active again, they should be able to
> retrieve quickly the "active" status. Is "emeritus" still a good name
> with such constraint?


Yes. Dropping the permission bits of inactive developers really only works if 
those developers can more or less no questions asked get those permissions back 
whenever they want them. Otherwise it’s not really a “we’re just trimming 
permission lists for security” thing anymore.___
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] Wrongly stopping merges discourages merging.

[Donald Stufft]

I’d also add that it is generally a good thing that people with power and a 
voice (e.g. the core devs) are having a similar experience that an external 
contributor would. This is our best line of defense against the external 
contributor experience degrading to a bad place. By having core devs share a 
similar experience, we can get feedback like the one about AppVeyor and try to 
improve things for everyone, instead of simply giving core devs a way to opt 
out of the pain. 

Sent from my iPhone

> On Jun 4, 2018, at 1:54 PM, Brett Cannon  wrote:
> 
> Please realize that every time we have switched off CI, we have ended up with 
> a broken branch, so it's a trade-off between these occasional hiccups or 
> occasionally broken branches (and as Victor has pointed out, we are not 
> always good as a group about making sure we notice when stuff breaks). Also 
> note that because we now have branches that are almost always stable we have 
> users who actually run from a checkout directly instead of waiting for a 
> release (which also benefits us by helping to surface bugs earlier than e.g. 
> an RC).

___
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] number of active core devs [was: Comments on moving issues to GitHub]

[Donald Stufft]

Is that a 50% reduction or is that just 50% of the people who could be active 
are? 

Sent from my iPhone

> On Jun 2, 2018, at 8:33 PM, Ethan Furman  wrote:
> 
>> On 06/02/2018 12:46 PM, Mariatta Wijaya wrote:
>> 
>> And perhaps this is to be discussed in a separate thread: even though in the 
>> b.p.o we appear to have 170 committers,
>> really there are 90 core devs (people who has commit right to CPython on 
>> GitHub). and out of those 90, I think only
>> about half are currently active (since the migration to GitHub).
> 
> 50% reduction in activity?  Ouch.
> 
> --
> ~Ethan~
> ___
> 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] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Donald Stufft]

> On May 30, 2018, at 3:03 PM, Larry Hastings  wrote:
> 
> Yes, ISTM that the Dev Guide covers this.  The section on priority says:
> Triagers may recommend this priority and should add the release manager to 
> the nosy list.
> In other words: if a dev thinks an issue should be a release blocker for 
> version X, they should add the RM to the nosy list and make a comment 
> recommending the issue be escalated to release blocker.  I thought it was 
> telling that it doesn't instruct triagers to mark the issue as a release 
> blocker themselves.


That seems a rather poor way of handling it TBH. A key thing is that an 
escalation for a decision should itself be a release blocker, because if 
someone thinks the issue might be, then we should get a decision on whether it 
is or not before the release goes out. Relying on a comment seems far too easy 
for the release manager to accidentally miss it or forget about it.___
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] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Donald Stufft]

> On May 30, 2018, at 1:15 PM, Larry Hastings  wrote:
> 
> ISTM that opinions vary on what constitutes a "release blocker", and maybe 
> empowering only the release managers to make that call would be a good way 
> forward--which is what ISTM is what the Dev Guide already says anyway.  But I 
> guess not!

I think that RMs are empowered to decide what is a “real" release blocker, but 
you need some mechanism to flag an issue as potentially a release blocker for 
the RM to make a decision on it. Making a decision on that potentially release 
blocker should also itself be a release blocker (because if it’s possibly a 
release blocker, then we should treat it as such until the person empowered to 
make that call has decided one way or another).

So I think for the system to work, you need to either allow anyone to flag an 
issue as a release blocker, and the RM is empowered to say “No this really 
isn’t” and unflag it, or you need two flags, for release blocker, and maybe 
release blocker, and both block the release.___
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] A different way to focus discussions

[Donald Stufft]

> On May 24, 2018, at 2:05 PM, Antoine Pitrou  wrote:
> 
> 
> Le 24/05/2018 à 20:02, Brett Cannon a écrit :
>>> Just trying to
>>> understand how Discourse would be different enough to solve the issue
>>> you're having.
>> 
>>Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
>>really work for PEP discussions, IMO.  That's why I asked about
>>Discourse.
>> 
>> Fair enough. Would you want a PEPs section and then some naming
>> convention per thread to denote which PEP a thread is about?
> 
> That could work.  I'm not acquainted with Discourse, are there subsections?


Yes, you can nest sections as deeply as you want, but the sections are 
typically static (I mean they can change over time, but making one per PEP 
would be a weird use of discourse).

___
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] A different way to focus discussions

[Donald Stufft]

> On May 22, 2018, at 5:50 PM, Victor Stinner  wrote:
> 
> IMHO the discussions on the PEP 572 became a mess because nobody
> wanted to moderate the discussion. I asked on python-committers how to
> calm down the discussion, but no action has been taken and the flow of
> emails didn't stop.

FWIW, I think this is a key thing— Mailing lists are not easily moderatable. 
There’s no way to pause discussion, redirect, etc besides generating *more* 
email (and the tooling to do it is lackluster, it’s pretty much just asking 
people to do something, and hope everyone complies). Fracturing the discussion 
amongst multiple repos is one way of handling that, another option is better 
tooling for moderation.___
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] Security: please enable 2-factor authentication on GitHub and your email

[Donald Stufft]

> On Dec 11, 2017, at 2:52 PM, R. David Murray  wrote:
> 
> If 2fa is required for contribution to CPython, I'll stop
> contributing. 

I’m curious why? I have it on and 99% of the time you don’t even notice because 
you’re already logged into GitHub and pushes/pulls don’t require it.___
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] Security: please enable 2-factor authentication on GitHub and your email

[Donald Stufft]

> On Dec 11, 2017, at 9:35 AM, Paul Moore  wrote:
> 
> Maybe I didn't understand it. Doesn't that leave me in precisely the
> same situation as a username/password, in that I have a single set of
> credentials I can use? Or is the fact that it's tied to the specific
> machine the point here? If so, then thanks, I can certainly use that
> should someone decide that mandating 2FA is a good idea (I still
> maintain that recommended but not mandatory is better, as my GH
> account is not used solely for CPython development, so making such a
> change has wider effects than just for this project).

It is true that this weakens the guarantees of 2fa (as does allowing 
authentication using a SSH key!). In general this trade off is worth it because 
the authority granted by those credentials is limited (in this case, I believe 
you can only push/pull with them, you can’t do anything else on the account) 
and they’re typically only used in contexts where leaking the credential is far 
far harder. As a bonus, they’re not going to be shared between multiple 
services.

So yea, it’s not as good as 2FA only everywhere, but the specific circumstances 
around these specific credentials makes it a reasonable usability trade off to 
allow them.___
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] Security: please enable 2-factor authentication on GitHub and your email

[Donald Stufft]

> On Dec 11, 2017, at 8:04 AM, Paul Moore  wrote:
> 
>> On 11 December 2017 at 12:29, Donald Stufft  wrote:
>> 
>> On Dec 11, 2017, at 7:03 AM, Paul Moore  wrote:
>> 
>> Um, I use https not ssh, as for at least some of the time I'm behind a
>> firewall that only allows https, not ssh traffic. (I know, I'm sorry -
>> I can probably be the worst possible corner case for *any* suggestion
>> that gets made :-))
>> 
>> 
>> 
>> https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line
> 
> I use username and password and git credential manager. Uses the OS
> password store. I don't know of any way that 2FA integrates with that.
> If someone can tell me how it does (and it's as unobtrusive as, say
> gMail which only prompts me if I log on via a previously unused
> machine) then that's fine. Otherwise not so much.
> 
> Paul


Did you read the linked section? You generate a limited scope access token and 
use that in place of your password for command line usage via https.
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Donald Stufft]

> On Dec 11, 2017, at 7:03 AM, Paul Moore  wrote:
> 
> Um, I use https not ssh, as for at least some of the time I'm behind a
> firewall that only allows https, not ssh traffic. (I know, I'm sorry -
> I can probably be the worst possible corner case for *any* suggestion
> that gets made :-))


https://help.github.com/articles/providing-your-2fa-authentication-code/#through-the-command-line
 
___
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] OK to back-fill "awaiting" labels on open issues?

[Donald Stufft]

> On Oct 6, 2017, at 5:36 PM, Alex Gaynor  wrote:
> 
> Can we please use a phrase for re-triggering a review that makes more sense 
> like "I've updated the patch, please re-review", rather than magic inside 
> baseball language?
> 


+1

___
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] How does GitHub count contributors?

[Donald Stufft]

> On Jun 24, 2017, at 11:05 AM, Antoine Pitrou  wrote:
> 
> 
> Hello,
> 
> This is a bit of a futile question, but I realize I'm nowhere to be seen
> in https://github.com/python/cpython/graphs/contributors
> 
> Is there some map file somewhere that I must update to match my commit
> e-mail to my GitHub account?



That’s interesting, have you used multiple email addresses with the Python VCS 
history by any chance? If so you can add them all to your Github account and it 
should associate all of them with you. 

—
Donald Stufft



___
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] Revert changes which break too many buildbots

[Donald Stufft]

I’m +1 on reverting the change, I’d even go so far to say I’d be +1 on doing it 
as a first response. It’s always possible to revert the revert once the person 
who committed the patch has time to investigate the failure and recommit the 
patch with a fix.

> On Jun 14, 2017, at 5:00 PM, Victor Stinner  wrote:
> 
> 2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
>> I think we first should make buildbots notifying the author of a
>> commit that broke tests or building, so his can either quickly fix the
>> failure or revert his commit.
> 
> Hum, I think that I should elaborate my previous email.
> 
> It's usually easy to identify a commit which introduced regressions if
> you compare 2 or 3 failing buildbots and their list of changes. So
> when I identify the commit, if I cannot fix the issue immediately,
> usually I leave a message on the issue (bugs.python.org). So the
> author but also other people who worked on the issue are well aware of
> the regression.
> 
> In my experiemnce, it's rare that I get any feedback in less than 24h,
> while slowly more and more buildbots become red. It depends on the
> availability of the commiter.
> 
> Since I'm trying to always keep the highest number of green buildbots,
> I prefer to try to fix the bug myself.
> 
> My question is what to do if I'm unable to fix the issue and the
> author is not available. Keep a broken CI for hours, sometimes for
> days. Or revert the change to reduce the pressure and get more time to
> write a *proper* fix?
> 
> I propose to revert to get more people at the issue to find the best
> option, rather than urging to push a quick & dirty fix.
> 
> Hopefully, in most cases, the bug is trivial and I consider that the
> fix doesn't require a review, so I push it directly.
> 
> 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/


—
Donald Stufft



___
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] No Travis-CI on OS X?

[Donald Stufft]

> On May 2, 2017, at 5:35 PM, Antoine Pitrou  wrote:
> 
> 
> Hi,
> 
> Perhaps it would be possible to set up a Travis CI matrix entry for OS
> X, those builds are often quite slow but at least it could be part of
> the "allowed failures" suite.  That would help detect platform issues at
> PR time rather than later :-)
> 


I think the only reason we don’t have them on is because the macOS builds on 
Travis are _Super_ slow and regularly get a large backlog. Fast Finish and 
Allowed Failures would help with that though.

—
Donald Stufft



___
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] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 3:42 PM, Donald Stufft  wrote:
> 
> 
>> On May 2, 2017, at 3:09 PM, M.-A. Lemburg > <mailto:m...@egenix.com>> wrote:
>> 
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
> 
> 
> This is not really accurate to my experience using GitHub. In pip for example 
> while we have distutils-sig and a pypa-dev mailing list we hardly ever use 
> them for pip focused discussion. The vast bulk of our discussion (including 
> quite long ones, and I think most folks who end up in a discussion with me 
> know I can produce a fair amount of content in one) occur entirely within 
> GitHub and it works just fine. I don’t think this is unique to pip either. 
> Pretty much the only time we use anything but GitHub are when the blast 
> radius for a change is larger then pip itself (e.g. something that touches 
> pip, setuptools, and pypi) which we use distutils-sig for, or when something 
> is just a notice that doesn’t require discussion, which we use pypa-dev for.
> 
> I agree that there are benefits to separating code review and issue tracking 
> (although I’m not a purist about it, I think some PRs are too small to 
> warrant an issue for instance) and I think that without some effort to 
> automate and write a bot GitHub issues are not a good fit for replacing bpo. 
> However I think it’s going to be a regular struggle to get people to try and 
> primarily use bpo for issue discussion (vs code review) because the friction 
> of doing so is fairly high. I think if you want to encourage people to 
> utilize bpo better, your best bet is to do everything you can to reduce that 
> friction.
> 


To touch on this a bit more, arguably GitHub is *more* suited to long form 
discussion, given that it includes the ability to format your text which is an 
incredibly important part of producing readable content more then a few 
sentences long. You can attempt to apply some of this with bpo using ASCII 
representations, but an inlined URL or a footnote to the URL is never going to 
be as good as a hyperlink, or an inlined image, or bold, italics, etc.


—
Donald Stufft



___
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] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 3:09 PM, M.-A. Lemburg  wrote:
> 
> This doesn't have much to do with UX/UI. It's mainly a questions
> of culture. Github is more geared up for a culture of quick chat
> style comments, whereas bpo has traditionally seen a more elaborate
> in-depth discussions style.


This is not really accurate to my experience using GitHub. In pip for example 
while we have distutils-sig and a pypa-dev mailing list we hardly ever use them 
for pip focused discussion. The vast bulk of our discussion (including quite 
long ones, and I think most folks who end up in a discussion with me know I can 
produce a fair amount of content in one) occur entirely within GitHub and it 
works just fine. I don’t think this is unique to pip either. Pretty much the 
only time we use anything but GitHub are when the blast radius for a change is 
larger then pip itself (e.g. something that touches pip, setuptools, and pypi) 
which we use distutils-sig for, or when something is just a notice that doesn’t 
require discussion, which we use pypa-dev for.

I agree that there are benefits to separating code review and issue tracking 
(although I’m not a purist about it, I think some PRs are too small to warrant 
an issue for instance) and I think that without some effort to automate and 
write a bot GitHub issues are not a good fit for replacing bpo. However I think 
it’s going to be a regular struggle to get people to try and primarily use bpo 
for issue discussion (vs code review) because the friction of doing so is 
fairly high. I think if you want to encourage people to utilize bpo better, 
your best bet is to do everything you can to reduce that friction.

—
Donald Stufft



___
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] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 2:37 PM, Eric V. Smith  wrote:
> 
> On 5/2/17 2:13 PM, Guido van Rossum wrote:
>> I'm not necessarily disagreeing, I'm just skeptical that we can stop
>> this tide. New contributors are familiar with GitHub and GitHub only,
>> and for them, BPO looks and feels like a legacy system. And honestly,
>> for smaller projects, I've found GitHub a very effective place to have
>> discussions (e.g. most mypy design work is done there). Though I agree
>> that GitHub currently doesn't scale to the size of CPython unless you
>> work hard on setting up filtering (which *is* possible, just done very
>> differently).
> 
> I grant that it's an uphill battle. But even github has a separate issue 
> tracker, we're just not using it. So even github black belts should be 
> familiar with the concept of an issue tracker being used for a different 
> purpose than code reviews are.
> 


I suspect part of it may simply be that mucking around with b.p.o is far less 
streamlined then GitHub issues or PRs. One thing we might want to look at is 
making it possible to login with GitHub to b.p.o, as that is one possible 
hurdle for someone to cross when looking at making a comment on a PR/issue.

The flip side of that is even prior to using GitHub it wasn’t like all of the 
discussion was happening on b.p.o either, some of it happened in Reitveld 
(though less of it than is happening on GitHub because using Reitveld is/was 
more frustrating than a GitHub comment) and a lot of it happened in random back 
channels between individuals.

Ultimately, it’s likely to be a Sisyphean battle to stop it from happening 
unless b.p.o gets updated to have a UX on par with GitHub and the integration 
between the two of them makes it as low friction as possible.


—
Donald Stufft



___
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] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 1, 2017, at 6:32 PM, Christian Heimes  wrote:
> 
> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.
> 



Add yourself to https://github.com/python/cpython/blob/master/.mention-bot 
<https://github.com/python/cpython/blob/master/.mention-bot> using:

"alwaysNotifyForPaths": [
  {"name": "tiran", "files": ["Lib/ssl.py", "Lib/hashlib.py"]}
]

Include all the paths you want to _always_ be notified for globbing works as 
well.

Then anytime someone sends a PR that touches that, the mention bot with @tiran 
you (unless we turned it off….).

—
Donald Stufft



___
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] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

[Donald Stufft]

> On Apr 11, 2017, at 12:25 PM, Terry Reedy  wrote:
> 
> On 4/10/2017 11:55 PM, Martin Panter wrote:
>> On 11 April 2017 at 13:13, Mariatta Wijaya  wrote:
>>> "View Changes" doesn't work when commits in PR were squashed, which seems to
>>> be the case in https://github.com/python/cpython/pull/851
>>> 
>>> I wonder if there is a way to unsquash the commits? Will it help with
>>> reviewing this PR?
> 
>> In this particular pull request, I think the submitter has rebased
>> their commit, and force-pushed it. These days, I notice Git Hub seems
>> to forget old commits pretty soon after you force-push the branch they
>> are on. I don't think you can "unsquash" them retrospectively; you
>> would need a copy of the old commits saved somewhere.
>> 
>> Other times people add revised commits on top of their old commits,
>> which would have been easier for me in this situation, but I suspect
>> that makes it harder for the person pushing the final change if they
>> have to squash it into a single commit. (I noticed the eventual commit
>> message is often messy, redundant, automatically generated, etc.)
> 
> I was under the impression that the green [commit] button would do the 
> squashing.   Or at least that it could.
> 

Yes it can, and IIRC for CPython we have it set so it _only_ does that. 
Although the commit message may be ugly if you don’t adjust it in the text 
editor that pops up when GitHub asks you to confirm the merge since it by 
default just concats all of the commit messages into a list so you might get a 
commit message like:

* implement feature

* fix thing

* ugh

* address review

Instead of a nice clean one. That’s going to be up to the person hitting the 
merge button to edit the commit message to be clean though.

—
Donald Stufft



___
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] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

[Donald Stufft]

If someone makes a review on github (as opposed to a simple comment) I believe 
the state of the code as it was when that review as made can be viewed by 
hitting the “View Changes” button next to that review in the timeline.

> On Apr 10, 2017, at 3:18 PM, Guido van Rossum  wrote:
> 
> Thanks for the clarification. We should probably move this discussion to the 
> python-committers list rather than core-mentorship.
> 
> On Mon, Apr 10, 2017 at 12:12 PM, Terry Reedy  <mailto:tjre...@udel.edu>> wrote:
> On 4/10/2017 12:54 PM, Guido van Rossum wrote:
> So the response from Martin Panter
> (https://github.com/python/cpython/pull/851#issuecomment-292755992 
> <https://github.com/python/cpython/pull/851#issuecomment-292755992>)
> sounds like he's not set up for the new GitHub workflow. I'm CC'ing
> Martin here.
> 
> The specific issue Martin raised is "Sorry but I don’t have an easy way to 
> see your fixes relative to the old version I reviewed."  If the original and 
> modified patches were posted in proper format to b.p.o., then one could hit 
> [review] to start Rietveld and request a side-by-side diff of the two 
> versions.  This is perfect for reviewing responses to comments, especially 
> those made in-line.  For this issue, Martin made about 20 inline comments.
> 
> I don't see any way to get the equivalent on a github PR.  It appears that 
> the original patch is replaced by the revised patch.  To me, Rietveld was a 
> great review tool and its loss a regression in the work process. I hope that 
> this can be fixed somehow.
> 
> tjr
> 
> 
> 
> ___
> Core-mentorship mailing list
> core-mentors...@python.org <mailto:core-mentors...@python.org>
> https://mail.python.org/mailman/listinfo/core-mentorship 
> <https://mail.python.org/mailman/listinfo/core-mentorship>
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> ___
> 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/


—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
> 
> Is the mention bot helpful? (Our config is at 
> https://github.com/python/cpython/blob/master/.mention-bot 
> <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are 
> at https://github.com/facebook/mention-bot 
> <https://github.com/facebook/mention-bot>)


Just as an FYI, I’ve turned the mention-bot down from mentioning a max of 5 to 
a max of 3 reviewers. I’m not sure if this is going to help or not, but at the 
very least it will reduce the number of people getting notified (and thus 
hopefully, the total number of notifications). If the touched-it-last algorithm 
is still not useful then that might be all the more it helps, but it might also 
be a problem trying to get too many useful reviewers out of touched-it-last.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 12, 2017, at 9:12 PM, Brett Cannon  wrote:
> 
> Already have. We got 25 jobs shared between python, pypa, and pyca thanks to 
> Donald. At this point the best option we have to speed things up is to 
> consider dropping tests (e.g. do we want to keep the C++ header test, or do 
> we really need to test both clang and gcc?).



Just to let everyone know, this hadn’t been activated yet, but as of this 
morning it is. So we should now be getting 25 concurrent jobs shared between 
the three projects. I think this will work out well because it gives us 25 job 
burst and it’s unlikely that all orgs are having high activity at the same time 
(except maybe at something like PyCon, but that is going to be an issue either 
way ;) ).


—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 13, 2017, at 11:54 AM, Barry Warsaw  wrote:
> 
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got closer
> to solving Raymond's comment.  If the domain expert could be notified when PRs
> touch stuff they care about, that might be better.  The mentionbot could then
> be opt-in for folks who want to see more detail.


So mention-bot supports that, it just needs configured. I suspect though that 
it’s touched-it-last mentioning will get better once we get more people with 
commits under their actual name.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 11, 2017, at 9:30 PM, Martin Panter  wrote:
> 
> I am also aware of
> <https://github.com/python/cpython/blob/master/.mention-bot 
> <https://github.com/python/cpython/blob/master/.mention-bot>> but
> haven’t added myself there yet.


Yea this is what I meant, adding your name to the ``userBlacklist`` array.

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 11, 2017, at 3:03 AM, Zachary Ware  
> wrote:
> 
>> 
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot 
>> <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are
>> at https://github.com/facebook/mention-bot 
>> <https://github.com/facebook/mention-bot>)
> 
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?


There’s no way to make it opt-in except by having people explicitly list what 
files they want to be notified on (either on an always basis, or on a “if you 
couldn’t find enough people through your heuristics” basis).

—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 8:38 PM, Martin Panter  wrote:
> 
>> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
>> at https://github.com/facebook/mention-bot)
> 
> On 11 March 2017 at 00:32, Donald Stufft  wrote:
>> I’ve found it helpful thus far. It’s poked me on a  few issues and I jumped
>> in and gave a review on them. There is too much churn in python/cpython for
>> me to get notified of every issue. I suspect as we get more people
>> submitting PRs (and thus, retaining author) it will get more diverse in who
>> it notifies as well.
> 
> I dislike it. At the moment I have the Git Hub repository blocked, but
> this means I can’t even subscribe myself to interesting threads any
> more. I think there were way too many useless emails (lacking context,
> uninteresting to me, etc). It is automated spam.
> 
> I encourage you to remove it, or at least make it opt-in. Perhaps you
> can encourage contributors to look themselves at the “experts” list,
> history of the relevant code, or whatever, to find potential people to
> invite to a Git Hub discussion.


You know you can tell it not to message you?


—
Donald Stufft



___
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] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 5:13 PM, Brett Cannon  wrote:
> 
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday when 
> we moved. :)
> 
> First, I hope people are not regretting letting/having me make this 
> migration. I know there have been some things to work through (and others 
> still to come), but I hope this is all a net positive (either now or in the 
> near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> Requiring Travis to pass (I really don't want to turn this off as we already 
> had a broken build when I temporarily turned it off at someone's request when 
> Travis was backed up from the AWS S3 outage; I also don't plan to make 
> AppVeyor required unless there's a way to make it be skipped for doc-only 
> changes)

I agree with not wanting to turn off mandatory CI. It’d be nice to get as much 
coverage of platforms as we can as required CI on a per-merge basis, but there 
is obviously a balance to be had here between quick responses and maximal 
coverage.

> Cherry-picking working out? (We can go back to forward merging if people 
> really want to, but I think long-term cherry-picking will allow for more 
> automation)
> Along with that, are the labels for cherry-picking working out? (Some devs 
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's 
> more obvious in emails so I don't know if the labels are really that useful)

For the couple of things I’ve done I’ve not had any problem with it.

One thing I noticed that might be weird is that Misc/NEWS is kind of weird now. 
On `master` it only contains entries for 3.6 up until the point that 3.6 was 
branched off of `master` (or more specifically in this case, since we migrated 
to a cherry-picking work flow). This will likely cause some issues now that I 
think about it with the stuff in #python/core-workflow#6 because files added to 
`master` between the last release of X.Y and when X.Y gets branched off of 
`master` are going to show up as new in X.Y+1. This could be resolved I think 
by, immediately altering branching X.Y off of `master`, deleting all pending 
news files and also cherry-picking the “compile” step of say, 3.6 into the 
`master` branch (and so on up the line). Alternatively still do the delete 
thing, but make the ``Misc/NEWS`` specific to a particular release series.

> Is the mention bot helpful? (Our config is at 
> https://github.com/python/cpython/blob/master/.mention-bot 
> <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are 
> at https://github.com/facebook/mention-bot 
> <https://github.com/facebook/mention-bot>)

I’ve found it helpful thus far. It’s poked me on a  few issues and I jumped in 
and gave a review on them. There is too much churn in python/cpython for me to 
get notified of every issue. I suspect as we get more people submitting PRs 
(and thus, retaining author) it will get more diverse in who it notifies as 
well.

> Anything to tweak about the coverage bot and reports? (Our config is at 
> https://github.com/python/cpython/blob/master/.codecov.yml 
> <https://github.com/python/cpython/blob/master/.codecov.yml> and docs at 
> https://docs.codecov.io/docs/codecov-yaml 
> <https://docs.codecov.io/docs/codecov-yaml>)
> Third, I wanted to point out some of the more critical discussions going on 
> at https://github.com/python/core-workflow/issues 
> <https://github.com/python/core-workflow/issues>. Specifically, 
> https://github.com/python/core-workflow/issues/6 
> <https://github.com/python/core-workflow/issues/6> is working towards a 
> solution for Misc/NEWS so if you care about the final solution you should 
> participate there. After Misc/NEWS is solved the next step becomes solving 
> the cherry-picking overhead with a more automated approach. We are also 
> discussing closed branches to make the list of branches more manageable at 
> https://github.com/python/core-workflow/issues/31 
> <https://github.com/python/core-workflow/issues/31>.
> 
> Fourth, the lack of messages showing up on bugs.python.org 
> <http://bugs.python.org/> after a commit is being tracked at 
> http://psf.upfronthosting.co.za/roundup/meta/issue613 
> <http://psf.upfronthosting.co.za/roundup/meta/issue613>. I'm sure Ezio and 
> Maciej would appreciate any help people may be able to volunteer to help in 
> solving the problem.
> 
> Fifth, anything I missed? :)
> ___
> 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/


—
Donald Stufft



___
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] Please Publicize your Github Membership for Python

[Donald Stufft]

> On Mar 3, 2017, at 2:03 AM, Nick Coghlan  wrote:
> 
> - if your org info is public, but you don't want the mentions, then you can 
> add yourself to the blacklist in 
> https://github.com/python/cpython/blob/master/.mention-bot 
> <https://github.com/python/cpython/blob/master/.mention-bot> (as Guido has)
> - if you want to find your own reviewers for your PRs, add yourself to the PR 
> blacklist in the same file (as Benjamin has)


Note, this .mention-bot file is a JSON file, so if you want to exclude yourself 
you’ll need to add yourself to the list of the already existing keys.

—
Donald Stufft



___
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] Please Publicize your Github Membership for Python

[Donald Stufft]

> On Mar 3, 2017, at 2:03 AM, Nick Coghlan  wrote:
> 
> On 2 March 2017 at 23:20, Donald Stufft  <mailto:don...@stufft.io>> wrote:
> Hello!
> 
> Some of our automation needs to be able to determine who is a member of the 
> Python organization on Github to effectively work. Unfortunately it currently 
> can only see users who have publicized their membership in the Org, but so 
> far only 50 out of 138 current members have done so.
> 
> Providing some more specifics on the helper that needs this:
> 
> - Donald & Brett recently enabled https://github.com/facebook/mention-bot 
> <https://github.com/facebook/mention-bot> which tries to find and mention 
> relevant reviewers based on files touched in the commit
> - the bot only has access to public info, so if your org membership is 
> private, it will never mention you, so you may miss PRs you actually want to 
> review
> - if your org info is public, but you don't want the mentions, then you can 
> add yourself to the blacklist in 
> https://github.com/python/cpython/blob/master/.mention-bot 
> <https://github.com/python/cpython/blob/master/.mention-bot> (as Guido has)
> - if you want to find your own reviewers for your PRs, add yourself to the PR 
> blacklist in the same file (as Benjamin has)
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com <mailto:ncogh...@gmail.com>   |   
> Brisbane, Australia


There’s also an option to *always* get notified for files that match a certain 
set of globs too.

—
Donald Stufft



___
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] Please Publicize your Github Membership for Python

[Donald Stufft]

Hello!

Some of our automation needs to be able to determine who is a member of the 
Python organization on Github to effectively work. Unfortunately it currently 
can only see users who have publicized their membership in the Org, but so far 
only 50 out of 138 current members have done so.

If you have a minute and are able to do that, it would be great.

It’s pretty easy to do, just go to https://github.com/orgs/python/people 
<https://github.com/orgs/python/people> and locate yourself on the list. Once 
you found yourself, if you look to the right hand side of your entry, you’ll 
see either the word “Private” or “Public”, if it says “Private”, click on it 
and select “Public” (https://s.caremad.io/MLlxY1W5r0/ 
<https://s.caremad.io/MLlxY1W5r0/>). That’s all you need to do.


Thanks a lot!

—
Donald Stufft



___
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] Disable Codecov on GitHub pull requests?

[Donald Stufft]

> On Feb 13, 2017, at 9:49 AM, Victor Stinner  wrote:
> 
> Hi,
> 
> I don't get the value of code coverage on a CI. I *like* running code
> coverage sometimes, but I don't like being annoying by "test failed:
> coverage -0,01%" by a change completely unrelated to code (note: this
> issue has been fixed be using a threshold of 1%). I'm annoyed by all
> these Codecov messages. Berker just told me that he even created a
> Gmail filter to drop all these email notifications...
> 
> What do you think of keeping this very useful feature, but not use it
> on pull requests: only run it on the branches (once changes are
> merged), to not "pollute" pull requests?
> 


I think it’s incredibly useful on PRs, particularly because it can tell you if 
the PR has actually covered every line that it’s added or not. If you’re only 
periodically running coverage, then in my experience you generally miss 
covering a lot of lines accidentally. I’ve also never see the random -0.01% 
coverage of code in another project, and my guess is that there is some sort of 
non-determinism in the CPython test suite that would be a good idea to make 
deterministic anyways.

As with Alex, most projects I’ve been involved in turn off the comments and 
rely on the status checker.


—
Donald Stufft



___
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] Discussions on PRs

[Donald Stufft]

> On Feb 13, 2017, at 5:49 AM, Stefan Krah  wrote:
> 
> What I
> see now is that patches without comments emerge really fast:
> 
>https://github.com/python/cpython/pull/65 
> <https://github.com/python/cpython/pull/65>


It looks like the person in question is commenting on the issue tracker.

—
Donald Stufft



___
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] We are now live on GitHub!

[Donald Stufft]

> On Feb 10, 2017, at 6:19 PM, Brett Cannon  wrote:
> 
> While this doesn’t solve all testing scenarios (e.g. this doesn’t test a 
> macOS or Windows-related change due to the added hours it take for a PR to be 
> “green” when run on Travis for macOS or AppVeyor for Windows)


Just an FYI, I was talking to a friend in Travis and he suggests in the next 
few weeks they’re going to get a lot more macOS capacity. We might want to try 
this again in a few weeks and see if their new capacity is enough that the lead 
time is good enough.

—
Donald Stufft



___
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] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

[Donald Stufft]

If we want the version to be PEP 440 compliant it'd be like 3.6rc1.dev0 or so 
if I remember correctly. 

Sent from my iPhone

> On Nov 22, 2016, at 3:40 PM, Steve Dower  wrote:
> 
>> On 22Nov2016 1150, R. David Murray wrote:
>> Being who we are (precisionist programmers), the inconsistency between
>> "beta release cuts off features" and "last beta before RC cuts off
>> non-release-critical fixes" does produce some cognitive dissonance.
>> I've seen the RC described as "the first beta that might be turned into
>> the production release", and if you think of it that way it makes it
>> easier to remember that we're restricting commits in order to produce that
>> "special beta".  That is probably better, conceptually, than producing
>> an RC that we fully expect will require release-critical bug fixes because
>> we just committed a bunch of non-release-critical bug fixes, just
>> so cutoff-when-the-name-changes stays consistent.
> 
> It might also help if the version info was updated to (for example) 
> "3.6.0rc1-" rather than "3.6.0b4+", to emphasize that any work going on in 
> that branch is work against RC and not against a beta.
> 
> I'm not sure that a trailing '-' is the right way to mark this. Maybe 
> "rc1+dev" or similar?
> 
> Cheers,
> Steve
> ___
> 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] Temporary moderator needed for Distutils SIG

[Donald Stufft]

I can do this. 

Sent from my iPhone

> On Nov 12, 2016, at 5:04 PM, A.M. Kuchling  wrote:
> 
> I'm going on vacation starting this Tuesday November 15th, and won't
> have much Internet access, and perhaps none at all, until I get back
> on November 30th.  Could someone please take over moderating the
> Distutils-SIG mailing list?  There's enough moderated traffic (list
> messages, spam, misdirected help requests) that it can't be left
> 
> If you want to volunteer, please send me your e-mail address and then
> I'll e-mail you an admin password privately.  You can either stay on
> as a moderator once I get back, or I can remove you.
> 
> I'm also moderator for a few other lists that are largely inactive
> such as medusa-dev and psf-redesign; the only mail that arrives is
> spam, and spam can just sit for two weeks until I delete it, so we
> don't need to bother about them.
> 
> (I couldn't think of a better place to ask for help; the Meta-SIG
> seems largely inactive, so I ruled it out.)
> 
> --amk
> ___
> 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] The peps repo is now on GitHub!

[Donald Stufft]

> On Jun 16, 2016, at 1:38 AM, Barry Warsaw  wrote:
> 
> On Jun 15, 2016, at 06:59 PM, Donald Stufft wrote:
> 
>> Currently there’s nothing preventing people from pushing directly to
>> the PEP repository, in https://github.com/python/peps/issues/5 there’s
>> talk of setting up Travis to ensure the PEPs are always building and
>> if the flag is set to require a +1 from Travis, then all changes will
>> need to go through PRs.
> 
> Yes, I agree that's where we want to end up.  It might make sense to
> allow PEP editors to push directly for $reasons, but I don't know if
> that's possible.

If we want to give a group of people the ability to override the status check
we just need to give that group of people Administrator access to the repository
so we could add a “PEP Editors” group if we didn’t want to give the entire
Python Core team such permission.

I’m unsure if that means that they can push directly or not, or if that
only means they can merge a PR that doesn’t have the requisite passing status
checks.

—
Donald Stufft



___
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] The peps repo is now on GitHub!

[Donald Stufft]

> On Jun 15, 2016, at 6:55 PM, M.-A. Lemburg  wrote:
> 
> On 16.06.2016 00:48, M.-A. Lemburg wrote:
>> On 16.06.2016 00:42, Brett Cannon wrote:
>>> I don't think anything has fallen over, so I'm calling this a successful
>>> migration! The peps repo is now https://github.com/python/peps .
>> 
>> Thanks for putting so much hard work into this !
> 
> BTW: Is it ok to push directly into the PEP repo or should we
> (as PEP authors) always go through PRs which we then merge into
> the repo ?
> 


Currently there’s nothing preventing people from pushing directly to the PEP 
repository, in https://github.com/python/peps/issues/5 there’s talk of setting 
up Travis to ensure the PEPs are always building and if the flag is set to 
require a +1 from Travis, then all changes will need to go through PRs.

—
Donald Stufft



___
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] We will be moving to GitHub (hopefully) in 2016

[Donald Stufft]

> On Jan 4, 2016, at 7:06 PM, Trent Nelson  wrote:
> 
> Hey Brett, all,
> 
> I’m playing a bit of catch-up with e-mail, but it occurred to me some of the
> work I did getting PyParallel switched over to github could be of benefit.
> First thing that comes to mind is this wiki page where I tried to capture the
> steps I used for the conversion and subsequent keeping-in-sync:
> 
> https://github.com/pyparallel/pyparallel/wiki/Source-Control
> 
> They’re very rough notes but may prove useful.  Should *hopefully* be
> repeatable.  One issue I noticed after the fact is that a couple of the 
> renames
> that happened when we went 2.x->3.x (like ConfigParser.py -> configparser.py)
> didn’t get picked up by the hg->git conversion so I had to manually fix them
> with commits like this:
> https://github.com/pyparallel/pyparallel/commit/d3654f13048c8d6185a4c4b7953cbe8bd46b5d83
> 
> (I’ll be able to produce a proper list of the exact ones I had to fix… I just
> wanted to get this e-mail out there for now.)

You probably did this on OS X or another case insensitive filesystem yea? I had 
the same problem the first time I did the CPython demo repository, until I did 
it on Linux instead.

> 
> (That repo is sync’d up to around 3.5-ish (i.e. as of a few months ago)… all
> the PyParallel stuff lived in separate *-px branches that originated from
> 3.3.x-ish.  Obviously we wouldn’t use that repo directly… or at least not
> without git filtering out my PyParallel stuff.)
> 
> I also made some changes to things like the buildinfo glue to work with git
> instead of hg:
> 
> https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/diffs/PCbuild/make_buildinfo.c.patch
> 
> I also updated the installer/msi.py to work with git but Steve’s since
> overhauled all this stuff so I’m not sure how useful it will be:
> 
> https://github.com/pyparallel/pyparallel/commit/ca64e60fd323875e2ca4af497d15d2f856f6c34d
> 
> What timeframe are we looking at?  There were some mentions of PSF funding in
> later e-mails which I think this sort of work (once off but still needs high
> precision) is well suited for.  I’ll throw my hat into the ring if the
> PSF<->Continuum want to formally book out some time.  (I’m happy to help 
> either
> way, but doing it formally at least guarantees time availability.)
> 
> Regards,
> 
>Trent.
> 
> On Fri, Jan 01, 2016 at 07:24:53PM +, Brett Cannon wrote:
>> If you want to read the reasons I chose GitHub over GitLab, see
>> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
>> If you want to discuss the decision or help with the transition, please
>> subscribe to the core-workflow mailing list.
>> 
>> Happy 2016 everyone, and here is to hoping we will have an easier developer
>> workflow by the end of this year!
> 
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
> 
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

[Donald Stufft]

I'm not sure that you'd see much savings. You'd only get deltas that were never 
merged to master excluded. Point taken though. 

Sent from my iPhone

> On Jan 4, 2016, at 4:18 PM, Brett Cannon  wrote:
> 
> 
> 
>> On Mon, 4 Jan 2016 at 13:14 Donald Stufft  wrote:
>> 
>>> On Jan 4, 2016, at 4:11 PM, Brett Cannon  wrote:
>>> 
>>> 
>>> 
>>> On Mon, 4 Jan 2016 at 13:08 Steve Dower  wrote:
>>>> I've found that hggit works very well - I used it to migrate my work 
>>>> project to github and still use it to avoid having to deal with git. (My 
>>>> intent is to keep using it for Python as well.)
>>>> 
>>>> Is the plan to migrate the entire history or just master?
>>> 
>>> TBD. Email beginning to outline the dependency graph for the transition 
>>> forthcoming once I finish a code review at work that some co-worker handed 
>>> to me when he went off to Australia for an extended holiday. ;)
>> 
>> 
>> It’s pretty easy to migrate the entire history (at least what’s in Hg) 
>> including all branches and tags.
> 
> It's not about the difficulty as the size of the clone. E.g., if we make 
> Python 2 a separate repo does it buy us a lot of space savings (we need to 
> remember not everyone has broadband, so there is some potential balance to be 
> had between history vs. clone size)?
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

[Donald Stufft]

> On Jan 4, 2016, at 4:11 PM, Brett Cannon  wrote:
> 
> 
> 
> On Mon, 4 Jan 2016 at 13:08 Steve Dower  <mailto:steve.do...@python.org>> wrote:
> I've found that hggit works very well - I used it to migrate my work project 
> to github and still use it to avoid having to deal with git. (My intent is to 
> keep using it for Python as well.)
> 
> Is the plan to migrate the entire history or just master?
> 
> TBD. Email beginning to outline the dependency graph for the transition 
> forthcoming once I finish a code review at work that some co-worker handed to 
> me when he went off to Australia for an extended holiday. ;)
> 


It’s pretty easy to migrate the entire history (at least what’s in Hg) 
including all branches and tags.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Donald Stufft]

> On Jan 4, 2016, at 3:51 PM, Barry Warsaw  wrote:
> 
> I once looked at it and decided it wasn't something I wanted to touch ;) so
> paying Eric to do it might not be a bad idea.


I’d prefer it if we didn’t financially support ESR since he likes to spout off 
racist and misogynistic garbage. I’m sure we can figure out how to successfully 
migrate from Hg to git. I’ve already done it once on the demo repo, if that’s 
not good enough I’ll work on it some more if need be.

---------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PSA: replace your DSA keys for SSH

[Donald Stufft]

On August 27, 2015 at 4:37:21 PM, Georg Brandl (g.bra...@gmx.net) wrote:
> Hi all,
>  
> newer OpenSSH versions (7.0+) default to not allowing ssh-dss keys for
> public key authentication. If you experience "permission denied" errors,
> this (currently) comes from the client side only and hg.python.org will
> accept these keys if you enable them using the PubkeyAcceptedKeyTypes
> option in your SSH config file.
>  
> Of course ssh-dss is being phased out for a reason; we'd like to invite
> everybody who has only DSA keys submitted for hg.python.org access to
> send an RSA (min. 1024 bits) or ED25519 key to hgaccou...@python.org.
>  
>

Can we bump up the minimum on RSA keys? 1024 isn’t really enough anymore, 
ideally they’d be at least 4096 but 2048 is also OK.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Alternative to SSH port 22?

[Donald Stufft]

> On May 5, 2015, at 11:09 PM, A.M. Kuchling  wrote:
> 
> I'm working on a DC-area python-dev meetup.  One location has been
> reported to intermittently have trouble connecting to the SSH port
> (port 22) externally, which would clearly make it impossible to commit
> to hg.python.org.
> 
> Does hg.python.org support SSH on any alternative ports, like ?
> Otherwise I guess we could run an SSH tunnel on some alternate server,
> going from a port number >1024 to hg.python.org:22.
> 
> --amk
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers

It doesn’t currently have another port number available but we could
easily add one, we’ll just need to set it up the LBs.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] Do we need to sign Windows files with GnuPG?

[Donald Stufft]

ated by trojans, viruses or malicious proxies.
>> 
>> Is that a good enough reason to continue providing the GPG
>> sigs or do you need more proof of goodness ? ;-)
>> 
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>> 
>> Professional Python Services directly from the Source
>>>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>> 
>> 
>> ::: Try our new mxODBC.Connect Python Database Interface for free ! 
>> 
>> 
>>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>   Registered at Amtsgericht Duesseldorf: HRB 46611
>>   http://www.egenix.com/company/contact/
>> 
> 
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Paul Moore for commit privileges

[Donald Stufft]

+1


> On Mar 14, 2015, at 4:23 PM, Brett Cannon  wrote:
> 
> Paul has been participating on python-dev for quite a while, he is a 
> committer on pip, and (co-)author on 5 PEPs. At this point I think it would 
> be prudent for Paul to have commit privileges if for any other reason than to 
> help manage the code related to his PEPs. But on top of that I bet Steve 
> wouldn't mind more help managing Windows-specific stuff.
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Possible "REMOTE HOST IDENTIFICATION HAS CHANGED!" Error.

[Donald Stufft]

Can you do ssh -v to that box and send me the output?


> On Jan 23, 2015, at 8:50 AM, Brett Cannon  wrote:
> 
> I tried updating my checkout this morning and then I was given the warning. 
> So I deleted the key from my known_hosts file, accepted the new one, but now 
> I just keep getting my connection rejected:
> 
> remote: Received disconnect from 104.130.43.97: 2: Too many authentication 
> failures for hg
> 
> abort: no suitable response from remote hg!
> 
> 
> 
> This this rejection going to timeout so I can eventually connect, and if so 
> how long do I need to wait?
> 
> 
>> On Tue Jan 20 2015 at 11:55:08 AM Donald Stufft  wrote:
>> Sending this to python-committers as well for anyone who doesn't keep up with
>> python-dev. If you've gotten this message twice now I'm sorry!
>> 
>> Just a heads up that people might see a "REMOTE HOST IDENTIFICATION HAS
>> CHANGED!" error when connecting to hg.python.org's SSH (or any other PSF
>> machine). The reason for this is that previously we allowed RSA, ECDSA, and
>> ED25519 host keys. However ECDSA relies on having an unbiased random number
>> generator on every connection and any bias in the random numbers can leak the
>> private key. Since these are running on VMs where we don't know for sure what
>> the quality is of the random numbers I've disabled the ECDSA host key.
>> 
>> The impact of this is if you had previously connected to a PSF machine, and
>> your client had the ECDSA key in your ~/.ssh/known_hosts file, that you'll
>> see an error like:
>> 
>>@@@
>>@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>>@@@
>>IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>>Someone could be eavesdropping on you right now (man-in-the-middle 
>> attack)!
>>It is also possible that a host key has just been changed.
>> 
>> The remediation is to remove the ECDSA for the PSF servers from your known
>> hosts and connect again and accept either the RSA or the ED25519 key when it
>> presents it.
>> 
>> The fingerprints for hg.python.org for both of those keys are:
>> 
>> $ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
>> 2048 a0:12:52:50:4a:4b:db:43:ac:65:26:b6:6f:0a:f7:b8 
>> /etc/ssh/ssh_host_rsa_key.pub (RSA)
>> $ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
>> 256 1d:02:d1:d2:7b:a1:cb:e0:51:65:25:d7:19:dd:4e:74 
>> /etc/ssh/ssh_host_ed25519_key.pub (ED25519)
>> 
>> Sorry for any inconvience this causes!
>> 
>> ---
>> Donald Stufft
>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Possible "REMOTE HOST IDENTIFICATION HAS CHANGED!" Error.

[Donald Stufft]

Sending this to python-committers as well for anyone who doesn't keep up with
python-dev. If you've gotten this message twice now I'm sorry!

Just a heads up that people might see a "REMOTE HOST IDENTIFICATION HAS
CHANGED!" error when connecting to hg.python.org's SSH (or any other PSF
machine). The reason for this is that previously we allowed RSA, ECDSA, and 
ED25519 host keys. However ECDSA relies on having an unbiased random number
generator on every connection and any bias in the random numbers can leak the
private key. Since these are running on VMs where we don't know for sure what
the quality is of the random numbers I've disabled the ECDSA host key.

The impact of this is if you had previously connected to a PSF machine, and
your client had the ECDSA key in your ~/.ssh/known_hosts file, that you'll
see an error like:

   @@@
   @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
   @@@
   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
   Someone could be eavesdropping on you right now (man-in-the-middle attack)!
   It is also possible that a host key has just been changed.

The remediation is to remove the ECDSA for the PSF servers from your known
hosts and connect again and accept either the RSA or the ED25519 key when it
presents it.

The fingerprints for hg.python.org for both of those keys are:

$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 a0:12:52:50:4a:4b:db:43:ac:65:26:b6:6f:0a:f7:b8 
/etc/ssh/ssh_host_rsa_key.pub (RSA)
$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 1d:02:d1:d2:7b:a1:cb:e0:51:65:25:d7:19:dd:4e:74 
/etc/ssh/ssh_host_ed25519_key.pub (ED25519)

Sorry for any inconvience this causes!

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Hook error when pushing (5.7.0 Message limit reached)

[Donald Stufft]

> On Jan 11, 2015, at 10:43 AM, Antoine Pitrou  wrote:
> 
> 
> Hello,
> 
> I just got the following error when pushing a changeset:
> 
> remote: buildbot: change(s) sent successfully
> remote: Traceback (most recent call last):
> remote: File "/srv/hg/repos/hooks/hgroundup.py", line 56, in update_issue
> remote: _update_issue(*args, **kwargs)
> remote: File "/srv/hg/repos/hooks/hgroundup.py", line 108, in _update_issue
> remote: s.login(username, password)
> remote: File "/usr/lib/python2.7/smtplib.py", line 615, in login
> remote: raise SMTPAuthenticationError(code, resp)
> remote: SMTPAuthenticationError: (535, '5.7.0 Message limit reached.')
> remote: error: changegroup.roundup hook raised an exception: (535,
> '5.7.0 Message limit reached.')
> remote: Traceback (most recent call last):
> remote: File "/srv/hg/repos/hooks/mail.py", line 166, in incoming
> remote: return _incoming(ui, repo, **kwargs)
> remote: File "/srv/hg/repos/hooks/mail.py", line 156, in _incoming
> remote: smtp.login(username, ui.config('smtp', 'password', ''))
> remote: File "/usr/lib/python2.7/smtplib.py", line 615, in login
> remote: raise SMTPAuthenticationError(code, resp)
> remote: SMTPAuthenticationError: (535, '5.7.0 Message limit reached.')
> remote: error: incoming.notify hook raised an exception: (535, '5.7.0
> Message limit reached.')
> 
> Regards
> 
> Antoine.
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers

For some reason it looks like our mailgun account is disabled. It says because
we’ve exceded the limit of the plan.. however that limit is 50k and I’m not sure
how we’ve managed to exceed that. I’ve filed a ticket with Mailgun and will 
await
further information.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers