[python-committers] Changing commiter status (was: Missing In Action)

[Jack Jansen]

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 at 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 at python.org <mailto:brett at python.org>> wrote:
> 
> 
> On Mon, 18 Jun 2018 at 06:43 Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
> On 18 June 2018 at 18:07, M.-A. Lemburg <mal at egenix.com <mailto:mal at 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 at python.org <mailto:python-committers at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180618/2ea4300a/attachment.html>