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

[Justin (jlec)]

On 05/02/15 07:56, Michał Górny wrote:
> Hello, everyone.
>
> It's finally time to discuss some of the recruitment issues. It's not
> a new complaint that the process is time-consuming and discouraging to
> our contributors. 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.
>
> I have discussed this with kensington and a few Council members
> (unofficially), and we came up with following ideas:
>

Hi,

just as a general remark, from my own experience I know that it is very hard to
judge recruitment if you have never recruited someone. So please be careful with
assumptions about the good and bads of the current process. (You should also
discuss with recruiters and not only with the council.)

Second, actually yesterday I went through all current open bugs and there was no
one ready to be recruited. So I think a crucial consideration should be the
quality, availability and motivation of good and well trained mentors. This is
how valuable recruits are generated.

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

One point beyond the the actual answer of the quizzes, is having a basis to do
the review session on. In case you are removing the majority of the questions,
we would need to ask them in one or the other way to cover the topics. And this
would enlarge the time needed for the review sessions enormously. What in turn
would slow down the whole recruitment.

" ... can't be checked otherwise." Who is signing responsible for checking this?

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

This needs to be split in two parts, which is actually the current state.
First the mentor should be sure that the recruit knows the business before
opening a bug at all. And second the mentor needs to review the commits in the
first month as already stated in our policies.

How this is done is up to the mentor.

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

It is not the recruit-recruiter, but the recruit-mentor relationship you should
consider. The recruiters are checking the amount and quality of knowledge the
recruit has, when the mentor thinks she/he is ready to join. Teaching and
supervising is the job of the mentor. The recruiter is just a controlling
instance of the decision of the mentor.

All in all you are right the quizzes suck. But chopping them down isn't the
solution. Looking at all recruits I have seen so far it all depends on the
mentor (neglecting those recruits, who could have been devs for ages due to
their depth of knowledge). So we should discuss the mentoring/training of the
new ones as central part of this topic.


Justin