Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Tobias Heinlein]

I'd first like to extend the idea of bug #312977. It's basically about a
different level of detail for each question.

I think the quiz questions can be divided into different groups:

1) Questions that are fun to answer. People should either already know
the answer, know where to look, or be willing to figure the answers out
themselves without a hint to specific docs.

2) Questions about stuff that people NEED to know for day-to-day
development, but that aren't much fun to answer. Petteri's proposed
level of detail would be appropriate here.

3) Questions that aren't that important at all and would just be "nice
to know". These are the ones that make people give up on the quizzes
because they are boring and the answers hard to find. Most people would
like to see this kind of questions dropped entirely, but recruiter's
point is that people should know about them, even though they aren't
fun. This is why for these I'd add a more exact pointer to the docs,
similar to the way we do in the interviews when a recruit doesn't know
an answer. This way they won't be demotivated because they won't have to
search for too long, yet know the answer and remember it when they need
it someday.

Examples for these:

5.	What is the Gentoo Foundation? How does one apply for membership and
who are eligible?
	[Gentoo Foundation Bylaws, "Members"]

5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
	inside SRC_URI, DEPEND, etc?
	[Devmanual, Caching]
	

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.

As soon as we have implemented that, we can think about how to make the
ebuild-related questions more interesting by using tasks and example
ebuilds. I guess this part will take a longer time.

basile wrote, on 04/04/2010 05:16 PM:
> The learning flow should go something like this:
> [..]

I like that idea. However, I would combine writing the example ebuild
(i.e. "doing the task") and answering questions. There's no need to show
twice what you have learnt. Also, some of our questions could pretty
easily be replaced by doing a task, some cannot.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Eray Aslan]

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.

What is demotivating is a) lack of response from your
mentor/proxy-maintainer etc.  It is demotivating when you have to wait
for days for each question you ask.  b) infighting and name calling one
sees on irc, gentoo-dev etc.  "Do I really want to be a part of this?"
pops into mind.

Suggestions:
1. Bring your responsibilities in line with your capabilities.  If you
are always falling behind, either increase the time you spend on Gentoo
or decrease your responsibilities.  It is no fun playing catch-up.
2. Streamline the recruitment process so that existing devs do not spend
too much time and effort during mentoring.  Objective is to make
recruitment not a burden on the dev, i.e streamline for the dev not for
the candidate.
3. Take it down a notch in gentoo-dev, irc.  No ad hominem attacks and
no flame wars please.  You are supposed to enjoy this.  Easier said than
done I suppose.

-- 
Eray

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Jon Portnoy]

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? :)

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[George Prowse]

On 05/04/2010 17: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? :)
>
That assumes the system is working perfectly and the whole fact that we 
are having this discussion would go against that.

 From what i've read in the community, lots of people would have no 
problems helping out maintaining packages, they just don't want the 
baggage that comes with it.

You could say they're lazy or they're not the "type of developers you 
want" but at the end of the day they're just different developers, most 
of whom probably just want to make sure the packages they like are in 
the tree and updated.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Jon Portnoy]

On Mon, Apr 05, 2010 at 05:50:49PM +0100, George Prowse wrote:
> That assumes the system is working perfectly and the whole fact that
> we are having this discussion would go against that.
> 
> From what i've read in the community, lots of people would have no
> problems helping out maintaining packages, they just don't want the
> baggage that comes with it.
> 
> You could say they're lazy or they're not the "type of developers
> you want" but at the end of the day they're just different
> developers, most of whom probably just want to make sure the
> packages they like are in the tree and updated.

Which is all well and good -- the "you wrote some ebuilds so here's
your commit privs and @gentoo.org" approach to recruitment worked great
when Gentoo had a few dozen developers.

Today QA is a bit more important, and development is often rather more
complex than "new version, bump the ebuild" -- it's important that new
developers have a firm understanding of ebuild complexities.

I have no dog in this fight, I don't even like resurfacing to post to -dev.
Just here to offer some insight on why we originally kept the quiz system.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Mon, Apr 5, 2010 at 11:57 AM, Jon Portnoy <avenj@eris.oppresses.us> wrote:
> Which is all well and good -- the "you wrote some ebuilds so here's
> your commit privs and @gentoo.org" approach to recruitment worked great
> when Gentoo had a few dozen developers.
>
> Today QA is a bit more important, and development is often rather more
> complex than "new version, bump the ebuild" -- it's important that new
> developers have a firm understanding of ebuild complexities.

That's a very important point. On one side there are developers and
would-be developers who want an easier way to recruit people. Most
ideas revolve around lowering the technical/social barriers. On the
other side there's QA and a bunch of other developers who want fewer
people screwing up the tree. Those are proponents of being stricter
during the recruiting process (i.e. in the end recruiting fewer
people) and firing more devs.

None of them though help the poor guys in the middle. Those are the
recruiters who could swing completely one way or the other for
simplicity, or be more subtle and try and make the best out of the
situation and resources.

When you're all done barking, and in case you really consider helping
here are two things you can do:
 - join the recruiters
 - actually *mentor* people to become developers. And by that I don't
mean passing them your quiz answers, but really training them and
preparing them to become good and well behaved developers. When people
ask me how to go about that my usual answer is do as you were teaching
your son/little brother how to fly fish (or replace fly fishing with
what you do best). Start from the start, progress from there, don't
overlook any aspect of the art (there's more to being a dev than
writing ebuilds), and be ready to spend hours explaining and
re-explaining. If your recruit doesn't get it then it can only be your
fault, so try harder.

Before you replace/change a system you should first try and make it work.

> II don't even like resurfacing to post to -dev.
> Just here to offer some insight on why we originally kept the quiz system.

Hi Jon, long time no see. Thanks for doing that.

Denis.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Zeerak Mustafa Waseem]

[-- Attachment #1: Type: text/plain, Size: 3151 bytes --]

On Mon, Apr 05, 2010 at 04:07:01PM +0000, 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? :)
> 

There should be a process of weeding out developers that bitch and/or whine, but if most of the teams are understaffed then there has to be done something about it.
The way I see it there are two options: 
a) Scale down the size of the operation, reduce packages offered, and if there are more packages wanted, let the users maintain them. 
b) Look at an effective way of making the process of become a developer (and being a developer for that matter) more attractive.

The first option could be somewhat simple, we already have overlays so those could simply be used. The second option (which would be the best IMO) is a fair bit harder. The first thing that needs to be done is find out why people don't want to become developers. I've heard a few users mention the quiz, but it seems that the thing keeping most people away from becoming developers are all the flame wars that have occured, and the fact that it (to us users) seems like the council isn't doing much of anything about it. 
So while I believe that improving (and/or updating) the recruitment process is important, I think there would be more success if it seemed like a nice place to be a part of, and that bad behaviour is dealt with.

-- 
Zeerak Waseem

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On 04/05/2010 09:26 PM, Zeerak Mustafa Waseem wrote:

> 
> The first option could be somewhat simple, we already have overlays
> so those could simply be used. The second option (which would be the
> best IMO) is a fair bit harder. The first thing that needs to be done
> is find out why people don't want to become developers. I've heard a
> few users mention the quiz, but it seems that the thing keeping most
> people away from becoming developers are all the flame wars that have
> occured, and the fact that it (to us users) seems like the council
> isn't doing much of anything about it. So while I believe that
> improving (and/or updating) the recruitment process is important, I
> think there would be more success if it seemed like a nice place to
> be a part of, and that bad behaviour is dealt with.
> 

Developers are not required to be subscribed to any of the mailing lists
where the huge threads happen so if they want they can just ignore them
and go about maintaining their packages.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05-04-2010 18:26, Zeerak Mustafa Waseem wrote:
> On Mon, Apr 05, 2010 at 04:07:01PM +0000, Jon Portnoy wrote:
> There should be a process of weeding out developers that bitch and/or whine, but if most of the teams are understaffed then there has to be done something about it.
> The way I see it there are two options: 
> a) Scale down the size of the operation, reduce packages offered, and if there are more packages wanted, let the users maintain them. 
> b) Look at an effective way of making the process of become a developer (and being a developer for that matter) more attractive.
> 
> The first option could be somewhat simple, we already have overlays so those could simply be used. The second option (which would be the best IMO) is a fair bit harder. The first thing that needs to be done is find out why people don't want to become developers. I've heard a few users mention the quiz, but it seems that the thing keeping most people away from becoming developers are all the flame wars that have occured, and the fact that it (to us users) seems like the council isn't doing much of anything about it. 
> So while I believe that improving (and/or updating) the recruitment process is important, I think there would be more success if it seemed like a nice place to be a part of, and that bad behaviour is dealt with.

The Council has a very important role in Gentoo, but if everyone keeps
turning to them to do everything, nothing will get done and they'll get
swamped trying to do anything.
Bad behaviour in the mailing lists is something that all of us have an
obligation to prevent and help fix - including every developer and all
interested community members. If and when someone violates Gentoo's Code
of Conduct[1] and or exhibits a repetitive abrasive behaviour, please
contact either the User Relations[2] or the Developer Relations[3] teams
in case of an user or a developer.
As Petteri already replied, developers who chose to focus in their
"corner" are free to ignore most of the mailing lists and have no
requirement to participate or even read the flames. In other words, if
you'd like  to become a developer but have kept away because of the
flames, don't worry as you don't have to get involved on them.
However and despite all the recent complaints about flames in the
mailing lists, as someone that has been following the mailing lists for
a while, the amount and level of flames has been substantially reduced
in the last 2 years or so. We still have flames, but nothing like we
used to have before. Also noteworthy, the number of people involved in
the flames is very small and the majority is well known.

 [1] - http://www.gentoo.org/proj/en/council/coc.xml
 [2] - http://www.gentoo.org/proj/en/userrel/
 [3] - http://www.gentoo.org/proj/en/devrel/

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLupmUAAoJEC8ZTXQF1qEPXzgQAISLb1K8s4Fa2ORYK4+Lef/Y
YeAYiM5xzNPl6kTi6rJF1IoQwDuaS0G/YfRRtzDYeibcYBE0GLVQL0cAyQDTF371
EvgQblvMpTpay8hiNmtdNAb0X6Bm5WUhZoTeY+ayrh6Yih+cniGP5K+zP70550vQ
vvI0y9AdebwZzWrjedeEkUutaxNoBrED7IOfdixDpgD2110NuRcBHpdiBqen0exr
Q2iBdG2ynfdEzYyYAgGHvHcjibtlboLe9DWkQ/APW5uOJHCt0M5QW8HtF7eaPvNf
DS27KNwzoV1VLKxSD5I6cLFz5+NTikI7htZrxqvqjJx0zdk3X+whDOZBXT+7Amv3
2Jaiym4VCsmVXu2hWtZTlbhh0hp07ybx3NmLqNiRkNXX2636A5dCg6fwAUy/CC/g
bmCIMtkTe7oXj+m23AVB1tU5zQuaBMhuV6BucRl3on2bAkSr53Hg0dFbGwwCdiMc
FDULTNrXI1c1P5AKrqFWY6wHj6HW+m6rOVPowXHkuMEmde+T152jci0XYVOCj4v4
YjwKvDyQphk2rzb4S7hLTHpiMIzmM3cbt2/u0zfeviRkMueeT+zfIl8PMi3IN+5W
fvwbTPEq3Eh1JfEaTDDhcYXeIZjrLFx1Es2MYgBKOVzRXCZm9z1Lm15A0LgjpP9O
e09KPDVHG33o/pVc/pqA
=AdOw
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [Gentoo Phoenix] recruitment process

[Duncan]

Jorge Manuel B. S. Vicetto posted on Tue, 06 Apr 2010 02:16:52 +0000 as
excerpted:

> However and
> despite all the recent complaints about flames in the mailing lists, as
> someone that has been following the mailing lists for a while, the
> amount and level of flames has been substantially reduced in the last 2
> years or so. We still have flames, but nothing like we used to have
> before.

Yes.  And thanks to all participants who've helped make and keep it that 
way. =:^)

But while I don't do IRC, from various hints I've seen here, that hasn't 
necessarily been the case there.  I'm not making a judgement of whether 
that's good or bad and am only going on various asides I've seen here 
because as I said, I don't do IRC, but that's the impression I've gotten.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Tue, Apr 6, 2010 at 7:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> But while I don't do IRC, from various hints I've seen here, that hasn't
> necessarily been the case there.  I'm not making a judgement of whether
> that's good or bad and am only going on various asides I've seen here
> because as I said, I don't do IRC, but that's the impression I've gotten.

There's something to be said about not trusting hearsay, and also
about not talking about something you haven't witnessed yourself. In
other words it looks like you might have wasted an opportunity to shut
up.

Denis.

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Nathan Zachary]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3257 bytes --]

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Denis Dupeyron]

On Mon, Apr 5, 2010 at 12:51 PM, Nathan Zachary
<nathanzachary@gentoo.org> wrote:
> [...] but it
> would be much more enlightening to me to work on creating ebuilds while
> working one-on-one with a mentor.

The whole purpose of the training period between the ebuild quiz and
the end quiz (see [1]) is exactly this. If your mentor isn't doing
that with you then look for another one who will mentor your properly.
Don't blame the system when it's not used.

Denis.

[1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Markos Chandras]

On Monday 05 April 2010 21:51:34 Nathan Zachary wrote:
> 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
This is why it is good to train "wanna-be" developers in our overlays. 
Studying and blindly answering the quizzes is not enough. They have to work on 
actuall ebuilds, dealing with as many eclasses as possible and handle all kind 
of bugs in our bugzilla. In other words, recruitment must not be one-
dimensional but it has to cover all aspects of gentoo development
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Mon, 05 Apr 2010 03:33:52 +0200
Tobias Heinlein <keytoaster@gentoo.org> wrote:
> 3) Questions that aren't that important at all and would just be "nice
> to know".
> [snip]
> Examples for these:
> 
> 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
> 	inside SRC_URI, DEPEND, etc?
> 	[Devmanual, Caching]

How the heck is this not important? Anyone who doesn't immediately know
the answer to this has absolutely no business touching any ebuild that
might end up being given to someone else.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Mon, Apr 05, 2010 at 08:48:08AM +0100, Ciaran McCreesh wrote:
> On Mon, 05 Apr 2010 03:33:52 +0200
> Tobias Heinlein <keytoaster@gentoo.org> wrote:
> > 3) Questions that aren't that important at all and would just be "nice
> > to know".
> > [snip]
> > Examples for these:
> > 
> > 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
> > 	inside SRC_URI, DEPEND, etc?
> > 	[Devmanual, Caching]
> 
> How the heck is this not important? Anyone who doesn't immediately know
> the answer to this has absolutely no business touching any ebuild that
> might end up being given to someone else.

That question really needs chunking up offhand- there are valid usages 
of $(), but the question doesn't really ask when it's not explicitly.  
You see it, I see it, so lets skip getting into it further lest 
someone have a very easy google answer on it ;)

Either way, file a bug re: it for wording improvements if you'd like.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

[Richard Freeman]

On 04/05/2010 03:48 AM, Ciaran McCreesh wrote:
> On Mon, 05 Apr 2010 03:33:52 +0200
> Tobias Heinlein<keytoaster@gentoo.org>  wrote:
>> 3) Questions that aren't that important at all and would just be "nice
>> to know".
>> [snip]
>> Examples for these:
>>
>> 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
>> 	inside SRC_URI, DEPEND, etc?
>> 	[Devmanual, Caching]
>
> How the heck is this not important? Anyone who doesn't immediately know
> the answer to this has absolutely no business touching any ebuild that
> might end up being given to someone else.
>

My concern with these kinds of questions is that there really isn't any 
page where we have key gotchas consolidated like "don't execute external 
programs in global scope."  Sure, it is in the devmanual, and if you 
read the whole thing then maybe you might remember that one bit in 
particular.

I agree that somebody who doesn't know this particular fact shouldn't be 
committing ebuilds.  My concern is that we don't really have any way to 
make people aware of that particular fact.

Honestly, I think it would be just as effective to simply write up a 
single webpage with thou shalt not's, and not make people go hunting all 
over the place to figure out the whys.  By all means have a link on each 
thou shalt not to the reason.

There are lots of people who would be perfectly capable of doing many 
developer activities who might not come in knowing about the metadata 
cache.  They don't need to know the nuts and bolts of how it works, just 
what they need to do to avoid problems with it.

In any case, giving hints as to the location of the answer in this kind 
of a question seems fine to me.  The important thing is that the 
candidate dev learn about the potential problem - not that they figure 
it out 100% on their own.  Still, the socratic method is a good approach 
to teaching, so I'm not opposed to the Q&A format of the quiz in 
general.  We just need to let candidates know that we're there to help 
them succeed and the quiz is a tool - the goal isn't to eliminate any 
potential contributor who doesn't come to the table knowing as much 
about Gentoo as any seasoned dev.

Rich