Cultivating contributors is a tricky endeavor; large projects like
Linux distributions need to add developers, testers, packagers,
and more on an ongoing basis. But recruiting involves more than
extending an invitation; training new talent on the ins-and-outs of
the development process is vital, as is deftly handling volunteers
that don't quite have their act together. Debian, for instance, has a
multi-step process for joining that
requires both contribution and a recommendation from existing
Gentoo has long taken the recruiting game seriously as well,
but it recently decided to shut down its
developer-recruitment web application, and return to its previous
method of email-submitted "quizzes." Opinion is divided as to which
direction the recruitment process should take; the distribution has
historically found success with its structured process, pairing new
volunteers with mentors for training. But if the mechanics of
maintaining that process become a burden, it can drive off new
contributors and mentors.
In the past, the Gentoo recruitment training process
centered around a set of quizzes that each new recruit had to complete
successfully before getting commit privileges. There were two
quizzes: one for those who would be working with the distribution's ebuild
build system or Portage tree, and
another for those who would be working on infrastructure and other
non-build components. Both quizzes include a mix of policy and
technical questions, requiring (sometimes lengthy) essay-style
answers. For example, the ebuild
What is the proper method for suggesting a wide-ranging feature or
enhancement to Gentoo? Describe the process for getting this feature
approved and implemented.
in the "Organizational structure" section, and:
You find a package that will not build on some architectures without
PIC (-fPIC) code in the shared libraries. What is the proper way
to handle this situation?
in the "Ebuild technical" section. The recruit would send the
completed quiz to his or her mentor and, upon receiving a satisfactory
grade, would advance to the next step: opening a recruitment "bug" to
track the recruit's progress, which eventually culminates in account
The term "quiz" might be slightly confusing to some who associate the
word with brief and/or quick tests. In Gentoo's case, the recruit
could take as much time as necessary to complete the questions, and
might be asked by the mentor to try again through several iterations.
On the plus side, this technique emphasizes letting the new developer
get familiar with the documentation and the distribution's way of
doing things. But it also led to new recruits taking months or even
years to complete the quizzes, often while they continued to
contribute back in "unofficial" ways.
The web application (at recruiting.gentoo.org) was
deployed in 2010, with the goal of streamlining the process by storing
the questions and answers online. Mentors could provide feedback
through the application, without juggling email threads. But the web
application has not proven so useful in practice: it is buggy, it has
UI issues, it runs on an outdated version of Rails, and there is
insufficient developer-power in the project to fix it up. All of
those factors combined to convince the recruiters to move back to the
old-style, email-driven quiz process.
Markos Chandras from the Gentoo
Recruiters team announced
the decision on July 14, saying that new
recruits (not including those who have already started using the
web application) should use the old quizzes instead. "We
understand that quizzes is not an ideal way to 'hire' people either, but they
worked ok for all these years and it is the only alternative we have
at the moment." Chandras added that hopefully a future Google
Summer of Code (GSoC) project will be able to improve the application.
But not everyone agreed that the old-style quizzes worked acceptably,
or that the web application was the only alternative to consider. Ben
de Groot said
that the time involved takes away from time the new recruit could
contribute to Gentoo:
The first time I did the quizzes, it took me 9 months. After having
been away for a couple of years, I recently returned as Gentoo
dev, and the second time I did the quizzes it took me 3 months.
I've seen others take a long time doing them as well. Davide (pesa),
one of our most valued contributors in the Qt team, took close
to two years I think.
I think this way we lose much valuable developer time. These
people could have had commit access and done much
valuable work so much earlier, if there wasn't this obstacle
of the quizzes...
[...]What I noticed in my own experience as lead of our Qt team,
is that getting people started on the real work, being part of the
developer community and process, is a good way to introduce
them to how we do things in Gentoo. The Qt team has its official
overlay, and it is easy for us to give new contributors access to
it. That way they can learn to write ebuilds and eclasses, and
how to improve them, commit them, and get used to a good
De Groot proposed improving the wiki documentation to cover the quiz
material, and having mentors walk their recruits through the
documentation while simultaneously helping them learn development
work. Alternatively, he said, mentors could assign tasks for recruits
to complete. Chandras replied
that the quizzes cover a specific set of material to ensure
consistency between mentors, and that doing away with them would
necessitate someone else monitoring the mentors to ensure they cover
the proper work. On the other hand, he did like the idea of improving
the wiki, and suggested that the post-quiz review steps could be
simplified, particularly if a recruit has already been
Rich Freeman expressed surprise at the lengths of time taken by some
recruits, but agreed
that the quizzes have weaknesses, saying "I did struggle because
policies were not always spelled out" and "sometimes the
indirectness of some of the questions was frustrating," but
that he completed his quiz in eight hours, and learned a lot in the
process. He also suggested improving documentation, in particular by
creating step-by-step tutorials for ebuild, which could guide new
recruits through learning the system (in contrast to the existing
documentation, which is predominantly reference material).
Several people responded that the absolute time required to complete
the quizzes was not the issue, rather it was finding the free time to
devote to the process amidst all other responsibilities (including
Gentoo contributions). Peter Stuge commented,
jokingly, that "the idiots that the quizzes are designed to keep
out can spend two (or four/eight if they need) days to pass anyway
with a little dedication, while less idiotic idiots such as perhaps
myself need years because we're doing whatever work as opposed to
learning foundation bylaws by heart."
Freeman also speculated in several messages on the impact the
recruitment process has on the overall Gentoo culture, apart from the
method used to indoctrinate new developers. On one hand, he suggested
that the need to ensure a training regimen stemmed from technical
choices like using CVS (where commit access is required). Using Git
instead would alleviate some of the concern about adding new
developers, because they could still do useful work in their own
trees. More developers with more freedom to improve packages, he
said, "would be a good thing. The all-or-nothing model too often
turns out to be nothing."
On the other hand, Freeman argued
that the non-technical topics in the quizzes — such as learning
to work within teams, ask questions, and build consensus — are
more important in the long term:
What really causes havoc around here is when people change ebuilds
without consulting with the maintainer, or when they go tweaking
system packages without a great deal of care and being part of the
appropriate team, and so on. [...] Many of these issues have dwindled
in recent years, and I think it is precisely because teams like the
recruiters have been paying more careful attention to them.
Freeman may have summed up the feelings of many Gentoo developers: the
specifics of the training process are less important than the fact
that is it deliberate and guided by active mentors and recruiters,
because the end goal is to integrate the new developers into the
Gentoo community — not to train them on a particular suite of
tools. On that front, the web application still has its share of
fans. Theo Chatzimichos said
he prefers it to the email-driven quizzes because it simplifies
keeping track of recruits' answers. Chatzimichos said he mentors two
or three recruits at a time, and proposed putting out a call for
volunteers to revamp the web application, while making sure to not let
the web application get out-of-sync with the quizzes.
In an email, Chandras said that Gentoo averages 10 to 15 recruits per
year. That may not be many when compared to large distributions like
Ubuntu or Fedora, but in a sense it only makes the recruitment process
more critical. It is clear from the discussion that neither the old
email-driven quizzes nor the recent web application quite meet
everyone's needs — but at least the recruiters and the mentors
are committed to sticking with the process even in spite of its
Comments (31 posted)
I guess this is a matter of opinion, but on Gentoo I don't think we're
really at much risk of driving people away by OVER-communicating.
-- Rich Freeman
Comments (none posted)
The 3.5-gnu Linux-libre kernel
released. The Linux-libre kernel meets the Free Software Foundation's
criteria for free software and is suitable for distributions
that aim to include only free software
Comments (90 posted)
The July 22, 2012 entry in the slackware-current changelog (i386
has the announcement that Slackware 14.0 has reached beta.
"Howdy! Lots of shiny stuff here, including the long awaited Xfce 4.10!
Thanks to Robby Workman for the initial set of build scripts, and lots
of testing (plus some very helpful notes about things such as the proper
build order). I'm calling this a beta (finally!), and it's really very
close to what we expect to release. Test away.
Comments (3 posted)
The Fedora project has launched a sweepstakes for Fedora contributors with
Open Hardware for prizes.
Unfortunately, we don't have enough hardware to give something to every
Fedora Contributor, so this is a sweepstakes, and sweepstakes come with
all sorts of rules and restrictions.
This sweepstakes is for Fedora Contributors (defined as users in the
Fedora Account System who have signed the FPCA and are in one additional
group). There are some geographic and age restrictions, the reason for
this is that it is extremely costly and time-consuming to determine
whether or not it is possible to run a sweepstakes in a given country.
Sweepstakes laws and regulations vary considerably from country to
country, and many countries have strict registration requirements and
fees associated with running sweepstakes. Other countries simply
prohibit sweepstakes entirely. As a result, we are only offering this
sweepstakes in countries where we know that the sweepstakes is lawful.
We sincerely apologize for any inconvenience this may cause you.
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
On her blog, Fedora project leader Robyn Bergeron considers
a different approach for the Fedora Users and Developers Conference (FUDCon). In the post, she suggests having a single FUDCon per year (rather than four), timing the conference so that it works well with the release schedule, and renaming (and repurposing) it to "DoCon". "Make this event be focused on the “do-ers” – and not the users. I mentioned previously in this post that it does not make the best use of our face-to-face bandwidth, and I’m sticking to that — and moreover, I think that trying to plan a parallel “user track” just winds up taking people away from getting things done. This is not a “we don’t care about the users” statement in any way, so don’t jump down my throat. But I think that mixing up the event tends to leave casual users/potential users/non-contributor users unsure about what to attend, and I haven’t seen any evidence on any large scale that users magically become contributors at a FUDCon. And there is NO REASON IN THE UNIVERSE why we can’t come up with a type of event that costs significantly less to host, requires fewer numbers of contributors to attend, and is geared solely towards users/potential users/potential contributors, and can be made repeatable in many places. The fact that a FUDCon in Pune can draw in a crowd of 500+ shows that there is absolutely interest.
Comments (9 posted)
Over at The H, Richard Hillesley has an in-depth look
at the history and future of Mandriva, both the company and the distribution. "Mandriva is hoping that 'contributors will come to the new distribution because it will be a fun place to be. The new distribution will bring very much the same care for the end user that the Mandriva line of distributions have always brought, and will hope to be as technically advanced as Fedora,' says [Charles H.] Schulz, 'and this will be exciting and new.' Mandriva the company will contribute but does not expect to be in charge. 'We're not going to hog the governance. We won't be the ones that decide,' says Schulz. There has already been a community proposal for hosting the servers, and Mandriva and Rosa Labs will also contribute some servers, 'but we prefer to lead by example rather than domination.'
Comments (none posted)
The H looks
at the inclusion of the Cinnamon desktop in the Fedora 17 repositories.
"Now that Muffin and the Cinnamon package have been approved, the
desktop has been included in the Fedora 17 standard repositories; from
there, it can be installed using a command such as yum install cinnamon and then selected when signing in via GDM or another login
manager. Provided that the desktop continues to be maintained, it will
likely also be part of Fedora 18, which is scheduled to be released this
" The article also mentions that there is an add-on
repository for Ubuntu's Unity desktop.
OMG! Ubuntu! warns
that installing Unity on top of Fedora 17 "will replace some core
GNOME components with Unity-compatible versions" and should be done
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>