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

[Matthew Thode]

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.

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


-- 
kind regards
Ian Delaney

-- 
Matthew Thode (prometheanfire)