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