Principles - Processes - Categorization - GitLab the Product - PM Responsibilities - Being a PM - Performance Indicators - Leadership
We believe that a single application for the DevOps lifecycle based on convention over configuration offers a superior user experience. The advantage can be quoted from the Wikipedia page for convention over configuration: "decrease the number of decisions that developers need to make, gaining simplicity, and not necessarily losing flexibility". In GitLab you only have to specify unconventional aspects of your workflow. The happy path is frictionless from planning to monitoring.
We're doubling down on our product for concurrent DevOps which brings the entire lifecycle into one application and lets everyone contribute. We are leaning into what our customers have told us they love: our single application strategy, our pace of iteration, and our deep focus on users.
Consider opportunities to take advantage of this unique attribute in early iterations. Integrating features with different parts of the application can increase the adoption of early iterations. Other advantages:
Although not every feature needs to be integrated with other parts of the application, you should consider if there are unique or powerful benefits for integrating the feature more deeply in the second or third iteration.
GitLab.com runs GitLab Enterprise Edition.
To keep our code easy to maintain and to make sure everyone reaps the benefits of all our efforts, we will not separate GitLab.com codebase from the Enterprise Edition codebase.
To avoid complexity, GitLab.com tiers and GitLab self-managed tiers are named the same.
GitLab.com subscriptions work on a namespace basis, which can mean:
JaneDoe/*gitlab-org/This means that group-level features are only available on the group namespace.
Public projects get Ultimate for free. Public groups do not get Ultimate for free. Because:
Admittedly, this is complex and can be confusing for product managers when implementing features. Ideas to simplify this are welcome (but note that making personal namespaces equal to groups is not one of them, as that introduces other issues).
For more guidance on feature tiers and pricing, visit tiering guidance for features
There are cases where we need to test features before we are confident that we'll be able to scale, support, and maintain the features in their current form for every designed use case. There are also scenarios where a feature is not complete enough to be considered an MVC. In these cases, we have the option to release features as Experiment, Beta, or Limited Availability, and users can opt-in and test the new experience. Features might not be fully documented or supported in the Experiment or Beta phases.
Please note that some features may not be aligned to these recommendations if they were developed before the recommendations were in place or if the group determined an alternative implementation approach was needed.
It's never acceptable to make changes that:
introduces friction into high MAU areas.
Please refer to Support for Experiment, Beta, Limited Availability, and Generally Available Features for a detailed list of the characteristics of Experiment, Beta, LA, and GA features, including when feature flags should be used.
To ensure the phases before General Availability are as short as possible each phase of Experiment, Beta and LA should include exit criteria. This encourages rapid iteration and reduces cycle time. Exit criteria may include but are not be limited to:
A breaking change is defined as a non-backward compatible change that:
A breaking change may occur when you intentionally plan to change or remove functionality. Breaking changes can sometimes result from the addition of new features. It is the responsibility of the PM and EM for a category to carefully consider the risk and impact of introducing a breaking change as they can cause severe disruption to users.
If you are introducing a breaking change, you must notify the user community and users through a deprecation notice in the monthly release post as soon as possible. Follow the process outlined below for deprecations and removals.
With a few exceptions, if the answer is yes to any of the following questions, the change is to be considered a breaking change and should only be introduced in a major version.
Deprecating and removing a feature needs to follow a specific process because it is important that we minimize disruption for our users. As you move through the process, use the language deprecated or removed to specify the current state of the feature that is going to be or has been removed.
Note - some deprecations or removals do not result in a breaking change. So in your deprecation or removal notice, you need to be explicit about the following:
As soon as possible, but no later than the third milestone preceding intended removal:
For example, if the intended removal milestone is 16.0, given the following release schedule: 15.9, 15.10, 15.11, 16.0, then 15.9 is the third milestone preceding intended removal.
If you believe you need to push a breaking change outside a major release, tag your manager into the deprecation issue for approval. Upon manager approval, tag in Delivery group PM @swiskow into the deprecation issue for advisement/collaboration on whether any additional communication to users is required. Communicating to SaaS users on breaking changes is critical, it is recommended you set up a broadcast message one milestone ahead of the milestone in which the breaking change will happen.
Milestone of Removal:
Important Notes
Our CI syntax keeps evolving. We cannot support all keywords indefinitely, so deprecating and removing keywords is inevitable.
GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the deprecating and removing features process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.
Deprecation notice - Syntax removal introduces a breaking change, as outlined in our deprecation process, we must notify the community and customers, which means including a deprecation notice in the monthly release post.
Track keyword usage - Tracking keyword usage should begin as early as possible. It is a mandatory step that helps estimate the user impact, timing, and needed effort. The more users use the keyword, the more time it takes to remove it (It took more than four years to move from remove to deprecation for 'type' keyword).
In-app warning - Provide our users with an in-app notification that we plan to remove a keyword they use in their pipeline. Our customers will get a notification in each run of the pipeline that uses the deprecated keyword. The warning will be printed:
This step is optional if the keyword usage is relatively low (Recommend minimal reach of ~5% impacted users).
Keyword removal - The keyword will be removed from our code and schema and should happen in a major version. Once removed, using the keyword will result in a lint error.
Naming new features or renaming existing features is notoriously hard and sensitive to many opinions.
The bar for renaming existing features is extremely high, especially for long-time features with a lot of usage. Some valid but not exclusive reasons are:
When renaming features follow the process to rename a category starting with an MR to change the name in data/features.yml. Request review by the Product Director and Engineering Director of your Section for approval. Optionally, add a comment including your technical writer, engineering manager, product design manager, and product designer for transparency.
When renaming a feature other items to consider are updates to documentation, blogs, direction pages and competitive information.
What's New is a feature that is part of GitLab.com and Self-managed GitLab that is used to communicate highlights from each release. After each major release, a yaml file is published that contains 3-10 highlights from the release along with links to the relevant documentation to get started using them.
A small notification dot appears above the "?" icon, and when users click on "What's new" in the menu, a drawer containing the updates slides into view.
The goal of What's New is to make it easy for users to be aware of the most important changes in GitLab so we can help them stay up-to-date on all of our changes and feature updates.
Use this section as guidance for using existing features and developing new ones.
/admin. Outside of that, admins are the same as the highest possible permission (owner)./admin, group settings, and project settings. Auditor has read-only access to all other areas.To keep the permissions system clear and consistent we should improve our roles to match common flows instead of introducing more and more permission configurations on each resource, if at all possible.
For big instances with many users, having one role for creating projects, doing code review and managing teams may be insufficient. So, in the long term, we want our permission system to explicitly cover the next roles:
All the above can be achieved by iteratively improving existing roles.
You can now find our security paradigm on the Secure Strategy page.
Also see our Secure Team engineering handbook.
Traditionally, applications only reveal valuable information about usage and performance to administrators. However, most GitLab instances only have a handful of admins and they might not sign in very often. This means interesting data is rarely seen, even though it can help to motivate teams to learn from other teams, identify issues or simply make people in the organisation aware of adoption.
To this end, performance data and usage statistics should be available to all users by default. It's equally important that this can be optionally restricted to admins-only, as laws in some countries require this, such as Germany.
GitLab is developed in English, but supports the contribution of other languages.
GitLab will always default to English. We will not infer the language / location / nationality of the user and change the language based on that. You can't safely infer user preferences from their system settings either. Technical users are used to this, usually writing software in English, even though their language in the office is different.
Fast applications are better applications. Everything from the core user experience, to building integrations and using the API is better if every query is quick, and every page loads fast. When you're building new features, performance has to be top of mind.
We must strive to make every single page fast. That means it's not acceptable for new pages to add to performance debt. When they ship, they should be fast.
You must account for all cases, from someone with a single object, to thousands of objects.
Read the handbook page relating to performance of GitLab.com, and note the Speed Index target shown there (read it thoroughly if you need a detailed overview of performance). Then:
You must prioritize improvements according to their impact (per the availability & performance priority labels). Pages that are visited often should be prioritized over pages that rarely have any visitors. However, if page load time approaches 4 seconds or more, they are considered no longer usable and should be fixed at the earliest opportunity.
In addition, to meet the ethical criteria of GNU, all our JavaScript code on GitLab.com has to be free as in freedom. Read more about this on GNU's website.
The ability to monitor, visualize and improve upon cycle time (or: time to value) is fundamental to GitLab's product. A shorter cycle time will allow you to:
When we're adding new capabilities to GitLab, we tend to focus on things that will reduce the cycle time for our customers. This is why we choose convention over configuration and why we focus on automating the entire software development lifecycle.
All friction of setting up a new project and building the pipeline of tools you need to ship any kind of software should disappear when using GitLab.
We understand that not everyone will use GitLab for everything all the time, especially when first adopting GitLab. We want you to use more of GitLab because you love that part of GitLab. GitLab plays well with others, even when you use only one part of GitLab it should be a great experience.
GitLab ships with built-in integrations to many popular applications. We aspire to have the world's best integrations for Slack, JIRA, and Jenkins.
Many other applications integrate with GitLab, and we are open to adding new integrations to our technology partners page. New integrations with GitLab can vary in richness and complexity; from a simple webhook, and all the way to a Project Service.
GitLab welcomes and supports new integrations to be created to extend collaborations with other products. GitLab plays well with others by providing APIs for nearly anything you can do within GitLab. GitLab can be a provider of authentication for external applications.
There is some natural tension between GitLab being a single-application for the entire DevOps lifecycle, and our support for better user experience via integration with existing DevOps tools. We'll prioritize first our efforts to improve the single-application experience, second to enable a rich ecosystem of partners, and third to improve integration with the broader ecosystem to other tools. GitLab is open-source so this should not prohibit contributors adding integrations for anything that they are missing - as long as it fits with GitLab product vision.
If you don't have time to contribute and are a customer we'll gladly work with you to design the API addition or integration you need.