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