Commit ca1b1c12 authored by Boris Budini's avatar Boris Budini

Add test files

parent a77b329d
.. note::
**This page was uploaded from GitLab's Handbook**
Everyone at GitLab has a responsibility to prevent and stop harassment.
Working remotely means that the majority of our interactions are by
video call and written communication, such as email or shared documents,
with the exception of team summits, attending conferences together, and
local team meetups. No matter the method of communication, it is
expected that everyone will contribute to an inclusive and collaborative
working environment and respect each other at all times. Should you
become aware of or witness any form of harassment or behavior that
violates this policy or our `company values </handbook/values/>`__,
please report the incident directly to the Chief Culture Officer or
People Operations Generalist immediately for thorough investigation.
GitLab is a Silicon Valley, California based start-up that has grown
into a global fully distributed team. We strive to ensure our team is
fully aligned with Gitlab’s no tolerance harassment policy despite their
location. We want everyone to feel confident and comfortable
communicating concerns. GitLab respects, appreciates, understands and
supports every aspect of diversity. We aim to continuously foster a
globally aware team.
This policy applies to all team members employed by any entity of
GitLab, whether contractor or employee, in all locations. There are
local labor laws in every country and in the case of the United States,
state laws, that must be followed when handling, reporting and
investigating incidents of harassment. The People Operations team and
legal counsel, if required, in each of those countries will be called
upon to ensure compliance and the appropriate legal processes and
procedures are followed. Specific country requirements for employees
(subject to changes in employment law) are listed in the `Country & US
State Specific
Requirements <#country--us-state-specific-requirements>`__ section and
will be updated regularly. All individual contributors, managers, and
leaders will be subject to disciplinary action, up to and including
termination, for any act of harassment they commit.
Types of Harassment
The following are considered forms of harassment and will not be
tolerated by GitLab:
Sexual Harassment
Sexual harassment is considered unwelcome conduct of a sexual nature
that is sufficiently persistent or offensive enough to interfere with
the receiver’s job performance or create an intimidating, hostile or
offensive working environment.
Sexual harassment encompasses a wide range of conduct, examples of
misconduct include, but may not be limited to, the following actions:
1. Physical assaults or the attempt to commit an assault of a sexual
nature. This physical conduct can include touching, pinching,
patting, grabbing, brushing against or poking another team member's
2. Unwelcome sexual advances, propositions or other sexual comments,
such as sexually oriented gestures, noises, remarks, jokes or
comments about a person’s sexuality or sexual experience.
3. Preferential treatment or promises of preferential treatment to a
team member for submitting to sexual conduct, including soliciting or
attempting to solicit any team member to engage in sexual activity
for compensation or reward.
4. Subjecting, or threats of subjecting a team member to unwelcome
sexual attention or conduct or intentionally making performance of
the team member's role more difficult because of that team member's
5. Creating displays, communications, or publications including content
of a sexually offensive nature.
6. Purposely misgendering people, consistently referring to someone as
'he' after repeated requests to call someone a 'she' or vice versa.
Sexual harrassment is considered a form of team member misconduct and
sanctions will be enforced against individuals engaging in sexual
harrassment and against supervisory and managerial personnel who
knowingly allow such behaivor to continue. Any retaliation against an
individual who complain of sexual harrassment or who testify or assist
in any proceeding under the law is unlawful.
Any form of discrimination towards an individual is strictly prohibited.
Types of discrimination may include:
- Age
- Disability
- Race; including color, nationality, ethnic or national origin
- Religious belief or lack of religious belief
- Life expectancy
- Sex
- Sexual orientation
- Transgender status
If you believe you have been discriminated against or witnessed
discriminatory practices, please contact the Chief Culture Officer or
the People Operations Generalist to initiate an investigation into the
Bullying / Workplace Violence
GitLab does not tolerate violent acts or threats of violence. The
company will not tolerate fighting, bullying, coercion or use of abusive
or threatening words directed to, about or against a co-worker, lead,
manager, executive, candidate, client/customer or vendor. No individual
employed by GitLab should commit or threaten to commit any violent act
or discuss committing such offenses, even in a joking manner.
Retaliation of any sort for filing a claim of harassment will not be
tolerated. If you believe you have been retaliated against, please
contact the Chief Culture Officer or the People Operations Generalist to
initiate an investigation.
Speaking up during a public situation
If someone messes up, people are encouraged to speak up publicly and
within the moment, in order to let that person and others know, that
what happened, is not inclusive behaviour.
This makes for a situation from which all parties can learn, and is one
which promotes understanding. Additionally it makes it possible for that
someone to de-escalate the situation by correcting themselves and
This does not ensure there will be no consequences. However, it will
greatly reduce the chance of escalation and has the potential to return
a situation to once again become comfortable and inclusive.
Reporting Alleged Harassment
1. Any individual who believes they have been the target of harassment
of any kind is encouraged to immediately and directly address the
harasser, letting them know that their behavior is unwelcome,
offensive and must stop immediately.
2. If they do not wish to address the harasser directly or the behavior
doesn’t cease, they should report the misconduct to the Chief Culture
Officer or the People Operations Generalist.
3. Once reported, an impartial investigation will be conducted by People
Operations or by an independent third party, depending on the
severity and circumstances of the complaint.
4. Individual(s) reporting an incident or pattern of behavior will be
asked to provide a written account of any action(s) causing concern,
dates and times such actions occurred, and names of anyone involved,
including participants and witnesses. All complaints or concerns of
alleged harassment or discrimination will be taken seriously and
handled confidentially.
The Role of Managers
If managers become aware of misconduct, they must deal expeditiously,
seriously, confidentially and fairly with any allegations, whether or
not there has been a written or formal complaint made to People
Operations. Informed managers are expected to:
1. Take all complaints or concerns of alleged harassment seriously no
matter how minor or who is involved.
2. Ensure that any form of harassment or misconduct is immediately
reported to People Operations.
3. Take appropriate action to prevent retaliation or the alleged
misconduct from recurring during and after an investigation.
Managers who knowingly allow or tolerate any form of harassment or
retaliation, including the failure to immediately report such misconduct
to People Operations, are in violation of this policy and subject to
disciplinary action, including termination.
The Role of Individual Contributors
All employees have the responsibility to help create and maintain a work
environment free of bullying and harassment and can help by:
1. Being aware of how their own behavior may affect others and changing
it if necessary
2. Treating their colleagues with dignity and respect
3. Taking a stand if they think inappropriate jokes or comments are
being made to others
4. Making it clear to others where they find their behavior unacceptable
5. Intervening, if possible, to stop harassment or bullying occurring
6. Reporting promptly to their manager or the People Operations
department any incident of bullying or harassment witnessed by them.
The Role of People Operations
The Chief Culture Officer, People Operations Business Partners, and
People Operations Generalist are responsible for:
1. Ensuring that any individual filing a complaint and any accused
individual(s) is made aware of the seriousness of misconduct.
2. Explaining GitLab's no tolerance harassment policy and investigation
procedures to all individuals included in a complaint.
3. Arranging for an immediate investigation of alleged misconduct and
the preparation of a written report summarizing the results of the
investigation and making recommendations for remediation to
designated company officials.
4. Notifying appropriate authorities (police, FBI, country specific
bureaus) when criminal activities are alleged.
5. Exploring informal means of resolving potential harassment if a
written (formal) complaint is not made when verbal allegations are
Classification of disciplinary action
All individual contributors, managers, and leaders will be subject to
disciplinary action, up to and including termination, for any act of
harassment they commit. Although disciplinary action will be specific to
each case, it can generally be classified into 4 levels:
Level 1
First time occurrences of inappropriate behavior. An act out of
character. After formal investigation coworkers still feel comfortable
working with the delinquent.
- Suspension (Paid/Unpaid based on country)
- Formal apology towards inflicted parties
Level 2
Recurring socially inappropriate behavior.
- Suspension (Paid/Unpaid based on country)
- Mandatory course on Inclusivity
- Formal apology towards inflicted parties
- Written admonition
- Potential transfer to another team
- Potential of termination
Level 3
Major infraction, including retaliation, or recurring socially
inappropriate behavior after a written admonition.
- Termination of contract
Level 4
Serious cases, including any criminal offence.
- Termination of contract
- Reported to the Police/Authorities
Training & Guidance
Training and guidance on understanding, preventing, and dealing with
discrimination & sexual harassment will be provided to both managers and
individual contributors. This training will be given annually or as when
new legal requirements are introduced.
`COM 001 Common Ground: Prevention of Harassment, Sexual Harassment, and
Abusive Conduct in the workplace (2
hrs) <>`__ This training will be
assigned to all managers using `Will Interactive's content and LMS
platform <>`__. Details on how to use the
platform can be found on the `learning and development
page. </handbook/people-operations/learning-and-development/index.html#common-ground-harassment-prevention-for-managers>`__
Once the course has been completed each manager will receive a
certificate of completion which will be kept on their employee record in
Country & US State Specific Requirements
GitLab BV (The Netherlands)
**Complaint Procedure**
If attempts to solve the problem in an informal manner prove
insufficient or if these attempts were refused or proved to be
ineffective, the victim may follow the procedure below.
1. Write a motivated complaint and send it to the Chief Culture Officer
or the People Operations Generalist. In case the Chief Culture
Officer or the People Operations Generalist receives the complaint,
they must immediately handle the written complaint.
2. The Chief Culture Officer or the People Operations Generalist shall
ensure that within a reasonable period of time the complaint is
included in a dated document including the statements of the victim
and any witnesses, as well as the outcome of any mediation.
3. The victim and the witnesses receive a copy of their statement.
4. A copy of the complaint will immediately be handed over to the
responsible person within GitLab.
5. After submission of the complaint to the responsible person within
GitLab, an investigation will be initiated. This investigation may be
conducted by a third party (independent party) depending on the
complaint itself.
6. After the investigation, the conclusion and a proposal for
appropriate measures will be handed over to the responsible person
within GitLab.
7. GitLab will take the appropriate measures.
Without prejudice to the provisions that may arise from a judicial
process instituted by the victim, the person guilty of undesirable
conduct shall impose one or more of the following sanctions:
• A written admonition.
• Transfer to another department.
• Termination of the agreement.
GitLab shall impose, by registered letter and within five working days,
the sanctions imposed upon the person who has been guilty of undesirable
behavior. In case an employee abuses this complaint procedure, the above
sanctions may also apply for the employee.
GitLab BV (Belgium)
**Psychosocial Intervention**
GitLab has engaged with an external health and safety service called
`Mensura <>`__ who are
responsible for handling any complaints received of harassment that can
not be resolved informally and internally. Team members in Belgium may
contact this service if they wish and make a request for an informal or
formal psychosocial intervention. A request for a formal intervention
should include the following:
- a precise description of the constitutive facts of violence or
psychological or sexual harassment at work, according to the
- when and where each of the events took place;
- the identity of the person(s) involved;
- the request to the Employer to take appropriate measures to put an
end to the events.
The psychosocial intervention advisor will investigate further and
provide a report to the employee and People Operations with a
recommended course of action.
GitLab LTD (The UK)
**Complaint Procedure**
1. If the employee does not wish to address the harasser directly or the
behavior does not cease, then the employee (accompanied by a
colleague/union representative if they wish) should report the
misconduct to their line manager or a member of the People Operations
team. Wherever appropriate the line manager and or the People
Operations team may attempt to resolve the situation on an informal
2. If the informal approach does not resolve matters or the situation is
too serious to be dealt with informally, the employee will need to
make a formal complaint to the line manager and/or the People
Operations Team.
3. Once reported, a formal investigation will be conducted impartially
by People Operations or by an independent third party, depending on
the severity and circumstances of the complaint. Individual(s)
reporting an incident or pattern of behavior will be asked to provide
a written account of any action(s) causing concern, dates and times
such actions occurred, and names of anyone involved, including
participants and witnesses. All complaints or concerns of alleged
harassment or discrimination will be taken seriously and handled
promptly, sensitively and confidentially.
4. Wherever possible the Company will try to ensure that the employee
and the alleged harasser are not required to work together whilst the
complaint is being investigated. This may involve the alleged
harasser being suspended or transferred to another work area. In very
serious cases, a criminal offence may have been committed and the
employee may wish to report the matter to the Police/Authorities.
5. Employees will be kept informed of the general progress of the
investigation and the outcome of any disciplinary proceeding.
6. If following investigation, the complaint is upheld, appropriate
disciplinary proceedings will be brought against the alleged harasser
up to and including dismissal for gross misconduct. GitLab will work
to prevent recurrence of the behavior.
7. If following investigation, the complaint is not upheld then the
company will support both the employee and the alleged harasser in
rebuilding their working relationship and may consider making
arrangements to avoid the employee and the alleged harasser working
8. Where the employee is unhappy with the outcome of the formal
investigation, they have the right to appeal against the outcome if
they can demonstrate why they believe a particular aspect of the
investigation has materially affected the outcome. Appeals must be
submitted within 10 working days of receiving the outcome of the
9. People Operations will arrange a meeting to take place with the
appeal chair within a reasonable time period. The appeal chair’s
decision will be final and there is no further right of appeal. The
appeal chair will be independent of the investigation.
California Law Requirements
Every team member located in the state of California will be required to
sign an acknowledgement confirming they have read, reviewed and
understood the following three documents:
- `State requirements
policy <>`__
- `California Law Prohibits Workplace Discrimination &
Harassment <>`__
- `Sexual Harassment & Civil
Remedies <>`__
These will be sent via HelloSign for signature.
We are continuously gathering country specific references to review
regulation and obtain guidance on the management of harassment or
misconduct at work. Here are a few authorities we referred to in the
creation of this policy:
- `Equal Employer Opportunity Commission
(EEOC) <>`__
- `Society of Human Resource Management
(SHRM) <>`__
Further Guidance (Country Specific)
- `UK: Acas (advisory service for employees and
employers) <>`__
- `The Netherlands: Inspectorate SZW <>`__
- `India: Ministry of Labour &
Employment <>`__
- `Belgium: Unia: For equality, against
discrimination <>`__
This diff is collapsed.
.. note::
**This page was uploaded from GitLab's Handbook**
General Guidelines
1. Working at GitLab Inc. is cooperating with the most talented people
you've ever worked with, being the **most productive** you'll ever
be, and creating software that is helping the most people you've ever
2. We recognize that inspiration is perishable, so if you’re
**enthusiastic** about something that generates great results in
relatively little time feel free to work on that.
3. Do what is right for our **customers** and the rest of the GitLab
community, do what is best over the long term, don't be evil.
4. We create **simple** software to accomplish complex collaborative
5. Please read and contribute to our
`**strategy** </company/strategy/>`__.
6. Also see our `handbook usage </handbook/handbook-usage/>`__ and
`leadership guidelines </handbook/leadership/#guidelines>`__.
7. We want to have a great company so if you meet people that are
**better** than yourself try to recruit them to join the company.
Getting things done
1. We **use** our own software to accomplish complex collaborative
2. We take ownership and start by creating an merge request. If you see
something that needs to be improved submit a merge request. Don't
tell someone else about the problem and expect them to start the
merge request. "If you see something don't say something, if you see
something create an MR."
3. For each action or comment, it helps to ask yourself (i) does this
help the company achieve its strategic goals? (ii) is this in the
company's interest, and finally, (iii) how can I contribute to this
effort/issue in a constructive way?
4. There is no need for **consensus**, make sure that you give people
that might have good insights a chance to respond (by /cc'ing them)
but make a call yourself because `consensus doesn't
scale <>`__.
5. Everyone at the company cares about your **output**. Being away from
the keyboard during the workday, doing private browsing or making
personal phone calls is fine and encouraged.
6. Explicitly note what **next action** you propose or expect and from
7. Before **replying** to a request, complete the requested task first.
Otherwise, indicate when you plan to complete it in your response. In
the latter case, always send a message after the task is subsequently
8. If you don't have time to do something let people know when they give
you the tasks instead of having it linger so they can find an
alternative. You can use the text: "I have other priorities and can't
help with this" or "I can complete this on May 25, please let me know
if that is OK".
Write it down
1. {: #handbook-first} Develop procedures and templates in a
**`handbook-first <../handbook-usage/#why-handbook-first>`__** way,
as opposed to migrating content to the handbook later from
Google/Word documents.
- This ensures the handbook is always up-to-date.
- This makes them easier to find and suggest changes to with the
organization and shows our commitment to open collaboration outside
the organization.
- This means discussion and collaboration on this content should happen
in issue comments or merge request comments.
1. When creating any content, create it **web-first**, as opposed to
using Google slides, sheets, docs, etc, because they can only be
found and contributed to by team members, and not by Users,
Customers, Advocates, Google Handbook searches, or Developers.
2. If you fix something for or one of our users, make sure to
make that the default (preferred) and **radiate** the information in
the docs. We should run with the same default settings and
setup our users would also have, if we deviate from it we should add
it to the `settings page for </gitlab-com/settings/>`__.
3. Everything is **always in draft** and subject to change, including
this handbook. So do not delay documenting things and do not include
"draft" in the titles of documents. Ensure everyone can read the
current state. Nothing will ever be finished.
Behavior and language
1. Do **not** make jokes or unfriendly remarks about race, ethnic
origin, skin color, gender, or sexual orientation.
2. Use **inclusive** language. For example, prefer "Hi everybody" or "Hi
people" to "Hi guys".
3. Share problems you run into, ask for help, be forthcoming with
information and **speak up**.
4. Don't display surprise when people say they don't know something, as
it is important that everyone feels comfortable saying "I don't know"
and "I don't understand." (As inspired by
`Recurse <>`__.)
5. You can always **refuse** to deal with people who treat you badly and
get out of situations that make you feel uncomfortable.
6. Everyone can **remind** anyone in the company about these guidelines.
If there is a disagreement about the interpretations, the discussion
can be escalated to more people within the company without
7. If you are unhappy with anything (your duties, your colleague, your
boss, your salary, your location, your computer) please let your
boss, or the CEO, know as soon as you realize it. We want to solve
problems while they are **small**.
8. Make a conscious effort to **recognize** the constraints of others
within the team. For example, sales is hard because you are dependent
on another organization, and Development is hard because you have to
preserve the ability to quickly improve the product in the future.
Be transparent
1. Work out in the **open**, try to use public issue trackers and
repositories when possible.
2. {: #not-public} Most things are **public** unless there is a reason
not to. Not public by default are:
- security vulnerabilities
- financial and legal information
- individual job applications / compensation / feedback since it can
contain negative feedback and `negative feedback is
1-1 </handbook/values/#collaboration>`__ between you and your manager
- partnerships with other companies
- acquisition offers
- customer information in issues: if an issue needs to contain *any*
specific information about a customer, including but not limited to
company name, employee names, number of users, the issue should be
made confidential.
1. Share solutions you find and answers you receive with the **whole
2. If you make a mistake, don't worry, correct it and **proactively**
let the affected party, your team, and the CEO know what happened,
how you corrected it and how, if needed, you changed the process to
prevent future mistakes.
Access to resources
1. Respect the **privacy** of our users and your fellow GitLabbers.
Secure our production data at all times. Only work with production
data when this is needed to perform your job. Looking into production
data for malicious reasons (for example,
`LOVEINT <>`__ or spying on
direct messages of GitLabbers) is a fireable offense.
2. If you need to start a **new repo** or project that is intended to be
maintained over the long term, make sure that you follow the `GitLab
Repo Guidelines </handbook/engineering/#gitlab-repositories>`__.
3. If you need access to GitLab resources, make sure to follow the
`GitLab Access Request
Guidelines </handbook/engineering/#gitlab-access-requests>`__
.. note::
**This page was uploaded from GitLab's Handbook**
History of the handbook
The handbook started when GitLab was a company of just ten people to
make sharing information efficient and easy. We knew that future
GitLabbers wouldn't be able to see emails about process changes that
were being sent before they joined and that most of the people who would
eventually join GitLab likely hadn't even heard of us yet. The handbook
was our way of ensuring that all of our company information was
accessible to everyone regardless of when they became part of the team.
At GitLab our handbook is extensive and keeping it relevant is an
important part of everyone's job. It is a vital part of who we are and
how we communicate. We established these processes because we saw these
1. Reading is much faster than listening.
2. Reading is async, you don't have to interrupt someone or wait for
them to become available.
3. Recruiting is easier if people can see what we stand for and how we
4. Retention is better if people know what they are getting into before
they join.
5. On-boarding is easier if you can find all relevant information
spelled out.
6. Teamwork is easier if you can read how other parts of the company
7. Discussing changes is easier if you can read what the current process
8. Communicating change is easier if you can just point to the diff.
9. Everyone can contribute to it by proposing a change via a merge
Flow structure
1. A (process) problem comes up, frequently in an issue or chat.
2. A proposal is made in a merge request to the handbook.
3. Once merged, the change is announced by linking to the diff in the MR
or commit. Major ones are put in the agenda of the company call.
Medium ones are posted in on the #handbook channel for visibility,
with a one line summary of the change . If there was an issue, close
it out with a link to the diff.
Why handbook first
Documenting in the handbook before taking an action may require more