Project:Recruiters

Gentoo's true strength is its impressive and constantly evolving developer base. It's the job of recruiters to manage the growth of the development team by locating, approving, and managing new developers to add further innovative talent to our already strong organization.

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 his progress throughout his 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 staff 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.

When adding yourself to a bug
I will be your recruiter. Always add a comment to this bug when you send something to that address. Please contact me by IRC or email to schedule the first review session. 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 on IRC 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.

Email template for the final review session
Attach the test ebuild to the mail and send it encrypted. This gives the recruit time to get used to decrypt mail content

Adding the new developer to LDAP
At first, start adding the new developer to LDAP. This requires you to ssh to  and use the   script to create the new account. Optionally place the recruit's ssh pub key in, 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 by hand, you will be asked for it for every LDAP change.

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:

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

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

Granting VCS access
TODO: this section is obsolete because of git migration, we should rewrite it. -- Zlogene

Currently we are in a transition phase. You need to ask infra to manually grant access.

Creating the developer's account on dev.gentoo.org
Now get the developer to to   as the first login will trigger the creation of his account.

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

Change his current  to read handle-name@gentoo.org (in the present case that is hyakuhei@gentoo.org ). Hit  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 and ask for a gentoo/developer cloak for the new dev. One of them will have to acc the request. After this, someone from Freenode staff will change the cloak.

Developer operator status in #gentoo-dev
After freenode staff has changed the cloak for our new dev, he should get  when joining. In order to make sure, the  is working, kick the new developer from  and wait till he rejoins. If everything is working as it should, he will get the  on join by ChanServ.

If you want to automatically give voice status in  to a recruit, e.g. during his/her mentoring period, contact our IRC groupcontacts in  and request the change.

Introducing the developer on mailing lists
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 recruitee 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.

Reinstating developers
For returning developers  needs to have an entry for every time they come back and   needs to be set to. You also need to make sure that the  attribute contains at least the following two values:   and.

Permissions needed for recruiters

 * useradmin group on cvs.gentoo.org
 * add useradmin ability for granting cvs groups access for legacy cvs modules not yet converted to git
 * recruiters group on dev.gentoo.org for newpasswd
 * recruiters.group in LDAP
 * editusers in bugzilla