Hi,
Last months, we debated about the number of *active* core developers.
The problem is that there are 3 lists and each has different numbers of core developers: 90 according to GitHub, 170 according to bugs.python.org.
- https://github.com/orgs/python/teams/python-core/members
- https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
- https://devguide.python.org/developers/
I propose to move inactive core developers to a new list (ex: "Inactive Core Developers") and remove their permission for security reasons. If the core developer shows up, they will just have to ask a GitHub administrator (like Brett Cannon) to be added again.
My intent is to enhance security and better track of the current number of active core developers.
In practice, it should only mean removing these inactive developers from the list of core developers on bugs.python.org. To make sure that a developer can become again a core developer, we should track that we dropped their priviledge. We can add new section in the devguide, near: https://devguide.python.org/developers/#permissions-dropped-on-request
There are already two lists of inactive core developers in the devguide: "Permissions Dropped on Request" and "Permissions Dropped after Loss of Contact".
I propose to start by removing all core developers who didn't migrate to GitHub yet, since it's a simple way to check if they are active since February 2017.
I can work on a concrete list of developers, but it seems like it will take me some time. Some developers are cores according to bugs.python.org but I cannot find them in the devguide list. Some developers are no longer core devs according to devguide, but still core in bugs.python.org. There are some inconsistencies.
Victor
"Missing In Action"
Oh. After I sent my email, I checked the translation of "Missing In Action". It means more or less "lost", but it seems to be commonly associated to war:
https://en.wikipedia.org/wiki/Missing_in_action "a casualty classification assigned to combatants, military chaplains, combat medics, and prisoners of war who are reported missing during wartime or ceasefire"
I don't recall where I heard the expression, but I didn't mean that inactive developers are dead :-) I'm quite sure that there is life after Python. Right?
Victor
I think I am one of those core developers who hasn’t committed anything in ages (even though I do have a git account and am somewhat following what goes on), but the term missing in action may be a bit too loaded….
How about “missing in inaction”?
:-)
Jack
On 16-Jun-2018, at 02:03 , Victor Stinner <vstinner@redhat.com> wrote:
"Missing In Action"
Oh. After I sent my email, I checked the translation of "Missing In Action". It means more or less "lost", but it seems to be commonly associated to war:
https://en.wikipedia.org/wiki/Missing_in_action "a casualty classification assigned to combatants, military chaplains, combat medics, and prisoners of war who are reported missing during wartime or ceasefire"
I don't recall where I heard the expression, but I didn't mean that inactive developers are dead :-) I'm quite sure that there is life after Python. Right?
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/
-- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
We could call them "dormant".
And I obviously support culling our membership list for the exact reasons Victor listed (especially since I was planning to do this at some point anyway :) .
My only question is whether we care about leaving people on b.p.o who have gone dormant with triage privileges as well? It's much less important, but if they haven't contributed in a while they probably are not up to sped with triage practices and thus might do something wrong by accident.
On Sun, 17 Jun 2018 at 14:38 Jack Jansen <jack.jansen@cwi.nl> wrote:
I think I am one of those core developers who hasn’t committed anything in ages (even though I do have a git account and am somewhat following what goes on), but the term missing in action may be a bit too loaded….
How about “missing in inaction”?
:-)
Jack
On 16-Jun-2018, at 02:03 , Victor Stinner <vstinner@redhat.com> wrote:
"Missing In Action"
Oh. After I sent my email, I checked the translation of "Missing In Action". It means more or less "lost", but it seems to be commonly associated to war:
https://en.wikipedia.org/wiki/Missing_in_action "a casualty classification assigned to combatants, military chaplains, combat medics, and prisoners of war who are reported missing during wartime or ceasefire"
I don't recall where I heard the expression, but I didn't mean that inactive developers are dead :-) I'm quite sure that there is life after Python. Right?
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/
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
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/
On 6/17/2018 9:18 PM, Brett Cannon wrote:
We could call them "dormant".
Sounds good.
And I obviously support culling our membership list for the exact reasons Victor listed (especially since I was planning to do this at some point anyway :) .
My only question is whether we care about leaving people on b.p.o who have gone dormant with triage privileges as well? It's much less important, but if they haven't contributed in a while they probably are not up to sped with triage practices and thus might do something wrong by accident.
I think disabling their access is a good idea from an infosec perspective. It's not like it's onerous to re-enable them if they express any renewed interest.
Eric
On Sun, 17 Jun 2018 at 14:38 Jack Jansen <jack.jansen@cwi.nl <mailto:jack.jansen@cwi.nl>> wrote:
I think I am one of those core developers who hasn’t committed anything in ages (even though I do have a git account and am somewhat following what goes on), but the term missing in action may be a bit too loaded…. How about “missing in inaction”? :-) JackOn 16-Jun-2018, at 02:03 , Victor Stinner <vstinner@redhat.com <mailto:vstinner@redhat.com>> wrote: "Missing In Action" Oh. After I sent my email, I checked the translation of "Missing In Action". It means more or less "lost", but it seems to be commonly associated to war: https://en.wikipedia.org/wiki/Missing_in_action "a casualty classification assigned to combatants, military chaplains, combat medics, and prisoners of war who are reported missing during wartime or ceasefire" I don't recall where I heard the expression, but I didn't mean that inactive developers are dead :-) I'm quite sure that there is life after Python. Right? Victor _______________________________________________ python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/-- Jack Jansen, <Jack.Jansen@cwi.nl <mailto:Jack.Jansen@cwi.nl>>, http://www.cwi.nl/~jack <http://www.cwi.nl/%7Ejack> If I can't dance I don't want to be part of your revolution -- Emma Goldman _______________________________________________ python-committers mailing list python-committers@python.org <mailto: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/
This idea also comes from Brett Cannon who proposed something similar: https://mail.python.org/pipermail/python-committers/2018-June/005526.html
Victor
2018-06-16 1:59 GMT+02:00 Victor Stinner <vstinner@redhat.com>:
Hi,
Last months, we debated about the number of *active* core developers.
The problem is that there are 3 lists and each has different numbers of core developers: 90 according to GitHub, 170 according to bugs.python.org.
- https://github.com/orgs/python/teams/python-core/members
- https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
- https://devguide.python.org/developers/
I propose to move inactive core developers to a new list (ex: "Inactive Core Developers") and remove their permission for security reasons. If the core developer shows up, they will just have to ask a GitHub administrator (like Brett Cannon) to be added again.
My intent is to enhance security and better track of the current number of active core developers.
In practice, it should only mean removing these inactive developers from the list of core developers on bugs.python.org. To make sure that a developer can become again a core developer, we should track that we dropped their priviledge. We can add new section in the devguide, near: https://devguide.python.org/developers/#permissions-dropped-on-request
There are already two lists of inactive core developers in the devguide: "Permissions Dropped on Request" and "Permissions Dropped after Loss of Contact".
I propose to start by removing all core developers who didn't migrate to GitHub yet, since it's a simple way to check if they are active since February 2017.
I can work on a concrete list of developers, but it seems like it will take me some time. Some developers are cores according to bugs.python.org but I cannot find them in the devguide list. Some developers are no longer core devs according to devguide, but still core in bugs.python.org. There are some inconsistencies.
Victor
16.06.18 02:59, Victor Stinner пише:
The problem is that there are 3 lists and each has different numbers of core developers: 90 according to GitHub, 170 according to bugs.python.org.
There is also a list of experts:
It contains not only core developers, but third-party experts. Some names are flagged with "(inactive)" or a star.
Victor:
please make sure that you contact the developers whos status you intend to modify prior to doing so. Being a core developer of Python is a status and not something that should be changed without consent by the developer in question.
Also note that the dev list log doesn't include all core developers. Data from before the move to SVN in 2006 is essentially missing, since AFAIK we never kept around a log of who received the core bit before that.
And there were times when the core bit itself did not exist, since all patches had to go through the small team around Guido which had access to the CVS system at the time.
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Thanks,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 18 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/
On 16.06.2018 01:59, Victor Stinner wrote:
Hi,
Last months, we debated about the number of *active* core developers.
The problem is that there are 3 lists and each has different numbers of core developers: 90 according to GitHub, 170 according to bugs.python.org.
- https://github.com/orgs/python/teams/python-core/members
- https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
- https://devguide.python.org/developers/
I propose to move inactive core developers to a new list (ex: "Inactive Core Developers") and remove their permission for security reasons. If the core developer shows up, they will just have to ask a GitHub administrator (like Brett Cannon) to be added again.
My intent is to enhance security and better track of the current number of active core developers.
In practice, it should only mean removing these inactive developers from the list of core developers on bugs.python.org. To make sure that a developer can become again a core developer, we should track that we dropped their priviledge. We can add new section in the devguide, near: https://devguide.python.org/developers/#permissions-dropped-on-request
There are already two lists of inactive core developers in the devguide: "Permissions Dropped on Request" and "Permissions Dropped after Loss of Contact".
I propose to start by removing all core developers who didn't migrate to GitHub yet, since it's a simple way to check if they are active since February 2017.
I can work on a concrete list of developers, but it seems like it will take me some time. Some developers are cores according to bugs.python.org but I cannot find them in the devguide list. Some developers are no longer core devs according to devguide, but still core in bugs.python.org. There are some inconsistencies.
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/
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett@python.org> wrote:
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
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/
-- --Guido van Rossum (python.org/~guido)
I know that this is the case for me.
I wouldn’t _dream_ of committing anything (after 10 years or so) without first consulting with current core developers, etc. But formally being a Python core dev does give me status with my colleagues, students, children (well, one only), nephews and nieces, etc. and I have just enough vanity to kind of enjoy that. Just the other day a nephew took a selfie of the two of us and posted it to all friends, YES! :-)
That said: I would fully understand if my status was changed to “dormant core dev” or “retired core dev” and I wouldn’t have any problems with that.
Jack
On 18-Jun-2018, at 21:07 , Guido van Rossum <guido@python.org> wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote:
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>> wrote: On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org <http://bugs.python.org/> username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org <http://bugs.python.org/> if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
-- --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/
-- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
I propose "emeritus core dev". It's a word that conveys *extra* status.
On Mon, Jun 18, 2018 at 12:24 PM Jack Jansen <jack.jansen@cwi.nl> wrote:
I know that this is the case for me.
I wouldn’t _dream_ of committing anything (after 10 years or so) without first consulting with current core developers, etc. But formally being a Python core dev does give me status with my colleagues, students, children (well, one only), nephews and nieces, etc. and I have just enough vanity to kind of enjoy that. Just the other day a nephew took a selfie of the two of us and posted it to all friends, YES! :-)
That said: I would fully understand if my status was changed to “dormant core dev” or “retired core dev” and I wouldn’t have any problems with that.
Jack
On 18-Jun-2018, at 21:07 , Guido van Rossum <guido@python.org> wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett@python.org> wrote:
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
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/
-- --Guido van Rossum (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/
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
-- --Guido van Rossum (python.org/~guido)
On 6/18/2018 3:24 PM, Jack Jansen wrote:
I know that this is the case for me.
I wouldn’t _dream_ of committing anything (after 10 years or so) without first consulting with current core developers, etc.
We would, of course, help you get back up to speed with the current workflow, if you wished. You could even start by reviewing a few PRs before merging one yourself.
tjr
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Hope that's a little clearer.
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 Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett@python.org> wrote:
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from history, they just won't have the core dev logo next to their bugs.python.org username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
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/
On 18 June 2018 at 20:41, M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing.
So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it).
Paul
What will be the threshold of activity? For example, if one hasn’t been committing due to time but occasionally comments on or opens b.p.o. issues or reviews pull requests, etc, would that mean the logo disappears? There is value in having the logo show up when commenting.
—Chris
On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 June 2018 at 20:41, M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing.
So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it).
Paul
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/
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
- Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
- Email all of them, asking if they still want to be a core dev. Choices could include a. Yes b. Keep the logo and b.p.o. access but disable GitHub key c. Drop everything
- If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
What will be the threshold of activity? For example, if one hasn’t been committing due to time but occasionally comments on or opens b.p.o. issues or reviews pull requests, etc, would that mean the logo disappears? There is value in having the logo show up when commenting.
—Chris
On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 June 2018 at 20:41, M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing.
So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it).
Paul
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/
-- --Guido van Rossum (python.org/~guido)
On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum <guido@python.org> wrote:
If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
We have at least one list on the developers' guide: https://devguide.python.org/developers/
It's more of a log of permissions granted and dropped. It also has a section titled "Permissions Dropped after Loss of Contact", currently with a single entry.
- Tal Einat
On Mon, Jun 18, 2018 at 10:12 PM Tal Einat <taleinat@gmail.com> wrote:
On Tue, Jun 19, 2018 at 3:54 AM, Guido van Rossum <guido@python.org> wrote:
If we currently have a list of core devs we should by default change
people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
We have at least one list on the developers' guide: https://devguide.python.org/developers/
It's more of a log of permissions granted and dropped. It also has a section titled "Permissions Dropped after Loss of Contact", currently with a single entry.
Hm, yeah, and it's incomplete (original developers like Jack are not listed at all). The UX of the tree separate reverse-chronologically ordered lists is also debatable: I'd have two lists, current core devs (with a record of when and by whom they were given permissions, as the current list) and emeritus core devs (with the same record, plus a record of when and why their permission was dropped).
On the plus side, I spent a minute of nostalgia while perusing the older entries...
-- --Guido van Rossum (python.org/~guido)
2018-06-19 2:54 GMT+02:00 Guido van Rossum <guido@python.org>:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
- Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
- Email all of them, asking if they still want to be a core dev. Choices could include a. Yes b. Keep the logo and b.p.o. access but disable GitHub key c. Drop everything
- If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
Question about "emeritus".
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?
Note: I like "emeritus" name to describe inactive core devs ;-)
Victor
On Jun 19, 2018, at 1:35 PM, Victor Stinner <vstinner@redhat.com> 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.
On Mon, 18 Jun 2018 at 17:56 Guido van Rossum <guido@python.org> wrote:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
- Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
- Email all of them, asking if they still want to be a core dev. Choices could include a. Yes b. Keep the logo and b.p.o. access but disable GitHub key c. Drop everything
- If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
One point I want to make about this pull approach versus a push one is this is going to be a lot of work. :) For the "no GitHub username" situation on bugs.python.org there are 80 people to reach out to. For people with commit rights who have not committed in the past year to CPython (because that's the best data point I have without writing custom code to find out who has commented on a PR recently), that would require reaching out to an additional 50 people. So we're looking at potentially up to 130 people to try and track down.
If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
We can make a complete list as people seem to want that and have it be active versus emeritus and list the year people got their commit rights.
Here's a counter-proposal so we can figure out what middle ground we are all happy with. The developer log gets rewritten to be simpler to just be two lists: a chronological one of active core devs sorted by when they got commit privileges, and an alphabetized list of core devs who are now emeritus (listing their years of service to the project).
The lists start with everyone who has committed to CPython, the devguide, or the peps repo in the past year as active. Everyone else is listed as emeritus. People are then given some window -- a month? -- to update themselves in those lists from emeritus to active. At the end of that month whomever is still listed as emeritus we turn off their commit access and b.p.o extras. We announce this here, python-dev, social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
-Brett
On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
What will be the threshold of activity? For example, if one hasn’t been committing due to time but occasionally comments on or opens b.p.o. issues or reviews pull requests, etc, would that mean the logo disappears? There is value in having the logo show up when commenting.
—Chris
On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 June 2018 at 20:41, M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing.
So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it).
Paul
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/
-- --Guido van Rossum (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/
I honestly have very little stake in this -- the minimum that I'd like to see is that unused GitHub permissions be revoked to reduce the risk when a dormant core dev is compromised. (Though if they contribute regularly to *other* GitHub projects even that risk seems minimal.)
On Tue, Jun 19, 2018 at 11:23 AM Brett Cannon <brett@python.org> wrote:
On Mon, 18 Jun 2018 at 17:56 Guido van Rossum <guido@python.org> wrote:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
- Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
- Email all of them, asking if they still want to be a core dev. Choices could include a. Yes b. Keep the logo and b.p.o. access but disable GitHub key c. Drop everything
- If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
One point I want to make about this pull approach versus a push one is this is going to be a lot of work. :) For the "no GitHub username" situation on bugs.python.org there are 80 people to reach out to. For people with commit rights who have not committed in the past year to CPython (because that's the best data point I have without writing custom code to find out who has commented on a PR recently), that would require reaching out to an additional 50 people. So we're looking at potentially up to 130 people to try and track down.
If we currently have a list of core devs we should by default change people's status to emeritus core dev when they choose (c). They may also choose to be removed from such a list. But I don't know if we have a list.
We can make a complete list as people seem to want that and have it be active versus emeritus and list the year people got their commit rights.
Here's a counter-proposal so we can figure out what middle ground we are all happy with. The developer log gets rewritten to be simpler to just be two lists: a chronological one of active core devs sorted by when they got commit privileges, and an alphabetized list of core devs who are now emeritus (listing their years of service to the project).
The lists start with everyone who has committed to CPython, the devguide, or the peps repo in the past year as active. Everyone else is listed as emeritus. People are then given some window -- a month? -- to update themselves in those lists from emeritus to active. At the end of that month whomever is still listed as emeritus we turn off their commit access and b.p.o extras. We announce this here, python-dev, social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
-Brett
On Mon, Jun 18, 2018 at 5:21 PM Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
What will be the threshold of activity? For example, if one hasn’t been committing due to time but occasionally comments on or opens b.p.o. issues or reviews pull requests, etc, would that mean the logo disappears? There is value in having the logo show up when commenting.
—Chris
On Mon, Jun 18, 2018 at 1:52 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 June 2018 at 20:41, M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
> Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Just to add my thoughts here. I agree that "being a Python core developer" is something people can be proud of (I know I am!), as well as being good to put on a CV. It would be a shame to devalue that pride by saying in effect that you're no longer a "real" core developer if you don't keep contributing.
So I'd very much like to distinguish the idea of "being a core developer" from the administrative management of commit privileges. The respect and gratitude of our peers is one of the few things it's possible to get as a reward for open source contributions - let's be generous with that (and with openly acknowledging it).
Paul
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/
-- --Guido van Rossum (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/
-- --Guido van Rossum (python.org/~guido)
On 06/19/2018 11:17 AM, Brett Cannon wrote:
On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
Email all of them, asking if they still want to be a core dev. Choices could include  a. Yes  b. Keep the logo and b.p.o. access but disable GitHub key  c. Drop everything
If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
One point I want to make about this pull approach versus a push one is this is going to be a lot of work. :) For the "no GitHub username" situation on bugs.python.org <http://bugs.python.org> there are 80 people to reach out to. For people with commit rights who have not committed in the past year to CPython (because that's the best data point I have without writing custom code to find out who has commented on a PR recently), that would require reaching out to an additional 50 people. So we're looking at potentially up to 130 people to try and track down.
I'm happy to do this.
We can make a complete list as people seem to want that and have it be active versus emeritus and list the year people got their commit rights.
At the end of that month whomever is still listed as emeritus we turn off their commit access and b.p.o extras. We announce this here, python-dev, social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
The problem with this approach as it's one time -- as soon as someone fades away it's once again out of date.
I'll take on the task of contacting the 130 people to get this started, then once a year somebody does the same thing with whichever handful of people have gone dormant that year.
Sound fair?
-- ~Ethan~
I'm happy to see you do this. It'll be very interesting what kind of responses you get. Do you know how to get the list of 130 people? (I don't, but Mariatta probably has it already.)
On Tue, Jun 19, 2018 at 12:51 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 06/19/2018 11:17 AM, Brett Cannon wrote:
On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
Email all of them, asking if they still want to be a core dev. Choices could include  a. Yes  b. Keep the logo and b.p.o. access but disable GitHub key  c. Drop everything
If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
One point I want to make about this pull approach versus a push one is this is going to be a lot of work. :) For the "no GitHub username" situation on bugs.python.org <http://bugs.python.org> there are 80 people to reach out to. For people with commit rights who have not committed in the past year to CPython (because that's the best data point I have without writing custom code to find out who has commented on a PR recently), that would require reaching out to an additional 50 people. So we're looking at potentially up to 130 people to try and track down.
I'm happy to do this.
We can make a complete list as people seem to want that and have it be active versus emeritus and list the year people got their commit rights.
At the end of that month whomever is still listed as emeritus we turn off their commit access and b.p.o extras. We announce this here, python-dev, social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
The problem with this approach as it's one time -- as soon as someone fades away it's once again out of date.
I'll take on the task of contacting the 130 people to get this started, then once a year somebody does the same thing with whichever handful of people have gone dormant that year.
Sound fair?
-- ~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/
-- --Guido van Rossum (python.org/~guido)
On Tue, 19 Jun 2018 at 13:16 Guido van Rossum <guido@python.org> wrote:
I'm happy to see you do this. It'll be very interesting what kind of responses you get. Do you know how to get the list of 130 people? (I don't, but Mariatta probably has it already.)
WFM! Thanks, Ethan!
I guess the first step is to go through https://bugs.python.org/user?iscommitter=1&@action=search&@sort=github&@pagesize=300 and contact the folks missing a GitHub username and to track who says "yes" or "no" in https://devguide.python.org/developers/ in new active/emeritus lists (opened https://github.com/python/devguide/issues/390 to track the list change). After that would be to go through the Python Core team on GitHub -- which should match who has a GitHub username on b.p.o -- and then correlate that with who has committed in the last year on appropriate repos and then reach out to those people.
-Brett
On Tue, Jun 19, 2018 at 12:51 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 06/19/2018 11:17 AM, Brett Cannon wrote:
On Mon, 18 Jun 2018 at 17:56 Guido van Rossum wrote:
I'd do it as follows. This basically makes withdrawal voluntary unless they don't respond at all.
Make a list of people who've not shown any sign of activity (on the b.p.o. or GitHub, as reviewer or committer) for at least one year.
Email all of them, asking if they still want to be a core dev. Choices could include  a. Yes  b. Keep the logo and b.p.o. access but disable GitHub key  c. Drop everything
If someone doesn't respond despite repeated attempts (maybe using different email addresses or social media) then after 4 weeks assume they meant to answer (c). But if they write back later they can be restored according to their preference (a, b, c), no questions asked.
One point I want to make about this pull approach versus a push one is this is going to be a lot of work. :) For the "no GitHub username" situation on bugs.python.org <http://bugs.python.org> there are 80 people to reach out to. For people with commit rights who have not committed in the past year to CPython (because that's the best data point I have without writing custom code to find out who has commented on a PR recently), that would require reaching out to an additional 50 people. So we're looking at potentially up to 130 people to try and track down.
I'm happy to do this.
We can make a complete list as people seem to want that and have it be active versus emeritus and list the year people got their commit rights.
At the end of that month whomever is still listed as emeritus we turn off their commit access and b.p.o extras. We announce this here, python-dev, social media, etc. IOW this becomes more opt-in/push than opt-out/pull.
The problem with this approach as it's one time -- as soon as someone fades away it's once again out of date.
I'll take on the task of contacting the 130 people to get this started, then once a year somebody does the same thing with whichever handful of people have gone dormant that year.
Sound fair?
-- ~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/
-- --Guido van Rossum (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/
On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Hope that's a little clearer.
Yep, and no one is suggesting you don't get listed as a core dev somewhere. Basically the idea is you would swap the Python logo next to your name on bugs.python.org to being listed on a page on devguide.python.org in terms of visibly being identified as a core dev.
-Brett
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 Mon, Jun 18, 2018 at 11:59 AM Brett Cannon <brett@python.org> wrote:
On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 18 June 2018 at 18:07, M.-A. Lemburg <mal@egenix.com> wrote:
Overall, I think that removing repo or bpo permissions should be kept separate from the status itself. It would probably be wise to send around reminders to all core devs who have access and have not used their permissions every few year. The keys of those who don't respond could then be disabled, without affecting anything else; and, of course, easily be reenabled if needed, without much process either.
Aye, that's the key concept behind adding an explicit "Dormant" status for core developers - they're folks that are still trusted with core commit privileges if they choose to exercise them, but while they're not using their access, it's better to deactivate their credentials to reduce the potential for compromise.
We'd add a note to the developer guide that gave instructions on how to request reactivation (likely just "Check the developer guide to ensure you're up to speed with any changes since you were last active, then past to python-committers requesting that your credentials be reactivated").
Right, no one's role of having been a core dev will be wiped from
history,
they just won't have the core dev logo next to their bugs.python.org username in the issue tracker (which if they are so dormant to have not added their GitHub username then they probably don't care about that anyway ;) . And flipping everything back on is a radio button and a word in bugs.python.org if their triage rights are removed and clicking on a button on a web page on GitHub if we clean up for dev access on the repository.
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/
On 19.06.2018 18:39, Brett Cannon wrote:
On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg <mal@egenix.com> wrote:
On 18.06.2018 21:07, Guido van Rossum wrote:
Hm, unless I misunderstood, MAL's
Being a core developer of Python is a status
suggests that core devs might want to keep this status since it confers "status" on their person (it looks good on a resume for sure). And I wouldn't want to make it any harder for a 3rd party to verify someone's claim to this status in their resume.
Marc-Andre, is that what you meant?
I guess I wasn't clear, sorry.
Perhaps the better term is "title" rather than "status". My understanding is that you become core developer and essentially keep this title forever.
Whether you actually have your keys in the repo to push a PR or not is a different story and not really related to the "title" you earned.
Listing the core developers somewhere on an official page would help with the verification you are referring to. At the moment, we don't seem to have this. It does make a difference on CVs and it's one of the few things we can give back to people when contributing code and time to Python.
Hope that's a little clearer.
Yep, and no one is suggesting you don't get listed as a core dev somewhere. Basically the idea is you would swap the Python logo next to your name on bugs.python.org to being listed on a page on devguide.python.org in terms of visibly being identified as a core dev.
I personally would not want that to happen, since while I don't have time to contribute code anymore, I still do comment on tickets.
Ok, let me be even clearer :-)
While I understand that there is a need to show the world that we need more active core devs, this drive to shelve existing developers is not a good way to achieve this.
Here's a simple approach which is effective without all the implied social costs of removing core dev flags:
- create a page with the core devs who have at least 10 commits in the last 6 months (the "active" ones):
https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c
(at the moment, this gives 21 entries)
run a few posts calling for help, pointing people to ways of becoming a core developers, the mentoring program, sprints to attend, etc.
create a page listing the core developers to show the world who we are and add value to the title in order to make it interesting for other developers to get on that page as well
perhaps also mention some other forms of recognition such as Mike's Python Dev of the Week: https://www.blog.pythonlibrary.org/category/pydevoftheweek/
add more ways to add recognition to the core dev title to make it more attractive, e.g. an free tickets to PyCon US for life, your own page on python.org, etc.
We need to put some carrots out there, and keep refreshing them.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 19 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/
On 06/19/2018 11:14 AM, M.-A. Lemburg wrote:
Ok, let me be even clearer :-)
While I understand that there is a need to show the world that we need more active core devs, this drive to shelve existing developers is not a good way to achieve this.
Here's a simple approach which is effective without all the implied social costs of removing core dev flags:
- create a page with the core devs who have at least 10 commits in the last 6 months (the "active" ones):
https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c
(at the moment, this gives 21 entries)
[...]
- add more ways to add recognition to the core dev title to make it more attractive, e.g. an free tickets to PyCon US for life, your own page on python.org, etc.
I would love tickets to PyCon US. I've only been able to afford to attend once, and then only because it was being held 25 miles away.
-- ~Ethan~
Le 19/06/2018 à 22:26, Ethan Furman a écrit :
On 06/19/2018 11:14 AM, M.-A. Lemburg wrote:
Ok, let me be even clearer :-)
While I understand that there is a need to show the world that we need more active core devs, this drive to shelve existing developers is not a good way to achieve this.
Here's a simple approach which is effective without all the implied social costs of removing core dev flags:
- create a page with the core devs who have at least 10 commits in the last 6 months (the "active" ones):
https://github.com/python/cpython/graphs/contributors?from=2017-12-19&to=2018-06-19&type=c
(at the moment, this gives 21 entries)
[...]
- add more ways to add recognition to the core dev title to make it more attractive, e.g. an free tickets to PyCon US for life, your own page on python.org, etc.
I would love tickets to PyCon US. I've only been able to afford to attend once, and then only because it was being held 25 miles away.
Or to whatever-Pycon-suits-you? I'd probably rather go to EuroPython than PyCon US.
Regards
Antoine.
participants (15)
-
Antoine Pitrou -
Brett Cannon -
Chris Jerdonek -
Donald Stufft -
Eric V. Smith -
Ethan Furman -
Guido van Rossum -
Jack Jansen -
M.-A. Lemburg -
Nick Coghlan -
Paul Moore -
Serhiy Storchaka -
Tal Einat -
Terry Reedy -
Victor Stinner