Product sections, stages, groups, and categories
Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership
Interfaces
We want intuitive interfaces both within the company and with the wider
community. This makes it more efficient for everyone to contribute or to get
a question answered. Therefore, the following interfaces are based on the
product categories defined on this page:
Hierarchy
The categories form a hierarchy:
- Sections: Are a collection of stages. We attempt to align these logically along common workflows like Dev, Sec and Ops.
Sections are maintained in
data/sections.yml.
- Stages: are maintained in
data/stages.yml.
Each stage has a corresponding devops::<stage> label under the gitlab-org group.
- Group: A stage has one or more groups.
Groups are maintained in
data/stages.yml.
Each group has a corresponding group::<group> label under the gitlab-org group.
- Categories: A group has one or more categories. Categories are high-level
capabilities that may be a standalone product at another company. e.g.
Portfolio Management. To the extent possible we should map categories to
vendor categories defined by analysts.
There are a maximum of 8 high-level categories per stage to ensure we can
display this on our website and pitch deck.
(Categories that do not show up on marketing pages
show up here in italics and do not count toward this limit.) There may need
to be fewer categories, or shorter category names, if the aggregate number of
lines when rendered would exceed 13 lines, when accounting for category names
to word-wrap, which occurs at approximately 15 characters.
Categories are maintained in
data/categories.yml.
Each category has a corresponding Category:<Category> label under the gitlab-org group. Category maturity is managed in the product Category Maturity Change process
- Features: Small, discrete functionalities. e.g. Issue weights. Some
common features are listed within parentheses to facilitate finding
responsible PMs by keyword.
Features are maintained in
data/features.yml.
It’s recommended to associate feature labels to a category or a group with feature_labels in data/categories.yml or data/stages.yml.
Notes:
- Groups may have scope as large as all categories in a stage, or as small as a single category within a stage, but most will form part of a stage and have a few categories in them.
- Stage, group, category, and feature labels are used by the automated triage
operation “Stage and group labels inference from category labels”.
- We don’t move categories based on capacity. We put the categories in the stages where they logically fit, from a customer perspective. If something is important and the right group doesn’t have capacity for it, we adjust the hiring plan for that group, or do global optimizations to get there faster.
- We don’t have silos. If one group needs something in a category that is owned by another group, go ahead and contribute it.
- This hierarchy includes both paid and unpaid features.
Naming
Anytime one hierarchy level’s scope is the same as the one above or below it, they can share the same name.
For groups that have two or more categories, but not all categories in a stage, the group name must be a unique word or a summation of the categories they cover.
If you want to refer to a group in context of their stage you can write that as “Stage:Group”. This can be useful in email signatures, job titles, and other communications. E.g. “Monitor:Health” rather than “Monitor Health” or “Monitor, Health.”
When naming a new stage, group, or category, you should search the handbook and main marketing website to look for other naming conflicts which could confuse customers or employees. Uniqueness is preferred if possible to help drive clarity and reduce confusion. See additional product feature naming guidelines as well.
More Details
Every category listed on this page must have a link to a direction page. Categories may also have documentation and marketing page links. When linking to a category using the category name as the anchor text (e.g. from the chart on the homepage) you should use the URLs in the following hierarchy:
Marketing product page > docs page > direction page
E.g Link the marketing page. If there’s no marketing page, link to the docs. If there’s no docs, link to the direction page.
Solutions
Solutions can consist of multiple categories and are typically used to align to a customer challenge (e.g. the need to reduce security and compliance risk) or to market segments defined by analysts such as Software Composition Analysis (SCA). Solutions are also often used to align to challenges unique to an industry vertical (e.g. financial services), or to a sales segment (e.g. SMB vs Enterprise).
Solutions typically represent a customer challenge, and we define how GitLab capabilities come together to meet that challenge, with business benefits of using our solution.
Market segments defined by analysts don’t always align to GitLab stages and categories and often include multiple categories. Two most frequently encountered are:
- Software Composition Analysis (SCA) = Dependency Scanning + License Compliance + Container Scanning
- Enterprise Agile Planning (EAP) = Team Planning + Planning Analytics + Portfolio Management + Requirements Management
We are intentional in not defining SCA as containing SAST and Code Quality despite some analysts using the term to also include those categories.
Capabilities
Capabilities can refer to stages, categories, or features, but not solutions.
Layers
Adding more layers to the hierarchy would give it more fidelity but would hurt
usability in the following ways:
- Harder to keep the interfaces up to date.
- Harder to automatically update things.
- Harder to train and test people.
- Harder to display more levels.
- Harder to reason, falsify, and talk about it.
- Harder to define what level something should be in.
- Harder to keep this page up to date.
We use this hierarchy to express our organizational structure within the Product and Engineering organizations.
Doing so serves the goals of:
- Making our groups externally recognizable as part of the DevOps lifecycle so that stakeholders can easily understand what teams might perform certain work
- Ensuring that internally we keep groups to a reasonable number of stable counterparts
As a result, it is considered an anti-pattern to how we’ve organized for categories to move between groups out
of concern for available capacity.
When designing the hierarchy, the number of sections should be kept small
and only grow as the company needs to re-organize for span-of-control
reasons. i.e. each section corresponds to a Director of Engineering and a
Director of Product, so it’s an expensive add. For stages, the DevOps loop
stages should not be changed at all, as they’re determined from an external
source. At some point we may
change to a different established bucketing, or create our own, but that will
involve a serious cross-functional conversation. While the additional value
stages are our own construct, the loop and value stages combined are the primary
stages we talk about in our marketing, sales, etc. and they shouldn’t be changed
lightly. The other stages have more flexibility as they’re not currently
marketed in any way, however we should still strive to keep them as minimal as
possible. Proliferation of a large number of stages makes the product surface
area harder to reason about and communicate if/when we decide to market that
surface area. As such, they’re tied 1:1 with sections so they’re the
minimal number of stages that fit within our organizational structure. e.g.
Growth was a single group under Enablement until we decided to add a Director
layer for Growth; then it was promoted to a section with specialized
groups under it. The various buckets under each of the non-DevOps stages are
captured as different groups. Groups are also a non-marketing construct, so we
expand the number of groups as needed for organizational purposes. Each group
usually corresponds to a backend engineering manager and a product manager, so
it’s also an expensive add and we don’t create groups just for a cleaner
hierarchy; it has to be justified from a span-of-control
perspective or limits to what one product manager can handle.
Category Statuses
Categories can have varying level of investment and development work. There are four main investment statuses:
- Accelerated - Top category for product strategy that has received additional investment in the next year
- Sustained - Categories where new features will be added in the next year
- Reduced - Categories where scope and ambition is decreased although, new features will still be added in the next year
- Maintenance - Categories where no new features will added
Typically, product direction pages will transparently state the investment status of the category for the fiscal year based on annual product themes and investment levels.
Changes
The impact of changes to sections, stages and groups is felt across the company.
All new category creation needs to be specifically approved via our Opportunity Canvas review process. This is to avoid scope creep and breadth at the expense of depth and user experience.
Merge requests with
changes to sections, stages and groups and significant changes to categories
need to be created, approved, and/or merged by each of the below:
- Chief Product Officer
- PLT Leader relevant to the affected Section(s)
- The Director of Product relevant to the affected Section(s)
- The Director of Engineering relevant to the affected Section(s)
- Director of Product Design
_Note: Chief Product Officer approval should be requested once all other approvals have been completed. To request approval, post the MR link in the #chief-product-officer channel tagging both the Chief Product Offcer and cc’ing the EBA to the Chief Product Officer.
The following people need to be on the merge request so they stay informed:
- Chief Technology Officer
- Development Leader relevant to the affected Section(s)
- VP of Infrastructure & Quality Engineering
- VP of UX
- Director, Technical Writing
- Engineering Productivity (by @ mentioning
@gl-quality/eng-prod)
- The Product Marketing Manager relevant to the stage group(s)
After approval and prior to merging, ping the Engineering Manager for Quality Engineering in the MR, if there are changes that:
- Add a new category, group, stage or section
- Move an existing category to a new or existing group
- Move an existing group to a new or existing stage
- Move an existing stage to a new or existing section
- Rename a group, stage or section
- Delete a group, stage or section
This is to ensure that GitLab Bot auto-labeling can be updated prior to the change, which can be disruptive if missed.
Upon approval, tag the group Technical Writer in the merge request to ensure documentation metadata is updated after the category change is merged.
Ensure that relevant slack channels are updated following our slack channel naming convention, open an access request to have slack channel names updated as they can no longer be updated by creators.
Examples
Because it helps to be specific about what is a significant change and what should trigger the above
approval process, below are non-exhaustive lists of examples that would and would not, respectively, require full approvals as outlined above.
Changes that require the above approvers include:
- Changes to a section, stage, group, or category name or
marketing attribute
- Removal or addition of a section, stage, group, or category
Changes that require approval only from the relevant Product Leadership Team member include:
- Changing name or removing a non-marketing category, per the
marketing attribute.
Changes that require approval only from the relevant Product Director include:
- Changing a category maturity date
- Changes to section or group member lists
- Changes to a category vision page
Changing group name
When changing the name of a group, create a merge request to change the group name in data/stages.yml
using the Group-Stage-Category-Change template,
and make sure to complete all the steps in the template.
Changing category name
When changing an existing category name, there are some considerations to the order of events:
- First, create a MR to change the name in
data/stages.yml and spec/homepage/category_spec.rb.
- Get sign off from all required stakeholders listed in the instructions above.
- Merge the name change MR.
- Tag the category’s technical writer so that they can update the documentation metadata
- Re-name the category direction page with a new MR. Search for the old category name on the category direction page to ensure the name has been updated in all places.
- Use the
#it-help Slack channel to request an update to Slack channel name for the re-named category
Changing category maturity
We primarily use the Category Maturity Scorecard process to determine category maturity.
Typically, category maturity moves up from planned to minimal to viable to complete to lovable. However, maturity can also be downgraded. For example, in cases where we discover a JTBD is not met (see example), or when we change the definition of maturity, we may choose to move category maturity down.
When downgrading product maturity, we adjust our customer’s current expectations about our product. This is particularly impactful to our go-to-market team members in customer success and product marketing. We need to do the following to enable alignment between all affected and interested parties:
- Raise an MR for the downgrade and clearly state the reasons for change in the description (see example)
- Inform VP, Product Management by adding them as Reviewer on the MR
- Notify the product group counterparts in the MR; Product Marketing, Product Designer, Engineering Manager, and Technical Writer
- Post the MR in the #customer-success slack channel prior to merging, to allow the team to assess impact and adjust
- Post the MR in the #product slack channel for awareness
DevOps Stages
Analytics section
graph TD;
analytics[Analytics section]-->s_monitor[Monitor stage];
s_monitor-->g_analytics_instrumentation["Analytics Instrumentation
group"];
click g_analytics_instrumentation "/handbook/<no value>";
s_monitor-->g_platform_insights["Platform Insights
group"];
click g_platform_insights "/handbook/<no value>";
Click on a group name to see more details.
Monitor stage
Analytics Instrumentation group
|
Backend |
| Development Totals |
7 |
CD section
graph TD;
cd[CD section]-->s_deploy[Deploy stage];
s_deploy-->g_environments["Environments
group"];
click g_environments "/handbook/product/categories/#environments-group";
Click on a group name to see more details.
Deploy stage
Environments group
|
Backend |
Frontend |
| Development Totals |
4 |
2 |
CI section
graph TD;
ci[CI section]-->s_package[Package stage];
s_package-->g_container_registry["Container Registry
group"];
click g_container_registry "/handbook/product/categories/#package-group";
s_package-->g_package_registry["Package Registry
group"];
click g_package_registry "/handbook/product/categories/#package-group";
ci[CI section]-->s_verify[Verify stage];
s_verify-->g_ci_platform["CI Platform
group"];
click g_ci_platform "/handbook/<no value>";
s_verify-->g_hosted_runners["Hosted Runners
group"];
click g_hosted_runners "/handbook/product/categories/#hosted-runners";
s_verify-->g_pipeline_authoring["Pipeline Authoring
group"];
click g_pipeline_authoring "/handbook/product/categories/#pipeline-authoring-group";
s_verify-->g_pipeline_execution["Pipeline Execution
group"];
click g_pipeline_execution "/handbook/product/product-categories/#pipeline-execution-group";
s_verify-->g_runner["Runner
group"];
click g_runner "/handbook/product/categories/#runner-group";
Click on a group name to see more details.
Package stage
Container Registry group
|
Backend |
Frontend |
| Development Totals |
6 |
1 |
Package Registry group
|
Backend |
Frontend |
| Development Totals |
4 |
1 |
Verify stage
|
Backend |
| Development Totals |
3 |
| Name |
Maturity |
Links |
| Continuous Integration (CI) Scaling |
Viable |
Direction Page
|
Hosted Runners group
Pipeline Authoring group
|
Backend |
Frontend |
| Development Totals |
5 |
1 |
Pipeline Execution group
|
Backend |
Frontend |
| Development Totals |
6 |
2 |
Runner group
|
Backend |
| Development Totals |
12 |
graph TD;
core_platform[Core Platform section]-->s_foundations[Foundations stage];
s_foundations-->g_design_system["Design System
group"];
click g_design_system "/handbook/product/categories/#design_system-group";
s_foundations-->g_global_search["Global Search
group"];
click g_global_search "/handbook/product/categories/#global-search-group";
s_foundations-->g_import_and_integrate["Import and Integrate
group"];
click g_import_and_integrate "/handbook/product/categories/#import_and_integrate-group";
s_foundations-->g_personal_productivity["Personal Productivity
group"];
click g_personal_productivity "/handbook/product/categories/#personal_productivity-group";
s_foundations-->g_ux_paper_cuts["UX Paper Cuts
group"];
click g_ux_paper_cuts "/handbook/product/categories/#ux_paper_cuts-group";
core_platform[Core Platform section]-->s_systems[Systems stage];
s_systems-->g_cloud_connector["Cloud Connector
group"];
click g_cloud_connector "/handbook/product/categories/#cloud-connector-group";
s_systems-->g_distribution_build["Distribution::Build
group"];
click g_distribution_build "/handbook/product/categories/#distribution-group";
s_systems-->g_distribution_deploy["Distribution::Deploy
group"];
click g_distribution_deploy "/handbook/product/categories/#distribution-group";
Click on a group name to see more details.
Foundations stage
Design System group
|
Frontend |
| Development Totals |
4 |
Global Search group
|
Backend |
Frontend |
| Development Totals |
8 |
1 |
Import and Integrate group
|
Backend |
Frontend |
| Development Totals |
7 |
2 |
Personal Productivity group
|
Frontend |
| Development Totals |
3 |
UX Paper Cuts group
Systems stage
Cloud Connector group
|
Backend |
| Development Totals |
4 |
Distribution::Build group
|
Backend |
| Development Totals |
8 |
Distribution::Deploy group
|
Backend |
| Development Totals |
7 |
Data Science section
graph TD;
data-science[Data Science section]-->s_ai-powered[AI-powered stage];
s_ai-powered-->g_ai_framework["AI Framework
group"];
click g_ai_framework "/handbook/product/categories/#ai-framework-group";
s_ai-powered-->g_ai_model_validation["AI Model Validation
group"];
click g_ai_model_validation "/handbook/product/categories/#ai-model-validation-group";
s_ai-powered-->g_custom_models["Custom Models
group"];
click g_custom_models "/handbook/product/categories/#custom-models-group";
s_ai-powered-->g_duo_chat["Duo Chat
group"];
click g_duo_chat "/handbook/product/categories/#duo-chat-group";
s_ai-powered-->g_duo_workflow["Duo Workflow
group"];
click g_duo_workflow "/handbook/product/categories/#duo-workflow";
data-science[Data Science section]-->s_modelops[ModelOps stage];
s_modelops-->g_dataops["DataOps
group"];
click g_dataops "/handbook/product/categories/#dataops-group";
s_modelops-->g_mlops["MLOps
group"];
click g_mlops "/handbook/product/categories/#mlops-group";
Click on a group name to see more details.
AI-powered stage
AI Framework group
|
Backend |
Frontend |
| Development Totals |
8 |
2 |
AI Model Validation group
|
Backend |
| Development Totals |
4 |
Custom Models group
|
Backend |
Frontend |
| Development Totals |
6 |
1 |
Duo Chat group
|
Backend |
Frontend |
| Development Totals |
6 |
1 |
Duo Workflow group
ModelOps stage
DataOps group
MLOps group
|
Backend |
| Development Totals |
2 |
Dev section
graph TD;
dev[Dev section]-->s_create[Create stage];
s_create-->g_code_creation["Code Creation
group"];
click g_code_creation "/handbook/product/categories/#code-suggestions";
s_create-->g_code_review["Code Review
group"];
click g_code_review "/handbook/product/categories/#code-review-group";
s_create-->g_editor_extensions["Editor Extensions
group"];
click g_editor_extensions "/handbook/product/categories/#editor-extensions";
s_create-->g_remote_development["Remote Development
group"];
click g_remote_development "/handbook/product/categories/#remote-development-group";
s_create-->g_source_code["Source Code
group"];
click g_source_code "/handbook/product/categories/#source-code-group";
dev[Dev section]-->s_plan[Plan stage];
s_plan-->g_knowledge["Knowledge
group"];
click g_knowledge "/handbook/product/product-categories/#knowledge-group";
s_plan-->g_optimize["Optimize
group"];
click g_optimize "/handbook/product/categories/#value-stream-management-group";
s_plan-->g_product_planning["Product Planning
group"];
click g_product_planning "/handbook/product/categories/#product_planning";
s_plan-->g_project_management["Project Management
group"];
click g_project_management "/handbook/product/categories/#project-management-group";
Click on a group name to see more details.
Create stage
Code Creation group
|
Backend |
| Development Totals |
11 |
Code Review group
|
Backend |
Frontend |
| Development Totals |
4 |
4 |
Editor Extensions group
|
Backend |
Frontend |
| Development Totals |
7 |
5 |
Remote Development group
|
Frontend |
| Development Totals |
2 |
Source Code group
|
Backend |
Frontend |
| Development Totals |
10 |
4 |
Plan stage
Knowledge group
|
Backend |
Frontend |
| Development Totals |
4 |
1 |
Optimize group
|
Backend |
Frontend |
| Development Totals |
2 |
3 |
Product Planning group
|
Backend |
Frontend |
| Development Totals |
4 |
4 |
Project Management group
|
Backend |
Frontend |
| Development Totals |
5 |
5 |
Fulfillment section
graph TD;
fulfillment[Fulfillment section]-->s_fulfillment[Fulfillment stage];
s_fulfillment-->g_fulfillment_platform["Fulfillment Platform
group"];
click g_fulfillment_platform "/handbook/product/categories/#fulfillment-platform-group";
s_fulfillment-->g_provision["Provision
group"];
click g_provision "/handbook/product/categories/#provision-group";
s_fulfillment-->g_subscription_management["Subscription Management
group"];
click g_subscription_management "/handbook/product/categories/#subscription-management-group";
s_fulfillment-->g_utilization["Utilization
group"];
click g_utilization "/handbook/product/categories/#utilization-group";
Click on a group name to see more details.
Fulfillment stage
|
Backend |
Frontend |
| Development Totals |
6 |
1 |
Provision group
|
Backend |
| Development Totals |
4 |
Subscription Management group
|
Backend |
Frontend |
| Development Totals |
3 |
4 |
Utilization group
|
Backend |
Frontend |
| Development Totals |
3 |
4 |
Growth section
graph TD;
growth[Growth section]-->s_growth[Growth stage];
s_growth-->g_acquisition["Acquisition
group"];
click g_acquisition "/handbook/<no value>";
s_growth-->g_activation["Activation
group"];
click g_activation "/handbook/<no value>";
Click on a group name to see more details.
Growth stage
Acquisition group
|
Backend |
| Development Totals |
6 |
Activation group
graph TD;
platforms[SaaS Platforms section]-->s_platforms[SaaS Platforms stage];
s_platforms-->g_dedicated["GitLab Dedicated
group"];
click g_dedicated "/handbook/product/categories/#gitlab-dedicated-group";
s_platforms-->g_delivery["Delivery
group"];
click g_delivery "/handbook/<no value>";
s_platforms-->g_pubsec_services["US Public Sector Services
group"];
click g_pubsec_services "/handbook/product/categories/#us-public-sector-services-group";
s_platforms-->g_scalability["Scalability
group"];
click g_scalability "/handbook/<no value>";
s_platforms-->g_switchboard["Switchboard
group"];
click g_switchboard "/handbook/product/categories/#switchboard";
Click on a group name to see more details.
GitLab Dedicated group
Delivery group
US Public Sector Services group
Scalability group
Switchboard group
Sec section
graph TD;
sec[Sec section]-->s_application_security_testing[Application Security Testing stage];
s_application_security_testing-->g_composition_analysis["Composition Analysis
group"];
click g_composition_analysis "/handbook/product/categories/#composition-analysis-group";
s_application_security_testing-->g_dynamic_analysis["Dynamic Analysis
group"];
click g_dynamic_analysis "/handbook/product/categories/#dynamic-analysis-group";
s_application_security_testing-->g_secret_detection["Secret Detection
group"];
click g_secret_detection "/handbook/product/categories/#secret-detection-group";
s_application_security_testing-->g_static_analysis["Static Analysis
group"];
click g_static_analysis "/handbook/product/categories/#static-analysis-group";
s_application_security_testing-->g_vulnerability_research["Vulnerability Research
group"];
click g_vulnerability_research "/handbook/product/categories/#vulnerability-research-group";
sec[Sec section]-->s_security_risk_management[Security Risk Management stage];
s_security_risk_management-->g_security_infrastructure["Security Infrastructure
group"];
click g_security_infrastructure "/handbook/product/categories/#threat-insights-group";
s_security_risk_management-->g_security_insights["Threat Insights
group"];
click g_security_insights "/handbook/product/categories/#threat-insights-group";
s_security_risk_management-->g_security_platform_management["Security Platform Management
group"];
click g_security_platform_management "/handbook/product/categories/#threat-insights-group";
s_security_risk_management-->g_security_policies["Security Policies
group"];
click g_security_policies "/handbook/product/categories/#security-policies-group";
sec[Sec section]-->s_software_supply_chain_security[Software Supply Chain Security stage];
s_software_supply_chain_security-->g_anti-abuse["Anti-Abuse
group"];
click g_anti-abuse "/handbook/product/categories/#anti-abuse-group";
s_software_supply_chain_security-->g_authentication["Authentication
group"];
click g_authentication "/handbook/product/product-categories#authentation-group";
s_software_supply_chain_security-->g_authorization["Authorization
group"];
click g_authorization "/handbook/<no value>";
s_software_supply_chain_security-->g_compliance["Compliance
group"];
click g_compliance "/handbook/product/product-categories#compliance-group";
s_software_supply_chain_security-->g_pipeline_security["Pipeline Security
group"];
click g_pipeline_security "/handbook/product/categories/#pipeline-security-group";
Click on a group name to see more details.
Application Security Testing stage
Composition Analysis group
|
Backend |
| Development Totals |
15 |
Dynamic Analysis group
|
Backend |
| Development Totals |
4 |
Secret Detection group
|
Backend |
Frontend |
| Development Totals |
6 |
2 |
Static Analysis group
|
Backend |
| Development Totals |
13 |
Vulnerability Research group
|
Backend |
| Development Totals |
3 |
Security Risk Management stage
Security Infrastructure group
|
Backend |
Frontend |
| Development Totals |
8 |
4 |
Threat Insights group
|
Backend |
Frontend |
| Development Totals |
8 |
4 |
|
Backend |
Frontend |
| Development Totals |
8 |
4 |
Security Policies group
|
Backend |
Frontend |
| Development Totals |
5 |
3 |
Software Supply Chain Security stage
Anti-Abuse group
|
Backend |
| Development Totals |
1 |
Authentication group
|
Backend |
Frontend |
| Development Totals |
6 |
2 |
Authorization group
|
Backend |
Frontend |
| Development Totals |
5 |
1 |
Compliance group
|
Backend |
Frontend |
| Development Totals |
5 |
3 |
Pipeline Security group
|
Backend |
Frontend |
| Development Totals |
4 |
2 |
Single-Engineer Groups section
graph TD;
seg[Single-Engineer Groups section]-->s_mobile[Mobile stage];
s_mobile-->g_mobile_devops["Mobile DevOps
group"];
click g_mobile_devops "/handbook/product/categories/#mobile-devops-group";
Click on a group name to see more details.
Mobile stage
Mobile DevOps group
Possible future Stages
We have boundless ambition, and we expect GitLab to continue to add new stages to the DevOps lifecycle. Below is a list of future stages we are considering:
- Data, maybe leveraging Meltano product
- Networking, maybe leveraging some of the open source standards for networking and/or Terraform networking providers
- Design, we already have design management today
Stages are different from the application types you can service with GitLab.
Maturity
Not all categories are at the same level of maturity. Some are just minimal and
some are lovable. See the category maturity page to see where each
category stands.
Other functionality
This list of other functionality so you can easily find the team that owns it.
Maybe we should make our features easier to search to replace the section below.
Other functionality in Plan stage
Plan stage
Project Management group
Project Management group
- assignees
- milestones
- due dates
- labels
- issue weights
- quick actions
- email notifications
- to-do list
- Real-time features (excluding real-time collaboration)
Knowlege group
Knowlege group
- markdown functionality
- rich text editor
Other functionality in Create stage
Create stage
Code Review group
Code Review group
Remote Development group
Remote Development group
Other functionality in Verify
CI Group
CI Group
Pipeline Authoring Group
Pipeline Authoring Group
Other functionality in Monitor stage
Monitor stage
Other functionality in Engineering Productivity
Engineering Productivity
Test Platform
Internal Customers: Gitaly, Core Platform section, SaaS Platforms section, Infrastructure Department, Support Department, Customer Success
Other functionality in Analytics
Analytics
Product Analytics group
Product Analytics group
- Analytics Dashboards - used by many groups to add visualizations or provide pre-configured dashboards to users
Facilitated functionality
Some product areas are have a broad impact across multiple stages. Examples of this include, among others:
- Shared project views, like the project overview and settings page.
- Functionality specific to the admin area and not tied to a feature belonging to a particular stage.
- UI components available through our design system, Pajamas.
- Dashboards for displaying analytics, such as Product Analytics, Value Stream Analytics, and others.
While the mental models for these areas are maintained by specific stage groups, everyone is encouraged to contribute within the guidelines that those teams establish. For example, anyone can contribute a new setting following the established guidelines for Settings. When a contribution is submitted that does not conform to those guidelines, we merge it and “fix forward” to encourage innovation.
If you encounter an issue falling into a facilitated area:
- For issues that relate to updating the guidelines, apply the
group::category label for the facilitating group.
- For issues that relate to adding content related to a facilitated area, apply the
group::category label for the most closely related group. For example, when adding a new setting related to Merge Requests, apply the group::source code label.
Shared responsibility functionality
There are certain product capabilities that are foundational in nature and affect or refer to horizontal components of the architecture that have an impact across functional groups and stages.
These capabilities may refer to “Facilitated Functionality” (see section above) where the mental models are owned by a particular group, while anyone can contribute. However, there may be others that will not have a clear owner because they don’t fall squarely into any particular group’s purview of product categories. Prime examples of this are issues related to the improvement or evolution of foundational components, frameworks and libraries that are used by several or all groups across the organization. Another example could be components created by special task groups in the past that have been since dissolved and that have not required continued development to justify the funding of a dedicated permanent group to maintain them.
Whatever the source of the functionality, rather than thinking of these components as “not having an owner”, it is important to think of them as being owned by everyone through the lens of shared responsibility. “Shared responsibility” means that every group should be committed and responsible to contribute to their continued maintenance, improvement and innovation.
Contribution, in this context, may manifest in different ways:
- Triage by coordinating conversations with stakeholders from different functions and at different levels to find the right owner and/or set the right level of priority.
- Product feature scoping and UX design by fleshing out the details of implementation in requirements documents and/or mockups.
- Technical scoping and feasibility analysis for possible technical and architectural approaches to implementation
- Actual implementation and release activities
It does not mean, however, that a single group should necessarily be solely responsible for all of these activities. Multiple groups could end up collaborating in execution. This coordination however requires a careful triage of the shared responsibility issues in the issue tracker where a single DRI coordinates these activities.
For more information please review this section in the quality department handbook to learn more about a decentralized approach to triaging these types of issues.
Categories A-Z
Features by Group
This page is meant to showcase the features by tier across GitLab’s Product Hierarchy.
Analytics Section
Monitor
Monitor: Analytics Instrumentation Group
Steve Evangelista
Tim Zallmann
Taurie Davis
Will Leidheiser
Eugene McCrann
Sam Kerr
Ievgen Chernikov
Justin Mandell
Dave Smith
Sam Goldstein
Sean Gillespie
Mike Flouton
Marcel van Remmerden
Tiffany Chen
Viktor Nagy
Nicolò Maria Mezzopera
Rayana Verissimo
Staff Backend Engineer
Taka Nishida
Tiger Watson
Timo Furrer
Andrew Fontaine
Anna Vovchenko
Lewis Brown
Phillip Wells
Ameya Darshan
Devin Sylva
Jackie Porter
Erika Feldman
Tim Rizzi
Crystal Poole
Tiffany Rea
Hayley Swimelar
Jaime Martínez
João Pereira
Senior Backend Engineer
Senior Backend Engineer
Kate Grechishkina
Marcel Amirault
David Fernandez
Dzmitry Meshcharakou
Moaz Khalifa
Rad Batnag
Cheryl Li
Senior Backend Engineer
Marius Bobin
Tianwen Chen
Manuel Grabowski
Gabriel Engel
Nicole Williams
Rehab Hassanein
Joy Roodnick
Michael Trainor
Justin Farmiloe
Roshni Sarangadharan
Costel Maxim
Paulo Martins
Rachel Fuerst
Vladimir Dzalbo
Dov Hershkovitch
Avielle Wolfe
Furkan Ayhan
Kasia Misirli
Laura Montemayor
Rajendra Kadam
Briley Sandlin
Sunjung Park
Luminus Alabi
Segolene Bouly
Rohit Shambhuni
Rutvik Shah
Caroline Simpson
Allison Browne
Daniel Prause
Hordur Freyr Yngvason
Max Fan
Panos Kanellidis
Vlad Wolanyk
Jose Ivan Vargas
Payton Burdette
Veethika M
Charl Marais
Lysanne Pinto
Darren Eastman
Adrien Kohlbecker
Arran Walker
Axel von Bertoldi
Cam Swords
Davis Bickford
Georgi Georgiev
Hannes Hörl
Joe Shaw
Joe Burnett
Pedro Pombeiro
Romuald Atchadé
Tomasz Maczukin
Gina Doyle
Iris Gorman
Michelle Gill
Nivetha Prabakaran
Chris Micek
Jeff Tucker
Sam Beckham
James Rushford
Staff Frontend Engineer
Scott de Jonge
Vanessa Otto
Dan Mizzi-Harris
Jeremy Elder
Changzheng Liu
Arturo Herrero
Dmitry Gruzd
John Mason
Madelein van Niekerk
Ravi Kumar
Siddharth Dungarwal
Terri Chu
Tomáš Bulva
Brenda Nyaringita
Cleveland Bledsoe Jr
Ashraf Khamis
Kevin Morrison
Magdalena Frankiewicz
Martin Wortschack
Carla Drago
Senior Backend Engineer
James Nutt
Keeyan Nejad
Luke Duncalfe
Rodrigo Tomonari
Sam Word
Justin Ho
Oiza Baiye
Anton Smith
Olivier Némoz Saint-Dizier
Lukas Eipert
Paul Gascou-Vaillancourt
Thomas Hutterer
Jacki Bauer
Thaina Tavares
Amelia Bauerly
Austin Regnery
Suzanne Selhorn
Vishal Patel
Sacha Guyon
Aleksei Lipniagov
Matthias Käppler
Nikola Milojevic
Roy Zwambag
Gabriel Yoachum
Jon Glassman
Dilan Orrino
Peter Lu
Andrew Patterson
Alec Xu
Balasankar 'Balu' C
Dmitry Makovey
Dustin Collins
Pratik Singh
Ryan Egesdahl
Robert Marshall
Evan Read
Achilleas Pipinellis
Clemens Beck
Hossein Pursultani
Jason Plum
João Alexandre Prado Tavares Cunha
Jon Doveston
Lucas Li
Priyan Sureshbabu
Taylor McCaslin
Hillary Benson
Pini Wietchner
David O'Regan
Alexander Chueshev
Alejandro Rodríguez
Halil Coban
Backend Engineer
Małgorzata Ksionek
Nathan Weinshenker
Surabhi Suman
Lindsey Shelton
Emily Bauman
Katie Macoy
John Gaughan
Fiona Neill
Andras Herczeg
Hongtao Yang
Stephan Rayner
Tan Le
Sean Carroll
Bruno Cardoso
Eduardo Bonet
Igor Drozdov
Patrick Cyiza
Manoj Memana Jayakumar
Mohamed Hamda
Julie Huang
Timothy Noah
Torsten Linz
Juan Silva
Dillon Wheeler
Eva Kadlecová
Lesley Razzaghian
Mark Chao
Shinya Maeda
Tetiana Chupryna
Jannik Lehmann
Duncan Harris
Pedro Moreira da Silva
Alper Akgun
Fred de Gier
Graham Bachelder
Ben Leduc-Mills
Danika Teverovsky
Derek Ferguson
Darva Satcher
Jay McCure
Andy Volpe
Jordan Janes
Matt Nohr
Allen Cook
Jan Provaznik
Leaminn Ma
Mikołaj Wawrzyniak
Missy Davies
Pam Artiaga
Sri Rangan
Tian Gao
Vitali Tatarintev
Kai Armstrong
François Rosé
Sincheol (David) Kim
Gary Holtz
Marc Shaw
Patrick Bajao
André Luís
Phil Hughes
Stanislav Lashmanov
Thomas Randolph
Michael Le
Ben King
Amy Qualls
Dasha Adushkina
Kisha Mavryck Richardson
Anna Springfield
Dylan Bernardi
Erran Carey
John Slaughter
Karl Jamoralin
Marvin Gay
Andrei Zubov
Elwyn Benson
Olena HK.
Tomas Vik
Tristan Read
Michelle Chen
Adebayo Adesanya
Enrique Alcántara
Paul Slaughter
Chris Stone
Marie-Christine Babin
Devi Poosarla
Emma Park
Fred Reinink
Gavin Hinfey
Hunter Stewart
Javiera Tapia
Joe Woodward
Kerri Miller
Olaoluwa Oluro
Vasilii Iakliushin
Jacques Erasmus
Chaoyue Zhao
Paulina Sedlak-Jakubowska
Brendan Lynch
Conley Rogers
Simon Mansfield
Melissa Ushakov
John Hope
Désirée Chevalier
Caitlin Steele
Matthew Macfarlane
Vladimir Shushlin
Brett Walker
Janis Altherr
Naman Jagdish Gala
Piotr Skorupa
Himanshu Kapoor
Alex Fracazo
Marcin Sędłak-Jakubowski
Susan Tacker
Haim Snir
Brandon Labuschagne
Felipe Artur
Pavel Shutsin
Alex Pennells
Ezekiel Kigbo
Rudy Crespo
Libor Vanc
Amanda Rueda
Kushal Pandya
Abhilash Kotte
Eugenia Grieff
Kassio Borges
Nicolas Dular
Anastasia Khomchenko
Florie Guibert
Jack Chapman
Rajan Mistry
Nick Brandt
Gabe Weaver
Donald Cook
Alexandru Croitor
Heinrich Lee Yu
Mario Celi
Marc Saleiko
Stefanos Xanthopoulos
Senior Frontend Engineer
Deepika Guliani
Natalia Tepluhina
Simon Knox
Nick Leonard
Ben Prescott
Omar Fernandez
Jerome Ng
Valerie Burton
Richard Chong
Emily Sybrant
Anne Lasch
James Lopez
Aishwarya Subramanian
Etienne Baqué
Shreyas Agarwal
Tarun Vellishetty
Tyler Amos
Vladlena Shumilo
Lina Fowler
Tom McAtee
Courtney Meddaugh
Ragnar Hardarson
Bishwa Hang Rai
Corinna Gogolok
Paulo Barros
Qingyu Zhao
Keven Hughes
Tatyana Golubeva
Aman Luthra
Josianne Hyson
Ryan Cobb
Diana Zubova
Michael Lunøe
Sharmad Nachnolkar
Vamsi Vempati
Firdaws Farukh
Alexandra Martin
Jason Goodman
Suraj Tripathi
Vijay Hawoldar
Ammar Alakkad
Angelo Gulina
Kos Palchyk
Sheldon Led
Shem Gyll
Nikhil George
Kamil Niechajewicz
Gayle Doud
Buck O'Leary
David Hamp-Gonsalves
Doug Stull
Jay Montal
Roy Liu
Serhii Yarynovskyi
Paige Cordero
Fabian Zimmer
Marin Jankovski
Brittany Wilkerson
Chris Balane
Oriol Lluch
Wei-Meng Lee
Wade Jenkins
Daphne Kua
Brie Carranza
Armin Hergenhan
Dhruv Jain
Zane J Chua
Sam Wiskow
Michele Bursi
Amy Phillips
Jim Baumgardner
Rachel Nienaber
Loryn Bortins
Amy Shiel
Sarah Waldner
Thomas Woodham
Will Meek
Aditya Tiwari
Fabien Catteau
Oscar Tovar
Igor Frenkel
Nick Ilieskou
Olivier Gonzalez
Philip Cunningham
Shao Ming Tan
Thiago Figueiró
Zamir Martins Filho
Salman Ladha
Russell Dickenson
Bryan Miller
Brian Wald
Sam Morris
Alexander Dietrich
David Nelson
Mike Eddington
Alana Bellucci
Amar Patel
Ahmed Hemdan
Ethan Urie
Radu Birsan
Ross Fuhrman
Serena Fang
Vishwa Bhat
Dheeraj Joshi
Michael Fangman
Connor Gilbert
Adam Cohen
Craig Smith
Daniel Abeles
Gal Katz
Hua Yan
Jason Leasure
Julian Thome
Meir Benayoun
Mher Tolpin
Or Gal
Schmil Monderer
Senior Backend Engineer
Christopher Chewa Mutua
Isaac Dawson
Michael Henriksen
Mario Mora
Dennis Appelt
Harsha Muralidhar
Bala Kumar Subramani
Brian Williams
Gregory Havenga
Mehmet Emin Inac
Michał Zając
Rushik Subba
Subashis Chakraborty
Dave Pisek
Lorenz van Herwaarden
Samantha Ming
Savas Vedova
Neil McCorrison
Becka Lippert
Gerardo Gutierrez
Mirko Brandner
Yu-Chen Hsueh
Grant Hickman
Alan (Maciej) Paruszewski
Andy Schoenen
Dominic Bauer
Marcos Rocha
Martin Cavoj
Sashi Kumar Kumaresan
Alexander Turinske
Artur Fedorov
Camellia X. Yang
Ulises Fierro
Ryan Lehmann
Dominic Couture
Byron Boots
Sam White
Joe Randazzo
Jay Swain
Eugie Limpin
Michael Gibson
Shawn Sichak
Hannah Sutor
Adil Farrukh
Andrew Evans
Bogdan Denkovych
Drew Blessing
Imre Farkas
Smriti Garg
Aboobacker MK
Eduardo Sanz-Garcia
Jio Castillo
Alvin Gounder
Jeff Martin
Ayush Billore
Alex Buijs
Hinam Mehra
Jarka Košanová
Mo Khan
Daniel Tian
Ilonah Pelaez
Ian Khor
Nathan Rosandich
Andrew Jung
Harsimar Sandhu
Hitesh Raghuvanshi
Huzaifa Iftikhar
Sam Figueroa
Illya Klymov
Nataliia Radina
Jocelyn Eillis
Scott Hampton
Dmytro Biryukov
Erick Bajao
Shabini Rajadas
Miranda Fluharty
Mireya Andres
Bonnie Tsang
Nilanka De Silva
Tanuja Jayarama Raju
Jiaan Louw
Ankit Panchal
Sebastian Rehm
Jonas Larsen
Michał Wielich
Niko Belokolodov
Nwanna Isong
Sarah Yasonik
Nick Hertz
Greg Myers
Lindsy Farina
Nicholas Klick
Aathira Nair
Lorena Ciutacu
