Add the new site

source/handbook/developer-onboarding/index.html.md

+---
+layout: markdown_page
+title: "Developer Onboarding"
+---
+
+Awesome! You're about to become a GitLab developer!
+Make sure you've checked out our [handbook] beforehand, so you get a feeling
+of how we work at GitLab. Below you'll find everything you need to start developing.
+If something is missing, add it (as goes with everything at GitLab)!
+
+## GitLab Instances
+We have two main GitLab instances, as explained in the [general onboarding](https://about.gitlab.com/handbook/general-onboarding#gitlab-instances).
+
+## Getting started with GitLab development
+
+To start development, follow the instructions for the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).
+
+## GitLab Repositories
+
+Almost all repositories are available on both gitlab.com and dev.gitlab.org. We
+also mirror our biggest projects to [GitHub](https://github.com/gitlabhq),
+making them more widely available for people to contribute.
+
+### GitLab Community Edition (CE)
+
+This is the community edition of GitLab. Most of the development happens here,
+then gets merged into GitLab EE periodically. Unless you're making a change
+specific to GitLab EE, add it to CE.
+
+- [https://gitlab.com/gitlab-org/gitlab-ce](https://gitlab.com/gitlab-org/gitlab-ce)
+- [https://dev.gitlab.org/gitlab/gitlabhq](https://dev.gitlab.org/gitlab/gitlabhq)
+- [https://github.com/gitlabhq/gitlabhq](https://github.com/gitlabhq/gitlabhq)
+
+### GitLab Enterprise Edition (EE)
+
+This is _not_ an open source project, but we made the source code available for
+viewing and contributions. As of version 7.11, it requires a license key to be
+used.
+
+- [https://gitlab.com/gitlab-org/gitlab-ee](https://gitlab.com/gitlab-org/gitlab-ee)
+- [https://dev.gitlab.org/gitlab/gitlab-ee](https://dev.gitlab.org/gitlab/gitlab-ee)
+
+### GitLab Shell
+
+GitLab Shell handles git commands for GitLab. It's an essential part of GitLab.
+
+- [https://gitlab.com/gitlab-org/gitlab-shell](https://gitlab.com/gitlab-org/gitlab-shell)
+- [https://dev.gitlab.org/gitlab/gitlab-shell](https://dev.gitlab.org/gitlab/gitlab-shell)
+- [https://github.com/gitlabhq/gitlab-shell](https://github.com/gitlabhq/gitlab-shell)
+
+### GitLab Workhorse
+
+Gitlab-workhorse is a smart reverse proxy for GitLab. It handles "large" HTTP
+requests such as file downloads, file uploads, Git push/pull and Git archive
+downloads.
+
+- [https://gitlab.com/gitlab-org/gitlab-workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse)
+
+### Omnibus GitLab
+
+Omnibus GitLab creates the packages for GitLab.
+
+- [https://gitlab.com/gitlab-org/omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab)
+- [https://dev.gitlab.org/gitlab/omnibus-gitlab](https://dev.gitlab.org/gitlab/omnibus-gitlab)
+- [https://github.com/gitlabhq/omnibus-gitlab](https://github.com/gitlabhq/omnibus-gitlab)
+
+## Cloud infrastructure
+
+GitLab.com runs on Microsoft Azure. Many people in GitLab also have
+instances on DigitalOcean. If you need a VPS for any reason, it's probably easiest
+to set one up at DigitalOcean. Ask another developer for access.
+
+## Operations
+
+For everything related to operations, check out the
+[Operations handbook](https://about.gitlab.com/handbook/operations).
+
+## Basics of GitLab development
+
+### Quality
+
+One of GitLab's strengths is its high quality of software. To achieve this we've introduced
+some requirements to all source code that is contributed. All requirements are mentioned in
+[the Contribution guide](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md).
+Make sure you read and follow it.
+
+### Dependencies
+
+GitLab can be installed through an Omnibus package or from source on different Linux distributions and OS X.
+In order to maintain portability we need to avoid adding extra dependencies and use of exotic database extensions.
+Every time you choose between changes in the application code or adding new dependencies
+you should give priority to the first because this is easier to maintain and setup.
+If you still need to bring new dependencies to GitLab - ask another developer or the CTO for advice.
+
+### Submit your code
+
+In GitLab all code should go through a review process before it can be merged.
+Make sure you submit a merge request for any changes you've made.
+When the merge request is ready it should be assigned to someone else on the team.
+This person is then responsible for reviewing your code and merging it.
+Optionally you can request another developer to help or review by writing a comment.
+If a merge request is not assigned it will probably ignored and create unnecessary
+delays.
+
+Don't work on one task for multiple days before submitting a merge request.
+Even the biggest task can be split into smaller tasks.
+Try to submit a merge request for each part of the functionality.
+This means that we expect multiple a merge request per week from you.
+Smaller merge requests are more likely to receive good feedback and will get merged sooner.
+
+Unless the change is very minor, or is fixing a bug that was introduced in the
+same version, add an entry to `CHANGELOG` (or `CHANGELOG-EE` when applicable).
+Do not include your name in the entry as we only do that to give recognition to
+volunteer contributors.
+
+### Ruby Gems
+
+When building and publishing Gems for GitLab make sure multiple developers have
+access to said Gem on RubyGems.org. This ensures a Gem doesn't end up being
+orphaned because the original author left, lost their credentials, passed away,
+etc. When publishing a Gem you can add the following people as co-owners:
+
+* Dmitriy Zaporozhets
+* Douwe Maan
+* Robert Speicher
+
+You're of course free to add other developers as well.
+
+[handbook]: https://about.gitlab.com/handbook
+[in the open]: https://about.gitlab.com/2015/08/03/almost-everything-we-do-is-now-open/

source/handbook/general-onboarding/index.html.md

+---
+layout: markdown_page
+title: "GitLab Onboarding"
+---
+
+## Other pages
+
+* [Sales onboarding](/handbook/sales-onboarding)
+* [Developer onboarding](/handbook/developer-onboarding)
+* [Service engineer onboarding](/handbook/support/onboarding/)
+* [Offboarding](/handbook/offboarding/)
+
+## This page
+
+* [Master Checklist for Onboarding of New Hires](#checklist)
+* [Onboarding Topics That Apply to Everyone](#everyone)
+  * [General](#general)
+  * [GitLab Instances](#gitlab-instances)
+  * [Security](#security)
+  * [Git Quiz!](#quiz)
+
+
+## Master Checklist for Onboarding of New Hires <a name="checklist"></a>
+
+Create issue for new hire in organization with following checklist.
+This list looks strange in this handbook but this is to ensure you can copy paste it into an issue.
+When you paste it in an issue it will have checkboxes that you can click to complete.
+The topics are ordered by priority in which they need to be tackled, and the main person responsible is called out at the beginning of each task.
+
+```
+### BEFORE STARTING AT GITLAB
+
+* [ ] People Ops: Once the contract is signed, as soon as possible, create issue called 'Onboarding (NAME), starting (DATE), as (ROLE)' in
+[organization](https://dev.gitlab.org/gitlab/organization/issues) with relevant
+lines of the master checklist, paste the private email address of the hire in
+there and /cc @rspeicher, @jacobvosmaer, @patricio, @ernst, @emily, and @tiffanie.
+* [ ] Hiring manager is (FILL IN WITH @ HANDLE), buddy is (FILL IN WITH @HANDLE (Nominate someone preferably in similar timezone but different functional group)), and People Ops is tackled by (FILL IN WITH @ HANDLE).
+* [ ] People Ops: Add entry to availability calendar so the team can see when new people are joining.
+* [ ] People Ops: Add blank entry to team page (only the start date and position, use "logo-extra-whitespace.png" for the picture) so the team can see when new people are joining.
+* [ ] People Ops: Add entry to Team Call agenda to introduce the new team member, and make sure to include the new team members NAME as well as TITLE in the agenda item.
+* [ ] New team member: where applicable, provide scan of photo ID to People Ops.
+* [ ] New team member: read [Handbooks](https://about.gitlab.com/handbook/), read
+the relevant onboarding pages that are linked from there, and become comfortable
+with Git and the GitLab workflow.
+* [ ] People Ops: file signed contract, PIAA, and where applicable, photo ID in the "Files" tab on the team members profile on BambooHR
+* [ ] People Ops: input relevant data (dates, compensation) into the team members profile tabs "Job" and "Benefits" in BambooHR
+* [ ] Robert/Jacob/COO: create Google account, firstname@gitlab.com or initial(s)@gitlab.com, email instructions to private email address, comment with private email below this issue, turn off [2FA enforcement](https://admin.google.com/gitlab.com/AdminHome#ServiceSettings/notab=1&service=securitysetting&subtab=org) and schedule reenabling it
+* [ ] Robert/Jacob/COO: inform Hiring manager that Google account has been created by mentioning them with a comment in the issue.
+* [ ] Robert/Jacob/COO: Create a [new dev.GitLab.org account](https://dev.gitlab.org/admin/users/new) and invite to the [gitlab group](https://dev.gitlab.org/groups/gitlab/group_members) as a developer
+* [ ] Robert/Jacob/COO: @mention the new team member in this onboarding issue once their dev.gitlab.org account has been made.
+* [ ] Robert/Jacob/COO: Add to [Slack](https://gitlab.slack.com/admin)
+* [ ] People Ops: Give team member access to the GitLab availability calendar
+* [ ] People Ops: Add new team member to the next monthly GitLab 101 call
+* [ ] People Ops: Invite to team meeting.
+* [ ] People Ops: reach out to the new team member to identify and order any necessary supplies/equipment.
+* [ ] People Ops: Assign buddy and explain to buddy what that means: "If she/he
+has questions she/he can come to you. But your main job as a buddy will be to
+direct her/him to the right parts of the handbook, and/or encourage her/him to
+ask her/his questions of the wider group on Slack, etc."
+* [ ] People Ops: Send brief welcome email to their personal address that directs
+the new team member to their GitLab email and their onboarding issue. Template text:
+"Welcome to GitLab, we are happy to have you on the team! You should have received
+an invitation to your GitLab email account; please let me know if that is not the case.
+Everything you need to get started is listed in your onboarding issue (insert link).
+We're looking forward to seeing you on our daily Team Call! The first time that you
+join, please make sure that you connect at least 10 minutes before the call and
+make sure that your camera and microphone are working properly. We'd like you to
+introduce yourself to the team so please prepare some talking points for yourself.
+Some tips to help you out here: tell us about where you were before GitLab, why
+you wanted to join our team, just a little something about your background and
+of course something on what you like to do in your spare time."
+* [ ] New team member: schedule 10 calls of 30 mins with 10 different colleagues to get to know our team.
+   * [ ] 1. call with ___
+   * [ ] 2. call with ___
+   * [ ] 3. call with ___
+   * [ ] 4. call with ___
+   * [ ] 5. call with ___
+   * [ ] 6. call with ___
+   * [ ] 7. call with ___
+   * [ ] 8. call with ___
+   * [ ] 9. call with ___
+   * [ ] 10. call with ___
+
+
+### WITHIN TWO DAYS OF STARTING
+*For GitLab Inc employees only*
+
+* [ ] People Ops: gather relevant information from new team member to enter them into the TriNet system.
+* [ ] People Ops: complete and submit an online Add New Hire Form
+(TriNet Passport=>My Workplace=> Add New Hire/Rehire). This will generate the
+welcome email to the employee at their work email on their first date of hire.
+* [ ] New employee: complete [New Hire TriNet Passport 7 Steps Guide](https://docs.google.com/a/gitlab.com/document/d/1CFIyByd1Kgmz5353_aASVI1D8QTyJ2Uy60ziQHEPTUI/edit?usp=sharing). The I-9 portion of this must be completed with the first two days of hire. Note- this is critical so you must contact PeopleOps if you have difficulty with this form.
+* [ ] New employee: read through the [New Hire Benefits Guide](https://drive.google.com/a/gitlab.com/file/d/0B0dixQ9qzgilNlN0MnNFS29xWnB2SjNWVUk3dUV2aWlhejVR/view?usp=sharing). This will go over medical, dental, vision and voluntary benefits. Note - If you have any questions or need help within the TriNet system please contact the Employee Solution Center at 800-638-0461 or email them at employees@trinet.com.
+* [ ] People Ops: Set up new hire training with TriNet (If necessary).
+
+#### For GitLab BV employees only
+
+* [ ] New team member: fill in this payroll information [form](https://docs.google.com/a/gitlab.com/forms/d/1mExVeTRn1cd0MtnNuvMSy7UJ8WazI5D6_snq3R6bsmI/viewform)
+This info is needed to get your profile ready with Savvy HR in order to get you your payslips and other information.
+Next to Savvy, the People Ops team will also get a copy of the form info for your employee file on BambooHR
+
+
+### WITHIN FIRST WEEK OF STARTING
+
+* [ ] PeopleOps: Invite to autoconnect on [Beamy](https://about.gitlab.com/handbook#beamy-guidelines).
+* [ ] PeopleOps: Order business cards for new team member.
+* [ ] PeopleOps: Add team member to Expensify (if employee).
+* [ ] PeopleOps: Add new team member to the info sheets of the Austin Summit.
+* [ ] PeopleOps: Send the new team member the "reset password" email for their BambooHR profile.
+* [ ] PeopleOps: Create a profile on [Egencia](https://about.gitlab.com/handbook/travel/) for new team member.
+* [ ] New team member: Register on 1Password by clicking [this link](https://gitlab.1password.com/teamjoin/invitation/J2KWH3CJDRFA7KTFDVVXXDSCMY)
+and then ping @rspeicher to confirm your account.
+* [ ] New team member: Set up [secure passwords per the handbook](https://about.gitlab.com/handbook/security/).
+* [ ] New team member: Create GitLab.com account and leave a comment in this issue with the handle. (To clarify, this is **not** the same as your account and username on dev.gitlab.org which you already have if you can see this issue).
+* [ ] Robert/Jacob/COO: Invite team members' GitLab.com account to the [gitlab-com group](https://gitlab.com/groups/gitlab-com/group_members) as a developer.
+* [ ] New team member: Use the "reset your password" email of BambooHR to set a password and access your profile.
+* [ ] New team member: Add your Address, Phone number, private email and emergency contact to your BambooHR profile page.
+* [ ] New team member: Link your GitLab email address to an easily recognizable photo of yourself on [gravatar](https://en.gravatar.com/) (don't use an avatar, stock photo or something with sunglasses).
+* [ ] New team member: [Add yourself](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/add_member_to_team_page.md) to the [team page](https://about.gitlab.com/team/) with an easily recognizable photo. Assign the merge request to your hiring manager.
+* [ ] Hiring manager: Merge the request to add the new team member to be added to the team page, and coordinate with Marketing to send out a tweet from @gitlab.
+* [ ] New team member: Add yourself to the [public map](https://sundial.teleport.org/public/groups/Y3IahPR5vYjBpMyU2kZj) of everyone's location via [Sundial](https://docs.google.com/a/gitlab.com/document/d/1U0ZYlKgX_VZVCKUozRYehRSiNquzIN1hg8B2RP19QCw/edit?usp=sharing).
+* [ ] New team member: I verify that the home folder of my hard drive is encrypted (see the [security handbook](https://about.gitlab.com/handbook/security) for help).
+* [ ] New team member: Read the [Summit page](https://gitlab.com/summits/Austin-Summit-2016-project/) and save the date!
+* [ ] New team member: Make an improvement to the handbook (something that you wished was there), assign the merge request (MR) to your manager and link the MR url in this onboarding issue.
+
+
+### FOR ENGINEERING ONLY (Devs, PEs, SEs)
+
+* [ ] Patricio/Robert/Jacob: Add new team member to the [gitlab-org](https://gitlab.com/groups/gitlab-org/group_members) group on GitLab.com as a `Developer`.
+* [ ] For Production Engineering team members: Hiring manager: add the [sysadmin onboarding checklist](https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/onboard-new-sysadmin.md).
+* [ ] PeopleOps: Add the new team member to the next Retro meeting and the Kickoff meeting that's scheduled and save for all events in the future.
+* [ ] For Service Engineering team members: Patricio/Robert/Jacob: Create GitLab.com admin account.
+* [ ] For Service Engineering team members: Patricio/COO: Add to Tweetdeck for @gitlabstatus.
+
+### FOR MARKETING ONLY
+
+* [ ] Patricio/COO: Add to Tweetdeck.
+
+### FOR SALES AND FINANCE ONLY
+
+* [ ] Finance: Add to Comerica (as user or viewer only if in Finance)
+* [ ] Finance: Add to [QuickBooks users](https://about.gitlab.com/handbook/hiring/) (finance only)
+* [ ] People Ops: Order company credit card (for all sales team members who are employees)
+* [ ] People Ops: If credit card holder, add to expense report calendar reminder
+* [ ] CFO / COO: Add to [Hellosign](https://hellosign.com) as a team member
+* [ ] Hiring Manager: Invite to sales meeting.
+* [ ] Hiring Manager: Add to [Recurly](https://app.recurly.com/login)
+* [ ] Hiring Manager: Add to  [Salesforce]
+* [ ] New team member: Ask a colleague if they can do a screenshare the next time they process an order using Recurly and Salesforce.
+* [ ] Sales Manager: Grant access to the [Sales Folder](https://drive.google.com/drive/u/0/#shared-with-me) in our Google Docs. In this folder, familiarize yourself with:
+* [ ] New team member: In the [Sales Folder](https://drive.google.com/drive/u/0/#shared-with-me), familiarize yourself with
+  1. [Our Sales Process](https://docs.google.com/document/d/1F0vXw58ctLfk9LKrh35kOSjYvdah4skGGUt46l1-4GM/edit)
+  1. [Our Sales Agenda](https://docs.google.com/document/d/1l1ecVjKAJY67Zk28CYFiepHAFzvMNu9yDUYVSQmlTmU/edit)
+  1. [The Sales Sheet](https://docs.google.com/spreadsheets/d/1755SblMccalWXSahspOrfzBwjGp4F8TkwlB8dOXCGlU/edit#gid=11) - add any targets to the Target tab
+  1. Competition https://about.gitlab.com/comparison/
+  1. [Our Sales Communication Guide](https://docs.google.com/document/d/1IMDzTj3hZrnsA417z9Ye7WBa8yLkWxGzaLZNJ3O_nVA/edit#heading=h.3nffcmsbeqo7)
+* [ ] New team member: familiarize yourself with the [Support and Development Process](https://about.gitlab.com/handbook/support-and-development-process)
+* [ ] New team member: familiarize yourself with [giving a GitLab demo](https://about.gitlab.com/handbook/demo/)
+
+```
+
+Please update this list as more steps arise.
+
+## Onboarding topics that apply to everyone<a name="everyone"></a>
+
+### General<a name="general"></a>
+
+* The first month at a remote first company is hard, especially if you have not worked remote before and/or if you're unfamiliar with the tools used (mainly GitLab, chat, and video calling). If you feel lonely feel free to schedule 1 on 1 video calls to get to know people. If you need help with the tools ask people for help. If you don't know who to ask for help use the #questions chat channel. If you're not happy please let your manager know so we can take action.
+* We've set up a monthly GitLab 101 call to explain our history and have some time for Q&A.
+* We use [Slack](https://gitlab.slack.com/messages/general/), [Google Docs](https://www.google.com/docs/about/) and [dev.gitlab.org](https://dev.gitlab.org) to communicate.
+* Check out our [about page](https://about.gitlab.com/about/), [How we use GitLab to build GitLab](https://about.gitlab.com/2015/07/07/how-we-use-gitlab-to-build-gitlab/) and [Life as a non technical employee at GitLab](https://about.gitlab.com/2015/06/30/life-as-a-non-technical-employee-at-gitlab/)
+* Follow the Git and GitLab course on [Platzi](https://courses.platzi.com/courses/git-gitlab/)
+* Become familiar with how GitLab works by learning our [GitLab Basics](http://doc.gitlab.com/ce/gitlab-basics/README.html)
+* Read our [Team Handbook](https://about.gitlab.com/handbook/)
+* Set-up and familiarize yourself with our apps: [Gmail](https://mail.google.com/), [Google Calendar](https://www.google.com/calendar/), [Slack](https://gitlab.slack.com/messages/general/) and [Google Drive](https://www.google.com/drive/)
+* You can [download](https://tools.google.com/dlpage/drive/index.html?hl=en) Google Drive for your computer to access offline
+* You should have been provided access to our [Internal GitLab Server](https://dev.gitlab.org). Take a moment to familiarize yourself with:
+  1. The Dashboard
+  1. The Projects
+  1. The Issue Tracker
+* Become familiar with the README.md’s for these projects:
+  1. [GitLab Enterprise Edition](https://dev.gitlab.org/gitlab/gitlab-ee)
+  1. [GitLab HQ](https://dev.gitlab.org/gitlab/gitlabhq)
+  1. [GitLab www-gitlab-com](https://dev.gitlab.org/gitlab/www-gitlab-com)
+* Create an account on our external / public [GitLab Server](https://gitlab.com) and have your manager grant access to the GitLab Enterprise Edition Project, Standard Subscribers Group and other projects / groups relevant to your role
+* Review our [Team Agenda](https://docs.google.com/document/d/1JiLWsTOm0yprPVIW9W-hM4iUsRxkBt_1bpm3VXV4Muc/edit) for daily call
+* Become familiar with [GitLab's Website](https://about.gitlab.com) and the following links:
+  1. [Documentation](https://about.gitlab.com/documentation/)
+  1. [EE Pricing](https://about.gitlab.com/pricing/)
+  1. [Blog](https://about.gitlab.com/blog/)
+  1. [About Us](https://about.gitlab.com/about/)
+* Connect with GitLab's social media sites:
+  1. [LinkedIn](https://www.linkedin.com/company/gitlab-com)
+  1. [Twitter](https://twitter.com/gitlab)
+  1. [Facebook](https://www.facebook.com/gitlab)
+  1. [YouTube](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg)
+* Learn how to use our Internal Issue Trackers:
+We use GitLab Issues to raise awareness, discuss and propose solutions for various issues related to any aspect of our business.
+The most common Issues are created in the following projects:
+  1. [GitLab Enterprise Edition](https://dev.gitlab.org/gitlab/gitlab-ee) - Issues related to GitLab Enterprise Edition
+  1. [GitLab HQ](https://dev.gitlab.org/gitlab/gitlabhq) - customer requests
+  1. [GitLab www-gitlab-com](https://dev.gitlab.org/gitlab/www-gitlab-com) - Issues related to our website
+* Add issues in the correct Issue Tracker:
+  1. Public issues related to GitLab website: use [www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com)
+  1. Internal issues related to documentation and gitlab.com usage: Use [GitLab HQ](https://dev.gitlab.org/gitlab/gitlabhq)
+  1. Internal issues related to the organization: Use [GitLab Organization](https://dev.gitlab.org/gitlab/organization)
+  1. Internal issues relate to Enterprise Edition: Use [GitLab EE](https://dev.gitlab.org/gitlab/gitlab-ee)
+
+### GitLab Instances<a name="gitlab-instances"></a>
+We have two GitLab instances that we use primarily, namely the 'dev' server and the free SaaS of GitLab at GitLab.com.
+
+#### dev.gitlab.org
+* This server is only accessible to people from GitLab the company.
+* This is the instance we use for customers development.
+* In addition, all our internal (company) issues are found here as well.
+* This server is updated from master every night, so we quickly see if we broke something.
+* Often referred to as `dev`.
+
+#### GitLab.com
+* This is the SaaS of GitLab. Everyone can host their repository for free here and
+this is where the majority of open source contributions come in. Unless there's
+a good reason not to (customer information disclosure, undisclosed security
+issues, etc.), do your development and submit your merge requests here [in the open](https://about.gitlab.com/2015/08/03/almost-everything-we-do-is-now-open/).
+
+#### Other instances
+Many developers set up their own private GitLab instance somewhere, for instance
+to test and work with LDAP or Active Directory, to give demos, or for various
+other reasons.
+
+### Security<a name="security"></a>
+
+See the [security handbook](https://about.gitlab.com/handbook/security).
+
+### Quiz<a name="quiz"></a>
+Employees should answer GitLab quiz questions in the first 2 weeks of working in
+the company. If the answers are not accurate, you may retest once:
+<a href="https://about.gitlab.com/handbook/questions/">GitLab Quiz.</a>
+Please schedule a call with your hiring manager.</li>

source/handbook/hiring/index.html.md

+---
+layout: markdown_page
+title: "Hiring"
+---
+## On this page:
+* [Vacancy Creation Process](#vacancy-creation-process)
+* [Hiring Process](#hiring-process)
+* [Screening Call](#screening-call)
+* [Interview Questions](#interview-questions)
+* [Reference calls](#reference-calls)
+* [Getting Contracts Ready, Reviewed, and Signed](#prep-contracts)
+
+## Vacancy Creation Process<a name="vacancy-creation-process"></a>
+
+The CEO needs to authorize any new job positions/searches, and agree on the proposed hiring team.
+
+1. Define hiring team. Roles can be assigned fluidly (see below for the [Hiring Process](#hiring-process)), depending on who is available, bearing in
+mind that the most time consuming aspect tends to be review of the first wave of applicants.
+1. Create the job description on our website, and in Workable
+    1. Create the relevant page in `https://about.gitlab.com/jobs/[name-of-job]`
+    1. Add a job of the exact same job title on [Workable](https://gitlab.workable.com/backend)
+       * For location, select "Telecommute".
+       * For the description, simply write `For the job description, see [url of relevant jobs page on GitLab's website]`
+       * Indicate what applicants need to provide with their application. By default, this will include their resumé, a cover letter, but it may also
+       include qualifying questions such as "What timezone are you in?" and "Are you aware that this is not a DevOps role?".
+       * "Publish" the job, and follow the links to the application form.
+    1. Embed the link to the application form for the new job on our [Jobs page](https://about.gitlab.com/jobs/)
+1. Optional: advertise the job description.
+    * This can be through “soft” referral, e.g. all GitLab staff post link to jobs site on their LinkedIn profiles.
+    * Tweet the new job posting.
+    * Consider advertising and/or listing on paid / free job boards.
+    * Use the [Workable Clipper](http://resources.workable.com/the-workable-clipper) to help source candidates directly from LinkedIn, and  familiarize yourself with the Workable environment, work flow, features, and support desk.
+
+## Hiring Process<a name="hiring-process"></a>
+
+1. Confirm application: applicants automatically receive confirmation of their application, thanking them for submitting their information. This is an automated message from Workable. If the person came though another channel please add them to Workable before continuing the process. There are various ways to do this, see [Workable's documentation](https://resources.workable.com/adding-candidates).
+1. Ask more information if needed: if information is missing and the applicant seems sufficiently promising (or not enough information to be able to make that determination), the appropriate person from the hiring team should follow up requesting additional information.
+1. Hiring manager does a first round of rejections. Disqualified candidates should be sent a note informing them of the rejection. There are templates in Workable to assist, but messages can be tailored as appropriate: place yourself in the receiving end of the message.
+1. [Screening call](#screening-call) (optional, see below for further detail).
+1. Technical interview (optional): As described on the [Jobs](https://about.gitlab.com/jobs/) page, certain positions
+require [technical interviews](https://about.gitlab.com/jobs/#technical-interview).
+1. Manager interview (see below for questions)
+1. For female candidates, include at least one interview with a female GitLab team member.
+1. C-level executive interview (if different than the manager, see below for questions)
+1. CEO interview (if different than the C-level executive, see below for questions)
+1. Make a verbal or written (email) offer (the CEO needs to authorize offers)
+1. Hiring manager follows up to ensure that the offer is accepted, and then moves to [preparing contracts](#prep-contracts)
+1. Hiring manager ensures that the contract is signed, and [starts the onboarding process](#move-to-onboarding) (the People Ops team can help).
+
+### Rejecting applicants
+
+1. At any time during the hiring process the applicant can be rejected
+1. The applicant should always be notified of this. The hiring manager is primarily
+responsible for this, but People Ops can help and does a weekly check-up in Workable.
+1. If the applicant asks for further feedback always offer frank feedback. This
+is hard, but it is part of our company values.
+1. If the candidate is not hired, People Ops sends out an email to ask for feedback.
+There is a "gathering applicant feedback" template in Workable with these questions.
+The feedback survey should be sent out about 3 days after the applicant has been
+notified of the rejection.
+1. PeopleOps will receive the feedback and will use this to improve the hiring process.
+
+
+## Screening Call<a name="screening-call"></a>
+
+For some positions, we conduct screening calls. This call is typically done by our [administrative coordinator](https://about.gitlab.com/jobs/administrative-coordinator/).
+
+Questions are:
+
+1. Why are they looking for a new job?
+1. What is your experience with X? (do for each of the skills asked in the job description)
+1. How do they feel about working remotely and do they have experience with it?
+1. Compensation expectation and compensation in current/last job.
+
+[An example of the output of a good screening call](https://gitlab.workable.com/backend/jobs/128446/browser/applied/candidate/7604850) (need workable account).
+
+At the end of the screening call applicant should be told what the timeline is for what the next steps are (if any).
+An example message would be "We are reviewing applications through the end of next week, and will let you know by the end of two weeks from today whether you've been selected for the next round or not. Please feel free to ping us if you haven't heard anything from us by then."
+
+## Interview Questions<a name="interview-questions"></a>
+
+Note: So you are about to interview folks for a job at GitLab? Please take a moment to carefully read
+[this document on keeping it relevant and legal, including a self-test](https://docs.google.com/document/d/1JNrDqtVGq3Y652ooxrOTr9Nc9TnxLj5N-KozzK5CqXw).
+
+1. Do you have any questions about the job or our organization?
+1. Why did you apply to GitLab?
+1. For each significant study and job ask: can you shortly say why did you select this one and why did it end? (for studies: why not do master, PhD, PostDoc, etc.)
+1. When were you most satisfied in your most recent position?
+1. What did you like least about your most recent position?
+1. Take each skill required for the job and do a [STAR](https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Result) for a couple of situations.
+1. What professional achievements are you most proud of?
+1. How do you keep up to date with developments in your profession?
+1. If you don't get this job what will you do?
+1. Are you interviewing anywhere else?
+1. How can we change GitLab the product to make it better?
+1. What can we change in GitLab the organization to make it better, for example the hiring process?
+1. What do you expect to achieve in your first month at GitLab?
+1. Where do you want to be in three years from now?
+1. How do you feel about working remote?
+1. If you get hired when can you start?
+1. What compensation would you feel comfortable with?
+1. Do you have any questions for me?
+
+## Reference calls <a name="reference-calls"></a>
+
+As part of our hiring process we may ask applicants to provide us with one or more
+references to contact. These reference calls are typically be done by our [administrative coordinator](https://about.gitlab.com/jobs/administrative-coordinator/) or the hiring
+ manager for that specific vacancy. 
+
+## Getting Contracts Ready, Reviewed, and Signed<a name="prep-contracts"></a>
+
+Offers made to new team members should be documented in the email thread between the
+person authorized to make the offer (e.g. CEO) and the applicant.
+
+1. Email example: "We would love to have you as part of our team. You will have
+a position of [job title]. As a contractor you will invoice [monthly rate] per month.
+You will report to the [manager]. We proposed to make you eligible for [number] of stock options.
+We will send you a contract on Monday based on
+the examples on https://about.gitlab.com/handbook/contracts/. If you have not
+received anything on that day please reply-to-all to let us know. Please let us
+know if you have any questions or concerns in the meantime."
+1. In the email confirmation of the offer,
+put the People Operations email alias (which can be found in the "GitLab Email Forwarding" google doc) in the cc.
+1. One person from People Operations will reply-to-all to everyone in the thread
+(including the applicant) to confirm that they will make the contract. Speed matters: if you are in People Operations and you can
+tackle this, then raise your hand and hit reply-all.
+   - For any hires for which the COO does _not_ sign, the COO reviews the contract
+after which it can be sent out to be signed by any of the relevant C-level team
+members. For any hires for which the COO should sign, either the CFO or the CEO must
+review the contracts.
+1. This person from People Operations makes the contract based on the details found in the Workable
+platform, and uses reply-all to gather any missing pieces of information, and to
+confirm with a reply-to-all when the contract is sent. Note: the number of proposed stock options
+must always be mentioned specifically, even when it is 0. People Ops must follow-up
+with the person who requested the contract to make sure that this point is addressed.
+1. This same person from People Operations files the signed contract in the appropriate place, and starts the [**onboarding issue**](https://about.gitlab.com/handbook/general-onboarding/).
+
+Note for People Operations:
+- the type of contract required (employee or contractor; BV or Inc) is clarified by the guideline on the
+[Contracts page](https://about.gitlab.com/handbook/contracts).
+- Onboarding info for the PeopleOps system, BambooHR, can be found on the [PeopleOps](about.gitlab.com/handbook/people-operations) page.

source/handbook/leadership/index.html.md

+---
+layout: markdown_page
+title: Leadership
+---
+## Behaviour
+
+- As a leader team members will follow your behaviour, always do the right thing.
+- Behaviour should be consistent inside and outside the company, don't fake it outside, just do the right thing inside the company as well.
+
+## Books to read
+
+- High output management - Andrew Grove
+- The Hard thing about hard things - Ben Horowitz
+- [The score takes care of itself - Bill Walsh](http://coachjacksonspages.com/The%20Score%20Takes%20Care.pdf)

source/handbook/leadership/offboarding/index.md

+---
+layout: markdown_page
+title: "GitLab Offboarding"
+---
+
+Create issue for former team member on the dev server in the [people ops confidential project](https://dev.gitlab.org/gitlab/people-ops-confidential/issues/) and add the following checklist (edit it for applicability to the individual).
+This list looks strange in this handbook but this is to ensure you can copy paste it into an issue.
+When you paste it in an issue it will have checkboxes that you can click to complete.
+
+```
+* [ ] For this offboarding, the manager is @MENTION, People Ops is handled by @MENTION. cc @rspeicher, @jacobvosmaer, @patricio, @ernst.
+* [ ] Manager of former team member: Organize smooth hand over of any work or tasks from former team member.
+* [ ] Robert/Jacob/COO: Dealing with the Google account
+   * [ ] Robert/Jacob/COO: Check with the former team member's manager if they
+   want email forwarded. If yes, then:
+   * [ ] Robert/Jacob/COO: switch off 2FA for the account, reset the password,
+   log on, and set email to forward to the manager. Also change the phone number
+   and alternative email (typically personal email address) that are associated
+   with the account. Switch 2FA back on and save login credentials in 1password.
+   * [ ] Robert/Jacob/COO: upon manager's request (typically 4 weeks after blocking
+     the Google account), transfer owned documents from Google Drive to
+   manager, and delete the Google account.
+* [ ] Robert/Jacob/COO: Disable team member in Slack.
+* [ ] People Ops: Remove former team member from TriNet and payroll if applicable.
+* [ ] People Ops: Reach out to former team member to identify and retrieve any company supplies/equipment.
+* [ ] People Ops: Inform Controller / Accounting if any items in former team members possession will not be returning, so that they can be removed from asset tracking.
+* [ ] Robert/Jacob/COO: Remove former team members' GitLab.com account from the [gitlab.com group](https://gitlab.com/groups/gitlab-com/group_members)
+* [ ] Robert/Jacob/COO: Block former team members' [dev.GitLab.org account](https://dev.gitlab.org/admin/users) and remove from [gitlab group](https://dev.gitlab.org/groups/gitlab/group_members)
+* [ ] People Ops: Remove access to 1Password.
+* [ ] People Ops: Remove team member access to Google Drive.
+* [ ] Manager: Remove access to SalesForce.
+* [ ] Manager: Remove access to Recurly.
+* [ ] Manager: Remove access to Netsuite.
+* [ ] People Ops: Remove access to company credit card.
+* [ ] People Ops: Remove from Beamy
+* [ ] People Ops: Remove team member from the GitLab availability calendar.
+* [ ] People Ops: Remove team member from team call invitation.
+* [ ] People Ops: Remove team member from HelloSign, if applicable.
+* [ ] People Ops: Remove team member from map / Sundial.
+* [ ] Patricio/Jacob/COO: Remove from tweetdeck
+* [ ] People Ops: Notify eShares administrator (CFO) of offboarding.
+* [ ] People Ops: Note final date of employment / contract in the "Organizational Chart and Hiring" sheet.
+* [ ] People Ops: Remove team member from [team page](https://about.gitlab.com/team)
+* [ ] Operations: If the person is from operations [remove the sysadmin](https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/user-administration.md#remove-a-sysadmin)
+* [ ] Manager: Announce in general chat channel 'X is no longer with GitLab'
+* [ ] Manager: Put on the agenda for the next team call 'X is no longer with GitLab'
+```

source/handbook/marketing/developer-relations/content-marketing/index.html.md

+---
+layout: markdown_page
+title: "Content Marketing"
+---
+
+## Introduction
+
+The philosophy for Content Marketing at GitLab is to help bring insider
+knowledge and implicit practice to the hands of developers getting acquainted
+with GitLab, and decision makers considering GitLab.
+
+We want to meet each user where they are now, and help them be the most
+efficient they can be with our tools.
+We want to help their teams realize their creative and collaborative goals.
+
+We also want to address the whole organization, the coal-face of development
+or in decision making roles. GitLab is not only used for code development and
+review. Those same tools are used by team members to track progress, create
+documentation and collaborate on projects. When we show how we work "inside
+GitLab" we also model how to use our software.
+
+## 2016 activities
+
+- Publish an active [blog](blog/) with useful content relevant to GitLab users.
+- Host [webcasts](webcasts/)
+which welcome newcomers, celebrate with existing users, and provide access to expertise.
+- Publish a twice-monthly email newsletter you can sign up to on [our contact page](https://about.gitlab.com/contact/).

source/handbook/marketing/developer-relations/index.html.md

+---
+layout: markdown_page
+title: "Developer Relations"
+---
+
+The developer relations organization includes the following roles:  
+
+- [Technical writing](/jobs/technical-writer/)  
+- [Developer advocacy](/handbook/marketing/developer-relations/developer-advocacy/)  
+- [Field marketing](/handbook/marketing/developer-relations/field-marketing/)  
+- [Content marketing](/handbook/marketing/developer-relations/content-marketing/)  

source/handbook/marketing/online-marketing/index.html.md

+---
+layout: markdown_page
+title: "Online Marketing"
+---
+Go to the [Marketing Handbook](/handbook/marketing)
+
+## This page
+* [URL Tagging](#urlTagging)
+
+## URL Tagging<a name="urlTagging"></a>
+
+All marketing campaigns that are promoted on external sites and through email should use URL tagging to increase the data cleanliness in Google Analytics. For a primer course, please see the [training video](https://drive.google.com/a/gitlab.com/file/d/0B1_ZzeTfG3XYNWVqOC11NWpKWjA/view?usp=sharing). This explains the why and how of URL tagging.
+
+Our internal URL tagging tool can be accessed on Google Docs under the name [Google Analytics Campaign Tagging Tool](https://docs.google.com/a/gitlab.com/spreadsheets/d/12jm8q13e3-JNDbJ5-DBJbSAGprLamrilWIBka875gDI/edit?usp=sharing).