From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NyrOP-0001vh-1y for garchives@archives.gentoo.org; Mon, 05 Apr 2010 18:51:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 093C3E0856; Mon, 5 Apr 2010 18:51:22 +0000 (UTC) Received: from themis.wsgurus.com (themis.wsgurus.com [65.98.70.26]) by pigeon.gentoo.org (Postfix) with ESMTP id B89DFE0823 for ; Mon, 5 Apr 2010 18:51:13 +0000 (UTC) Received: from 75-132-6-220.dhcp.stls.mo.charter.com ([75.132.6.220] helo=[192.168.1.100]) by themis.wsgurus.com with esmtpa (Exim 4.69) (envelope-from ) id 1NyrO2-0001Fw-Tz for gentoo-dev@lists.gentoo.org; Mon, 05 Apr 2010 14:50:39 -0400 Message-ID: <4BBA3136.3030709@gentoo.org> Date: Mon, 05 Apr 2010 13:51:34 -0500 From: Nathan Zachary User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100322 Thunderbird/3.0.3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Gentoo Phoenix] recruitment process References: <4BB93E00.3070301@gentoo.org> <4BB97A39.20500@caf.com.tr> <20100405160701.GA15345@eris.oppresses.us> In-Reply-To: <20100405160701.GA15345@eris.oppresses.us> Content-Type: multipart/alternative; boundary="------------010702040207020706060601" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - themis.wsgurus.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gentoo.org X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: b009ab96-1d79-430d-88c2-faf12e36698d X-Archives-Hash: 0c5a6081b52dbc6d783850f5ff44a160 This is a multi-part message in MIME format. --------------010702040207020706060601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------010702040207020706060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
 --------------010702040207020706060601--