Making it easier to track who is currently considered "active" for voting
With the next SC election fast approaching, I did the final tweaks I wanted to make to the voters repo to address visibility issues we had in the last election.
First, there is now a monthly cron job that will run at https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter... which will project a Dec 01 vote and then calculate who would fall off the voter roll based solely on activity, who would be added, and then the full list of voters. What that means is the two year of activity is calculated back from the next Dec 01, so you can check to see if you haven't committed or authored code in that timeframe to automatically be put on the voter roll.
Second, I created https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+... for manually creating the voter roll. This means people can manually trigger the same code used to create the initial voter roll and see who would (not) be automatically placed on it. I expect this to mostly be used by the folks running the election. And I do advise specifying the full date as the input instead of using the MM-DD shortcut if you choose today as it will most likely wrap around to projecting a vote next year.
Finally, I updated the data to include when someone left the core team (and if someone was ejected, which is a term from PEP 13). For those that never entered a GitHub username, I implicitly put them as having left the team the day the first PR was merged on GitHub since they stopped being able to participate actively from that day forward with an appropriate note as to why (2017-02-10). This is now shown in the developer log at https://devguide.python.org/developers/.
Hopefully this is enough to easily check if one should try to get a quick PR committed and/or authored before an election. We can all also try to remember to include it in the vote announcement email going forward if anyone forgets.
How are you measuring "activity"? Just commits?
On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon brett@python.org wrote:
With the next SC election fast approaching, I did the final tweaks I wanted to make to the voters repo to address visibility issues we had in the last election.
First, there is now a monthly cron job that will run at https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter... which will project a Dec 01 vote and then calculate who would fall off the voter roll based solely on activity, who would be added, and then the full list of voters. What that means is the two year of activity is calculated back from the next Dec 01, so you can check to see if you haven't committed or authored code in that timeframe to automatically be put on the voter roll.
Second, I created https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+... for manually creating the voter roll. This means people can manually trigger the same code used to create the initial voter roll and see who would (not) be automatically placed on it. I expect this to mostly be used by the folks running the election. And I do advise specifying the full date as the input instead of using the MM-DD shortcut if you choose today as it will most likely wrap around to projecting a vote next year.
Finally, I updated the data to include when someone left the core team (and if someone was ejected, which is a term from PEP 13). For those that never entered a GitHub username, I implicitly put them as having left the team the day the first PR was merged on GitHub since they stopped being able to participate actively from that day forward with an appropriate note as to why (2017-02-10). This is now shown in the developer log at https://devguide.python.org/developers/.
Hopefully this is enough to easily check if one should try to get a quick PR committed and/or authored before an election. We can all also try to remember to include it in the vote announcement email going forward if anyone forgets. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/D... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Tue, Oct 20, 2020 at 2:58 PM Nathaniel Smith njs@pobox.com wrote:
How are you measuring "activity"? Just commits?
Same as it has always been since the voters repo has existed and we automated any of this: you either committed or authored a change in the CPython repo. So you can either author a PR that someone else merges or you can merge someone else's PR and that counts as active (or author and merge your own PR).
-Brett
On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon brett@python.org wrote:
With the next SC election fast approaching, I did the final tweaks I wanted to make to the voters repo to address visibility issues we had in the last election.
First, there is now a monthly cron job that will run at https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter... which will project a Dec 01 vote and then calculate who would fall off the voter roll based solely on activity, who would be added, and then the full list of voters. What that means is the two year of activity is calculated back from the next Dec 01, so you can check to see if you haven't committed or authored code in that timeframe to automatically be put on the voter roll.
Second, I created https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+... for manually creating the voter roll. This means people can manually trigger the same code used to create the initial voter roll and see who would (not) be automatically placed on it. I expect this to mostly be used by the folks running the election. And I do advise specifying the full date as the input instead of using the MM-DD shortcut if you choose today as it will most likely wrap around to projecting a vote next year.
Finally, I updated the data to include when someone left the core team (and if someone was ejected, which is a term from PEP 13). For those that never entered a GitHub username, I implicitly put them as having left the team the day the first PR was merged on GitHub since they stopped being able to participate actively from that day forward with an appropriate note as to why (2017-02-10). This is now shown in the developer log at https://devguide.python.org/developers/.
Hopefully this is enough to easily check if one should try to get a quick PR committed and/or authored before an election. We can all also try to remember to include it in the vote announcement email going forward if anyone forgets. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/D... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Nathaniel J. Smith -- https://vorpus.org http://vorpus.org
On Tue, Oct 20, 2020 at 3:07 PM Brett Cannon brett@python.org wrote:
On Tue, Oct 20, 2020 at 2:58 PM Nathaniel Smith njs@pobox.com wrote:
How are you measuring "activity"? Just commits?
Same as it has always been since the voters repo has existed and we automated any of this: you either committed or authored a change in the CPython repo. So you can either author a PR that someone else merges or you can merge someone else's PR and that counts as active (or author and merge your own PR).
Or to be specific: https://github.com/python/voters/blob/master/coredev/active.py.
-Brett
On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon brett@python.org wrote:
With the next SC election fast approaching, I did the final tweaks I wanted to make to the voters repo to address visibility issues we had in the last election.
First, there is now a monthly cron job that will run at https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter... which will project a Dec 01 vote and then calculate who would fall off the voter roll based solely on activity, who would be added, and then the full list of voters. What that means is the two year of activity is calculated back from the next Dec 01, so you can check to see if you haven't committed or authored code in that timeframe to automatically be put on the voter roll.
Second, I created https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+... for manually creating the voter roll. This means people can manually trigger the same code used to create the initial voter roll and see who would (not) be automatically placed on it. I expect this to mostly be used by the folks running the election. And I do advise specifying the full date as the input instead of using the MM-DD shortcut if you choose today as it will most likely wrap around to projecting a vote next year.
Finally, I updated the data to include when someone left the core team (and if someone was ejected, which is a term from PEP 13). For those that never entered a GitHub username, I implicitly put them as having left the team the day the first PR was merged on GitHub since they stopped being able to participate actively from that day forward with an appropriate note as to why (2017-02-10). This is now shown in the developer log at https://devguide.python.org/developers/.
Hopefully this is enough to easily check if one should try to get a quick PR committed and/or authored before an election. We can all also try to remember to include it in the vote announcement email going forward if anyone forgets. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/D... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Nathaniel J. Smith -- https://vorpus.org http://vorpus.org
FYI: There's a ticket open to address the remaining missing parts of the process that is defined in PEP 13 vs. the what the voting script implements:
https://github.com/python/voters/issues/16
I've implemented some extra logic to enable tracking the inactivity status as per PER 13 and creating a file which can be used for the notification emails, which are needed to convert a core dev's status to inactive:
https://github.com/python/voters/pull/25
I'd like to get this merged before the next vote and can also volunteer to take care of sending out the notification emails, unless the SC or the voting managers want to do this.
As part of implementing the change, I noticed that even considering the new "left" field Brett added, we are missing quite a few status checks from core developers. The next vote should remedy this by adding the missing fields with the notification status and get us back on track with respect to PEP 13.
With the extra tooling in place, it would also be worthwhile to consider defining the notification process for how to use the tool and documenting it in the README.md.
The above tickets already have some ideas.
Thanks,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Oct 23 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.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 https://www.egenix.com/company/contact/ https://www.malemburg.com/
On 20.10.2020 21:16, Brett Cannon wrote:
With the next SC election fast approaching, I did the final tweaks I wanted to make to the voters repo to address visibility issues we had in the last election.
First, there is now a monthly cron job that will run at https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter... which will project a Dec 01 vote and then calculate who would fall off the voter roll based solely on activity, who would be added, and then the full list of voters. What that means is the two year of activity is calculated back from the next Dec 01, so you can check to see if you haven't committed or authored code in that timeframe to automatically be put on the voter roll.
Second, I created https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+... for manually creating the voter roll. This means people can manually trigger the same code used to create the initial voter roll and see who would (not) be automatically placed on it. I expect this to mostly be used by the folks running the election. And I do advise specifying the full date as the input instead of using the MM-DD shortcut if you choose today as it will most likely wrap around to projecting a vote next year.
Finally, I updated the data to include when someone left the core team (and if someone was ejected, which is a term from PEP 13). For those that never entered a GitHub username, I implicitly put them as having left the team the day the first PR was merged on GitHub since they stopped being able to participate actively from that day forward with an appropriate note as to why (2017-02-10). This is now shown in the developer log at https://devguide.python.org/developers/.
Hopefully this is enough to easily check if one should try to get a quick PR committed and/or authored before an election. We can all also try to remember to include it in the vote announcement email going forward if anyone forgets.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/D... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (3)
-
Brett Cannon -
M.-A. Lemburg -
Nathaniel Smith