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).
[Identity]` is collection of people (the denominator) and is usually a Division, Department, Sub-Department, or Team name from our Organizational Structure
MR Rate prefixes have been removed in favor of focusing on what was previously known as Narrow MR Rate. Narrow MR Rates are now referred to as MR Rate in Engineering performance indicators.
A 5 member team in the past month has merged 200 MRs authored by team members, merged 100 MRs authored by other GitLab team members, and 50 MRs authored by people from the wider-community.
The Team MR Rate would be 40 (200 / 5)
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