--- layout: handbook-page-toc title: "Contracts" --- ## On this page {:.no_toc .hidden-md .hidden-lg} - TOC {:toc .hidden-md .hidden-lg} ## 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. ## How to create a contract More detailed insructions on our contract and employer agreement processes can be found on the [Completing a Contract](/handbook/contracts/completing-a-contract/) page. ## 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 Total Rewards 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](#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](/handbook/people-group/global-compensation/) page under [Exchange Rates](/handbook/people-group/global-compensation/#exchange-rates). GitLab can pay local currency in the following countries: <%= partial "/includes/contracts/payable_countries" %> ## Amended Contracts The source of truth of all data for a contract or amended contract, should come from an Offer Packet in Greenhouse. This offer packet remains our source of truth of information. Amended contracts must be uploaded to Greenhouse and BambooHR and the People Operations Specialist must be informed. 1. If the old contract was never active, delete the old contract from BambooHR 1. Upload the updated contract in 'Contracts and Changes' folder and also in Greenhouse to ensure this is consistent in both systems 1. Notify the People Operations Specialist of the change in the [GitLab Onboarding Tracker](https://docs.google.com/spreadsheets/d/1L1VFODUpfU249E6OWc7Bumg8ko3NXUDDeCPeNxpE6iE/edit#gid=1721125348) It is essential that the People Operations Specialist is informed of all changes, as they must be updated in BambooHR ## Employee Types at GitLab To ensure the accurate entry of information in BambooHR, we created this table as guidance of what is applicaple in which location. When adding new team member's to BambooHR, please ensure you use this termnology for accurate reporting. | Country | Employee Type | Hiring Partner | PEO (Y/N) | Entity | Pay Frequency | |----------|-------------------------------------|--------|-----------|----------------|---------------| | Australia | Employee | Not applicable| N | GitLab PTY LTD | 12 | | Belgium | Employee | Not applicable| N | GitLab BV | 13.92 | | Brazil | Employee | Safeguard | Y | GitLab BV | 12 | | Canada | Employee | Not applicable | N | GitLab Canada Corp | 26 | | France | Employee-PEO | Safeguard | Y | GitLab BV | 12 | | Germany | Employee | Not applicable | N | GitLab GmbH | 12 | | Hungary | Employee-PEO and Contractor | Safeguard | Y | GitLab BV | 12 | | India | Employee-PEO | Lyra | Y | GitLab BV | 12 | | Ireland | Employee-PEO | Safeguard | Y | GitLab BV | 12 | | Italy | Employee-PEO | Safeguard | Y |GitLab BV | 14 | | Japan | Employee-PEO | Safeguard | Y | GitLab BV | 12 | | Netherlands | Employee | Not applicable | N | GitLab BV | 12.96 | | New Zealand | Employee-PEO and Contractor | CXC | Y | GitLab BV | 12 | | Poland | Contractor-PEO | CXC | Y | GitLab BV | 12 | | Portugal | C2C (Company to Company Contractor) | Not applicable | N | GitLab BV | 12 | | Serbia | C2C (Company to Company Contractor) | Not applicable | N | GitLab BV | 12 | | Spain | Employe-PEO | Safeguard | Y | GitLab BV | 12 | | South Africa | Employee-PEO and Contractor | Safeguard | Y | GitLab BV | 12 | | South Korea | Employee-PEO | Safeguard | Y | GitLab BV | 12 | | Switzerland | Employee-PEO | Safeguard | Y | GitLab BV | 12 | | UK | Employee | Not applicable| N | GitLab LTD | 12 | | Ukraine | Contractor-PEO | CXC | Y | GitLab BV | 12 | | US | Employee | Not applicable | N | GitLab Inc | 24 | | US Federal | Employee | Not applicable | N | GitLab Federal LLC | 24 | | Everywhere else | Contractor | Not applicable | N | GitLab IT BV | 12 | ## Employer of Record Providers There are multiple options for employers of record in the market. This is not the exact list of providers GitLab uses, but is intended to help the wider community when looking for vendors. * Safeguard * CXC * [Elements](https://elementsgs.com/) ## United States Employment Status **[Fair Labor Standards Act](http://www.flsa.com/coverage.html): Exempt v. Nonexempt Employees** * Nonexempt employees are paid hourly and required to track and report all hours worked. If a nonexempt employee works more than 40 hours during a work week, they are entitled to overtime pay. Overtime pay must have prior approval from the manager. Nonexempt employees are required to take two paid ten minute breaks and one unpaid thirty minute lunch break. As a fully distributed company, nonexempt employees are responsible for taking active ownership in ensuring they take the proper breaks. Please make the People Business Partner aware of circumstances where you feel compelled not to do so. * Exempt employees are paid on a salaried basis, do not need to track their hours, and are not eligible for overtime pay. These employees must not spend more than 50% of their time doing nonexempt duties to remain exempt. * For new positions, managers need to ensure the classification of the role is correct before sending an offer letter the candidate. For guidelines on how to determine if a role is exempt or nonexempt, please reference the "Exempt vs Nonexempt Checklist" (which can be found on the google drive, but is only viewable to managers at GitLab). For positions that already exist, please verify the classification with People Ops Analysts. ## 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](https://docs.google.com/document/d/1iyMRutEBnx4m2UBk0V2aaPQVvZi9iP3Kl9WqV8ouy0k/edit), 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. ## Letter of Adjustment When a team member receives any change in compensation and/or title we need to create a [Letter of Adjustment](https://docs.google.com/document/d/1lxx92gGXL6hltRxKn0I6D8a8dHtvFBnElDf7dAlxkkQ/edit) instead of staging an entirely new contract. This document is signed by the Compensation & Benefits Manager, the Director, Global People Operations or the Chief People Officer 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). 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 Candidate Experience Specialist will prepare the letter. Using the Offer through DocuSign - Letter of Adjustment template in Greenhouse the letter is Cc'd to the Total Rewards team for [processing](/handbook/people-group/promotions-transfers/#processing-promotion-or-transfer-changes). Effective dates for a letter of adjustment should be the first (1st) of the month or the sixteenth (16th). Once the document has been signed, the Candidate Experience Specialist hires the individual in GreenHouse (if applicable). Do not export the candidate into BambooHR, as an internal employee their profile is already in the HRIS. The signed letter is uploaded into BambooHR under the Contracts and Changes folder on the Documents Tab by the Total Rewards Analyst. The Total Rewards team team ensures the information in HRIS and Payroll systems is updated. ## Probation Period Upon joining GitLab some team members (location dependent, see the below table for detail about each location) will have a probationary period of 3 to 9 months. As per the [onboarding process](/handbook/general-onboarding/onboarding-processes/#adding-a-new-team-member-to-bamboohr) a notification in BambooHR would have been created. The People Experience Team is responsible for managing the probationary period process internally (communication with the team member, their manager, confirmation of probationary period completion, and updating BambooHR), while the People Operations Team is responsible for managing relationships with legal counsel externlly on a global scale to ensure compliance and iteration. ### Important steps during the Probation Period: 1. Hiring Manager's are responsible for reviewing performance half-way through the probation period. If any under-performance has been found, this should be communicated to the People Group immediately (either via a People Operations Business Partner or by emailing the People Experience Team). 1. Towards the end of the Probation Period, the Hiring manager will receive a notification from BambooHR, mentioning the probation period is coming to an end. The People Experience Associate receives the same notification. 1. The People Experience Associate will log into BambooHR and check who the current manager is, and also check the date this person started reporting to this manager. If it was a very recent change, please include the previous manager in the probation period confirmation email. 1. The People Experience Associate will email the manager to confirm the probation period was successfully completed and cc the `people-exp-ops@gitlab.com` email alias. 1. Once the Manager has confirmed that they are satisfied with their performance, the People Experience Associate will send a [confirmation email](https://docs.google.com/document/d/1JO9a1q3_-VSkzZiMbwhHkMIRvc88XMmg-eG7Aj2SbMo/edit) to the team member to confirm their probation period has been completed. Please cc peopleops@domain and the Manager. 1. The confirmation email from the Manager, should be printed and saved to pdf, and should be saved in BambooHR in the "Contracts & Changes" folder for proof that the probation period was completed. 1. The People Experience Associate will update the team member's status to "Active" under the employee status tab in BambooHR, effective to the date after the probabion period expires. 1. Should their performance not be at a level that their Manager is comfortable with at any time during the probation period, the Manager should reach out to a People Business Partner for further discussion and guidance, right away. 1. If the team member is employeed through one of our PEO's, the People Experience Associate will also need to reach out to the appropriate point of contact for that PEO. That information is listed in the 1Password People Operations Vault. Current Entities and Co-employers with Probationary Periods: | Location | Probation period | Notice during probation | Notice after probation | |--------------|------------------------------------------------------------|-------------------------|---------------------------| | Australia | 6 months | 1 week | 1 month | | Brazil | WIP | | | | China | 3 months | 3 days | | | France | 1 - 3 months dependant on reason for exit | | | | Germany | 6 months | 2 weeks | 4 weeks | | Hungary | 3 months | Immediate effect | | | India | 6 months | 1 week | 30 days | | Ireland | 6 months | 1 week | | | Italy | 6 months for all other employees | Not applicable | Not applicable | | Japan | 1 month | | | | New Zealand | WIP | | | | Netherlands | 1 month | 1 day |1 month before contract end| | Nigeria | 6 months | 2 weeks | | | South Africa | 6 months | 1 week | | | Spain | 6 months for skilled workers, 2 months for â€œotherâ€ workers | | | | UK | 3 months | 1 week | 1 month | | Canada | No probation period | Not applicable | 2 weeks | | USA (Inc) | No probation period | Not applicable | None | | USA (Fed) | No probation period | Not applicable | None | ## Approval for Outside Projects / Activities Before beginning work on outside projects, second jobs, additional work - paid or unpaid, that could potentially impair your ability to perform your obligations to GitLab or could be deemed a conflict of interest, you must obtain approval in writing from your Manager, and further approval from Engineering and/or Product leaders as needed, facilitated by the relevant People Partner for your division and department. This is also required to those at Offer stage who are yet to start their employment with GitLab. ### Steps as a Current Team member 1. Email your manager with details of your project(s) and activity(ies) to request approval. 1. Once approval has been received, please forward the email thread to the relevant [People Business Partner](https://about.gitlab.com/handbook/people-group/#people-business-partner-alignment-to-division) and cc the People Experience team using `people-exp@domain.com`. 1. If the People Business Partner sees no issue or conflict, they will state that they have received the information and approve of its resolution. 1. The People Experience team will then respond to the thread stating that the entire thread will be saved as a pdf and filed in the team member's BambooHR record in the `Contracts and Changes` folder. 1. More complicated requests that seem to show conflits or projects involving a 1099 might require additional legal approval which will be coordinated by the People Business Partner, who may forward the thread to the EVP of Engineering or EVP of Product, or both. Legal may also be added to conversation as needed. 1. Once there is final conclusion, the People Business Partner will relay and coordinate the information with the team member. The People Experience team will save the entire thread as a pdf and filed in the team member's BambooHR record in the `Contracts and Changes` folder. 1. For team members employed in the Netherlands confirmation will be given in the form of a [Authorization Letter](https://docs.google.com/document/d/1sDIRTqZZu46uiX8McOVuyfPKh-26rTDnQ3xBaoWzNjM/edit) once signed, this will be filed as outlined above. For any approved outside activity in which the GitLab team-member 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 viewed in [amendment to PIAA](https://docs.google.com/document/d/1oEfDCIht7Vy6KdcGXWPHZBUXLUUZS9hsvYnOYhQjllg/edit). 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](https://docs.google.com/document/d/1aZJZUUEN_ySueZ8i3ak7Eu21cEYm4a8EZm-xILJGiQM/edit) 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. ## Usability Testing Consent {:#usability-consent} **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.