From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LPUjl-0004bj-AN for garchives@archives.gentoo.org; Wed, 21 Jan 2009 04:30:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19BF9E0575; Wed, 21 Jan 2009 04:30:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 9F6B5E0575 for ; Wed, 21 Jan 2009 04:30:26 +0000 (UTC) Received: from gentoo.org (c-98-246-79-112.hsd1.or.comcast.net [98.246.79.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id B79A2647EF; Wed, 21 Jan 2009 04:30:25 +0000 (UTC) Date: Tue, 20 Jan 2009 20:30:23 -0800 From: Donnie Berkholz To: Denis Dupeyron Cc: Gentoo project list Subject: Re: [gentoo-project] Improving our people Message-ID: <20090121043023.GA19091@comet> References: <1816200222-1232218654-cardhu_decombobulator_blackberry.rim.net-1608419775-@bxe165.bisx.prod.on.blackberry> <4976627D.6050306@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <4976627D.6050306@gentoo.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Archives-Salt: 884a3c06-9532-42ad-b9a1-04623fc5988c X-Archives-Hash: 2766ffe50158ae90444b4f6e08a1af98 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? >=20 > Are you trying to rate the mentor or the mentee here ? The mentor, primarily. Evaluating the mentee is a separate issue, and I=20 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.=20 With this, we can do a better job of giving recognition to the good=20 ones. Recognition is so important in volunteer projects, and we give=20 almost none to our mentors. Furthermore, knowing who the best mentors=20 are gives us a good idea of pairs for co-mentoring and potential=20 recruiters. It isn't necessarily obvious from a recruiter's interaction=20 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=20 help them improve at mentoring or eventually say they just can't mentor=20 anymore. Since the product of a mentor is a new developer, the best way to look=20 at the strength of a mentor is to look at who he's mentored. > > Reward mentors publicly > > Recognition >=20 > 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. >=20 > > Mention in recruitment email >=20 > 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=20 of mention in the email could be a subtle clue in itself. =3D) > > Get better new devs >=20 > 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=20 how good of a dev they are (perhaps over their first 90 days).=20 Predicting is hard, looking at how they perform at the actual task is=20 easier. > Should we go hunting for candidates more actively ? I did this in the=20 > past and usually this doesn't work very well for various reasons.=20 > Should we advertise our needs more ? Or advertise only when there are=20 > urgent needs in order to avoid a wear-off effect ? We should always be on the lookout for good people. Our standard=20 shouldn't drop at all even if we desperately need new devs. The only=20 thing that should change is how much time we spend looking for those who=20 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=20 learnable. > > Improve existing devs by pairing w senior mentors (code review,=20 > > designing/proposing major changes, etc) >=20 > 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=20 necessarily pairing with the same person forever. As you become more=20 experienced and start trying new things, you should switch mentors to=20 those who are just a level "above" you in whichever area you're trying=20 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 >=20 > 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 he= lp. Indeed, Petteri is rocking it. Recruiting is so important that I've=20 thought about dropping some other responsibilities to get back into it.=20 (I was a recruiter long ago.) Maybe once I finish my Ph.D. and the=20 Gentoo book. I think a longer, 90-day probation period with a serious evaluation and=20 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=20 something is to someone, the more likely people are to actually remember=20 it. With that in mind, I think "classes" would actually have to be=20 workshops where everyone brought a project, and a couple of leaders were=20 available for occasional questions. Vaguely like a bugday. --=20 Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkl2pN8ACgkQXVaO67S1rtuQzACgz1HdEaEjQVagFNO2l1lN9/W/ oyoAn39rDdWGP9GZIXkpvGx8UzlZvaLV =z6d2 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2--