Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Contracts

On this page

Disclaimer

These agreements are examples of the agreements that we currently use at GitLab. However, the terms and conditions of an employee or contractor’s agreement will vary based on each employee or contractor’s specific circumstances. GitLab reserves the right to amend or change the sample agreements, as well as each employee or contractor’s actual agreement. The samples below are samples only — they are not valid as such and do not replace personalized signed agreements.

Available Currencies

The preference is for team members and future team members to be paid in their local currency. However, there may be instances where this is not possible and another currency may be chosen by the team member. This should be discussed and agreed with the Compensation Committee and the People Operations Analyst ahead of creating the appropriate contract (at offer stage for new team members) so a new one can be issued or confirmed by Letter of Adjustment. The effective exchange rate date used in these cases will be either January 1 or July 1 depending on the hire date of the new team member. This is to minimize significant fluctuations to salaries due to currencies that either strengthen or weaken throughout the year. Further details on this review period can be found in the Global Compensation page under Exchange Rates.

GitLab can pay local currency in the following countries:

Country ISO Code
Australia AUD
Bahrain BHD
Canada CAD
China CNY
Czech Republic CZK
Denmark DKK
Ethiopia ETB
Great Britain GBP
Hong Kong HKD
Hungary HUF
India INR
Indonesia IDR
Israel ILS
Japan JPY
Kenya KES
Kuwait KWD
Morocco MAD
Mexico MXN
Netherland Antilles ANG
New Zealand NZD
Norway NOK
Poland PLN
Romania RON
Russia RUB
Saudi-Arabia SAR
Singapore SGD
South Africa ZAR
Sweden SEK
Switzerland CHF
Thailand THB
Tunisia TND
Turkey TRY
United Arab Emirates AED
United States USD

How to use this page to prepare a contract

Assuming that the hiring process went smoothly, now it is time to prepare the applicable contracts.

First, be sure to validate the following:

  1. The currency listed in the offer package in Greenhouse should normally be the local currency of the new team member unless they explicitly request USD/EUR because their local currency has a lot of inflation. This needs to be confirmed and approved by our People Ops Analyst prior to making the offer, as any changes to the currency will require complete reapproval in Greenhouse, regardless if it is the same amount just in a different currency.
  2. Confirm if the team member would be an employee or contractor and through which entity the team member would be employed or contracted.
  3. Employee entity: employ through the GitLab entity where they are located (United States = Inc., the Netherlands = B.V., United Kingdom = Ltd, India = Lyra, Germany = GmbH, Ireland = SafeGuard, Canada = CXC, Australia = CXC, China = CIIC, Belgium = B.V. (Belgian contract - depending on the location in Belgium the contract will need to be in either French or Dutch with the English translation alongside).
  4. Contractor entity: if the team member is in the US, or if the person is part of the Sales organization, GitLab Inc. is the contracting entity. In all other regions and functional groups, GitLab BV is the contracting entity. If the team member wants to be contracted through a company, it can either be their own established legal entity or a separate and unaffiliated 3rd party company; please confirm which with the team member prior to sending out the contract. If the team member will be contracted through their own entity (or as an independent contractor), please use the BV Contractor Agreement. If the team member will be contracted through a 3rd party company, please inform Legal so that we can enter into a vendor contract with the company. The 3rd party company will then enter into a contract with the team member, and People Ops will provide the necessary specific salary and position information.

Send the contract through Greenhouse

  1. Once the offer package has been approved in Greenhouse, go to the offer details page of the candidate's profile in Greenhouse. Scroll to the section "Offer Documents" and click "Generate". Then click in the box and select from the options the appropriate template for the team member's entity, employment/contractor status, full-time or part-time, and any applicable bonuses. An example is GitLab Inc full-time, with variable bonus/commission. Then click "Generate". It will now populate and .docx and .pdf files under the "Offer Documents" section. Download the pdf and preview it to ensure everything populated correctly. If there are any token errors (i.e. problems with the information pulling from the candidate's profile and into the contract), Greenhouse will notify you. Most likely, if that happens it is because a field in the candidate profile is not accurately filled in. Once you fix the error, you'll need to "Regenerate" the contract.
  2. If the contract you are working on is unique and does not have a template or need one in the future, it's recommended to go to the manually create the contract using Google Docs. In the Google Drive, go to the folder titled "Employee and Contractor Templates and Staging". Only People Ops, Finance, and Legal should have access to this folder. Go to the folder "Templates" and find the relevant template contract (each document is also linked below). Make a copy of the contract in Google Drive, move it to the "Employee and Contractor Templates" folder so the details remain private. Rename the title so it includes the candidate's name, then make the edits in Google Docs by finding all fields with curly brackets ({ }) and replacing each field (including the curly brackets) with the specific details of the candidate. You can do this by clicking "Edit" then "Find and replace". Double check every field that needs to be filled out is completed; it is helpful to search only for { or [ to see if anything remains, as well as doing a quick look over the document. Once the contract is completed, have the contract reviewed for accuracy via Slack by the People Business Partner for the function the candidate will be in by including a link to the Google Doc document and the candidate's Greenhouse profile. After approved, download the Google Doc contract as a .docx, go to the candidate's profile in Greenhouse, go to the offer details section, scroll down to the "Offer Documents" section, then click "Upload" and choose the file. You can now delete the Google Docs version as it has been replaced by the version in Greenhouse.
  3. Next, click "Send with DocuSign" right below the offer documents. You will need to have first connected your Greenhouse account with your DocuSign account by going to the integrations tab in Greenhouse.
  4. Choose the template Offer through DocuSign. In the "To User" field, choose the GitLab signatory for the contract. In the "CC" field, add hiring@gitlab.com and peopleops@gitlab.com. Double check the body of the email is accurate. Then click "Preview on DocuSign".
  5. You will be redirected to DocuSign.
  6. On the top left of the screen, click where it says the candidate's name, then click "Edit Recipients". Drag the GitLab signatory from the bottom of the list to the very top and change the 1 next to the candidate's name to a 2. This ensures that the contract goes to the GitLab signatory to sign first, and once signed by them it will go to the candidate. Then click "Done".
  7. Scroll throughout the contract and double check that the candidate and GitLab signatory signature and date fields are accurately added. If there is an Exhibit A to the PIAA section of the contract, be sure to add blank text boxes assigned the candidate, with the "yes or no" text box being required and the "if yes…" text box being optional. There may also be other fields you'll need to add a textbox for, so double check if there are any other fields that need to be completed by either the candidate or GitLab signatory (as contracts for different entities vary; one that is easy to miss is the UK contract which requires the candidate to input their national insurance number). Once you've verified that all the information is correct and appropriately assigned, click "Send" at the top right corner.
  8. You'll now be redirected back to Greenhouse, where you can monitor the progress of the contract and be able to see when each party signs it. Once it is signed by all parties, you and everyone cc'd on the original request will receive a confirmation email that it has been signed.
  9. If you need to resend the contract, follow the same steps, but be sure to log into your DocuSign account and first delete the original one to avoid confusion.
  10. If you are processing a GitLab Inc. contractor agreement, also send a W9 via the DocuSign website. If you do have a W9 template, reach out to People Ops.
  11. Once the contract is signed, Recruiting will begin the background check for the candidate through the Sterling integration with Greenhouse, and People Ops will start the onboarding issue.

How to add a contract into Greenhouse

  1. In the Google Drive, go to the folder titled "Employee and Contractor Templates and Staging". Only People Ops, Finance, and Legal should have access to this folder.
  2. Click the folder called "Templates" to find the relevant template contract (each document is also linked below).
  3. Make a copy of the contract and move it into the "Greenhouse Templates" folder.
  4. Log in to Greenhouse and go to "Configure" by clicking the gear at the top right corner, then choose "Offer Templates".
  5. For each of the fields with curly brackets ({ }) in the template on Google Drive, find and replace that field (including the curly brackets) with the corresponding Greenhouse tokens (including the curly bracket). For example, {Contributor Name} in the Drive template will be replaced with {{CANDIDATE_NAME}}.
    1. Some fields that are not necessarily clear are the compensation fields as there are separate fields for the vacancy and for the candidate; we want the candidate fields for the contract, so in Greenhouse, the appropriate token for salary is {{CURRENCY}}, bonus is {{BONUS_AMOUNT}}, and stock options is {{STOCK_OPTIONS}}. Another field that is easily confused is the title; the {{JOB_NAME}} is the name of the vacancy, which is not always necessarily the same as the title the candidate will have; to make sure it is always correct and includes the appropriate level and specialty for the candidate, use the token {{FULL_TITLE__INCLUDING_LEVEL_AND_SPECIALTY_}}.
    2. The one exception to the curly bracket find and replace process is the Belgian contract. The fields that need to be edited are highlighted.
    3. If there is no corresponding field in the Greenhouse tokens, go to "Configure", "Custom Options", "Offers". Then click "Add Field" at the top, and add the name of this field (being as succinct yet descriptive as possible), add a description if needed (this will only show up when hovering over the field), the type of field it will be (this cannot be changed once the field is created), and check off "Create new email token (optional)" which will allow you to include it in the contract. Then click save. The new field will populate at the bottom, and you'll be able to drag it elsewhere in list, but do keep in mind that this is the list that populates the offer package, so unless it's crucial to the offer/approval process, it's usually best left towards the bottom. It is, however, best practice to at least move it above the "Signatory Name" and "Signatory Title" fields, so that they are always last. Then, go back to the "Offer Templates" section in Greenhouse, and you'll see the new field you created is a new token option.
    4. When removing optional clauses, take care that the paragraph / section numbering still makes sense.
    5. Double check that each field that needs to be filled out is replaced with a Greenhouse token. Sometimes it is not always obvious, as the curly bracket might be regular brackets by mistake.
    6. For each signature section, the following tokens must be on their own line in the document, with nothing else on the line: {{CANDIDATE_SIGNATURE}}, {{CANDIDATE_SIGNATURE_DATE}}, {{COMPANY_SIGNATURE}}, and {{COMPANY_SIGNATURE_DATE}}. Find each signature page, then hit enter to create the new line after the "Signature", "Name", "Title", and "Date" sections, then copy the corresponding Greenhouse tokens. These can be easy to miss, so double check each signature section has the appropriate Greenhouse tokens, each on their own line.
    7. Most contracts will have various versions that need to created, e.g. one that contains bonus language for variable bonus/commission, director/executive bonuses, or signing bonuses. Best practice is to create the contract containing all of the additional information and title it accordingly, then once you are done go to "File" in Google Docs and choose "Make a copy". Then remove the information as needed and rename the new document and continue the steps below. You can view other documents in the Greenhouse Templates folder for examples.
    8. For contract templates with variable bonus/commission plans, replace all paragraphs with the token {{VARIABLE_BONUS_TYPE_OFFER_SECTION}} which will tell Greenhouse to automatically choose the correct bonus type based on the offer package created in Greenhouse.
  6. Once you have completed customizing the contract for Greenhouse, click "File" in Google Docs, then "Download as" and "Microsoft Word (.docx)".
  7. Then go back to the "Offer Templates" section in Greenhouse and scroll down to "Template Name" and click "Upload New" to the left.
  8. Choose the document you've downloaded and add a name for the template. The convention is typically "GitLab Entity employment-type, with/without bonus", e.g. GitLab Inc full-time, with variable bonus/commission.
  9. Greenhouse will upload the document and it will appear at the bottom of the page. There will be a Test button next to it; click this, and it will validate that all of the Greenhouse tokens are correctly inputted. If there are any errors, it will notify you. You will then need to go back to the template in Google Docs and correct the errors, redownload it, and reupload it to Greenhouse (after deleting the original one with mistakes). If all of the tokens are functioning properly, there will be green checkmarks, and you're ready to use this template for contracts!
  10. To delete a contract template from Greenhouse, click the three dots ... to the right of the template name, then click delete and confirm.

The "source of truth" for the contract templates are in the Google Drive, in the folder titled "Employee and Contractor Templates and Staging". Any updates to contracts will be done there first, and then the recruiting team needs to be pinged to be made aware of the changes so they can update the corresponding Greenhouse template.

To change or update a contract that has already been created and uploaded into Greenhouse, return to the corresponding Google Drive doc in the "Greenhouse Templates" folder, open the templates that need to be updated (there may be multiple that need to be changed, since there are different varieties of each contract to accommodate bonus structures, full-time/part-time, etc.), then update each accordingly. If you need to add new tokens to accommodate the change, be sure to follow step 5.3 in the above instructions. Once you have finished making any updates, click "File" in Google Docs, then "Download as" and "Microsoft Word (.docx)". Then go back to the "Offer Templates" section in Greenhouse. Find the contract that you are replacing, copy the name of it so you can maintain consistency, then click the three dots ... to the right of the template name, then click delete and confirm. Then click "Upload New", paste the name of the template, and upload the new version. Click "Test" to validate that everything translated correctly (per step 9 above), and you are ready to use the new template.

Employment and Contractor Agreements

The following contracts are in Google docs that are viewable by anyone with the link. They should be signed by the Recruiting Director, with the CCO, CFO, or CEO as backup.

United States Employment Status

Fair Labor Standards Act: Exempt v. Nonexempt Employees

Portugal Employment Status

In Portugal, we can only hire individuals that are hired on a C2C basis. This means, contractors that are hired through our BV Contractor agreement, via an established company in Portugal, with more than one client. Unfortunately at this time, we are not able to hire any team members in sales whatsoever.

CXC

GitLab is working in partnership with CXC Global to employ GitLabbers located in several countries listed below. The actual employment contracts will be sent and issued by CXC and are in accordance with local labor law. CXC also handle the processing and payment of payroll and associated taxes and compliance in each of the countries on behalf of GitLab. The contracts themselves are between the individual and CXC. The offer details will be provided to CXC by GitLab's hiring team.

Australia and New Zealand

CXC will hire individuals as casual employees with an initial contract of two years. This can be extended. Working time is set at 40 hours each week and payment of salary happens on a monthly basis upon payment of invoices that CXC will submit to GitLab at the beginning of each month. In addition to the details on leave, as stated in CXC's contract, further details are also provided in a separate letter.

  1. Offer is made by the manager/recruiter per the hiring process.
  2. The Candidate Experience Specialist emails the new team member the Contract Info Request - Australia and New Zealand from GreenHouse.
  3. The Candidate Experience Specialist will complete the SOW (statement of work) document. This is located on the Google Drive: Employee and Contractor Templates and Staging => CXC Australia Folder.
  4. Details of the state payroll taxes and CXC's costs that need to be added to SOW can be found in the same folder in a spreadsheet called CXC Costs. Please add to this list if the state is not listed. CXC can be contacted for this information. Please see below for contact details.
  5. Once SOW is completed it will need to be reviewed and approved by a fellow Recruiting or PeopleOps team member. Once reviewed it will need to be staged for signing by GitLab only.
  6. After the SOW has been signed it will need to be emailed to CXC. Contact details can be found in 1password => People Operations Vault => Entity & Co-employer HR Contacts
  7. CXC will then reach out to the candidates directly to co-ordinate the contract signing and onboarding to CXC's payroll.

Canada

CXC will hire individuals as T4 Workers, paid on an hourly basis each fortnight. Time-sheets are required to be completed and submitted to CXC. These are to comply with the public holiday paid time off requirements and vacation pay accrual that is credited to the individuals account. In addition to the paid vacation as stated in CXC's contract, further details are also provided in a separate letter.

  1. Offer is made by the manager/recruiter per the hiring process.
  2. The Canidate Experience Specialist emails the new team memeber the Contract Info Request - Canada from GreenHouse.
  3. The Canidate Experience Specialist will complete the CXC Global Project Information sheet. This is located on the Google Drive: Employee and Contractor Templates and Staging => CXC Canada Folder.
  4. Once that sheet is completed post in the peopleops confidential slack channel for approval. (unless it is for a People Ops team memeber)
  5. Email the sheet to CXC Canada contact (see Australia section above for location of contact details). CXC will then prepare the SOW for signatures.
  6. Once the SOW has been sent back to recruiter or people ops rep, stage for signature in DocuSign and then send back to CXC who will then prepare the contract
  7. Kindly allow a duration of one week for CXC to complete their process. This might mean that a two week notice period to start at GitLab, could increase to three weeks, its important to communicate this duration to new hires in this location.

CXC currently does not cover the Medical Services Plan (MSP) fees in British Columbia, Canada.

SafeGuard

Process for Ireland, Hungary, Switzerland, South Africa and the Ukraine

GitLab has also partnered with SafeGuard. While current team members in France and Spain are employed via SafeGuard as well, we are not hiring any further team members in these locations right now.

To create the contract:

  1. The Offer is made by the manager/recruiter per the hiring process.
  2. The Candidate Experience Specialist emails the new team member the Contract Info Request - SafeGuard from GreenHouse.
  3. The Candidate Experience Specialist emails the main Account Manager at SafeGuard to request the contact for the new team members onboarding by providing the name and their location (country). Contact details can be found in 1password => People Operations Vault => Entity & Co-employer HR Contacts.
  4. The Candidate Experience Specialist will complete the New Hire Form. This is located on the Google Drive: Employee and Contractor Templates and Staging => SafeGuard.
  5. Once the form is completed, post in the People Ops confidential channel in Slack for review on accuracy (unless it is for a People Ops team member, this should be done via email to the People Operations Generalist or a People Operations Business Partner).
  6. The Candidate Experience Specialist will stage the form for their own signature via DocuSign and CC the appropriate SafeGuard contact.
  7. Once SafeGuard receives the form they will contact the candidate directly to onboard them. This usually takes 2-3 days, but can take up to a week.
  8. If the Candidate Experience Specialist does not hear back from SafeGuard within 72 hours, they will follow up to check if the start date is viable, get timing on when they will hear back and when the new hire will receive their contract and other important employee information. The new hire should be kept updated by the Candidate Experience Specialist or Recruiter by email. If the contract has not been received by GitLab, one week prior to the start date, we'll need to reconsider the start date.

Preparing Employment Agreements for GitLabbers in India

GitLab is working in partnership with Lyra Infosystems for employing GitLabbers located in India. These agreements are mailed rather than emailed so there is a lead time of approximately one week for completion before the new hire can start their employment at GitLab. The process for creating and sending an agreement is as follows:

  1. Once the offer from the manager has been communicated as per the hiring process People Ops will email Lyra HR with salary information for the new hire so that Lyra can prepare the Cost to Company (CTC) breakdown to include in the contract. The Cost to Company (CTC) breakdown will be sent to you and included in the next steps.
  2. The Candidate Experience Specialist will email the new team member Contract Info Request - India from GreenHouse.
  3. When all of the information asked for in the above two steps has been received, complete the contract as per the steps in the how to use this page to prepare a contract section, apart from staging the contract in DocuSign. Add the Cost to Company (CTC) Excel Sheet to "Anexure A."
  4. Once the contract is ready to be sent, save it as a PDF, email it to the new hire and cc peopleops and HR at Lyra.
  5. Once the contract has been emailed, HR at Lyra will send the hardcopy for signature directly to the new hire's home address.
  6. When the contract has been signed HR at Lyra will send Peopleops a PDF copy of the document which can then be filed in BambooHR.
  7. Complete the last step in the how to use this page to prepare a contract section.

Employment Agreements for GitLabbers in China

GitLab is working in partnership with CIIC to employ GitLabbers located in China. Signed agreements between GitLab and CIIC are required to employ any new hire. Therefore, there will be a lead time of approximately three weeks prior to starting. As soon as it becomes clear that an offer to a candidate is going to be made, People Ops will reach out to CIIC to begin the process. The process for preparing the agreements between all parties is as follows:

GitLab and New Hire:

  1. Once the email offer from the hiring manager has been sent as per the hiring process complete the Template-GitLab China Employee Offer letter as per How to use this page to prepare a contract.
  2. In addition to GitLab's Offer Letter, CIIC require a Chinese version of a Letter of Employment Intent.
  3. Complete the Letter of Intents with all of the information required/known. This should be completed in English first then translated into Chinese using Google Translate.
  4. Once this has been done send the GitLab offer letter and both (Chinese & English) versions of the Letter of Employment Intent to the new hire for their review, completion and signature using DocuSign. Ensure that Peopleops and CIIC are copied.
  5. Once everything has been signed, print and FedEx the Chinese and English Letter of Intents to CIIC. The address can be found in the PEO China folder > China Employment Options > CIIC in the Google Drive.

GitLab & CIIC:

  1. GitLab has a Secondment Agreement in place with CIIC, this may need to be updated but CIIC will confirm.
  2. Once CIIC have received the documents they will prepare a payment notice and send this to GitLab (peopleops) for payment. This must be paid upfront and may need CFO approval.
  3. After CIIC receive payment they will reach out to the new hire to complete a Labor Contract.

CIIC & New Hire

Once the Labor Contract has been signed by both CIIC and the new hire the individual can now commence their work with GitLab.

Employment Agreements for GitLabbers in Germany

When a wet signature is required for employment agreements the following process must be followed:

  1. Email offer from the manager/recruiter is sent per the hiring process (the candidate's address will need to be asked for at this stage). This email should also contain a link to this process so that the candidate is aware.
  2. People Operations will prepare the contract per the instructions in How to use this page to prepare a contract .

The Candidate Experience Specialist will send the following email after the offer has been sent, to communicate next steps in the process:

My name is XXX, Candidate Experience Specialist, and I will be sending out your contract. We wanted to let you know what the steps are for doing so. There are quite a few, so please reach out if you have any questions! 
I will send you a copy of the contract through DocuSign. This is not the formal contract. This serves as temporary acceptance of the position, and it allows you to look everything over (address, name spelling, start date, etc) before we send you the contract in the mail for your signature.
Once you sign the DocuSign contract, our Director of Recruiting will mail you a copy of the contract for you to sign. 
Be sure to email me once you receive it so that I can direct you on next steps.
Attached to this email is the Power of Attorney document for you to review. 
Please do let me know if you have any questions. We are looking forward to working with you!

Once you have signed the contract the Candidate Experience Specialist will send you the following email:

Hi XXX,
We are so glad that you have signed your contract! Next, we will need you to send one of the signed contracts to our German Law Office, Employment Matters Germany.`
Address:
*Add address here from the Germany Employment Agreement Note in the People Ops 1Password vault*
Please be sure to save any receipts for reimbursement. If you have any questions, as always, do not hesitate to reach out!

Recruiting Director or CFO Signatory

  1. Once the contract has been reviewed and approved, either the Recruiting Director or CFO will need to print two copies of the contract, sign and send them to the candidate by postal mail using FedEx (details of this can be found in 1Password => Secretarial Vault => Fedex) or another courier service.
  2. A copy of the Power of Attorney (POA) will also need to be enclosed with the contracts. The POA can be found in the German Templates folder on the Google Drive.
  3. Once the documents have been sent the CCO or CFO will email People Operations with the tracking number
  4. People Operations will then email the candidate to let them know the contract is on its way and provide the following instructions for the candidate to send one copy of the contract:
    1. GitLab's FedEx account details. The candidate can use another courier if that's easier for them and they will be reimbursed.
    2. Address of GitLab's German Counsel where the contract will be filed (address is in 1Password => People Operations Vault => Entity HR Contacts => address under Legal: Employment Matters Germany)
  5. Once the law firm has received the contract they will scan and email a copy to People Operations to file in BambooHR.

CEO Signatory

  1. If the CEO is the signatory, once approved, the contract will need to be emailed to the CEO's EA. If the EA is unavailable People Operations should handle the signing and sending of the contracts.
  2. The EA will print out two copies of the contract for the CEO to sign
  3. Once the contracts are signed they will be sent by the EA to the candidate's home address.
  4. Once the documents have been sent the EA will email People Operations with the tracking number
  5. People Operations will then email the candidate to let them know the contract is on its way and provide the following instructions for the candidate to send one copy of the contract:
    1. GitLab's FedEx account details (1Password => Secretarial Vault => Fedex). The candidate can use another courier if that's easier for them and they will be reimbursed.
    2. Address of GitLab's German Counsel where the contract will be filed (address is in 1Password => People Operations Vault => Entity HR Contacts => address under Legal: Employment Matters Germany))
  6. Once the law firm has received the contract they will scan and email a copy to People Operations to file in BambooHR.

Core Team Member Non-Disclosure Agreements

Core team members are an important part of the GitLab community. In order for these individuals to be able to participate in confidential GitLab communications we ask core team members to sign a Non-Disclosure Agreement. This document is reviewed and signed by the CFO.

Letter of Adjustment

When a team member receives any change in compensation and/or title we need to create a Letter of Adjustment instead of staging an entirely new contract. This document is signed by the Director, Global People Operations and the team member through either DocuSign (if the adjustment was a transfer/promotion done through Greenhouse) or HelloSign (if the adjustment was not done through Greenhouse, e.g. cost-of-living increases). Once the document has been signed, it is uploaded into BambooHR under the Contracts and Changes folder on the Documents Tab. Also, file any other supporting documentation, for example, an email with the approval to change the compensation. Information in HRIS and Payroll systems should also be updated, if applicable. Make sure to stage the adjustment letter using the team member's personal email address and cc their GitLab email.

When a team member applies for and receives a new position through Greenhouse, a Letter of Adjustment is prepared in lieu of a new contract using DocuSign. The recruiting team will prepare the letter. Once signed, it is sent to the People Operations Analyst for processing.

Probation Period - Confirmation Letter

Upon joining GitLab some team members (location dependent) will have a probationary period of 3 to 9 months. As per the onboarding process a notification in BambooHR will have been created. Once the manager has confirmed successful completion of the probationary period a confirmation letter is staged for signature and sent to People Operations and the team member to sign.

Current Entities and Co-employers with Probationary Periods:

Contractor Conversions to Employees

As GitLab continues to scale, we sometimes convert all BV Contractors in a country to Employees through a PEO (Professional Employer Organization). This also aligns with GitLab's strategy and growth plans. The People Operations Generalist is responsible for managing the country conversion process, which is typically initiated by a request from the VP of Legal or CFO.

Converting BV Contractors to Employees:

  1. The People Operations Generalist reaches out to existing vendors for rate quotes in the country we are planning to convert.
  2. An addendum with information and rates is then sent to the VP of Legal for review and approval, and if approved a signature is requested from the CFO.
  3. A confidential issue should be created in the the People-OPs General issue tracker with a clear check-list of what the process will involve.
  4. The People Operations Generalist will then complete the "Contractor Conversions" google sheet to calculate all costs, including information about benefits, employer and employee's contribution percentages, mandatory costs, and pricing from the PEO.
  5. Next, the People Operations Generalist will seek approval to proceed from the CFO and VP of legal. Once approved, the People Operations Generalist will inform the People Operations Analyst and Payroll Lead of any upcoming conversions.
  6. All benefits information, contract templates, and any other documentation relating to the location, should be added under the Employee and Contracts Templates and Staging Folder in the shared drive.
  7. Next, an email will be sent, containing the issue and all other information about the conversion, to the team member and their manager, confirming that a conversion in their location will be taking place. A kick-off call can be arranged, on request, but should not halt the conversion process. All questions relating to the converion should be sent to the People Operation Generalist via email.
  8. Complete the onboarding document for the PEO that was selected. These templates are found under the Employee and Contracts Templates and Staging Folder in the shared drive. These should then be sent to the main Account Manager of the relevant PEO that was selected and confirm which local contact should be used for this conversion.
  9. The selected PEO will then reach out to the team member and start the onboarding process.
  10. The People Operations Generalist will complete a Mutual Termination Agreement, found in the same shared drive as listed above. This will need to be signed in accordance with the new selected start date of the team member. These start dates are usually one to two calendar months after the initial conversion email was sent.
  11. The issue should be kept up to date with any questions asked documented in the relevant section of the handbook.
  12. As a final step, Payroll, the internal compensation calculator, and BambooHR will need to be updated with the new status.

Approval for Outside Projects

Before beginning work on outside projects, paid or unpaid, that could potentially impair your ability to perform your obligations to GitLab, you must obtain approval in writing from Manager and further approval from the CEO, CFO or Chief People Officer. To submit approval, email your manager to request approval and once given, please send that email to People Operations with details of the project/activities that you would like to work on. Confirmation will usually be in the form of an email and once received will be filed in the team members record in BambooHR under the Contracts and Changes folder on the Documents Tab. For team members employed in the Netherlands confirmation will be given in the form of a Authorization Letter once signed, this will be filed as outlined above.

For any approved outside activity in which the GitLabber will use his or her GitLab account, outside activity must be stored in a separate, personal project. All other work completed as part of the GitLab employment or contract should be stored in a GitLab namespace with a GitLab copyright.

PIAA Agreements

GitLab strives to help its Contributors maintain the ability to work on projects that are unrelated to GitLab’s business, including other open source projects. Our PIAA does not grant GitLab any rights in any creations that you may make that are not related to GitLab's business or the work you do for GitLab. That is, you are free to develop those creations without requesting approval in advance from GitLab. We have created an amendment to the PIAA agreement which can be view in amendment to PIAA. Please email people operations who will complete and stage the document for signatures. Given that there is necessarily some ambiguity about which projects relate to or don't relate to our business, we have created a process to increase clarity on this issue and encourage outside work by our Contributors. If you're pretty sure that a project you want to work on is unrelated to GitLab's business, but you want GitLab to confirm this ahead of time (or afterwards), you can fill out the Acknowledgement Letter we've provided with a detailed description of the project. GitLab will review your submitted project details, and if we agree that it is not related to our business and does not result from your work for GitLab, we'll sign the letter and return it to you.

Consent Form for GitLab Usability Test

During this usability test I agree to participate in an online session using my computer and telephone. During the session I will be interviewed about the site, asked to find information or complete tasks using the site, asked to complete an online questionnaire about the experience, and I may be video recorded (together, these form the “Materials”).

I understand and consent to the use and release of the Materials by GitLab B.V. (“GitLab”). These materials will likely be made public. I understand that it is the discretion of GitLab to decide whether and how to use the Materials. I relinquish any rights to the Materials and understand the recording may be copied and used by GitLab without further permission. I hereby agree to release, defend, and hold harmless GitLab and its agents or employees, from and against any claims, damages or liability arising from or related to the use of the Materials, including but not limited to libel, defamation, invasion of privacy or right of publicity, infringement of copyright or trademark, misuse, distortion, blurring, alteration, optical illusion or use in composite form, either intentionally or otherwise, that may occur or be produced in taking, processing, reduction or production of the Materials, their publication or distribution.

I have read the above authorization, release, and agreement and I am fully familiar with the contents thereof. This release shall be binding upon me and my heirs, legal representatives, and assigns. I understand that participation is voluntary and I agree to immediately raise any concerns I might have.

If you have any questions after today, please contact {GitLab Contact Person}.

Please sign below to indicate that you have read and understand the information on this form and that any questions you might have about the session have been answered.

Date:{Date}

Please print your name: {Usability Tester Name}

Please sign your name:

Thank you!

We appreciate your participation.