Gentoo Archives: gentoo-project

From: Denis Dupeyron <calchan@g.o>
To: Gentoo project list <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] Improving our people
Date: Tue, 20 Jan 2009 23:51:48
Message-Id: 4976627D.6050306@gentoo.org
In Reply to: [gentoo-project] Improving our people by Donnie Berkholz
1 Donnie Berkholz wrote:
2 > Track who's mentored people
3 > How many people?
4 > How good are the mentees?
5 > Commits, etc
6 > How long do the mentees stay in Gentoo?
7 > Do they become mentors or leaders?
8 > How long does mentorship continue?
9
10 Are you trying to rate the mentor or the mentee here ? Or both ? What do
11 you think you can identify with this data ? What's the goal ?
12
13 > Reward mentors publicly
14 > Recognition
15
16 You're right, I also think this is important. Plus, good mentors are
17 good potential candidates to become recruiters. When I see a good mentor
18 I always try to talk to him/her about becoming a recruiter. It almost
19 worked, once.
20
21 > Mention in recruitment email
22
23 When I notice the mentor did a good job I usually mention it in the
24 announcement. The question is should we say when we think the mentor did
25 a lousy job and for example recruiters had to find a new one or finish
26 the training themselves ? Until now I never did.
27
28 > Mentoring is important
29
30 I think we all agree here.
31
32 > Get better new devs
33
34 Should we do a better screening of potential devs ? Should we go hunting
35 for candidates more actively ? I did this in the past and usually this
36 doesn't work very well for various reasons. Should we advertise our
37 needs more ? Or advertise only when there are urgent needs in order to
38 avoid a wear-off effect ?
39
40 One thing I want to note here is that I'm convinced many of our users
41 could become good devs. We don't need geniuses, but people with adequate
42 social skills who make the commitment to help Gentoo. Maintaining
43 ebuilds isn't rocket science, even I can do it. Once you know the basics
44 and where all the necessary info is it's not that complicated. What it
45 takes is focusing on doing a good job and interacting in a suitable way
46 with other devs and users. What I mean really is that there's hope. Good
47 devs are everywhere, our only task is to train them for their daily
48 activity of maintaining ebuilds.
49
50 > Improve existing devs by pairing w senior mentors (code review, designing/proposing major changes, etc)
51
52 This happens during the one-month probation. I'm sure though that
53 probation isn't done properly by most mentors.
54
55 The pairing should also happen more at the project/herd level. It all
56 depend on the team, and on the motivation.
57
58 > Improve mentoring
59 > Best mentors can train how to do it
60
61 Yes, or recruiters. Also, I try to setup co-mentoring as soon as I see
62 an opportunity. The classical case is pairing an experienced dev/mentor
63 with little time to co-mentor with a less experienced dev or first-time
64 mentor.
65
66 The biggest problem is as always lack or recruiters. I'm currently away
67 until at least March due to not having a place to leave anymore, and
68 thus no (real) internet either. In the meantime Petteri is doing a
69 tremendous job at filling both my shoes and his. We should all thank him
70 for that. I hear there are a couple new recruiters coming in, but I'd
71 hate their training to be sacrificed due to our urgent need for help.
72 Bad recruiters means a few "generations" of bad devs (on a Gentoo
73 time-scale I'd consider a generation to be 6 months, i.e. the time it
74 takes for a new dev to become a mentor). On the other hand, we do need help.
75
76 Now for a different idea on the "Improving our people" subject, just
77 before I had to (temporarily) stop my recruiting work, I was thinking
78 about setting interactive "classes" on irc. We could decide of a topic,
79 time, etc... and have devs sign up (how about non-devs too ?). The
80 session would consist of a quick recap of the necessary knowledge on
81 this topic (say dev quiz level, for example). This would have to be
82 short to avoid being boring. Then most of the session would be spent on
83 questions and answers, and very probably participants could answer each
84 others questions most of the time. Topics would certainly be more often
85 technical, but not only. We could have topics like "Good mentor
86 practices" or "How to interact with other devs" for example.
87
88 See ? Another idea, another project, and as usual nobody to work on it.
89 We have to break this vicious circle at one point or another.
90
91 Denis.

Replies

Subject Author
Re: [gentoo-project] Improving our people Donnie Berkholz <dberkholz@g.o>