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

[Michał Górny]

Dnia 2015-02-05, o godz. 18:08:01
Markos Chandras <hwoarang@g.o> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 02/05/2015 05:54 PM, Michał Górny wrote:
> > Dnia 2015-02-05, o godz. 17:50:21 Markos Chandras
> > <hwoarang@g.o> napisał(a):
> >
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
> >>
> >> On 02/05/2015 06:56 AM, 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:
> >>>
> >>> 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?
> >>>
> >>
> >> So you want to discuss the procedures of how a team within
> >> Gentoo operates without talking to that team first. And lets say
> >> you get an agreement on the list on how recruiters should do
> >> their job, and what means they should use, and then you expect
> >> that team to simply follow that? Well how about *no*. It's nice
> >> to take decisions on behalf of a team that you are not part of
> >> and then simply expect them to follow what you have agreed on.
> >> Sorry it's not going to happen simply because you wanted to. And
> >> you really can't have the council to make such decision when that
> >> team is very much alive and active. If you don't like how we do
> >> things, then talk to us.
> >
> > I'm talking to you. Publicly, via this list. Is this a problem?
> >
>
> Taking this to a public debate, means that you expect recruiters to
> follow what the majority "decides". This is not how the teams operate
> in Gentoo. I explained to you why the process is not as "stupid" as
> you may think. Certainly there ways to improve it, but like I said,
> before you judge the process, you should discuss "mentoring" first.
> This is where the problem is.

No, it is just about transparency.

-- 
Best regards,
Michał Górny