Instructions for mentors of new recruits.
- 1 Introduction
- 2 The recruitment process
- 3 Ensuring your recruit is prepared to join the Gentoo community
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 the suspension.
Why do we do this? Because you need to show responsibility, 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 commit access to the Portage tree typically do not need to take the ebuild quiz. There is a separate developer 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 case-by-case basis.
Filing a new developer bug
The bug summary should be 'New Developer: real name (nickname)' and the alias set to the nickname. Copy and paste following lines to the first comment of the bug, then fill in the necessary information:
Name: John Deer Nick: jdee Mentor: foo Areas of contributions: Translation, foobar overlay, Qt Tree access: Yes
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.).
Any other information the mentor wishes to provide are welcome. 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.
When the new developer bug is filed, your recruit should e-mail the necessary quizzes after approval by you to email@example.com. 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 RSA 4096 bit public key for infrastructure access should be provided to recruiters.
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 assignments 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.
- Social ability :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 English language.
- Relevant talents :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 first 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 the gentoo-dev mailing list, if you're still in doubt.
These links may prove useful in developing additional ideas for training new recruits.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Donnie Berkholz, Denis Dupeyron
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.