Joining

1. Mentor System

1.1. Overview

New drone prospects (those seeking membership) will be adopted by a Tertiary Adjunct (Members / Mentors). The Collective is based on a tight ring of trust. As such, joining requires hard work and dedication. The Tertiary Adjunct will serve as the Collective's eyes and ears with regards to the new drone's status with the team and their ability level during the assimilation process. New drones will be expected to perform simple tasks regarding application design, programming concepts, and must demonstrate an aptitude with Subversion (svn) and Bazaar (bzr). Tertiary Adjuncts will be required to take accountability for their newly-assimilated drone, until such a time as they prove their credibility to the Collective. All work done by the new drone will be buffered through the Tertiary Adjunct, meaning the Tertiary Adjunct will be responsible for doing code reviews. This is necessary to ensure high quality code, and to avoid "whoopsies". Borg Tactical Cube

1.2. Signup

To be recognized as a drone awaiting assignment, put your name in the table below. Once you have been assigned to a Tertiary Adjunct, your name will be highlighted and you will be paired up with your TA. Please ensure your name is a link to your wiki page. If you have difficulty figuring the source code out to add yourself - just ask someone in #ubuntu-beginners-dev on Freenode.

If you want to add your name name rather edit Mentors

1.3. Accepting New Drones

When a new drone has shown their dedication to the Collective, a second member will be asked to step forward and vouch for the new drone. After a team vote, any Collective member will have a chance to speak out in both support of or opposition to the new drone. After a discussion (without the prospective drone present) a vote takes place. With a 3/4 vote in favour, barring any lead opposing assimilation, the new drone will be fully assimilated.

1.3.1. Tertiary Adjuncts

Once assimilated, the drone assumes the responsibilities of the tertiary adjunct. The responsibilities of a tertiary adjunct include (non-exclusively) the following:

  • All Tertiary Adjuncts are highly requested to adopt a drone at least once a year.
  • Show courtesy and respect towards everyone.
  • Provide assistance where possible.

It is imperative that the Prospective Drone list be monitored and minimized at all times. The more prospective drones that exist, the more the tertiary adjuncts need to adopt them and mentor them through either a) completion or b) dissolution. Should the list not be maintained appropriately, a round-robin system may become effective in assigning prospective drones to tertiary adjuncts.

1.4. Coding Standards

To make code reviews as easy as possible, and to ensure that all members of the Collective can easily read all code we produce, certain standards of coding must be adhered to. These standards cover everything from commenting requirements to variable and function naming to how code is to be formatted. The full coding standard documentation is currently in progress and will be made available when complete.

1.5. The "Quiz"

A demonstration of basic development knowledge will be required of all new drones. These skills include, but are not necessarily limited to, the following:

  • Version Control

    • Competence with Bazaar (bzr) and Launchpad
    • Competence with Subversion (svn) and Whube
      • Basic version control knowledge

  • Programming

    • Compiling code from source
    • Difference between compiled languages and interpreted languages
    • Object Oriented Programming (OOP) Knowledge
    • Data Structures (Arrays, Hashes, Queues, Stacks, etc.)
    • Loops (for, do..while, while, etc.)

  • Debugging

    • Basic GDB (GNU Debugger) knowledge

  • License

    • Documentation / Licensing (GPLv3)

  • 42

1.5.1. Skills We Look For

As with the "quiz", skills we look for in new members of the Collective include, but are not necessarily limited to, the following:

  • Basic version control skills, applied with Subversion and Bazaar

    • Check out code, commit changes, merge conflicts
    • What files should and should not be placed under version control
    • Ignoring specific files
  • Creating and applying patches
  • Finding differences between two arbitrary checkouts
  • Able to avoid the most common programming pitfalls, especially ones creating security problems
  • Understands data structures of programming
  • Understands the debugging process
  • Able to investigate a problem and creatively tackle it.

  • Possesses the desire to expand one's creative and programming knowledge to the greatness of 42.

CategoryBeginnersTeam

BeginnersTeam/FocusGroups/Development/Joining (last edited 2010-01-15 09:24:47 by adsl-76-241-121-249)