GitLab General Guidelines

On this page

Overall

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 reached.

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.

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.

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

We use our own software to accomplish complex collaborative tasks.

We take ownership and start by creating a 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."

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?

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.

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.

Explicitly note what next action you propose or expect and from whom.

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 completed.

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

Develop procedures and templates in a 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.

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.

If 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.

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

Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender, or sexual orientation.

Use inclusive language. For example, prefer "Hi everybody" or "Hi people" to "Hi guys". While there are several good guides from folks like 18f, University of Calgary, and Buffer on using inclusive language, we don't keep an exhaustive list. When new possibly non-inclusive words arise, we prefer to be proactive and look for an alternative. If your goal is to be inclusive, it is more effective to make a small adjustment in the vocabulary when some people have a problem with it, rather than making a decision to not change it because some people don’t think it is a problem. And if you make a mistake (e.g., accidentally using the wrong pronoun or an outdated phrase), acknowledge it, apologize gracefully and move on, no need to dwell on it at the moment. After, you can work hard to avoid making that mistake in the future.

Share problems you run into, ask for help, be forthcoming with information and speak up.

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.)

You can always refuse to deal with people who treat you badly and get out of situations that make you feel uncomfortable.

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 repercussions.

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.

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.

Security vulnerabilities are not public since it would allow attackers to compromise GitLab installations. We do make them public after we remediated a vulnerability. Issues that discuss how to improve upon the security posture of an implementation that is working as intended can be made public, and are often labeled as feature proposals. Security implementations that detect malicious activities cannot be made public because doing so would undermine our operations.

Financial information is confidential because we plan to be a public company and as such need to limit both the timing and content of financial information as investors will use and rely on it as they trade in GitLab stock. Examples are things that reveal revenue such as the specific IACV of an opportunity or the total monthly cash inflow/outflow for GitLab.com.

Partnerships with other companies are not public since the partners are frequently not comfortable with that.

Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive.

Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.

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. Try to avoid putting customer information in an issue by describing them instead of naming them and linking to their salesforce account.

Competitive sales and marketing campaign planning is confidential since we want the minize the time the competition has to respond to it.

Customer information is not public since customers are not comfortable with that and it would make it easier for competitors to approach our customers.

When we discuss a customer by name that is not public unless we're sure the customer is OK with that. When we discuss a competitor (for example in a sales call) this can be public as our competitive advantages are public.

Plans for reorganizations are not public and on a need-to-know basis within the organization. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team-members informed whenever possible.

Be transparent

Work out in the open, try to use public issue trackers and repositories when possible.

Share solutions you find and answers you receive with the whole community.

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

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.

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.