Gentoo Developer Recruiters

1.  Project Description

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.

2.  Developers

All developers can be reached by e-mail using nickname@gentoo.org.

3.  Subprojects

The recruiters project has the following subprojects:

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

5.  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 (linked above) 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.

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

6.  Stuff to remember

When adding yourself to a bug

I will be your recruiter. Please send your quizzes to recruiters@gentoo.org when approved by your mentor. Always add a comment to this bug when you send something to that address. When the quizzes are sent 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.

For setting up

What we did:
- LDAP
- bugzilla
- cvs/svn groups on cvs.gentoo.org
- IRC-cloak
- sent you your LDAP/mail password via encrypted mail
- announcement
- gentoo-core

What you need to do:
- subscribe to mailing lists with @gentoo.org address
- request forum status bump in #gentoo-forums or by mail to
  forum-mods@gentoo.org (if you have a forums count)
- send yourself mail to create .maildir
- add yourself to mail aliases ( like java@gentoo.org )
  see /var/mail/alias on dev.gentoo.org
- ask team leads to add yourself to herds.xml for the herds you want to
  join or do it yourself if you have the permission to do so
- 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 a blog on blogs.gentoo.org, contact planet@gentoo.org

For the mentor:
- You are also responsible for the commits of your recruit during the first
  month so you should watch the commits of your recruit via gentoo-commits
  mailing list.

7.  Steps for adding a new developer

1. Adding the new developer to LDAP

At first, start adding the new developer to LDAP. This requires you to ssh to dev.gentoo.org and use the perl_ldap script to create the new account.

# ssh dev.gentoo.org
# perl_ldap -b user -c
Enter LDAP Password:

LDAP Perl interface v1.0
[ou=devs] >> A hyakuhei
Adding LDAP user hyakuhei
Enter First Name: Robert
Enter Last Name: Clark
Enter LDAP Password:

done!

Afterwards, the new developer should look like this:

[ou=devs] >> s hyakuhei
Searching...
------------------------------------------------------------------------
dn:uid=hyakuhei,ou=devs,dc=gentoo,dc=org

             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
        birthday: undefined
  gentooLocation: undefined
     gentooRoles: undefined
      gentooJoin: 2007/01/07
            herd: undefined
    gentooStatus: active
          gpgkey: undefined
  gpgfingerprint: undefined
     objectClass: top
                  person
                  organizationalPerson
                  gentooDev
                  inetOrgPerson
                  posixAccount
                  shadowAccount
                  ldapPublicKey

Next step is to fill the remaining informations needed, for example birthday, gentooLocation and those others listed as undefined. Please be aware, that as of 17. December 2007, all dates in LDAP should be spelled in ISO8601, meaning like this: YYYY/MM/DD (ie. 2007/12/18).

[ou=devs] >> u hyakuhei
[hyakuhei, ou=devs] >> M gentooLocation "Wales, UK"
Modifying LDAP user hyakuhei
done!

Same scheme applies to all those other undefined elements.

Afterwards it should look like this:

[ou=devs] >> s hyakuhei
Searching...
------------------------------------------------------------------------
dn:uid=hyakuhei,ou=devs,dc=gentoo,dc=org

             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
                  person
                  organizationalPerson
                  gentooDev
                  inetOrgPerson
                  posixAccount
                  shadowAccount
                  ldapPublicKey
  gentooLocation: Wales, UK
        birthday: 1984/06/29
     gentooRoles: Security/log monitoring apps, Auditing
          gpgkey: 0x2217D168
  gpgfingerprint: 4C01 D375 8AEF CB2D 3AED  3B2D 119C 7E35 2217 D168

We then need to create the sshPublicKey attribute.

This first method requires the public ssh-key of the developer somewhere on dev.gentoo.org in order to import it this way into LDAP.

# perl_ldap -b user -M sshPublicKey "$(<hyakuhei.pub)" hyakuhei
Modifying LDAP user hyakuhei
done!

Another method assumes you'll copy and paste public ssh-key directly into command line. For readability we had to split very long public key but, of course, you don't need to split it and you can paste everything in one line.

[hyakuhei, ou=devs] >> C sshPublicKey "ssh-dss \
AAAAB3NzaC1kc3MAAACBAKmRjZ21SqPHwRXgkWDVuLfSZ5FOSV26xaV3Fnsc68r9caDWMZyD8PAJfX\
UeDXYOcUt4F3ZB+VL3DQSGg4ZEf4XVoNIOVnu87QaQyMJYT+u2EPsTJv99HZJM+tGT/ng6JfnRMWYd\
EDAUJ6iKZLNPKt+KWH7KprlHxRUJzd1MpbsVAAAAFQD9i0iTAesG4A1PJwT232+6IxtDlwAAAIEAoV\
tcO/ef4pd5WdJaeneOlmaFEF+P3lBbkaomT5oFv4GI+0BS3b+C9gOV+akDpu3Fn5JREwN665P+Cnid\
2y3FVZY77CazbfHBpVX6elTndo1wxRYE02GxMkhqWpuMkcMChdRjhRrcLHzAh6wO64r/wd5ofciBxu\
P2+ilWT151frgAAACAda4optpsYWmoSwIiLqfjr+Akxvzn9LWDcJ4LI4U8wakiHgBEGlhiIE7zrmS4\
ZEp8vGKv/Rhk3fOU96eUsoWFyMYtYFtCv5hQBJrqhC5Ur3dvjVzbracSZytn2xrTc+AEngPXu55WN2\
ebq/LMMTQV0Sq2wbDc7g9Jkxr4apAGDIM= hyakuhei@gentoo.org"
Modifying LDAP user hyakuhei
done!

We also need to add an external, i.e. non-@gentoo.org, email address. It can be done with the exact same two methods as for the attribute sshPublicKey above. For example:

[hyakuhei, ou=devs] >> C mail "joe.dev@mydomain.com"
Modifying LDAP user hyakuhei
done!

We are done now with adding the developer to LDAP, lets quit now.

[hyakuhei, ou=devs] >> quit

2. Setting up the developer's gentooAccess

In preparation of granting access to cvs/svn/git, the gentoo-core mailing list or changing his bugzilla login name, you will need to poke one of the leads to setup the developer's gentooAccess. This is needed, otherwise he/she won't be able to login to the machines we use in the development process (dev.gentoo.org and cvs.gentoo.org for example).

After a senior devrel member added the gentooAccess portion, you can go ahead with the next steps.

3. Granting svn/cvs/git access

In order to grant access to cvs/svn/git to the newly added developer, you will need to ssh to stork.gentoo.org and add the username to the appropriate groups.

# ssh stork.gentoo.org
# gpasswd -a hyakuhei cvs
Adding user hyakuhei to group cvs
# gpasswd -a hyakuhei svn
Adding user hyakuhei to group svn
# gpasswd -a hyakuhei git
Adding user hyakuhei to group git

4. Creating the developer's account on dev.gentoo.org

Now get the developer to ssh to dev.gentoo.org as the first login will trigger the creation of his account.

5. Changing the developer's bugzilla login

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 adress (the one he used for bugzilla).

Change his current Login name to read handle-name@gentoo.org (in the present case that is hyakuhei@gentoo.org). Hit Update once you're finished with the modifications.

6. Subscribing the developer to gentoo-core

Every developer needs to be subscribed to gentoo-core. It's the only gentoo mailing list only devrel/recruiters members can subscribe/remove other devs.

Point your browser at https://lists.gentoo.org/mlmmj/subscribers.cgi. Fill in the developer's @gentoo.org email adress and hit Subscribe.

7. Giving the developer operator status in #gentoo-dev

Every developer gets operator status (+o) in #gentoo-dev. In order to do that, you'll have to use FreeNode's ChanServ. Use the following command:

[(status)] /msg ChanServ access #gentoo-dev add hyakuhei +vVOriRA

You will see him getting +o by ChanServ. In order to make sure, the AUTOOP is working, kick the new developer from #gentoo-dev 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 to a recruit, e.g. during his/her mentoring period, use the following command:

[(status)] /msg ChanServ access #gentoo-dev add hyakuhei +ViA

8. Introducing the developer on gentoo-dev

In order to announce the new developer, you as recruiter have the honour to introduce him to the developer community. Write a brief introduction containing some details about your recruitee.

Remaining tasks

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