1 |
On 00:47 Wed 21 Jan , Denis Dupeyron wrote: |
2 |
> Donnie Berkholz wrote: |
3 |
> > Track who's mentored people |
4 |
> > How many people? |
5 |
> > How good are the mentees? |
6 |
> > Commits, etc |
7 |
> > How long do the mentees stay in Gentoo? |
8 |
> > Do they become mentors or leaders? |
9 |
> > How long does mentorship continue? |
10 |
> |
11 |
> Are you trying to rate the mentor or the mentee here ? |
12 |
|
13 |
The mentor, primarily. Evaluating the mentee is a separate issue, and I |
14 |
discuss it below. |
15 |
|
16 |
Or both ? What do |
17 |
> you think you can identify with this data ? What's the goal ? |
18 |
|
19 |
We want a way to measure who good mentors are, and who bad ones are. |
20 |
With this, we can do a better job of giving recognition to the good |
21 |
ones. Recognition is so important in volunteer projects, and we give |
22 |
almost none to our mentors. Furthermore, knowing who the best mentors |
23 |
are gives us a good idea of pairs for co-mentoring and potential |
24 |
recruiters. It isn't necessarily obvious from a recruiter's interaction |
25 |
with a mentor whether he is good at the actual task of mentoring. |
26 |
|
27 |
We can also know who the bad ones are, so that we can work with them to |
28 |
help them improve at mentoring or eventually say they just can't mentor |
29 |
anymore. |
30 |
|
31 |
Since the product of a mentor is a new developer, the best way to look |
32 |
at the strength of a mentor is to look at who he's mentored. |
33 |
|
34 |
> > Reward mentors publicly |
35 |
> > Recognition |
36 |
> |
37 |
> You're right, I also think this is important. Plus, good mentors are |
38 |
> good potential candidates to become recruiters. When I see a good mentor |
39 |
> I always try to talk to him/her about becoming a recruiter. It almost |
40 |
> worked, once. |
41 |
> |
42 |
> > Mention in recruitment email |
43 |
> |
44 |
> When I notice the mentor did a good job I usually mention it in the |
45 |
> announcement. The question is should we say when we think the mentor did |
46 |
> a lousy job and for example recruiters had to find a new one or finish |
47 |
> the training themselves ? Until now I never did. |
48 |
|
49 |
Compliment in public, criticize in private, and all that jazz. The lack |
50 |
of mention in the email could be a subtle clue in itself. =) |
51 |
|
52 |
> > Get better new devs |
53 |
> |
54 |
> Should we do a better screening of potential devs ? |
55 |
|
56 |
I think the only way to tell whether someone is a good dev is to look at |
57 |
how good of a dev they are (perhaps over their first 90 days). |
58 |
Predicting is hard, looking at how they perform at the actual task is |
59 |
easier. |
60 |
|
61 |
> Should we go hunting for candidates more actively ? I did this in the |
62 |
> past and usually this doesn't work very well for various reasons. |
63 |
> Should we advertise our needs more ? Or advertise only when there are |
64 |
> urgent needs in order to avoid a wear-off effect ? |
65 |
|
66 |
We should always be on the lookout for good people. Our standard |
67 |
shouldn't drop at all even if we desperately need new devs. The only |
68 |
thing that should change is how much time we spend looking for those who |
69 |
meet our standards. |
70 |
|
71 |
> One thing I want to note here is that I'm convinced many of our users |
72 |
> could become good devs. We don't need geniuses, but people with adequate |
73 |
> social skills who make the commitment to help Gentoo. Maintaining |
74 |
> ebuilds isn't rocket science, even I can do it. Once you know the basics |
75 |
> and where all the necessary info is it's not that complicated. What it |
76 |
> takes is focusing on doing a good job and interacting in a suitable way |
77 |
> with other devs and users. What I mean really is that there's hope. Good |
78 |
> devs are everywhere, our only task is to train them for their daily |
79 |
> activity of maintaining ebuilds. |
80 |
|
81 |
What we need from potential devs is interest and enthusiasm. The rest is |
82 |
learnable. |
83 |
|
84 |
> > Improve existing devs by pairing w senior mentors (code review, |
85 |
> > designing/proposing major changes, etc) |
86 |
> |
87 |
> This happens during the one-month probation. I'm sure though that |
88 |
> probation isn't done properly by most mentors. |
89 |
|
90 |
It needs to be longer. I'm talking about permanent mentoring, but not |
91 |
necessarily pairing with the same person forever. As you become more |
92 |
experienced and start trying new things, you should switch mentors to |
93 |
those who are just a level "above" you in whichever area you're trying |
94 |
to improve. |
95 |
|
96 |
> The pairing should also happen more at the project/herd level. It all |
97 |
> depend on the team, and on the motivation. |
98 |
|
99 |
Yep. I alluded to that above. |
100 |
|
101 |
> > Improve mentoring |
102 |
> > Best mentors can train how to do it |
103 |
> |
104 |
> Yes, or recruiters. Also, I try to setup co-mentoring as soon as I see |
105 |
> an opportunity. The classical case is pairing an experienced dev/mentor |
106 |
> with little time to co-mentor with a less experienced dev or first-time |
107 |
> mentor. |
108 |
|
109 |
/me looks at self wrt little time |
110 |
|
111 |
> The biggest problem is as always lack or recruiters. I'm currently away |
112 |
> until at least March due to not having a place to leave anymore, and |
113 |
> thus no (real) internet either. In the meantime Petteri is doing a |
114 |
> tremendous job at filling both my shoes and his. We should all thank him |
115 |
> for that. I hear there are a couple new recruiters coming in, but I'd |
116 |
> hate their training to be sacrificed due to our urgent need for help. |
117 |
> Bad recruiters means a few "generations" of bad devs (on a Gentoo |
118 |
> time-scale I'd consider a generation to be 6 months, i.e. the time it |
119 |
> takes for a new dev to become a mentor). On the other hand, we do need help. |
120 |
|
121 |
Indeed, Petteri is rocking it. Recruiting is so important that I've |
122 |
thought about dropping some other responsibilities to get back into it. |
123 |
(I was a recruiter long ago.) Maybe once I finish my Ph.D. and the |
124 |
Gentoo book. |
125 |
|
126 |
I think a longer, 90-day probation period with a serious evaluation and |
127 |
reconsideration of developer-ship at the end would be worthwhile. |
128 |
|
129 |
> Now for a different idea on the "Improving our people" subject, just |
130 |
> before I had to (temporarily) stop my recruiting work, I was thinking |
131 |
> about setting interactive "classes" on irc. We could decide of a topic, |
132 |
> time, etc... and have devs sign up (how about non-devs too ?). The |
133 |
> session would consist of a quick recap of the necessary knowledge on |
134 |
> this topic (say dev quiz level, for example). This would have to be |
135 |
> short to avoid being boring. Then most of the session would be spent on |
136 |
> questions and answers, and very probably participants could answer each |
137 |
> others questions most of the time. Topics would certainly be more often |
138 |
> technical, but not only. We could have topics like "Good mentor |
139 |
> practices" or "How to interact with other devs" for example. |
140 |
|
141 |
I've thought about that. It seems to me that the more practical |
142 |
something is to someone, the more likely people are to actually remember |
143 |
it. With that in mind, I think "classes" would actually have to be |
144 |
workshops where everyone brought a project, and a couple of leaders were |
145 |
available for occasional questions. Vaguely like a bugday. |
146 |
|
147 |
-- |
148 |
Thanks, |
149 |
Donnie |
150 |
|
151 |
Donnie Berkholz |
152 |
Developer, Gentoo Linux |
153 |
Blog: http://dberkholz.wordpress.com |