Our centralized engineering dashboards provide a set of common metrics that capture the overall health of the entire R&D Product/Engineering structure, with drill downs into every stage and group.
undefined, spend some time to review your team's issues and MRs and add labels so we can get a more accurate classification.
Merge Request (MR) Rate is a measure of productivity and efficiency. The numerator is a collection of merge requests to a set of projects. The denominator is a collection of people. Both are tracked over time (usually monthly).
MR Rate begins with an
[Identity] prefix which defines the group of people (the denominator) taken into calculation. This is usually a Division, Department, Sub-Department, or Team name from our Organizational Structure. The calculation for MR rate is the number of authored MRs by the team members divided by the number of team members in the group. For example:
Team A consists of 5 members. In the past month, there were 200 merged MRs:
Team A's MR Rate for that month would be: (100 / 5) = 20
We use the following type labels to classify our Issues and Merge Requests.
~"Community contribution": A community contribution label takes precedence over other labels. Therefore, while the work may introduce a new feature or resolve a bug, we prioritize this label over others due to the importance of this particular category. You may apply a second type label such as
~"feature"to indicate the type of issue or merge request.
~"security": Security-related MRs.
~"bug": Defects in shipped code. Read more about features vs bugs.
~"feature": Any MR that contains work to support the implementation of a feature and/or results in an improvement in the user experience. Read more about features vs bugs.
~"feature::addition": Refers to the first MVC that gives GitLab users a foundation of new capabilities that were previously unavailable. For example, these issues together helped create the first MVC for our Reviewer feature: Create a Reviewers sidebar widget, Show which reviewers have commented on an MR, Add reviewers to MR form, Increase MR counter on navbar when user is designated as reviewer
~"feature::enhancement": Refers to GitLab user-facing improvements that refine the initial MVC to make it more useful and usable. For example, these issues enhance the existing Reviewer feature: Show MRs where user is designated as a Reviewer on the MR list page, Display which approval rules match a given reviewer, Add Reviewers quick action
~"feature::maintenance": Refers to refinements to an existing feature that are not GitLab user-facing and not related to
~bugresolution. This could include
~"technical debt"and industry-standard updates such as work towards Rails upgrade. For example: Updating software versions in our tech stack, Recalculating UUIDs for vulnerabilities using UUIDv5
~"tooling": MRs related to engineering tooling.
~"tooling::pipelines": MRs related to pipelines configuration.
~"tooling::workflow": MRs related to improvements of the engineering workflow and release tooling like Danger, RuboCop, linters, etc.
~"documentation": For documentation-only MRs, use
~"documentation"only unless the work is attributable to code changes for a feature or bug, and in that case, use
~"bug", even if the doc change is being made late for a feature/bug from a previous milestone.
If these labels are missing, it will be tracked in the
undefined bucket instead.
The Engineering Manager for each team is ultimately responsible for ensuring that these labels are set correctly.
~"backstage" was intended to be changes that were done to keep product development running smoothly. Over time,
~"backstage" was also being used for pre-feature work and has become unclear and confusing.
~"backstage" was deprecated as part of https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/488.
This guidance may be helpful if you are wondering the go-forward type label based on your use case for applying
~"feature::maintenance"for industry standard and refactoring changes such as:
~"feature::maintenance"for addition or updates to specs for existing GitLab features
~"feature::addition"for all changes related to the release of a new feature
~"tooling::workflow"for changes to engineering workflows such as:
~"tooling::pipelines"for changes to project pipeline configurations
~backstage will be removed with https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/483.
In the spirit of "Everyone can Contribute" it's natural that members in a group will contribute to another group.
Our guideline aims to cover for the 20/80 (default accounting method). By default the MR from an author should belong to their
group::xxx and direct parent
Optimizing for all edge cases will lead to complexity since there will always be edge cases.
We allow flexibility where the parent
devops::xxx and child
group::xxx label may not match. For example:
backstagework that spans multiple groups.
If a contribution happens across groups, we leave it to the discretion of the engineering and product manager to change the
group::xxx label to reflect which group worked on it.
They can also decide if they want to move over the
devops::xxx as well or keep it to reflect the product area.
The triage bot automatic labelling we will not override existing labels.
In the MR Rate and Volume of MR calculations, we consider MRs from projects that contributes to the overall product efforts.
The current list of projects are identified in the
gitlab-data/analytics project for the following system databases:
The guidelines for inclusion in the
is_part_of_product lists are:
Follow these steps to request a new project to be tracked:
There is no need to remove archived projects from the
is_part_of_product list. Removal of projects will remove historical merge requests from metrics and reduce Merge Request rates.
Please reach out to a member of the Engineering Productivity team if more assistance is needed
URLproperty is only used to link to a chart until it is an embedded Sisense chart.
<a>in description text if we need to link out to a supporting artifact e.g. Epics or Issues.
At or above ...
At or below ...
whenclause in Sisense. Example below:
CASE WHEN date_month < date_trunc('month',current_date) THEN MEDIAN(open_age_in_days) ELSE NULL END AS "Historical Median Open Days",
CASE WHEN date_month = date_trunc('month',current_date) THEN MEDIAN(open_age_in_days) ELSE NULL END AS "Current Median Open Days",
chart, and the
dashboardkey-value pairs to the corresponding Performance Indicators data file under the
:in strings as it's an important character in YAML and will confuse the data parsing process. Put the string in "quotes" if you really need to use a