As a mentor, you are the liaison between a recruit and the recruiters. You may
be the first in-depth contact a recruit has with Gentoo, so the impression you
make is critical to the recruit's future with Gentoo.
You have two goals, which you will need to balance:
- Fulfilling the recruitment requirements, and
- Ensuring your recruit is prepared to join the Gentoo community.
Before you can mentor anyone, you must have been with Gentoo for at least six
months. Previously being a project lead was enough too but with GLEP 39 anyone
can create new projects.
If you are unsure whether you have time to mentor a recruit, don't. Failure to
properly mentor, such as abandoning the recruit or not providing the recruit
with quizzes and related documentation, results in suspension of your mentoring
capability. The first offense is two months, and each further offense doubles
Why do we do this? Because you need to show responsiblity, maturity and
experience. If you can't mentor your recruit for some reason, immediately
contact the recruiters so they can work with you to find a new mentor.
The Recruitment Process
Once you identify a potential recruit, make contact to see whether he or she has
the desire, drive, ability and time to become part of Gentoo.
The First Quiz
Have your recruit do the first quiz before anything else, such as filing a new-
developer bug. Go over the quiz with your recruit and resolve any problems. If
this step satisfied you, file a new-developer bug.
Developers working strictly on infrastructure, documentation, or bug-wranglers
with no CVS access to the Portage tree typically do not need to take the ebuild
quiz. There is a separate staff quiz available for this. Some developers
working on software external to the tree may need to take the ebuild quiz for a
general sense of how Gentoo development works. Recruiters will decide this on a
Filing a New Developer Bug
The bug summary should be 'New Dev: real name (nickname).' The bug must
contain the new developer's real name, email address, and reason for joining
the project. Real names must be provided for all developers, including
infrastructure and documentation. Any exceptions to this for extenuating
circumstances will be considered on a case-by-case basis. No exceptions will
be made for people doing copyrightable work (ebuilds, software, scripts, etc.).
The bug should also contain who the new developer's mentors will be and any
other information the mentor wishes to provide. Please do not attach quiz
answers or encryption keys to the bug -- these should be emailed to recruiters.
The new developer and all mentors should be CC'd on the bug to keep everybody
in the loop. In addition, your project lead must be CC'd and must approve the
bug when it's filed to confirm that the project is accepting new developers.
At the same time as you file the new developer bug, your recruit should e-mail
the first quiz to email@example.com and CC you. A recruiter will approve or
reject the quiz and note this on the bug. If it gets rejected, repeat the cycle
of refining the answers and re-sending to recruiters until they approve it.
Comment on the bug each time your recruit sends the quiz, so recruiters know
the status of the bug and what remains to be done.
Recruits taking the quiz should consult technical and policy documentation for
answers. Mentors may provide as much assistance as needed. Along with the quiz,
an OpenSSH SSH2 DSA public key for infrastructure access should be provided to
The training period is 30 days. New developers should be responsive to questions
from recruiters during this training period. If the new developer will be
absent for significant periods of time during training, the bug should be
updated to reflect this. If a new developer is unresponsive to pings,
recruiters will close the bug. Bugs closed under these circumstances may be
reconsidered at a later time.
If applicable, your recruit may begin the second quiz at any time. It is due by the
end of the training period. The second quiz procedure mirrors the first.
At the end of the training period, write up a summary of how the dev is
doing and add it to the bug.
Along with the second quiz the mentor and recruit must compile a list of all the
ebuilds and eclasses, or any other relevant work, written from scratch by the
recruit or where he/she has made a significant contribution. Care should be taken
to isolate all work from the recruit from corrections and/or modifications made by
any other person (i.e. either send the original version of the file before it was
corrected or a patch in case of work on something that already existed before,
Once both quizzes have been approved by recruiters, one of them will start making
arrangements with the recruit to organize a review. This is usually conducted on
irc in a private channel, so the recruit must make sure he/she is comfortable enough
with his/her irc client to not be distracted during the discussion. It is a good idea
for the recruit to log all activity on the channel for future reference.
The review shouldn't be considered as an examination but more as another part of
the training. The recruiters are in charge of making sure all necessary knowledge
has been acquired and understood. Their goal is not to stress or scare the recruit,
thus the discussion should occur in a relaxed yet professional atmosphere.
During the review, the recruiter will go through every single quiz answer with the
recruit, comment it, correct it if necessary, add some more specific context or on
the contrary generalize the examples, answer any additional questions from the
recruit, etc... This process usually takes about one to two hours per quiz. The
recruiter will most probably add some more questions (not all of them technical) and
give one or two assigments to the recruit. The review may be done in several
different sessions due to time constraints of either the recruit or the recruiter,
and because one single session must not exceed 2 to 3 hours in order to avoid that the
recruit loses his/her focus or gets tired.
Recruiters may reject new developers if they think it's appropriate. When doing so
they will explain their decision.
Once the training period ends and the recruiters have approved the recruit,
they will set him/her up as a provisional developer. At this point, the
recruit spends a month in probation. Tell your recruit to take extra care during
this month, because other developers will rely on their early impressions of
actions and words. That's all they will know of your recruit's ability and
character, which will also reflect onto you. In addition, you are responsible
for the new developer's actions.
You must remain available during probation to walk the developer through the
first commit and answer any questions that come up. If you aren't sure of an
answer, don't say it. Find out the answer for sure.
Your recruit will still see you as a mentor even after probation ends. You will
be a role model, so make sure you act like one.
Ensuring Your Recruit is Prepared to Join the Gentoo Community
Characteristics and Abilities
To find the most successful recruit, you will want to look for certain
characteristics and abilities:
Willing to help:
A significant portion of developer time is spent dealing with users,
either on mailing lists, forums or Bugzilla. Recruits need to start
working with users before they become developers, if they aren't
already doing it.
Willing to learn:
Nobody knows everything. A good recruit will admit lack of omniscience
and will exhibit eagerness to close that gap in relevant areas.
This strongly ties in with "Willing to help." Even the best of
intentions can be meaningless without the ability to carry them out.
Make sure a recruit has the social ability necessary to interact with
other developers and users. This also entails a strong grasp of the
Each area of Gentoo has some requisite talents that may be required
before a recruit can become a developer in that area. These vary, so
each project should create its own list. Some projects also create
a customized quiz, in addition to the devrel quiz, to ensure that these
criteria are met.
Interacting with Recruits
As mentioned earlier, the impression you make on the new recruit is critical to
how the recruit sees Gentoo. Treat recruits with the same high level of
professionalism and courtesy that you treat fellow Gentoo developers with. After
all, they'll probably be developers soon too.
There are a few key points you should emphasize to your recruits, among the
other aspects of their training:
Too much communication is better than too little:
This is a chronic problem within Gentoo. There will always be less time
wasted by communicating too much than there would be by the duplication
of effort caused by too little communication.
Be courteous and professional:
Once you offend and alienate someone, you can never take it back. Also,
remember we draw new developers from our user base. You could lose
potential developers by being rude and unprofessional, creating more
work for yourself and for other current developers who really need help.
Respect existing maintainers:
Never commit when someone else has clear ownership. Never commit on
things with unclear ownership until you've tried to clear it up.
When you aren't sure about something, don't commit it:
It's always easier to discuss problems before than after. If you don't
know what to do, check the documentation and e-mail gentoo-dev, if
you're still in doubt.
These links may prove useful in developing additional ideas for training new