svn commit: r345786 - svnadmin/conf

[Rodney W. Grimes]

> Warner Losh <imp at bsdimp.com> writes:
> 
> > On Mon, Apr 1, 2019 at 7:15 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> > wrote:
> 
> >> > Author: jrm (ports committer)
> >> > Date: Mon Apr  1 21:34:58 2019
> >> > New Revision: 345786
> >> > URL: https://svnweb.freebsd.org/changeset/base/345786
> 
> >> > Log:
> >> >   Set jhb@ as new mentor to anish@
> 
> >> >   Approved by:        core (brooks, seanc)
> >> >   Differential Revision:      https://reviews.freebsd.org/D19782
> 
> >> Can we please have a check list that when someones
> >> commit bit is reaped, or steps away from the project
> >> for more than N days, N being something rather small
> >> given the context here, that includes the item:
> 
> >>         x)  Is this person a mentor of anyone?
> 
> 
> > Great idea...  Joseph will put one together based on this round of
> > retirement...
> 
> <snip>
> 
> This is the current checklist:

Should this be a publically visible check list?  If I had know of it
I would not of even raised an issue.

This only handles the reap situation, which takes too long to leave
a menteee hanging, they are gone long before you get to this point.

Perhaps adding an item to the new committers guide:
	If a mentor should go unresponsive or seem to be inactive
	in the project you should contact core@ asking for remediation or
	reassignment of that mentor.

> - Check for idle developers using: idle-commit-bits.pl base 18
> 
> - Source bits are taken in for safekeeping after three consecutive emails about
>   reaping go unanswered, or if the developer in question confirms that the bit
>   can be taken in.  The email-to-idlers.pl script can be used to send warning
>   emails, but Ren? is currently taking care of this job.
>   
> - Once it has been established that a bit is to be taken in, first check the
>   mentors file to see if this developer is a mentor.  If so, a new mentor must
>   be found before the bit is taken in.

I see no reason for delaying the reap action, that just further leaves
the mentee in limbo.  Perhaps:
Once it has been established that a bit is to be take in, first check the
mentors file to see if this developer is a mentor.  If so, create a core@
action item to find them a replacement, inform the mentee that this action
item has been created, asking them if they have any input as to who might
be a good canidate.  Reassign them to core@ in the mentors file.

> - If the developer whose bit to be removed is a mentee, remove the developer
>   from the mentors file.
>   
> - Remove the developer from the access file.
> 
> --
> Joseph
-- 
Rod Grimes                                                 rgrimes at freebsd.org