On 05/04/10 11:07, Jon Portnoy wrote:
> On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
>   
>> Just replying randomly.
>>
>> On 05.04.2010 04:33, Tobias Heinlein wrote:
>>     
>>> I think this is a good starting point to get rid of the "some important
>>> questions are too hard to answer" dilemma that can be implemented
>>> relatively fast. On top of that I like Sebastian's idea to order the
>>> quizzes by difficulty -- this means just ordering by the categories I
>>> just mentioned would be sufficient: 1 first, then 2, then 3.
>>>       
>> I am not against this idea but frankly, I do not understand what is so
>> demotivating about the ebuild quiz.  If you get demotivated because of a
>> single exam, perhaps the problem is with the motivation and not with the
>> exam itself.  I took the published quiz just for the fun of it and to
>> see where I missed.  It is not that long.
>>
>>     
> Agreed...
>
> I've been following this discussion with mixed feelings. When we 
> originally began using the quiz system the idea was simply to try
> to force new developers to RTFM -- and I was not such a fan of the 
> entire concept (as I recall, the quizzes were a "suggestion" from Daniel).
>
> As it turns out, the quiz system has repeatedly proven itself useful
> in another way: developers who whine/bitch/moan and are hesitant to 
> even attempt to complete the quizzes often turn out to be bitchy,
> unmotivated, or unpleasant developers. I don't want to name any names,
> but I've seen this often.
>
> IMO, those "boring" "too much like high school" quizzes serve one
> extremely valuable function: finding out up front who's a team player
> (or at least willing to do something mildly unpleasant for the
> Greater Good)
>
> If that's causing potential devs to drop out... perhaps the system is 
> working as it should? :)
>
>   
My problem with the quizzes is not that they have to be done, but rather
the way they are structured.  I have read through the dev manual (which
is excellent in explaining some things, and a little rough in others),
but it would be much more enlightening to me to work on creating ebuilds
while working one-on-one with a mentor.  For instance, in a recent
ebuild I wrote, the application installed successfully but yielded
sandbox errors.  By jumping on IRC and chatting with a few people, I
readily found a solution to that problem.  Later, it was brought to my
attention that there were other problems with the ebuild.  I would have
never known about these issues solely from the information presented in
the devmanual.  Therefore, I think the most valuable aspect of the
recruitment process is "hands-on" time with ebuilds, commits, et cetera
WHILE working with a mentor.

--Zach

Reply via email to