Contracts, Background Screenings, Probation Periods & PIAA

Contract Templates

GitLab’s Team Member contract templates are accessible (for reference) within GitLab only (here). The DRI for all GitLab Team Member contracts is the People Connect Team. Any changes to any contracts should be requested to the People Connect Team and will require approval from our Senior Director of Legal, Employment.

Process for Suggesting Changes to the Contract Templates

Contracts are audited and updated on a regular basis. All suggested changes should be added to the current Global Employment Contract Audit issue. If immediate changes are needed to any one of the contract templates, follow the process below:

1. Create a Contract Update Issue - The template can be found here.
2. Open the relevant contract template, which automatically redirects to its original editable Google Doc.
3. If you have editing rights in the doc, change the document view to “Suggesting” mode (top right corner). If you do not have editing rights, you are able to make a comment on the doc or alternatively ping the People Connect Team member for assistance with having the suggestions added to the contract for approval.
4. Any edits that are made will then be made as a suggestion to the contract.
5. Once you have made the required changes, please tag the Senior Manager, People Operations as well as our Director of Legal, Employment to view and approve the relevant changes.
6. Once the changes have been approved, it is important to notify the Candidate Experience Specialist Team to update the contracts in Greenhouse.

No changes or edits should be made to the contracts without the required approval.

The Senior Manager, Global Enablement reviews if all Greenhouse tokens are correct

1. See here for current set of tokens
2. Update tokens on the contract if applicable
3. Review in Greenhouse if all tokens are available (admin access is needed for that):
   • Log in to Greenhouse > click on: Settings (Gear Icon) > Offer Templates > click on: Upload New > Template Name: Country Name (OTE or no OTE) > Make sure All Offices All Departments and All Employment Types are all selected > Upload contract template as .doc file only > Save Template
   • Click on Test > Make sure all tokens have blue checks meaning the tokens are valid
4. If you are updating a contract that is already in use (not for a brand new entity), you need to be sure to delete the old version of the contract out of Greenhouse.
5. Delete the uploaded contract again, if it was just a test and final legal approval is still required

Correcting an error in an issued employment contract

1. If an error is noticed, please make the Associate Manager, Candidate Experience aware.
2. The Associate Manager, Candidate Experience will assign the contract correction to a Candidate Experience Specialist, ideally to the same person, that created the already issued contract.
3. If the change is payroll relevant The Candidate Experience Specialist makes total-rewards@ gitlab.com and uspayroll@ gitlab.com or nonuspayroll@ gitlab.com aware.
4. The Candidate Experience Specialist creates a new corrected contract using above templates and adds the following sentence in: “This agreement is effective {Hire date} and supersedes the employment agreement dated {date of erroneous agreement}.”
   • Make a copy of the template and save it to the working documents folder on Google Drive to edit
5. The Candidate Experience Specialist creates a Cover Letter explaining the reason for the correction.
   • Make a copy of the template and save it to the working documents folder on Google Drive to edit
6. Once the new contract and cover letter have been created, ping a Candidate Experience Specialist for auditing.
7. Send the audited created documents and any additional details on the correction to Legal for review.
8. Once approved by Legal stage the cover letter and new contract in DocuSign and send it for signature first to the Company signatory and subsequently to the team member.
9. Upload the signed documents to the team member’s documents folder in Workday.
10. If applicable, make any necessary updates to the team member’s Workday profile and email Total Rewards total-rewards@ gitlab.com and Payroll uspayroll@ gitlab.com or nonuspayroll@ gitlab.com to notify them of the changes.

Job Change Letter

If a team member changes roles at GitLab and the approval goes through Greenhouse, the process for a Job Change Letter is laid out in the Job Change Letter section on the CES Contract Processes handbook page. If a team member changes roles at GitLab and the approval goes through Workday, the process for a Job Change Letter is laid out in the Job Change Letter section on the Promotions & Transfers handbook page.

For other instances such as a Relocation, the People Connect Team member will create a Relocation letter according to the parameters as listed in the Relocation within the Same Country section on the Relocation handbook page.

Background Screenings

GitLab uses appropriate controls to ensure that its team members, assets, customer relationships, and information are protected. To reduce these risks, GitLab will obtain and review background information of covered prospective, and, as applicable, current team members as allowed by local law.

GitLab currently contracts with Sterling Talent Solutions to provide background screenings. For all candidates being considered for a position at GitLab, an employment history for the last 5 years and/or the three most recent employers will be verified in accordance with applicable local law (if applicable local law limits the review of employment history to fewer years and/or employers, then GitLab follows local law) and screening will be performed against various denied party lists including but not limited to the Office of Foreign Asset Control’s Specially Designated Nationals and Blocked Persons List. In jurisdictions where criminal records may be reviewed, criminal records will be requested. Additional screenings may include, where applicable and in accordance with local law, a search against the U.S. Department of Health and Human Services Office of Inspector General’s List of Excluded Individuals/Entities and/or screening for financial related offenses and credit checks, when relevant to the position. GitLab may use the returned background information to make decisions regarding employment, where allowed by local law. No background screening will be run until a conditional offer has been made, unless local law explicitly requires otherwise.

In the event the background screening is not available on the scheduled hire date due to delays in processing, GitLab will run the background screening as soon as possible. The same adjudication guidelines will apply to current team members as they do with prospective team members. The Senior Background Check Specialist will monitor background screenings for completion and accuracy and will follow up accordingly regarding any concerns or issues.

GitLab does not currently require subsequent background screenings, or re-screenings, for current team members beyond onboarding/pre-hire requirements. Current team members may opt-in for additional background screenings if requested to work with specific customers.

The Candidate Experience Specialists will initiate all background screenings for candidates. The Senior Background Check Specialist will initiate any applicable retroactive background screenings or requested enhanced background screenings for current team members.

Please contact the Senior Background Check Specialist at backgroundchecks@gitlab.com regarding any questions.

Contractors, Contingent Workers, & Temporary Service Providers

Background screenings will be completed or verified for contractors, contingent workers, and/or temporary Service providers when requiring access to orange or red data and/or utilizing a GitLab laptop unless the vendor is an approved sub-processor or has valid Third Party Risk Management review. GitLab will complete these background screenings in accordance with local law and at minimum, criminal record information (or local equivalent) will be required. However, GitLab may also review similar criteria as mentioned above. GitLab will first request proof of completed background screenings from a vendor before completing one internally.

Disclosure and Authorization

Candidates (and, as applicable, current team members) will receive an email to fill out the background screening application. The application will ask for personal and professional information. The application process includes signing disclosure and consent forms which explain the rights of an individual undergoing the background screening. The application process is designed to take less than fifteen minutes to complete.

Candidates should gather each previous employer’s name, address, position title held, employment start and end dates, manager’s name, and contact information. Details for a Human Resources contact can be entered instead of a manager’s contact details. Occasionally, and where permitted by law, Sterling will reach out to the candidate to retrieve additional documentation to act as proof of previous employment. Proof of employment can typically be provided in various ways, such as tax returns (e.g. W2s), pay stubs, LLC documentation, official company registrations, etc. In certain circumstances, the Senior Background Check Specialist may also reach out to candidates and/or team members for additional documentation.

Background screenings will act as an additional mechanism of transparency and will help to build trust with our clients.

Review Criteria for Candidates and Team Members

Reviews of background screenings are conducted by the Senior Background Check Specialist in accordance with the applicable law of the candidate’s jurisdiction. The Senior Background Check Specialist will first review the report for omissions, inaccuracies, and/or discrepancies with employment, including, but not limited to, dates of employment, employer names, and/or positions held. If the report includes discrepancies related to employment, the Senior Background Check Specialist will take the necessary steps to investigate and adjudicate the discrepancies. The Senior Background Check Specialist may escalate the report, as necessary, to the Legal Employment team. Employment decisions based on the employment verification portions of the background screening report shall be finalized before any review of the criminal records information takes place.

If criminal record information has been provided, then it will be adjudicated in accordance with applicable local law. Generally, and subject to local law, criminal records are reviewed to determine if criminal convictions have a direct connection with an applicant’s ability to fulfill the job duty with competence and integrity, while also considering the safety and/or security of GitLab team members, customers, vendors, and/or overall business. Decisions are made that are job related and consistent with business necessity. Arrest records are not considered during the adjudication process, nor is any criminal conviction information that is prohibited from being reviewed by applicable local law.

Probation Period

Upon joining GitLab, some team members (location-dependent, see the below table for detail about each location) will have a probationary period between 1 and 9 months. Common practice is for contracts in each country to have the maximum allowable probationary period. In case of relocation to a different country or change of contract, if a team member has continued service with GitLab (tenure with GitLab has been uninterrupted) and they have already passed the probationary period of their original location or contract, they do not need to go through the probation period of their new location or contract. As per the onboarding process, the probation period status is added to Workday.

The People Connect Team is responsible for managing the probationary period process internally (communication with the team member, their manager, confirmation of probationary period completion, and updating Workday). In some instances, the People Connect Team may also be responsible for managing relationships with legal counsel externally on a global scale to ensure compliance and iteration.

If an exception request is made to end a probation period early, this should be escalated by the team member’s manager to a skip-level and the People Business Partner/Team Member Relations Specialist via email. We will then evaluate the risk, performance and overall reason for the request. Further escalation to Legal might be necessary as well as decision making on how to proceed. There should be no expectation of approval.

Important steps during the Probation Period

For Managers

1. Managers are responsible for monitoring and specifically reviewing performance halfway through the probation period of their direct report.
2. If underperformance is an issue, or there is any hesitation regarding the successful completion of a probation period, this should be discussed immediately with Team Member Relations.
3. 28 days prior to the end of their direct reports’ Probation Period, the manager will receive an email from Workday reminding them that their direct reports’ probation period is coming to an end, and that there is a task in Workday for the manager to submit the outcome of the probation period.
   • Note: For team members located in the Netherlands or Austria, the manager will receive an email from Workday, 14 days prior to the end of the probation period.
4. The Hiring Manager will select the appropriate probation outcome in Workday based on the team member’s performance. A helpful job aid can be found here on this process.

For Team Members

1. If you have successfully passed your probation period, in addition to receiving the good news through your manager, you will also receive a probation period confirmation letter in Workday.
2. In your inbox, you can review this letter and then select Submit. This letter will then be saved in your Workday documents for future reference if needed.

Current Locations With Probationary Periods

Country	Probation Period	Notice during probation	Notice after probation
Australia	6 months	1 week	In accordance with the Fair Work Act 2009 (Cth)
Austria	1 months	No notice	Less than 2 years is 6 weeks notice. 3-5 years is 2 months.6-15 years is 3 months. 16-25 years is 4 months. 25 years and above 5 months.
Austria	1 months	No notice	Less than 2 years is 6 weeks notice. 3-5 years is 2 months.6-15 years is 3 months. 16-25 years is 4 months. 25 years and above 5 months.
Brazil	3 months	No notice, but there are termination costs. Employers must pay team members half of the time remaining until the end of the probation period. (Example: Start date 2020-04-01, termination 2020-06-20, 10 days remaining until meeting 90-day probation period. Payment due for 5 days.)	30 days for less than one year's tenure. This is increased by 3 days per additional year of service up to a maximum of 90 days. (Ex. A team member with 3 years + 2 months of service needs 36 days' notice.)
Canada	3 months (For any team member with a contract issued after April 5th, 2021. For contracts issued prior to April 5th, 2021 a 3-month probation period is not applicable.)		2 weeks
Costa Rica	3 months	No notice	3-6 months, 1 week notice. After 6 months to 1 year, 15 days notice. 1 year onwards, one months notice.
Denmark	3 months	1 month	1 months’ notice until resignation within the first 6 months after commencement of the employment (probation period included), 3 months’ notice until resignation before the end of 3 years’ employment, 4 months’ notice until resignation before the end of 6 years’ employment, 5 months’ notice until resignation before the end of 9 years’ employment, 6 months’ notice until resignation after the end of 9 years’ employment.
France	4 months (or 3 months, depending on the role)	No notice	Except in case of gross misconduct (“faute grave”), wilful misconduct (“faute lourde”) or force majeure, the Party who wishes to terminate the contract must notify the other party by registered letter with acknowledgement of receipt, subject to prior notice as provided by the Collective Bargaining Agreement.
Germany	6 months	2 weeks	4 weeks
Hungary	3 months	No notice	30 Days
India	6 months	1 week	30 days
Ireland	6 months	1 week	1 month
Israel	3 months	If completed less than one working year the entitled to 1 day of advance notice for each of the first 6 months of work, and 2/5 days for each additional month.	30 days
Israel	6 months	1 day per month of work	6 days plus 2.5 days per each additional month up to one year, and 30 days notice thereafter (subject to anything conflicting in an individual employment agreement)
Italy (Papaya Global)	6 months	No notice	Executives: 6 months (less than 4 years of service), 8 months (between 4-10 years of service). All other team members: 60 working days (<5 years of service), 90 working days (between 5-10 years of service), 120 working days (more than 10 years of service).
Italy (Remote Technology)	6 months	No notice	Executives: 6 months (less than 4 years of service), 8 months (between 4-10 years of service). All other team members: 60 working days (<5 years of service), 90 working days (between 5-10 years of service), 120 working days (more than 10 years of service).
Japan	6 months	One week	30 days
Kenya	6 months	7 days	1 month
Kenya	6 months	1 week	1 month
Latvia	3 months	1 month	1 month
Latvia	3 months	3 days	1 month
Luxembourg	6 months	24 days	2 months for less than 5 years service, 4 months for 5-10 years service, and 6 months thereafter
Mexico	3 months	No notice	No notice
Mexico	3 months	No notice	No notice
Netherlands	1 months	1 day	1 month before contract end
New Zealand	6 months
Philippines	6 months	30 days	30 days
Philippines	6 months	30 days	30 days
Singapore	3 months	1 week	1 month
South Africa	6 months	1 week	1 week if the employee has been employed for six months or less. 2 weeks if the employee has been employed for more than six months but less than one year. 4 weeks if an employee has been employed for one year or more.
South Africa	6 months	1 week	1 week if the employee has been employed for six months or less. 4 weeks if the employee has been employed for more than six months but less than one year. 12 weeks if an employee has been employed for one year or more.
Spain	6 months 3-6 months, please check employment agreement for confirmation.	No notice
Sweden	6 months	1 month	The statutory minimum notice is 1 month. If the total period of employment with GitLab is at least 2 and <4 years, 2 months. If the total period of employment with GitLab is at least 4 years and <6 years, 3 months. If the total period of employment with GitLab is at least 6 and <8 years, 4 months. If the total period of employment with GitLab is at least 8 years and <10 years, 5 months. If the total period of employment with GitLab is 10+ years, 6 months.
Switzerland	3 months	2 days (or no notice if there are grounds)	7 days if during months 4-6. 30 days after 6 months of employment. There can be no notice if there are grounds for an immediate offboarding. From the second to the ninth year of employment, two months, from the last day of the month. From the tenth year of employment onwards, three months, from the last day of the month.
United Arab Emirates	6 months	During the probation period only 14 days' notice must be given by the employer; if a worker resigns during probation to move to a new company in the UAE they must give 30 days’ notice. However, if a worker is leaving the UAE then they just need to give 14 days’ notice.	A minimum of 30 days' notice (up to 5 years' service) and a maximum of 90 days' notice (over 10 years' service) can be used. 60 days' notice for between 5 and 10 years' service.
United Arab Emirates	6 months	During the probation period only 14 days notice must be given by the employer; if a worker resigns during probation to move to a new company in the UAE they must give 30 days notice. However, if a worker is leaving the UAE then they just need to give 14 days’ notice.	A minimum of 30 days notice (up to 5 years service) and a maximum of 90 days notice (over 10 years of service) can be used. 60 days notice for between 5 and 10 years of service.
United Kingdom	6 months (For any team member with a contract issued after April 22, 2020. For contracts issued prior to April 22, 2020 a 3-month probation period is applicable.)	1 week	1 month

Locations without Probation Periods

Country	Notice Period
Israel	30 days
South Korea	1 month
Turkey	2 weeks
USA - Federal	2 weeks
USA - Inc	2 weeks

PIAA (Proprietary Information and Assignment Agreement)

GitLab strives to help its team members 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 to 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.

If your employment contract was created prior to November 2017, we have created an amendment to the PIAA agreement which can be viewed here. It amends the 2A section of the PIAA. Please email people-connect@ who will complete and stage the document for signatures. The Amendment will first be signed by the team member and then by the requisite Company signatory.

Outside Employment (Paid or Unpaid), Projects, and Potentially-Conflicting Activities

GitLab recognizes that Rest and Time Off are Productive and encourages our team members to take time to relax and avoid burnout. However, GitLab also understands that, unless an individual employment contract provides otherwise, some team members may want to engage in outside employment (paid or unpaid), projects, and/or potentially-conflicting activities during their non-working hours (collectively referred to here as “outside activities”).

GitLab reminds these team members that their position with GitLab is their primary employment responsibility, and that GitLab positions are considered full-time employment and they require a team member’s full effort and concentration, despite any outside activities.

In order to honor the commitment team members make when they join GitLab, including protecting GitLab’s confidential information, trade secrets, and other business interests while team members are engaged in outside activities, GitLab has adopted the following policies: Outside activities must not interfere with the team member’s work performance or duties; or create an actual or apparent conflict of interest with GitLab. If outside activities lead to a team member’s poor performance, abuse of leave policies, or other negative outcomes relating to their position, GitLab may discipline the team member, up to and including termination. In line with our core value of Transparency, prior to starting outside activities that could potentially interfere with their commitments to GitLab, team members must disclose it to their manager, as noted below. GitLab will not approve outside activities that compromise a team member’s ability to perform their job effectively. Team members engaging in outside activities must comply with GitLab’s Code of Business Conduct and Ethics, as well as all policies related to Conflicts of Interest, Confidentiality, Non-Competition during Employment, and the Protection of Confidential and Proprietary Information, where enforceable by applicable state or local law. Outside activities cannot involve or compete with products or services provided or under development by GitLab. Outside activities also cannot make use of any of GitLab’s proprietary or confidential information, and team members cannot work in any capacity for any of GitLab’s suppliers, customers, or competitors. GitLab’s Internal Acceptable Use Policy permits limited personal use of GitLab-managed assets, subject to any conflicting statements contained in individual employment contracts. Subject to such limited personal use, team members may not use GitLab’s facilities, equipment, supplies, IT systems (such as computers, networks, or email), time, trademarks, brand, or reputation in connection with any outside activities. This policy is not intended to restrict communications or actions protected or required by state, federal or other applicable law.

Approval for Outside Activities

Before beginning outside employment, side projects, or other activities, whether paid or unpaid (collectively referred to as “outside activities”), you must disclose the activity in writing to your Manager, and further escalate as needed. Approval will not be granted if GitLab determines that the proposed outside activity would be a conflict of interest under the Code of Business Conduct and Ethics or if it would compromise a team member’s ability to perform their job effectively. Candidates at a certain stage in the recruiting process will also be asked to disclose outside employment, side projects, or other activities in order for GitLab to determine whether a conflict exists with their ability to perform their obligations to GitLab.

Steps as a current candidate (actively engaged in the hiring process)

1. At the reference stage, the Recruiter will ask the candidate to complete a form that asks them the following: to disclose any outside employment, projects, or activities; and any inventions or side projects that should be listed on the PIAA.
2. If the candidate discloses outside employment, projects, or activities in the completed form, CES will notify the hiring manager for approval and copy in Team Member Relations at teammemberrelations@gitlab.com for visibility and review to ensure consistency in application. Information that will need to be provided to the hiring manager shall include:
   • Name of the outside employment, project, or activity
   • GitLab clients who are involved in the project and scope of involvement (if applicable, please include tech stack used)
   • Estimated time investment per week (in hours)
   • Candidate’s role in the outside employment, project, or activity
3. Approval will follow the process set out for current team members. Any potential conflict of interest must be disclosed to and approved by the Chief Legal Officer in line with the Code of Business Conduct & Ethics.
4. If the candidate entered No or None CES will continue processing the application.

Steps as a current team member

1. Team member check their individual employment contract to ensure they are not prevented from engaging in outside activities.
2. Team member sends their request via email to their direct manager for approval and adds the Team Member Relations team teammemberrelations@gitlab.com in copy for visibility and to ensure consistency in application.

Information needed in the email:

• Project name (links to relevant website if available)
• Goal of the project/organization
• GitLab clients and/or team members who are involved in the project and scope of their involvement. (If applicable, please include tech stack used)
• Estimated time investment per week (in hours)
• Employment status/role in relation to the outside project (if applicable)

1. The manager will ask any additional questions if necessary. A manager may not approve a request for outside projects or activities for a variety of reasons, including team member performance or a provision in an individual employment contract which provides otherwise.
2. If the manager and Team Member Relations approves, they will then confirm this in the thread and add the applicable Director-level leader to the thread, for their review and approval. If the direct manager is also at a Director-level, they will add the next level leader (VP or C-level as appropriate) to the email thread for review and approval.
3. If a decision by the manager and Team Member Relations is made to deny, the manager will relay this to the team member, and then will forward the email thread to the People Connect Team member at people-connect@gitlab.com to be saved in the team member’s Workday Documents folder.
4. If the Director/next-level leader feels additional review and approval is needed, they will then add the next level leader (VP or C-level as appropriate) to the email thread. If this is not deemed necessary, the Director/next-level leader will respond indicating their approval. Note: A minimum of two leaders must review all outside projects up to the E-group leader. If the E-group leader is the next level manager, the E-group leader approval or denial is sufficient. Direct manager and Director-level are the usual levels. If the direct manager is at a Director-level, an additional level must approve or deny.
5. If the next level leader (VP or C-level) and Team Member Relations team feels additional review and guidance is needed, they will add the Senior Director of Legal, Employment and any other relevant leader to the thread. Any potential conflict of interest must be disclosed to and approved by the Chief Legal Officer in line with the Code of Business Conduct & Ethics
6. If a decision is made to approve and all approvals are documented, the People Connect Team member will save the entire thread as a pdf to the team member’s Workday Documents folder.
7. The People Connect Team member will then respond confirming receipt and state that the entire thread has been saved in the team member’s Workday profile.
8. For team members employed in the Netherlands, The People Connect Team member will state the given in the form of the Authorization Letter. This letter must first be sent to the relevant E-group leader for signature, then to the team member. Once signed, this will be saved in the team member’s Workday Documents folder.

For any approved outside activity in which the GitLab team member will use their GitLab account, this activity must be stored in a separate, personal project. All other work completed as part of the work they perform on behalf of GitLab should be stored in a GitLab namespace.

Annual Code of Business Conduct & Ethics Administration Process

Employees are required to review and acknowledge GitLab’s Code of Business Conduct & Ethics (aka “CoBCE”) upon starting employment at GitLab, and annually thereafter, regardless if there are any changes to the code.

The People Connect Team tracks the Code of Business Conduct & Ethics signature completion by new hires during onboarding. The People Compliance team oversees and administers the annual signature process, which is tracked and distributed through Workday. The annual signature process usually launches in April if every year. Process steps include:

1. Legal reviews the most current version of the CoBCE. If any changes are suggested, they are incorporated and a most up-to-date version is created and updated to the Investor Relations section of our handbook.
2. The most current and updated CoBCE is uploaded to Workday and is formatted as to log team member’s acknowledgment of the document, as well as the date it was acknowledged.
3. The People Compliance team crafts communications for the announcement of the process as well as any reminders and escalation. Legal and People leadership will review and approve these communications.
4. The People Compliance team announces to all team members (in Slack and email) that the annual CoBCE signature process is set to launch, and that the process will have a 30-day due date for 100% signature adherence.
5. The People Compliance Team creates the distribution list based on those who have not signed a CoBCE within the last three months prior to sending the new CoBCE.
6. The People Compliance Team launches the CoBCE to all relevant team members from Workday.
7. At two and three weeks post-launch, reminders from Workday are sent to individual team members who have not yet signed.
8. At four weeks post-launch, a final reminder email is sent to individual team members who have not yet signed, cc’ing their managers.
9. The People Compliance team will report weekly on progress and follow the escalation process after the 30 day window closes.

Code of Business Conduct & Ethics Escalation Process

1. At five weeks post-launch, People Compliance will send an escalation notification from Workday to individual team members who have not signed.

2. At six weeks post-launch, individual managers of direct reports who have not signed will receive escalation emails.

3. People Compliance will then follow the additional escalation process as described in the internal People Operations handbook. All communications templates are also found on this same page.

4. All escalation communication for any team member who has still not signed the CoBCE must be saved in the team member’s Workday Documents folder.

5. Team members must be aware that failure to sign the Code of Business Conduct & Ethics may result in consequences up to and including offboarding, due to values misalignment.

Contract Renewals

The below process can be used for the following:

• Fixed term contract to indefinite contract
• Fixed term contract to fixed term contract (after the initial contract expires)
• Contract update for invoice purposes due to individual incorporation of an entity

Note: In most cases this process will apply specifically for team members in the Netherlands.

When creating a new contract, if it is to be for 12 months, that timeframe is always to be written as (for example):

• Jan 1, 2010 to Dec 31, 2010
• Feb 20, 2004 to Feb 19, 2005

When renewing a contract, if it is to be for 12 months, the timeframes are at be seen as (for example):

• First 12-month contract starts on June 14, 2019. That entails that the contract ends on June 13, 2020.
• Second 12-month contract will start on June 14, 2020 and end on June 13, 2021.

1. Add the team member’s contract details to the People Connect Task Tracker under the Contracts tab. On the sheet you will assign the People Connect Team member owner, if you are the owner be sure to note the end date and start the below process 2 months before the end date.
2. Take note of the team members details and reach out to the team members manager via email using the following template.
3. Once you have received confirmation on next steps from the team members line manager, be sure to save the thread under the team member’s profile in Workday in the ‘Approvals - Confidential’ document folder.
4. Using the correct contract template from the templates folder complete with required team member details. These details can be found on the team member’s Workday profile.

• As we would honour the original hire date in terms of GitLab seniority add the following sentence into the contract after the contract start date: “Your continuity of service for statutory purposes begins on the {{Original Hire Date}}.”
• Do not keep the Stock Options line in the Key Terms section, unless additional shares are being given.
• Be sure to write both the Start date and Birth date of the team member in the Month DD, YYYY format to prevent confusion.
• Remove any wording regarding Probation Period if applicable.

1. When you have a completed contract be sure to allow a team member to peer review it for you. This can be done by posting the document link in the connect-ops-team private slack channel. Indicate that you are reviewing it by using the ‘Eyes’ emoji.
2. Once reviewed, stage the contract for signing in Docusign.
3. Ensure that the GitLab signatory is the first to sign, followed by the team member. This can be done by selecting the assign signing order option.
4. When signed by both parties, save the contract to the team member’s Workday Documents folder.
5. Update Workday to reflect the new contract information along with an end date if applicable.
6. Notify the People Connect team so that they may audit any Workday changes.
7. The People Connect Team member updates the People Connect Task Tracker confirming the contract has been completed.

Netherlands Renewal Process

1. Two months before the contract ends, HR Savvy will send an email to the People Connect Team member email address.
2. The People Connect Team member that is in charge of allocating contract renewals will assign a member of the People Connect team to complete the contract renewal process.
3. The People Connect Team member adds the team member’s contract details to the People Connect Task Tracker under the Netherlands Contracts tab.
4. The People Connect Team member will follow this HelpLab Job Aid to request approval from the team member’s manager two months before the team member’s contract ends.
5. GitLab offers one fixed term 12-month contract to start. After the year-long fixed term contract, if the team member is in good standing, they are given an Indefinite Agreement beginning at the team member’s second year with the company. If a team member has been with GitLab for over one year after their first fixed term contract finished due to a relocation, they are given an Indefinite Contract.
6. The Manager has then 2 weeks to evaluate the performance of the team member.

• If satisfied with the performance, the manager informs the People Connect team to extend the contract for an indefinite term.
• If there are performance concerns the manager will discuss the planned course of action with the Team Member Relations Team. The contract may end or get extended for another fixed term. The Team Member Relations Team can help with providing guidance on the messaging.

1. At least 1 month before the end of the contract, the manager informs the team member of the extension or not.
2. If a salary increase is required due to updated visa salary requirements the People Connect Team member requests approvals from the team member’s manager, total rewards and finally the team member’s Division’s E-Group leader.
3. The People Connect Team member uploads the approval to the Workday Documents folder.
4. If the contract extension is approved, the People Connect Team member creates the contract

• As we would honour the original hire date in terms of GitLab seniority add the following sentence into the contract after the contract start date: “Your continuity of service for statutory purposes begins on the {{Original Hire Date}}.”
• Do not keep the Stock Options line in the Key Terms section, unless additional shares are being given.
• Be sure to write both the Start date and Birth date of the team member in the Month DD, YYYY format to prevent confusion.
• Check whether the team member is currently paid the holiday allowance monthly. If yes, confirm with the team member whether we can update to yearly. If the team member agrees to update, ensure to update pay frequency. If no, confirm okay with Legal - Employment and ensure to add correct wording to this effect in new contract. To streamline the process all team members should receive the holiday allowance yearly.
• Remove any wording regarding Probation Period if applicable.
• Note: A second probation period should only be implemented if the team member’s new contract reflects the start of an entirely new role. If the contract is simply a continuation of employment in the current role, a second probation period should not be applied.
• Remove any wording regarding certificate of good conduct, as this was already requested as part of their first Netherlands contract.

1. The People Connect team member stages the contract via Docusign for the GitLab signatory and the team member to sign. Add hr@savvy-group.eu to ‘Receive a copy’ once signed.

• If another temporary contract is issued follow these steps and include the mentioned message when sending the contract via DocuSign

1. The People Connect Team member uploads the signed contract to the team members Workday Documents folder.
2. The People Connect Team member updates Workday to reflect the new contract: Open the team member’s Workday profile > Click on actions > Job Change > add contract. Fill in start and end date, contract type and reason (if applicable)
3. Notify another People Connect Team member so that they may audit any Workday changes.
4. The People Connect Team member updates the People Connect Task Tracker confirming the contract has been completed.

Note: A team member cannot have more than three fixed term contracts with the same employer in a row. If a fourth contract is offered by GitLab then it must be a permanent one.

The Netherlands Contract Best Practices

1. Best practice for team members in the Netherlands is to issue one 1-year Fixed term Contract prior to moving to an indefinite contract. After the completion of the 1-year Fixed term Contracts, we move to the indefinite contract.

2. GitLab is to take into consideration the entire tenure of the team member at time of relocation to determine the type of contract to create. Due to the usual 1-year tenure at GitLab prior to a team member requesting to relocate and immigrate to the Netherlands, if the team member has been at GitLab more than one year, the best practice procedure would be to give the team member an indefinite contract, with approval from their manager.

CXC Contract Renewal

CXC contracts are issued on a yearly basis, with contracts expiring after one year. CXC remains the responsible PEO for ensuring the contract renewal is completed for each team member.

• CXC will make contact with team members 2 weeks before their contracts are due to expire.
• CXC will create renewal contract and send for signing to the relevant team members.
• Once signed, CXC will send the renewed contract to People Connect.
• The People Connect Team member uploads the renewed contract to the team member’s Workday Contracts & Changes folder and updates Workday to reflect the new contract.

Standard practice is to automatically renew CXC contracts. The offboarding process will apply should a team member be terminated voluntarily or involuntarily.

GitLab Inc Best Practices

GitLab, Inc with OTE

• For Relocations, Promotions, and Transfers of current team members be sure to remove the draw information as it is not applicable.