PEP 13: Clarify how the inactive voters will be notified

[Mariatta]

I've added a paragraph to clarify how we will notify the folks that are inactive for the purpose of voting.
It does not change the original meaning of this PEP, rather make it clearer of how this will be done.
Hopefully it will be less ambiguous going forward.

[warsaw]

Thanks @Mariatta ! I made a small commit to fix a typo and some grammatical changes. With that, I'll approve this change. If you agree, feel free to merge it.

[aeros]

@warsaw I just left a review comment just before you did your approval; I'm fairly certain it's two years of inactivity rather than two months (based on https://mail.python.org/archives/list/python-committers@python.org/thread/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/)

Edit: nvm, looks like Barry fixed it.

[warsaw]

Thanks @aeros !

[Mariatta]

Thanks @warsaw , do I need to start a vote on Discourse first? Or is this deemed small enough change?

PEP 13 says changing this document require a vote:

https://www.python.org/dev/peps/pep-0013/#changing-this-document

Changing this document
Changes to this document require at least a two-thirds majority of votes cast in a core team vote which should be open for two weeks.

[warsaw]

@Mariatta Yes, I forgot that you do, even for non-substantive changes like this one. Thanks to @brettcannon for the reminder of this requirement.

[ethanfurman]

These updates to PEP 13 do not match the text already in PEP 13. Looking at the relevant sentence in two pieces:

Those who haven't made any non-trivial contribution in two years may be asked to move themselves to this category,

The proposed update equates a post to Python Committers as asking a core dev to make themselves inactive. If that was all the technology we had, or if the privileges at stake were minor, I'd be okay with that -- but it is not, and they are not. Ideally, an actual human would have a by-voice conversation with the core devs that were potentially inactive; failing that, and since we do not live in an ideal world, the next tier of interaction would be by direct mail -- either physical or digital; since we live in a digital age I think an email to each at-risk core dev is entirely appropriate. I recognize that email addresses can go stale, so as a simultaneous fall-back attempt at notification a post to Committers is also appropriate -- indeed, if we list the core devs in that post then somebody that knows them may also be able to get in contact with them.

and moved there if they don't respond.

This clause is, I think, key to the proper interpretation of that sentence: IF we ask them AND they don't respond THEN we move them to inactive (which is why voters #16 was created).

To sum up: a post to Python Committers as the sole attempt at notification is insufficient when we have the means to attempt more direct communication.

[warsaw]

FYI, here is some language on Debian's missing-in-action policies. In particular, they consider a "non-functional e-mail address is a violation of Debian Policy." We could do the same.

[Mariatta]

My reasoning for choosing python-committers instead of sending private personal email is as follows:

Of all the mailing-lists that exists, I believe the python-committers is the primary means for core developers to converse with each other. All other forums like discourse are considered optional. Important decisions and even about the election itself are always posted to python-committers.

If a pending inactive core developer can't even be bothered to keep up to date with python-committers mailing list (which is not high volume mailing list), and in addition to already not contributing to CPython, and not reviewing CPython PRs, then in my mind they're no longer committed to being a core developer, and so perhaps the "inactive" status is accurate.

By replying to the "pending inactive" message to python-committers, it creates transparency in the process, in addition to giving the opportunity to the "pending inactive" voters to show that they are indeed still active and watching python-committers.

[warsaw]

Thanks for the elaboration @Mariatta. I'm actually less certain that folks pay close attention to committers (although I agree that they should, if they want to be considered active). If that's the bar, we should codify that in PEP 13.

Maybe we can run an experiment. Say, create a Google form that just asks for their name, the email address they use for committers, and their GitHub username. Send that to committers, give folks 3 weeks to respond (to allow for vacations, holidays, general dealing with life), and see how the response numbers correlate to our known active and inactive members? I'd be interested to see who among the active members fail to respond. We'd have to make very clear that their response isn't an indication of their active status, just gathering data.

[malemburg]

@Mariatta The idea we're discussing over on https://github.com/python/voters/issues/16 is to send email to the core devs in question with CC to the committers list. This creates the needed transparency, shows respect for the core devs (which I find is missing in these discussions about active vs. inactive) and allows for an easy to follow process, which doesn't create too much work.

Your text variant essential codifies the process which was used in previous votes and which has resulted in people being surprised that they don't receive ballots.

[warsaw]

Your text variant essential codifies the process which was used in previous votes and which has resulted in people being surprised that they don't receive ballots.

IMHO, fixing that is more important than culling inactive members, although if we can find the right balance then we should.

[brettcannon]

@ethanfurman do recognize there is a scale problem here. We have 172 core developers, of which 77 automatically get picked up as "active" today. Emailing all of those other folks, let along tracking the responses, is not zero (if you assume people who went inactive by my implicit marking as such after the GitHub transition then that helps bring it down, but once it isn't zero; based on just who fell off from the last vote it's 10, but this is technically signing up to contact everyone else who hasn't specifically relinquished their commit rights).

Also note that you will have to re-check with everyone who asked to be kept active every vote as well, otherwise you never know when they have fallen out of total contact with Python's development and thus shouldn't be considered active anymore (IOW replying "keep me active" in a single email should not mean you're active perpetually, just until the next vote). So this also isn't a one-time thing where the list will necessarily shrink to zero after an initial cost, but will be at least annual.

Plus, up to this point no one has stepped forward to help maintain the voter records or the generation of its voter rolls, so it's very much been a Brett-only endeavour up until now and I am now burned out on working on that repo, so someone else will need to manage something as heavy as emailing individuals, recording their responses, and then redo this every vote. It's sounds like MAL is up for taking over the work, which is great.

So if people want to send the individual emails then that's great, but we need to then make sure it's a sustainable process and we have a commitment from someone to do this at least annually, possibly more frequently if some vote happens to come up between SC votes. Otherwise going with a much more sustainable approach as this PR proposes that's more push than pull from those wanting to keep their vote going simply makes the lives putting in the work much easier and the months of October and November less of a drag.

[malemburg]

With the PR for the tools, the process is very simple:

• Run the script:

python3 -m coredev active
python3 -m coredev voters

• Create an email with Thunderbird MailMerge, point it to the generated notifications.csv file and have it send the emails.

Currently, this would send out 31 emails, since a couple of core devs were not listed in the last voter roll.

• Wait two weeks, collect all the receipts, adjust the python-core.toml TOML and you're done.

In future votes, the number of emails will go down a lot, since we'll then have the needed data in the python-core.toml file.

The above could be simplified even more by having core devs update their entry directly in python-core.toml, which is what @ethanfurman suggested.

And yes, I would help with this.

[ethanfurman]

@Mariatta thank you for the explanation. For the most part I agree with you. The part I think is getting missed is that somebody who starts as a core-dev may move into other, non-code related but equally important to Python, spheres of influence -- between that and "life happening" -committers may not be monitored at the appropriate time, if at all.

@brettcannon thank you for your insight, and getting voters to where it is. If the emailing, etc, has to be done by a human then I totally agree with your stance; I think, however, that we should be able to set up an automated reminder system that is more effective than a single post to -committers. That reminder system is just, and only, that -- reminders. Any one on the list would need to go and edit the core-dev file (I forget its name) to change their status from "no response" to "stay active". The only human involvement after that should be making sure the system runs (and a CC to the SC from the emails could accomplish that).

[malemburg]

FWIW: I still think we ought to clarify that we'll contact the inactive members by direct email to the last known email address, in addition to posting on the committers list.

Any objections to merging the PR https://github.com/python/voters/pull/25 ? If not, I'll merge this later today. Thanks.

[malemburg]

FYI: I've merged python/voters#25 now, so we can identify and send out emails to core devs who have not committed in the last two years and ask them whether they want to be considered inactive w/r to PEP 13 or not.

[AA-Turner]

@Mariatta / @malemburg is this PR still needed, or can it be closed?

A

[malemburg]

The process is slightly different now with the new logic: an email will be sent to those committers who have no done any checkins to the CPython repo in the last year. They can then reply with "remain active" or "mark inactive". After the deadline for such replies, the voters roll is prepared with the then current status fields for the committers. @ewdurbin knows the details, since he usually runs this process.

[AA-Turner]

Thanks for the overview @malemburg.

If it would still be useful to update PEP 13 then please could this PR be updated, otherwise I propose to close this and delete the branch (It's a branch directly on the peps repo, not on @Mariatta's fork).

A