Re: [gentoo-project] Recruitment issues and potential improvement

[Michał Górny]

Matthew Thode <prometheanfire@g.o> napisał:

>I am sending this on behalf of idella4, as he can't send to the list at
>this time.  Just so you know :D
>
>
>On Thu, 5 Feb 2015 07:56:41 +0100
>Michał Górny <mgorny@g.o> wrote:
>
>> Hello, everyone.
>>
>
>...
>
>> It's finally time to discuss some of the recruitment issues.
>
>ooh is it. again, again, again.... ?!
>
>> It's not
>> a new complaint that the process is time-consuming and discouraging
>to
>> our contributors.
>
>indeed no
>
>> We have a pretty low number of new recruits [well,
>> we could definitely have a higher number!] and too often they resign
>> in the process.
>>
>> As I see it, the main issue are ebuild quizzes. They are very time-
>> consuming and discouraging. It's like filling a quiz with relatively
>> simple questions where answers need to fit a key, and you have to
>tell
>> the recruit to fill in the missing bits a few times just to help him
>> get further.
>>
>> I myself attempted ebuild quiz twice, because the first time I simply
>> ended up not having the time for it. My late recruit was making slow
>> progress, and recently vanished -- hopefully only because he doesn't
>> have will for that anymore. As I see it, the disadvantages outweigh
>> the benefits here.
>
>Well so far we have
>
>"I totally agree, and I have been saying that for years"
>and
>
>"I thought the quizzes were kind of fun. They took a little while, but"
>
>and
>
>"The quizzes are already relatively easy,"
>
>the morale here being something I learned in the early stages of the
>education stream of my degree back in the day.  Give the same task to
>different people and there are different reactions and approaches.  So
>don't go trying to generalise on how mentorees cope or fail to adapt.
>There are as many different responses as there are mentorees.  However
>let's not dismiss individual view on this outright.  The collective is
>after all made of each individual's input.  We find some common factors
>here; time available and time invested by a mentoree, and a mentoree's
>overall motivation.
>
>The task for any mentor is to get a firm handle on a mentoree's skills,
>knowledge, motivation, area(s) of interest and even more.  A mentor
>need know who and what he is working with, then achieving the tasks to
>achieve final goals then starting falling into place with relative
>ease.
>

And this seems to be a very important point. Quizzes work for some people. Some contributors will never become Gentoo developers because of them, effectively forcing us to proxy their commits.

Having more freedom on achieving the goal of getting a well-trained developer works for me as well.

>>
>> I have discussed this with kensington and a few Council members
>> (unofficially), and we came up with following ideas:
>>
>> 1. remove or reduce the ebuild quiz to a reasonable number of
>> questions. In other words, make it bearable. Focus on the stuff that
>> can't be checked otherwise.
>>
>> 2. Add an extra contribution period in which the candidate commits to
>> the tree through Pull Requests. Developers watch the requests, review
>> them and decide when the recruit is ready. We may extend this with
>> requirements like '3 different developers must review late activities
>> and evaluate them'.
>>
>> 3. Possibly extend the recruit-recruiter interaction. Rather than
>> treating the interrogation as some kind of final confirmation, make
>it
>> a small extra part of the learning process. In other words, reduce
>> the other parts, fill in the blanks here.
>>
>> What do you think?
>>
>
>
>This reads like yet another sample of "hey I found this works for me so
>let's make it for everyone 'cause I, actually, we, think it's good."
>Shaded of 'let's rid herds'.  After all if it works well in our broad
>scope, well, let's make it global.
>
>The point here is that getting devs into the gentoo community means
>playing the numbers game.  I have 2 mentorees both of whom I have I
>don't see ever getting there.  One has more insight and savvy about
>portage than most devs but appears content doing what he does as a user
>within the comfort of his overlays.  He also has himself horribly over
>stretched, but then he'd make a good dev.  The disinterest and lack of
>preparedness of a mentoree to sink in the time and effort to
>prepare for final review sees them self select themselves out of
>contention. The focus of importance has been touched upon lately, which
>is mentoring.  A senior dev posted an email months ago about making a
>wiki page pairing keen users with would be mentors, and last I asked he
>never did it because of the time factor. surprise surpise.  The
>proxy-maint project to me is an obvious path of assistance in this
>topic, a project I just recently joined and am still 'getting into'.
>
>I suggest you all re-read the reply by Markos to this thread.  He
>illustrates some key principles as an exp recruiter;
>
>a) the task of recruiters is to pass someone equipped to handle a
>number of generic tasks and responsibilities in the gentoo project, not
>just those he or she likes and is working in and on. They need a view
>of the bigger picture to be a dev, not just 1 or 2 little ones.
>GET OVER IT.
>
>b) The time consumed in a recruiting session is defined mostly in a
>mentoree's under preparation.  The recruiter it seems ends up playing
>part mentor during a final review.
>
>I was bounced back to my mentor by Markos in final review, so I know
>about being under prepared.  Markos was quite right in doing so at the
>time too.  There was nothing he said I needed to know about that
>I didn't actually need to know about.  Being prepared to become dev was
>never easy. Some may make it look easy but remember you can't
>generalise. For those who do, nice for them and that's all.
>
>If the recruiting process needs anything, it needs a search engine for
>the dev manual. The wiki pages has one I think.  Finding something you
>know to be in there in the dev manual is up there as the biggest time
>consumer of all.

-- 
Michał Górny