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

[gentoo-dev] [Gentoo Phoenix] recruitment process

[Ben de Groot]

On 3 April 2010 13:33, Richard Freeman <rich0@gentoo.org> wrote:
> I really think that the Gentoo recruitment process needs improvement. Right
> now it seems like a LOT of effort is required both to become a Gentoo dev
> and to help somebody become a Gentoo dev.  That means we have great people,
> but not many of them.

I agree. So what can we do to improve this process?

I myself am not fond of the quizzes, and from what I've seen most
recruits find them tedious as well. It can be quite demotivating,
maybe because it reminds one too much of highschool or something.
I took a long time myself to finish them, and that wouldn't have
been necessary, as my mentors ensured me I was ready to become a
dev. And I see the same thing happening with some of my own recruits.
They can be ready, but  just find the quizzes a chore.

So I think we need to rethink how to do this. What I have found very
helpful is to have my recruits working on actual ebuilds. The
sunrise project is ideally qualified to mold ebuild editors into
shape. Working on official overlays such as qting-edge and/or doing
proxy maintenance is also very helpful.

Recruiters (with some additional manpower) could make a list of
technical issues that recruits need to be aware of, and then gather
a number of ebuilds that display these problems and let recruits
correct some of these, under guidance of their mentors. This may
possibly be more fun and closer to the actual work that is required
of developers.

Of course this doesn't address the organizational side of things, so
we need to come up with something else for that.

Another problem I see is that our documentation seems to be scattered
all over the place. I propose that we make at least one portal page
for (prospective) developers that will link them to all the resources
they might need. It also means our existing documentation needs to
be brought and kept up to date.

Are there any other ideas on how to improve our recruitment process?

-- 
Ben de Groot
Gentoo Linux Qt project lead developer

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

["Paweł Hajdan, Jr."]

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

On 4/3/10 3:40 PM, Ben de Groot wrote:
> Are there any other ideas on how to improve our recruitment process?

The idea appeared before, but I think it's worth noting.

Either merge the ebuild and end quizzes, or make the split actually
meaningful. In my case I just finished both at the same time, but was
confused why they are separate. I think I've seen similar comments from
other developers.

I think I'd rather prefer merging the quizzes.

Paweł Hajdan jr


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

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

[Alistair Bush]

> On 4/3/10 3:40 PM, Ben de Groot wrote:
> > Are there any other ideas on how to improve our recruitment process?
> 
> The idea appeared before, but I think it's worth noting.
> 
> Either merge the ebuild and end quizzes, or make the split actually
> meaningful. In my case I just finished both at the same time, but was
> confused why they are separate. I think I've seen similar comments from
> other developers.
> 
> I think I'd rather prefer merging the quizzes.

One thing i've noticed is that the ebuild quiz is far more difficult than the 
eom quiz.   We seem to have the biggest hurdle first.

What I would like to see is either the quizzes be merged or....

An "easier" first quiz that covers the basics which after being answered the 
user can become a gentoo developer  ( ie @gentoo.org email, ssh access to 
d.g.o, etc) but no access to push directly to the tree.  Instead all commits 
must be pushed thru their mentor,  who is responsible for qa'ing and giving 
advice.   Currently I don't think mentors really have much of a role. There is 
certainly no requirement for a mentor to qa their charges commits,  but if 
they are the ones pushing to the tree the mentor has all the responsibility. 
This might just make mentors more responsible for the quality of recruits.

Some of this could be done regardless of whether there are separate quizzes or 
not obviously.  But I think it creates a nice workflow.

- Alistair.

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

[Petteri Räty]

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

On 04/05/2010 05:36 AM, Alistair Bush wrote:
>> On 4/3/10 3:40 PM, Ben de Groot wrote:
>>> Are there any other ideas on how to improve our recruitment process?
>>
>> The idea appeared before, but I think it's worth noting.
>>
>> Either merge the ebuild and end quizzes, or make the split actually
>> meaningful. In my case I just finished both at the same time, but was
>> confused why they are separate. I think I've seen similar comments from
>> other developers.
>>
>> I think I'd rather prefer merging the quizzes.
> 
> One thing i've noticed is that the ebuild quiz is far more difficult than the 
> eom quiz.   We seem to have the biggest hurdle first.
> 
> What I would like to see is either the quizzes be merged or....
> 
> An "easier" first quiz that covers the basics which after being answered the 
> user can become a gentoo developer  ( ie @gentoo.org email, ssh access to 
> d.g.o, etc) but no access to push directly to the tree.  Instead all commits 
> must be pushed thru their mentor,  who is responsible for qa'ing and giving 
> advice.   Currently I don't think mentors really have much of a role. There is 
> certainly no requirement for a mentor to qa their charges commits,  but if 
> they are the ones pushing to the tree the mentor has all the responsibility. 
> This might just make mentors more responsible for the quality of recruits.
> 

Yeah would be easy to implement if we get git some day.

Regards,
Petteri


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

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

[George Prowse]

On 03/04/2010 14:40, Ben de Groot wrote:
> On 3 April 2010 13:33, Richard Freeman<rich0@gentoo.org>  wrote:
>> I really think that the Gentoo recruitment process needs improvement. Right
>> now it seems like a LOT of effort is required both to become a Gentoo dev
>> and to help somebody become a Gentoo dev.  That means we have great people,
>> but not many of them.
>
> I agree. So what can we do to improve this process?
>
> I myself am not fond of the quizzes, and from what I've seen most
> recruits find them tedious as well. It can be quite demotivating,
> maybe because it reminds one too much of highschool or something.
> I took a long time myself to finish them, and that wouldn't have
> been necessary, as my mentors ensured me I was ready to become a
> dev. And I see the same thing happening with some of my own recruits.
> They can be ready, but  just find the quizzes a chore.
>
> So I think we need to rethink how to do this. What I have found very
> helpful is to have my recruits working on actual ebuilds. The
> sunrise project is ideally qualified to mold ebuild editors into
> shape. Working on official overlays such as qting-edge and/or doing
> proxy maintenance is also very helpful.
>
> Recruiters (with some additional manpower) could make a list of
> technical issues that recruits need to be aware of, and then gather
> a number of ebuilds that display these problems and let recruits
> correct some of these, under guidance of their mentors. This may
> possibly be more fun and closer to the actual work that is required
> of developers.
>
> Of course this doesn't address the organizational side of things, so
> we need to come up with something else for that.
>
> Another problem I see is that our documentation seems to be scattered
> all over the place. I propose that we make at least one portal page
> for (prospective) developers that will link them to all the resources
> they might need. It also means our existing documentation needs to
> be brought and kept up to date.
>
> Are there any other ideas on how to improve our recruitment process?
>

I suggested a while ago that you should have recruitment drives and 
recruitment days. Set aside a day where a few devs can answer any 
questions about what it takes to be a developer - the skills required, 
the time that needs to be set aside, the behavior expected and goals 
that developers aspire to.

Set up some threads on the forums, a channel on irc, a list like 
gentoo-recruitment and a FAQ on the front page of the website.

Armed with a list of where developers are spread too thinly, a 
willingness to answer questions (no matter how stupid you believe them 
to be) and some prior organisation then i see no reason why Gentoo 
wouldn't get an immediate influx of at least 20 well-qualified 
developers and more that are willing to give their time and limited 
knowlege to help out

"If you build it, they will come"

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

[Petteri Räty]

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

On 04/03/2010 04:53 PM, George Prowse wrote:

> 
> Armed with a list of where developers are spread too thinly, a
> willingness to answer questions (no matter how stupid you believe them
> to be) and some prior organisation then i see no reason why Gentoo
> wouldn't get an immediate influx of at least 20 well-qualified
> developers and more that are willing to give their time and limited
> knowlege to help out
> 

http://www.gentoo.org/proj/en/devrel/staffing-needs/

I don't know if developers know that this page is autogenerated from
individual project pages these days so it's easy for any developer to
get stuff there.

Regards,
Petteri


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

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

[George Prowse]

On 03/04/2010 15:05, Petteri Räty wrote:
> On 04/03/2010 04:53 PM, George Prowse wrote:
>
>>
>> Armed with a list of where developers are spread too thinly, a
>> willingness to answer questions (no matter how stupid you believe them
>> to be) and some prior organisation then i see no reason why Gentoo
>> wouldn't get an immediate influx of at least 20 well-qualified
>> developers and more that are willing to give their time and limited
>> knowlege to help out
>>
>
> http://www.gentoo.org/proj/en/devrel/staffing-needs/
>
> I don't know if developers know that this page is autogenerated from
> individual project pages these days so it's easy for any developer to
> get stuff there.
>

Looking at that page it seems clear that that is not a comprehensive list.

Maybe if all herds posted who and what they require like this:

Java Herd

2 people needed -

Essential: Java knowlege
Recommended - Javascript and ebuild writing

If no-one is willing to put a plan forward then I might acquiesce to do it.

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

[Sebastian Pipping]

On 04/03/10 16:05, Petteri Räty wrote:
> http://www.gentoo.org/proj/en/devrel/staffing-needs/
> 
> I don't know if developers know that this page is autogenerated from
> individual project pages these days so it's easy for any developer to
> get stuff there.

Has anyone every tried to read that page?
It's such a pain to that I doubt it.



Sebastian

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

[Petteri Räty]

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

On 04/03/2010 04:40 PM, Ben de Groot wrote:

> 
> Another problem I see is that our documentation seems to be scattered
> all over the place. I propose that we make at least one portal page
> for (prospective) developers that will link them to all the resources
> they might need. It also means our existing documentation needs to
> be brought and kept up to date.
> 

As I said elsewhere I support adding information to each question about
what piece of documentation has the answer. I will get to it eventually
but patches get us there faster.

https://bugs.gentoo.org/show_bug.cgi?id=312977

Regards,
Petteri


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

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

[Jesus Rivero (Neurogeek)]

Hi guys,

On Sat, Apr 3, 2010 at 9:10 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 3 April 2010 13:33, Richard Freeman <rich0@gentoo.org> wrote:
>> I really think that the Gentoo recruitment process needs improvement. Right
>> now it seems like a LOT of effort is required both to become a Gentoo dev
>> and to help somebody become a Gentoo dev.  That means we have great people,
>> but not many of them.
>
> I agree. So what can we do to improve this process?
>
> I myself am not fond of the quizzes, and from what I've seen most
> recruits find them tedious as well. It can be quite demotivating,
> maybe because it reminds one too much of highschool or something.
> I took a long time myself to finish them, and that wouldn't have
> been necessary, as my mentors ensured me I was ready to become a
> dev. And I see the same thing happening with some of my own recruits.
> They can be ready, but  just find the quizzes a chore.
>

   I understand that quizzes serve a purpose and IMHO, are a good way
to face common issues when writing ebuilds. On the other hand, I
understand that quizzes are lengthy and could become a blocker in the
recruitment process (I have met at least two prospects drop out due to
the inability to finish them, being for lack of time to concentrate or
because they got bored by the chore.)

   Maybe if we could find the way to make the knowledge found in
quizzes be more "exciting" to new devs, then we could still have a
strong recruitment process without the burden of completing the
quizzes. So, what I propose is to transform the "quizzes" part of the
process into a list of tasks the prospect should complete in order to
gain the necessary ability to "pass". This ability could be measured
in points or just by task completed.

   Then it gets interesting for them and for us. Those tasks could be
to tackle problems from the quizzes but in real ebuilds (prepared by
us for this, much as when recruiters ask us to clean some ebuild) or
could be tasks created by teams to specifically address common issues
in their domain if the prospect is trying to join them or shows an
interest on helping this specific team.

> Of course this doesn't address the organizational side of things, so
> we need to come up with something else for that.

   This doesn't address them either. But I really don't think this is
the main issue that causes the problem :) So I guess these questions
could remain in one "easy" quiz.

> --
> Ben de Groot
> Gentoo Linux Qt project lead developer
>
>

  If I can be of any assistance in this, I'll gladly help.

--
Jesus Rivero (Neurogeek)
Gentoo Python Team

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

[Sebastian Pipping]

On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote:
>    Maybe if we could find the way to make the knowledge found in
> quizzes be more "exciting" to new devs, then we could still have a
> strong recruitment process without the burden of completing the
> quizzes. So, what I propose is to transform the "quizzes" part of the
> process into a list of tasks the prospect should complete in order to
> gain the necessary ability to "pass". This ability could be measured
> in points or just by task completed.

Nice idea!


>    This doesn't address them either. But I really don't think this is
> the main issue that causes the problem :) So I guess these questions
> could remain in one "easy" quiz.

While you mention the non-technical part: I imagine a gain out of moving
that part to the very end of recruiting: to when people know they almost
made it.  Especially putting up these questions first, turns some people
away too: The problem is they get the wrong impression that being will
be about these boring things later on, but it isn't.

Betelgeuse, what do you think?



Sebastian

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

[Petteri Räty]

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

On 04/04/2010 12:48 AM, Sebastian Pipping wrote:
> On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote:
>>    Maybe if we could find the way to make the knowledge found in
>> quizzes be more "exciting" to new devs, then we could still have a
>> strong recruitment process without the burden of completing the
>> quizzes. So, what I propose is to transform the "quizzes" part of the
>> process into a list of tasks the prospect should complete in order to
>> gain the necessary ability to "pass". This ability could be measured
>> in points or just by task completed.
> 
> Nice idea!
> 
> 
>>    This doesn't address them either. But I really don't think this is
>> the main issue that causes the problem :) So I guess these questions
>> could remain in one "easy" quiz.
> 
> While you mention the non-technical part: I imagine a gain out of moving
> that part to the very end of recruiting: to when people know they almost
> made it.  Especially putting up these questions first, turns some people
> away too: The problem is they get the wrong impression that being will
> be about these boring things later on, but it isn't.
> 
> Betelgeuse, what do you think?
> 

Mentors can already suggest their students to do them in reverse order.
As always patches to separate technical and organizational stuff to
their own quizzes are accepted. My time on recruiting is quite maxed out
already. Doing this means just not fixing the quizzes but bringing all
the recruiting documentation up2date.

Regards,
Petteri


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

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

[Ben de Groot]

On 4 April 2010 11:43, Petteri Räty <betelgeuse@gentoo.org> wrote:
> Mentors can already suggest their students to do them in reverse order.
> As always patches to separate technical and organizational stuff to
> their own quizzes are accepted. My time on recruiting is quite maxed out
> already. Doing this means just not fixing the quizzes but bringing all
> the recruiting documentation up2date.

We do realize that recruiters are already stretched to their limits.
So I propose a few other people form a team to design an improved
recruitment process, including any curriculum and documentation
materials needed. Obviously this team would confer with recruiters
and incorporate their feedback into its work.

-- 
Ben de Groot
Gentoo Linux Qt project lead developer

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

[basile]

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

Sebastian Pipping wrote:
> On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote:
>   
>>    Maybe if we could find the way to make the knowledge found in
>> quizzes be more "exciting" to new devs, then we could still have a
>> strong recruitment process without the burden of completing the
>> quizzes. So, what I propose is to transform the "quizzes" part of the
>> process into a list of tasks the prospect should complete in order to
>> gain the necessary ability to "pass". This ability could be measured
>> in points or just by task completed.
>>     
>
> Nice idea!
>
>
>   
I am a dev in training.  My mentors are now looking over my end quiz.  I
am also an IT professor and teach software engineering.

The learning process was somewhat lacking in that I found myself often
just searching for answers rather than performing some exercise.  It
would help if we had exercises where the prospective dev is guided
through writing some ebuild and then commits it to some "play" overlay. 
He/she can do this over and over until the ebuild works, and then
answers quiz questions.  I effectively did this -> I wrote some
helloworld-xxx.tgz tarballs with various issues and then wrote ebuilds
to build/install the package, committed them to a git overlay I set up, etc.

Also, when I asnwered the quiz questions, I documented the references
where I found the answers and I documented a link to my ebuilds on my
git repo.

The learning flow should go something like this:

1) Read this documentation, eg. http://devmanual.gentoo.org/ section on
Eclass Writing and Tool References

2) Write an ebuild/eclass to do something, with skeleton howto steps,
eg. name transformation like versionator (don't worry if its already
been done)

3) Commit to the play overlay

4) Test the ebuild/eclass

5) Answer ebuild questions

6) Go back to step 1 and address the next issue.

-- 

Anthony G. Basile, Ph.D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
USA

(716) 829-8197




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