.1Working 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 reached.
.2We 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.
.3Do 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.
.4We create simple software to accomplish complex collaborative tasks.
.7We 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
.1We use our own software to accomplish complex collaborative tasks.
.2We 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."
.3For 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?
.4There 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.
.5Everyone 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.
.6Explicitly note what next action you propose or expect and from whom.
.7Before 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 completed.
.8If 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
.1Develop procedures and templates in a handbook-firstway, 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.
.2When 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.
.3If you fix something for GitLab.com or one of our users, make sure to make that the default (preferred) and radiate the information in the docs. We should run GitLab.com 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.
.4Everything 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
.1Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender, or sexual orientation.
.2Use inclusive language. For example, prefer "Hi everybody" or "Hi people" to "Hi guys".
.3Share problems you run into, ask for help, be forthcoming with information and speak up.
.4Don'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.)
.5You can always refuse to deal with people who treat you badly and get out of situations that make you feel uncomfortable.
.6Everyone 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 repercussions.
.7If 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.
.8Make 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
.1Work out in the open, try to use public issue trackers and repositories when possible.
.2Most things are public unless there is a reason not to. Not public by default are:
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.
.3Share solutions you find and answers you receive with the whole community.
.4If 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
.1Respect 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.
.2If 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.