From Gentoo Wiki
Jump to:navigation Jump to:search

This page lists all the necessary information for the recruiters.

What does it take to be a recruiter?

Recruiters need to possess several talents in order to successfully oversee additions to the development team. First and foremost, a recruiter needs to be a good judge of character. While most new developer sponsors pick only the best candidates, there have been and will be occasional duds. Recruiters need to be able to analyze an individual's background, experience, and past contributions, then use that information to decide whether or not to accept a developer. Recruiters also need to be aware of the big picture in order to recognize weaknesses in the organization and accept developers who will shore up those weaknesses. Remember, recruiters always have the final say on new developers. Never be afraid to say no, but always offer a detailed explanation of the decision.

What does the recruitment process involve?

All new developers must have a mentor. This mentor will be responsible for guiding the new developer through the new developer process and offering help to the developer futurely. Mentors should assist by pointing the new developer to developer-related documentation, answering questions, and explaining the ins and outs of working for Gentoo as much as possible.

A bug must be filed for each new developer. The bug summary should be 'New Developer (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, documentation, 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 CCed on the bug to keep everybody in the loop.

A developer's bug tracks their progress throughout their lifetime at Gentoo. If the developer retires, the initial recruitment bug is used to track all the things that must be done to retire a dev. If the developer later returns, the same initial recruitment bug is used to track it. Returning developers are subject to the same criteria as a first-time developer and must go through the same steps to rejoin Gentoo.

The new developer will have a mentoring and evaluation period of up to a month. This will be determined by the recruiter based on feedback from the mentor. During this mentoring period, the mentor is responsible for providing the quiz. Additionally, new developers should be responsive to questions from recruiters during this waiting period. If the new developer will be absent for significant periods of time during this period, 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.

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

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. Instead, a developer quiz is provided. See the quiz page for more information.

Recruiters may reject new developers if they feel it's appropriate. Additionally, for 30 days after joining, a new developer is considered to be in a 'probationary period' in which their mentor is responsible for actions taken by the new developer. This provides a certain level of accountability.

Stuff to remember

When adding yourself to a bug

I will be your recruiter. Always add a comment to this bug when you send something to recruiters. Please contact me by IRC or email to schedule the first review session (in UTC). If you think that recruiters aren't paying attention to this bug at any later point in time, it's your job to ping us if you don't want any delays.

For review session

I will go through your answers, find out errors and ask some extras related and unrelated to the quiz questions. Take your time, it's supposed to be a learning experience as much as a test of your skills. But just tell me if you can't absolute find something so that you don't use too much time.

After the sessions you are asked to submit a fixed versions of the quizzes so logging the session might be prudent.

Please see these review session as a learning experience.

Working on open bugs during recruitment

Recruits are suppose to work on open bugs during the recruitment phase. This help recruits to get used to gentoo workflow and be prepared to become full developer. Recruiter should pick appropriate bugs for recruit as soon as possible so recruit can work on bugs during the recruitment period.

For setting up

CODE Bugzilla setup comment
What we did:
- Bugzilla
- Granted access to main gentoo.git
- Added user to GitHub Gentoo team
- IRC cloak: ${IRC_USERNAME}
- Announcement

- gentoo-core
- gentoo-dev-announcement

What you need to do:
- Subscribe to mailing lists with your address
- If you have a forums account, request a forum status bump
  in #gentoo-forums or by emailing
- Send yourself an email to check if it works
- Add yourself to email aliases (such as
  See /var/mail/alias on
- Register to with your e-mail address using
  the following instructions:
- Set lat and lon attributes in LDAP if you want others to know where
  exactly you are located
- Set gentooIM if you want people to be able to contact you via other
  means than email
- If you want your blog to be syndicated to, check
- Visit the Gentoo Nitrokey portal at 
  in order to get a free Nitrokey Pro 2 security key
- Contact for Foundation membership (optional)

For the mentor:
- You are responsible for the commits of your recruit during the first
  month. Watch the commits of your recruit via gentoo-commits
  mailing list.

Steps for adding a new developer

ssh alias for (optional)

This only needed if your local username is different than the one. Otherwise you will not be able to pull a developer key(s) into the gitolite repository.

FILE ~/.ssh/config
     User ${gentoo_nickname}

Adding the new developer to LDAP

At first, start adding the new developer to LDAP. This requires you to ssh to and use the recruiters-newdev script to create the new account. Optionally place the recruit's ssh pub key in ~/pubkey-${DEV}.txt, which allows you to directly import it during the setting up. This script will ask you for all needed information and will set the ldap attributes. You should have your LDAP password in hand, you will be asked for it for every LDAP change.

user $ssh
recruiter@woodpecker ~ $recruiters-newdev hyakuhei

Please be aware, that as of 17 Dec 2007, all dates in LDAP should be spelled in ISO8601, meaning like this: YYYY/MM/DD (ie. 2007/12/18).

Afterwards it should look like this:

recruiter@woodpecker ~ $perl_ldap -b user -s hyakuhei


             uid: hyakuhei
              cn: Robert Clark
       givenName: Robert
              sn: Clark
    userPassword: {crypt}$1$HP/3wW0V$XUMrrFeQDHiMSGDOIUAbi/
shadowLastChange: 13520
       shadowMax: 99999
   shadowWarning: 15
      loginShell: /bin/bash
   homeDirectory: /home/hyakuhei
           gecos: Robert Clark
  shadowInactive: 15
    shadowExpire: 14883
       gidNumber: 100
       uidNumber: 2159
      gentooJoin: 2007/01/07
            herd: undefined
    gentooStatus: active
     objectClass: top
  gentooLocation: Wales, UK
        birthday: 1984/06/29
     gentooRoles: Security/log monitoring apps, Auditing
  gpgfingerprint: 4C01 D375 8AEF CB2D 3AED  3B2D 119C 7E35 2217 D168
    gentooMentor: mentor-in-charge
    gentooDevBug: 012345
    sshPublicKey: ssh-dss AAAAB3NzaC1kc3MAAACBAKmRjZ21SqPHwRXgkWDVuLfSZ5FOSV26x\
             lat: 3.43521
             lon: -4.2333

The sshPublicKey has been split in many lines for this website, it is just one line.

Additionally you should set the developer's Wiki username so that he can be associated to projects on their pages.

recruiter@woodpecker ~ $ perl_ldap -b user -C gentooWikiUser Hyakuhei hyakuhei

Granting gentoo.git access

Clone the gitolite-admin repo:

user $git clone git+ssh://

Fetch user's ssh key(s) from the ldap server:

user/gitolite-admin $ ./scripts/ <developer_nickname>

Automatically update group membership for the user:

user/gitolite-admin $ perl ./scripts/

Update the groups-ldap.conf file with an email of a developer you've just added:

user/gitolite-admin $ perl ./scripts/ > conf/groups-ldap.conf

Commit and push your changes.

Creating the developer's account on

Now get the developer to ssh to as the first login will trigger the creation of their account.

Try handing the dev-to-be the full command-line like ssh, in order to minimize mistakes and/or misconfigurations. Also point developer to LDAP Guide so they know how to check and change their attributes if needed.

Changing the developer's Bugzilla login

Before changing the developer's Bugzilla login email, let them decide whether she/he wants to setup email forwarding for their Gentoo e-mail account.

After the developer logged in successfully, you can proceed with the recruiter process. Login to Bugzilla, choose Users> in the Row Edit. Supplement the developer's current email address (the one he used for Bugzilla).

Change their current Login name to read (in the present case that is ). Hit Update once you're finished with the modifications.

Setting the developer cloak to gentoo/developer/account

Every developer should get a cloak in the form @gentoo/developer/account, where in most cases the account is the same as the nickname he uses.

You need to ping our group contacts (mentioned in the topic) on #gentoo-groupcontacts (webchat) and ask for a gentoo/developer cloak for the new dev. One of them will have to acc the request. After this, someone from Libera.Chat staff will change the cloak.

Developer operator status in #gentoo-dev

After Libera.Chat staff has changed the cloak for our new dev, he should get +o when joining #gentoo-dev (webchat). In order to make sure, the AUTOOP is working, kick the new developer from #gentoo-dev (webchat) and wait till he rejoins. If everything is working as it should, he will get the +o on join by ChanServ.

If you want to automatically give voice status (+v) in #gentoo-dev (webchat) to a recruit, e.g. during their mentoring period, contact our IRC groupcontacts in #gentoo-groupcontacts (webchat) and request the change.

Introducing the developer on mailing lists

After successful completion of the recruitment process, the new developer is announced on the mailing lists.

Special cases:

  1. Returning developers are announced only if the retirement period was longer than 6 months.
  2. Non-tree developers gaining tree access are announced again after successful recruitment.

In order to announce the new developer, you as recruiter have the honor to introduce him to the developer community. Write a brief introduction containing some details about your recruit to the and mailing lists.

Remaining tasks

Please follow up with the developer during their first month to make sure they are adapting well and to address any concerns.

Returning developers

The returning developers have one or more review sessions with the recruiter. Returning developer is supposed to prepare the minimal requirements for the session with the recruiter. These requirements are determined for everyone individually by each recruiter. During the session the recruiter checks the minimal requirements and reinstate developer accesses.

Minimal requirements

  1. Submit fixes for existing opened bugs in bugzilla approved by the recruiter.
  2. Answer some of the quizzes questions - depends on the experience of the returning developer.

Reinstating developers

For returning developers gentooJoin needs to have an entry for every time they come back and gentooStatus needs to be set to "active". You also need to make sure that the gentooAccess attribute contains at least the following two values: and To enable access to the Gentoo repository, add to gentooAccess.

recruiter@woodpecker ~ $perl_ldap -b user -C gentooJoin "YYYY/MM/DD" nick
recruiter@woodpecker ~ $perl_ldap -b user -C gentooAccess "" nick
recruiter@woodpecker ~ $perl_ldap -b user -C gentooAccess "" nick
recruiter@woodpecker ~ $perl_ldap -b user -M gentooStatus "active" nick
recruiter@woodpecker ~ $# For developers that require access to the Gentoo repository
recruiter@woodpecker ~ $perl_ldap -b user -C gentooAccess "" nick

Then sync gitolite with Project:Recruiters/Recruiting#Granting_gentoo.git_access.

Permissions needed for recruiters

  • useradmin group on
  • recruiters and useradmin group on for newpasswd
  • in LDAP
  • editusers in bugzilla
  • @recruiters group in the gitolite-admin repository
  • access to the recruiters and comrel repository