Commit ca1b1c12 authored by Boris Budini's avatar Boris Budini

Add test files

parent a77b329d
This diff is collapsed.
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>`__
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment