| 1 |
05.02.2015 22:16, Michał Górny пишет: |
| 2 |
> Dnia 2015-02-05, o godz. 22:05:55 |
| 3 |
> Sergey Popov <pinkbyte@g.o> napisał(a): |
| 4 |
> |
| 5 |
>> 05.02.2015 21:22, Michał Górny пишет: |
| 6 |
>>> Dnia 2015-02-05, o godz. 21:08:43 |
| 7 |
>>> Mikle Kolyada <zlogene@g.o> napisał(a): |
| 8 |
>>> |
| 9 |
>>>> |
| 10 |
>>>> 05.02.2015 09:56, Michał Górny пишет: |
| 11 |
>>>>> Hello, everyone. |
| 12 |
>>>>> |
| 13 |
>>>>> It's finally time to discuss some of the recruitment issues. It's not |
| 14 |
>>>>> a new complaint that the process is time-consuming and discouraging to |
| 15 |
>>>>> our contributors. We have a pretty low number of new recruits [well, |
| 16 |
>>>>> we could definitely have a higher number!] and too often they resign |
| 17 |
>>>>> in the process. |
| 18 |
>>>>> |
| 19 |
>>>>> As I see it, the main issue are ebuild quizzes. They are very time- |
| 20 |
>>>>> consuming and discouraging. It's like filling a quiz with relatively |
| 21 |
>>>>> simple questions where answers need to fit a key, and you have to tell |
| 22 |
>>>>> the recruit to fill in the missing bits a few times just to help him |
| 23 |
>>>>> get further. |
| 24 |
>>>>> |
| 25 |
>>>>> I myself attempted ebuild quiz twice, because the first time I simply |
| 26 |
>>>>> ended up not having the time for it. My late recruit was making slow |
| 27 |
>>>>> progress, and recently vanished -- hopefully only because he doesn't |
| 28 |
>>>>> have will for that anymore. As I see it, the disadvantages outweigh |
| 29 |
>>>>> the benefits here. |
| 30 |
>>>>> |
| 31 |
>>>>> I have discussed this with kensington and a few Council members |
| 32 |
>>>>> (unofficially), and we came up with following ideas: |
| 33 |
>>>>> |
| 34 |
>>>>> 1. remove or reduce the ebuild quiz to a reasonable number of |
| 35 |
>>>>> questions. In other words, make it bearable. Focus on the stuff that |
| 36 |
>>>>> can't be checked otherwise. |
| 37 |
>>>>> |
| 38 |
>>>>> 2. Add an extra contribution period in which the candidate commits to |
| 39 |
>>>>> the tree through Pull Requests. Developers watch the requests, review |
| 40 |
>>>>> them and decide when the recruit is ready. We may extend this with |
| 41 |
>>>>> requirements like '3 different developers must review late activities |
| 42 |
>>>>> and evaluate them'. |
| 43 |
>>>>> |
| 44 |
>>>>> 3. Possibly extend the recruit-recruiter interaction. Rather than |
| 45 |
>>>>> treating the interrogation as some kind of final confirmation, make it |
| 46 |
>>>>> a small extra part of the learning process. In other words, reduce |
| 47 |
>>>>> the other parts, fill in the blanks here. |
| 48 |
>>>>> |
| 49 |
>>>>> What do you think? |
| 50 |
>>>>> |
| 51 |
>>>> I try to be short. |
| 52 |
>>>> First of all, i'm against to make quizzes simpler or shorter. I have few |
| 53 |
>>>> real examples, when people do a LOT of mistakes even after they passed |
| 54 |
>>>> the quizzes. |
| 55 |
>>> |
| 56 |
>>> And how people doing mistakes *after* passing the quizzes proves that |
| 57 |
>>> quizzes are good? As I see it, this just proves that they don't do |
| 58 |
>>> their job. |
| 59 |
>>> |
| 60 |
>> |
| 61 |
>> Because quizes lacks some questions? You see - we should not shorten |
| 62 |
>> them, but on the contrary - increase the question's number. |
| 63 |
>> |
| 64 |
>> So, that's a not good argument. Quizes may be flawed, but not in the way |
| 65 |
>> of 'over complicated', definitely. |
| 66 |
> |
| 67 |
> Sure. If the quizzes take so much nobody will bother writing them, |
| 68 |
> there will be no more bad developers in Gentoo! |
| 69 |
|
| 70 |
|
| 71 |
Let's throw the quizes away and give everyone commit access. |
| 72 |
At least developers count will grow, for sure! |
| 73 |
|
| 74 |
No matter that distro would be totally ruined, your goal would be achieved. |
| 75 |
|
| 76 |
>>>>> Add an extra contribution period in which the candidate commits to |
| 77 |
>>>> the tree through Pull Requests. |
| 78 |
>>>> |
| 79 |
>>>> All mentors should track their recruits during first month. If mentor |
| 80 |
>>>> doesn't do this, this is "bad" mentor, IMO. It looks like some mentors |
| 81 |
>>>> think *ok, my mentee passed the quizzes, he is a developer, i can to |
| 82 |
>>>> nothing* |
| 83 |
>>> |
| 84 |
>>> This happens *after* being recruited. What I'm talking, there should be |
| 85 |
>>> more focus on doing and judging actual contributions before all that |
| 86 |
>>> formal crap. |
| 87 |
>>> |
| 88 |
>> |
| 89 |
>> Yep. And, guess, who is responsible for that? Mentor. Tadaaam! :-) |
| 90 |
> |
| 91 |
> You still don't get my point. My point is: if a recruit has proven me |
| 92 |
> (and possibly some other developers) that he can use grep, sed, awk, |
| 93 |
> whatever just fine, why does he have to bother answering some stupid |
| 94 |
> quiz question? |
| 95 |
> |
| 96 |
|
| 97 |
In current system recruiters can not track progress of every single |
| 98 |
mentee, that's what mentors for. |
| 99 |
|
| 100 |
If you want to prove your recruit is doing fine with all stuff - try not |
| 101 |
to fight with quizes, but provide easy-to-use solution for viewing |
| 102 |
commits for recruiters, that can be answers for quizes itself. |
| 103 |
|
| 104 |
Can recruit use grep/sed/awk? That's the commit where he did this pretty |
| 105 |
fine. |
| 106 |
|
| 107 |
Does he know about live/snapshot ebuilds? That's commit where he used it. |
| 108 |
|
| 109 |
Gathering apropriate commit links can be work, that could be done both |
| 110 |
by mentor and recruit. |
| 111 |
|
| 112 |
And yes, that would be also very time-consuming, but recruiters would be |
| 113 |
glad for speeding up review sessions. |
| 114 |
|
| 115 |
-- |
| 116 |
Best regards, Sergey Popov |
| 117 |
Gentoo developer |
| 118 |
Gentoo Desktop Effects project lead |
| 119 |
Gentoo Quality Assurance project lead |
| 120 |
Gentoo Proxy maintainers project lead |
Archives