[gentoo-project] Improving our people

[gentoo-project] Improving our people

[Donnie Berkholz]

If we want Gentoo to thrive, we need to focus on getting the best people. Here's some brainstorming I'm doing (as I wait in the store for my wife to try on clothes) on how to better develop our most important resource: our contributors. Does it make sense? Any thoughts?

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?

Reward mentors publicly
 Recognition
  GMN - graphs, individual names
  Mention in recruitment email

Goals
 Mentoring is important
 Get better new devs
 Improve existing devs by pairing w senior mentors (code review, designing/proposing major changes, etc)
 Improve mentoring
  Best mentors can train how to do it

Re: [gentoo-project] Improving our people

[Wulf C. Krueger]

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

On Saturday, 17. January 2009 19:53:21 Donnie Berkholz wrote:
> If we want Gentoo to thrive, we need to focus on getting the best people.

You might want to start with grasping a simple concept: Don't throw good 
people out just because they don't fit into your simple, pinkish view of the 
world. 

Unless, of course, there's a good reason... "If you hadn't noticed, all three 
of them are assholes." (D. Berkholz)



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Improving our people

[Petteri Räty]

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

Donnie Berkholz wrote:
> If we want Gentoo to thrive, we need to focus on getting the best people. 
>

Contributions to the Recruiter's Recreational Fund can be given at FOSDEM.

Thanks,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-project] Improving our people

[Denis Dupeyron]

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 ? Or both ? What do
you think you can identify with this data ? What's the goal ?

> 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.

>  Mentoring is important

I think we all agree here.

>  Get better new devs

Should we do a better screening of potential devs ? 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 ?

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.

>  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.

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

>  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.

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.

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.

See ? Another idea, another project, and as usual nobody to work on it.
We have to break this vicious circle at one point or another.

Denis.

Re: [gentoo-project] Improving our people

[Donnie Berkholz]

[-- 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 --]

Re: [gentoo-project] Improving our people

[Donnie Berkholz]

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

On 20:30 Tue 20 Jan     , Donnie Berkholz wrote:
> It isn't necessarily obvious from a recruiter's interaction with a 
> mentor whether he is good at the actual task of mentoring.

We could take a tip from the Summer of Code and have both mentor and 
mentee fill out a quick eval at the end of probation. This would perhaps 
be more valuable over a longer probation.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-project] Improving our people

[Douglas Anderson]

On Wed, Jan 21, 2009 at 1:32 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 20:30 Tue 20 Jan     , Donnie Berkholz wrote:
>> It isn't necessarily obvious from a recruiter's interaction with a
>> mentor whether he is good at the actual task of mentoring.
>
> We could take a tip from the Summer of Code and have both mentor and
> mentee fill out a quick eval at the end of probation. This would perhaps
> be more valuable over a longer probation.
>

The evaluation is a good idea, but it would have to be something maybe
only devrel had access to. With the Summer of Code, many students
leave the project after they're finished, but with a new dev they're
just starting a (hopefully) long relationship with their mentor. I
personally would hesitate to point out the weak points of an
experienced developer if I were just starting out here. Something to
think about...

-Doug

Re: [gentoo-project] Improving our people

[Donnie Berkholz]

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

On 16:04 Wed 21 Jan     , Douglas Anderson wrote:
> On Wed, Jan 21, 2009 at 1:32 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 20:30 Tue 20 Jan     , Donnie Berkholz wrote:
> >> It isn't necessarily obvious from a recruiter's interaction with a
> >> mentor whether he is good at the actual task of mentoring.
> >
> > We could take a tip from the Summer of Code and have both mentor and
> > mentee fill out a quick eval at the end of probation. This would perhaps
> > be more valuable over a longer probation.
> >
> 
> The evaluation is a good idea, but it would have to be something maybe
> only devrel had access to.

How would mentors know what they need to improve upon?

One way to answer this is to have 2 sections -- 1 optional section that 
only recruiters see, and 1 that the mentor sees.

> With the Summer of Code, many students leave the project after they're 
> finished,

The best ones stay. And they fill out evals too, so it's clearly a 
solvable problem.

> but with a new dev they're just starting a (hopefully) long 
> relationship with their mentor. I personally would hesitate to point 
> out the weak points of an experienced developer if I were just 
> starting out here. Something to think about...

I would love to improve my mentoring, and suggestions to help me are 
welcome. Pointing out unfixable weak points is also welcome because 
those are areas I should avoid, instead focusing on what I'm good at.

-- 
Thanks,
Donnie

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

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