svn commit: r345786 - svnadmin/conf

[Rodney W. Grimes]

> On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> wrote:
> 
> > > 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.
> >
> 
> That's the idea.

I am confused.
Is this a new list or a list that has existed for some time?

> 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.
> >
> 
> We've talked about a 6 month timeout for new committees. Nothing definite.
That is another issue, not the issue I raise above.  My concern is that
mentors may not be responsive to a mentee, and that needs a clear path
for the mentee to take action on.  Aka neel has been gone for a long
long time, and Grehan has been gone for months, yet we are just now
picking up a new mentor for Anish.  That preferable would of happened within
days of Grehan leaving.

> > - 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.
> >
> 
> We were able to find someone in 10ish minutes... there was no delay... it
> was one of the pre-commit activities.

That was this time, that may not always be the case, lets solve the problem
and document that solution so that the future is handled.

> There was one more: is this person a vendor committer? Is so, we do need to
> do additional checks to help vendor relationships. Normally, these are
> managed well, but if we get to time out for a vendor committer, that
> suggests something may have broken down. At one point the vendor wanted a
> fast path into the project.

Do we even track vendor bits, do we have any action plan for vendor
bits when that person leaves a vendor, should there be an action,
should it be possible for a vendor to reap the bit?

The whole vendor things just raises a huge can of worms.

> We also need to check to see if the volunteer is in any groups as well.
                                      committer?
Yes, defanitly, and that should include more than hat's, which is what
I think you meant by "groups".

> Warner
> 
> > - 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
-- 
Rod Grimes rgrimes at freebsd.org