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.jan...@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 <gu...@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 <br...@python.org> wrote: > >> >> >> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncogh...@gmail.com> wrote: >> >>> On 18 June 2018 at 18:07, M.-A. Lemburg <m...@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.jan...@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)
_______________________________________________ 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/
