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