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