Mentor guide

1.  Introduction

Introduction

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.

Considerations

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 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.

2.  The Recruitment Process

Getting Started

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 case-by-case basis.

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 recruiters@gentoo.org 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 recruiters.

Training

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, etc...).

The Review

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.

Probation

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.

Afterwards

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.

3.  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 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.

Take-Home Points

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.

Resources

These links may prove useful in developing additional ideas for training new recruits.

• The Seamonkey engineering bible
• The FreeBSD committers' big list of rules.