FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-03-2010, 01:40 PM
Ben de Groot
 
Default recruitment process

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
 
Old 04-03-2010, 01:53 PM
"Paweł Hajdan, Jr."
 
Default recruitment process

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
 
Old 04-03-2010, 01:53 PM
George Prowse
 
Default recruitment process

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"
 
Old 04-03-2010, 02:03 PM
Petteri Rty
 
Default recruitment process

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
 
Old 04-03-2010, 02:05 PM
Petteri Rty
 
Default recruitment process

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
 
Old 04-03-2010, 02:22 PM
George Prowse
 
Default recruitment process

On 03/04/2010 15:05, Petteri Rty 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.
 
Old 04-03-2010, 07:00 PM
"Jesus Rivero (Neurogeek)"
 
Default recruitment process

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
 
Old 04-03-2010, 09:39 PM
Sebastian Pipping
 
Default recruitment process

On 04/03/10 16:05, Petteri Rty 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
 
Old 04-03-2010, 09:48 PM
Sebastian Pipping
 
Default recruitment process

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
 
Old 04-04-2010, 09:43 AM
Petteri Rty
 
Default recruitment process

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
 

Thread Tools




All times are GMT. The time now is 11:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org