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.
The links below take you to a handbook dashboard page which covers metrics from the Development, Infrastructure, Quality, UX, and Security Departments.
These handbook dashboard pages are populated from 5 filterable Sisense dashboards.
For a section with multiple stages or a stage with multiple groups, these metrics are repeated further down the page to give team members the ability to view these metrics at a section, stage, or group level. To navigate to section metrics, click on the
___ Section Dashboards link above. To navigate to stage metrics, click on the
___ Stage Dashboard link above or from the header link in the section dashboards pages. To navigate to the group metrics, find the stage that contains the group and click on the corresponding
___ Stage Dashboards link above.
Groups are extracted from labels applied on an MR or issue. For example, the
~group::access label is used to query MRs or issues attached to the Access group. If a group is missing from the filter dropdown in the embedded dashboards above, check if it’s included in this spreadsheet. If it’s missing, add a new row with the corresponding stage and section. This spreadsheet flows to our data warehouse once a day so you may not see updates in Sisense until the next day. In order to display this new group in the handbook dashboard pages, please reach out to a member of the Engineering Analytics Team to get this added to the handbook dashboard page filters.
For the Development Embedded Dashboard, metrics are filtered based on what group each team member comes from. Group comes from the
job title specialty field in Bamboo HR. Per the handbook, managers are responsible for updating the
job title speciality field in for any/all specialty changes. If a team member isn’t counted in the organization metrics but their group information is correct in Bamboo HR, check that the notification email in their GitLab.com profile matches the work email in Bamboo HR. If there is a mismatch, update the Bamboo HR profile email to match the GitLab.com notification email. If a group was recently added or moved to a different sub department, update this mapping file. This mapping file links each job title speciality to the corresponding stage and section and flows to our database once a day.
The Engineering Metrics listed here are available for all product group teams. The indicators captured here may or may not roll into an existing KPI/PI. The Engineering Analytics team reserves the urgency for these dashboards to provide timely visibility without the requirement of having all indicators be a KPI/PI at the department level.
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:
Previously MR Rate was called "Narrow MR Rate," but that term was removed.
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
~"feature::enhancement"for user-facing improvements that refine the initial MVC to make it more useful and usable.
~"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.
We allow flexibility where the parent
devops::xxx and child
group::xxx label may not match. For example:
toolingwork 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