Principles - Processes - Categorization - GitLab the Product - 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 strive to match 1:1.
Since we are not able to give admin access and do not yet have full feature parity between self-managed instances and GitLab.com, we avoid saying that there is a one to one match between subscription levels and tiers in marketing materials. This has been a source of confusion in the past for customers.
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 Gold for free. Public groups do not get Gold 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).
Keep in mind that the CEO is the DRI for pricing and tiers. This includes any changes that directly impacts how we charge customers under our licensing model, such as a change to how we handle active users. Please review the entirety of the stewardship and pricing pages before making any determinations of which tier a given feature should go in.
Our stewardship principles determine whether something belongs in a paid tier. The likely buyer determines which tier.
When making a decision on the tier for a new feature, please refer to the pricing page for guidance. Be sure to consider documenting your rationale for the decision in the issue description, including a reference to our stewardship page when appropriate.
Please indicate the applicable tier for an issue by applying the label associated with the tier (e.g. GitLab Core, GitLab Starter) and the
Enterprise Edition label for features targeting a paid tier. Ensure this is defined before feature development begins.
Should you have any questions when making this decision, do not hesitate to collaborate with your manager, product leadership, or the CEO in the issue for clarification.
To propose bringing a feature to a lower tier or making a change that impacts how we charge customers, please follow the process on the CEO pricing page.
All Starter, Premium, and Ultimate features must:
Occasionally we need to test large, complex features before we are confident that we'll be able to scale, support and maintain them as they are. In this case we have the option to release them as Alpha or Beta versions.
In general, we should avoid releasing Alpha or Beta versions of features. A minimal viable change should be viable and therefore should not need a pre-release. That said, if there is a situation where we have no valid alternative, the definitions of each stage is below.
It's never acceptable to make changes that risk any damage to existing production data accessed by our users.
Similar to Beta, but only available to selected users.
Passed the Production Readiness Review for GitLab.com, which means that it is:
Deprecating features follows a particular pattern.
Use the language Deprecated or Removed to specify the state
of a feature that is going to be or is removed.
Features that are deprecated or removed should be:
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:
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).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 and maybe adding one more.
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.
In pursuit of our product vision of becoming a complete platform for the entire DevOps lifecycle, delivered as a single application, GitLab will inevitably compete for user and business with other DevOps tools technologies and vendors. For clarity, GitLab publicly competes with other vendors only in categories where our product is lovable (in our maturity model). We may at times name these competitors publicly.
For all other categories, GitLab will highlight examples of tools that have functionally similar features to the features GitLab is developing, but we will not name them as explicit competitors. This does not mean that we will not be trying to acquire users or business based on those categories, but it does mean that we will not refer to those other vendors as 'competitors', as our goal is to pursue our product vision (not to specifically win against other tools or vendors where we are not yet lovable).
