Our mission is to enhance developer efficiency by delivering actionable insights, optimizing pipeline performance, and building scalable productivity tools that measurably improve the software development lifecycle.
Vision
We envision a future where GitLab’s development workflows are seamless, insightful, and empowered by data. The Development Analytics team will:
Establish GitLab as the industry benchmark for measurable developer productivity
Improve cycle time to industry-leading standards through tooling and practices
Create intuitive, powerful analytics dashboards that drive informed development decisions
Deploy AI-powered systems that optimize pipeline performance and resource utilization
As part of our commitment to aligning with GitLab’s company goals, our team conducts a thorough review of company-level Roadmap and Objectives and Key Results (OKRs) at the beginning of each quarter. This process ensures that our efforts are strategically focused on delivering high-impact results that contribute to the broader organizational objectives. View the Development Analytics Roadmap for FY26 for detailed insights and upcoming priorities
Note: Access to these dashboards requires appropriate permissions. Contact team leads for access requests.
How we work
Philosophy
We prioritize asynchronous communication and a handbook-first approach, in line with GitLab’s all-remote, timezone-distributed structure.
We emphasize the Maker’s Schedule, focusing on productive, uninterrupted work.
Most critical recurring meetings are scheduled on Tuesdays and Thursdays.
We dedicate 3–4 hours weekly for focused learning and innovation. This protected time enables the team to explore emerging technologies, conduct proof-of-concepts, and stay current with industry trends. Meeting requests during these blocks require advance notice.
All meeting agendas can be found in the Team Shared Drive as well as in the meeting invite.
Meetings/Events
Event
Cadence
Agenda
End-of-Week progress update
Once a week (Wednesday)
Summarize status, progress, ETA, and areas needing support in the weekly update in issues and Epics. We leverage epic-issue-summaries bot for automated status checks
Once the roadmap is approved, during our bi‑weekly team meetings, we review progress, address blockers, and gather feedback on the planned roadmap work.
Internal Rotation & Support Requests
Internal Rotation
We use an internal rotation for support requests and other team maintenance tasks. This frees up time for other Engineers in the team to work on planned work.
Support Requests
If one finds a bug, needs assistance, or identifies an improvement opportunity then raise support requests using the ~"group::Development Analytics" and ~"development-analytics::support-request" labels. If the issue is urgent, escalate to the designated Slack channel - #g_development_analytics.
If a request first comes through Slack, either the requester or a group::Development Analytics member should open an issue with the correct labels to ensure proper tracking and triage.
The team reviews the support request board and prioritizes accordingly. Generally, the team reserves ~20% of weekly time for support tasks, though this may vary based on current priorities.
Tools/Repository Maintenance
Team does not automatically watch every new issue created in each group-owned repository—use the group labels or escalate in Slack to ensure visibility.
We highly promote self-served Merge Requests. If one already identified a fix or improvement, we request opening an MR for faster turnaround. The ~group::development analytics maintainers will review and merge as appropriate.
Feature work and bug fixes follow the team’s current priorities.
Find the version management rituals for ~group::development analytics owned repositories:
Repository
Release Process
gitlab-roulette
Version updates are not scheduled on a set cadence. A release can be cut whenever a version-update MR is submitted.
gitlab-dangerfiles
Same as above—no regular cadence; release triggered by a version-update MR.
triage-ops
A new release is initiated after merging a new commit into master.
engineering-productivity-infrastructure
Dependency update MRs are generated by Renovate bot.
This guide provides comprehensive instructions for writing triage automation policies in triage-ops using GitLab Duo Workflow. You will be able to self service label migrations after a department re-org by following this page.
Todo: include instructions for writing policies to perform other types of automated tasks.
Purpose
Triage policies are used when team members migrate labels across existing issues, merge requests, and epics using gitlab-triage. This tool automates triaging through policies defined in YAML. To optimize operational efficiency and ensure seamless implementation, we recommend self-servicing the label migration MRs using GitLab Duo Workflow.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Cookie Policy
User ID: 88659897-b9d0-4b21-bc7e-c0feaced34ed
This User ID will be used as a unique identifier while storing and accessing your preferences for future.
Timestamp: --
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, enabling you to securely log into the site, filling in forms, or using the customer checkout. GitLab processes any personal data collected through these cookies on the basis of our legitimate interest.
Functionality Cookies
These cookies enable helpful but non-essential website functions that improve your website experience. By recognizing you when you return to our website, they may, for example, allow us to personalize our content for you or remember your preferences. If you do not allow these cookies then some or all of these services may not function properly. GitLab processes any personal data collected through these cookies on the basis of your consent
Performance and Analytics Cookies
These cookies allow us and our third-party service providers to recognize and count the number of visitors on our websites and to see how visitors move around our websites when they are using it. This helps us improve our products and ensures that users can easily find what they need on our websites. These cookies usually generate aggregate statistics that are not associated with an individual. To the extent any personal data is collected through these cookies, GitLab processes that data on the basis of your consent.
Targeting and Advertising Cookies
These cookies enable different advertising related functions. They may allow us to record information about your visit to our websites, such as pages visited, links followed, and videos viewed so we can make our websites and the advertising displayed on it more relevant to your interests. They may be set through our website by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertisements on other websites. GitLab processes any personal data collected through these cookies on the basis of your consent.