Re: [gentoo-project] Improving our people

[Donnie Berkholz <dberkholz@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6952 bytes --]

On 00:47 Wed 21 Jan     , Denis Dupeyron wrote:
> Donnie Berkholz wrote:
> > Track who's mentored people
> >  How many people?
> >  How good are the mentees?
> >   Commits, etc
> >  How long do the mentees stay in Gentoo?
> >  Do they become mentors or leaders?
> >  How long does mentorship continue?
> 
> Are you trying to rate the mentor or the mentee here ?

The mentor, primarily. Evaluating the mentee is a separate issue, and I 
discuss it below.

 Or both ? What do
> you think you can identify with this data ? What's the goal ?

We want a way to measure who good mentors are, and who bad ones are. 
With this, we can do a better job of giving recognition to the good 
ones. Recognition is so important in volunteer projects, and we give 
almost none to our mentors. Furthermore, knowing who the best mentors 
are gives us a good idea of pairs for co-mentoring and potential 
recruiters. It isn't necessarily obvious from a recruiter's interaction 
with a mentor whether he is good at the actual task of mentoring.

We can also know who the bad ones are, so that we can work with them to 
help them improve at mentoring or eventually say they just can't mentor 
anymore.

Since the product of a mentor is a new developer, the best way to look 
at the strength of a mentor is to look at who he's mentored.

> > Reward mentors publicly
> >  Recognition
> 
> You're right, I also think this is important. Plus, good mentors are
> good potential candidates to become recruiters. When I see a good mentor
> I always try to talk to him/her about becoming a recruiter. It almost
> worked, once.
> 
> >   Mention in recruitment email
> 
> When I notice the mentor did a good job I usually mention it in the
> announcement. The question is should we say when we think the mentor did
> a lousy job and for example recruiters had to find a new one or finish
> the training themselves ? Until now I never did.

Compliment in public, criticize in private, and all that jazz. The lack 
of mention in the email could be a subtle clue in itself. =)

> >  Get better new devs
> 
> Should we do a better screening of potential devs ?

I think the only way to tell whether someone is a good dev is to look at 
how good of a dev they are (perhaps over their first 90 days). 
Predicting is hard, looking at how they perform at the actual task is 
easier.

> Should we go hunting for candidates more actively ? I did this in the 
> past and usually this doesn't work very well for various reasons. 
> Should we advertise our needs more ? Or advertise only when there are 
> urgent needs in order to avoid a wear-off effect ?

We should always be on the lookout for good people. Our standard 
shouldn't drop at all even if we desperately need new devs. The only 
thing that should change is how much time we spend looking for those who 
meet our standards.

> One thing I want to note here is that I'm convinced many of our users
> could become good devs. We don't need geniuses, but people with adequate
> social skills who make the commitment to help Gentoo. Maintaining
> ebuilds isn't rocket science, even I can do it. Once you know the basics
> and where all the necessary info is it's not that complicated. What it
> takes is focusing on doing a good job and interacting in a suitable way
> with other devs and users. What I mean really is that there's hope. Good
> devs are everywhere, our only task is to train them for their daily
> activity of maintaining ebuilds.

What we need from potential devs is interest and enthusiasm. The rest is 
learnable.

> >  Improve existing devs by pairing w senior mentors (code review, 
> >  designing/proposing major changes, etc)
> 
> This happens during the one-month probation. I'm sure though that
> probation isn't done properly by most mentors.

It needs to be longer. I'm talking about permanent mentoring, but not 
necessarily pairing with the same person forever. As you become more 
experienced and start trying new things, you should switch mentors to 
those who are just a level "above" you in whichever area you're trying 
to improve.

> The pairing should also happen more at the project/herd level. It all
> depend on the team, and on the motivation.

Yep. I alluded to that above.

> >  Improve mentoring
> >   Best mentors can train how to do it
> 
> Yes, or recruiters. Also, I try to setup co-mentoring as soon as I see
> an opportunity. The classical case is pairing an experienced dev/mentor
> with little time to co-mentor with a less experienced dev or first-time
> mentor.

/me looks at self wrt little time

> The biggest problem is as always lack or recruiters. I'm currently away
> until at least March due to not having a place to leave anymore, and
> thus no (real) internet either. In the meantime Petteri is doing a
> tremendous job at filling both my shoes and his. We should all thank him
> for that. I hear there are a couple new recruiters coming in, but I'd
> hate their training to be sacrificed due to our urgent need for help.
> Bad recruiters means a few "generations" of bad devs (on a Gentoo
> time-scale I'd consider a generation to be 6 months, i.e. the time it
> takes for a new dev to become a mentor). On the other hand, we do need help.

Indeed, Petteri is rocking it. Recruiting is so important that I've 
thought about dropping some other responsibilities to get back into it. 
(I was a recruiter long ago.) Maybe once I finish my Ph.D. and the 
Gentoo book.

I think a longer, 90-day probation period with a serious evaluation and 
reconsideration of developer-ship at the end would be worthwhile.

> Now for a different idea on the "Improving our people" subject, just
> before I had to (temporarily) stop my recruiting work, I was thinking
> about setting interactive "classes" on irc. We could decide of a topic,
> time, etc... and have devs sign up (how about non-devs too ?). The
> session would consist of a quick recap of the necessary knowledge on
> this topic (say dev quiz level, for example). This would have to be
> short to avoid being boring. Then most of the session would be spent on
> questions and answers, and very probably participants could answer each
> others questions most of the time. Topics would certainly be more often
> technical, but not only. We could have topics like "Good mentor
> practices" or "How to interact with other devs" for example.

I've thought about that. It seems to me that the more practical 
something is to someone, the more likely people are to actually remember 
it. With that in mind, I think "classes" would actually have to be 
workshops where everyone brought a project, and a couple of leaders were 
available for occasional questions. Vaguely like a bugday.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]