Improve MR type classification
Background
We have the following top level MR types with visibility into MR types of all Product group teams https://app.periscopedata.com/app/gitlab/976817/Merge-Request-Types
- Bugs
- Feature
- Maintenance
As defined as top level types in https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification
Problem
We have observed a bias to over use Maintenance, after a deeper analysis we discovered that a number these are in support of feature development and bug fixes.
In addition, to provide clear top level types and in alignment with external reporting in the industry we will only keep 3 top level types, as such the top level ~"type::tooling"
will be consolidated with maintenance categories.
Getting down to bug/feature/maintenance is key to our reporting to industry analysts, there is a clear business need & justification for this consolidation. This is important for GitLab to communicate effort spent into a format that is easily understandable widely in the industry.
Fix
Video overview: https://www.youtube.com/watch?v=TvUwsFIb9gA
To improve MR type accuracy we will be implementing more specific sub types and create categorization space to capture all types of work under the 3 top level types.
New
- We do not have any sub-types for Bugs, we need more fidelity on the types of defects. We are going to provide the following.
-
~"bug::performance"
: Performance defects or response time degradation -
~"bug::availability"
: Defects related to GitLab SaaS availability- All existing ~availability issues have typebug also assigned to them per https://gitlab.com/gitlab-org/gitlab/-/issues?sort=created_date&state=opened&label_name[]=availability so this change is an organic fit.
-
~"bug::vulnerability"
: Defects related to Security Vulnerabilities- Majority of ~vulnerability issues already have typebug applied to them https://gitlab.com/gitlab-org/gitlab/-/issues?sort=created_date&state=opened&label_name[]=vulnerability
-
~"bug::mobile"
: Defects encountered on Mobile Devices
-
- All feature development work should be under Features, we will provide the following in addition to Additions & Enhancements
-
~"feature::consolidation"
: Merging a feature into an existing feature for simplification. -
~"feature::removal"
: Deprecation and removal of a functionality when it's no longer needed.
-
- In Maintenance we will provide the following for better fidelity
-
~"maintenance::refactor"
: Simplifying or restructuring existing code or documentation -
~"maintenance::dependency"
: Dependency updates and their version upgrades -
~"maintenance::usability"
: General improvements to product usability that are unrelated to feature prioritization -
~"maintenance::test-gap"
: Test coverage improvements that were not included in feature prioritization. -
~"maintenance::pipelines"
: Internal Pipelines configuration. -
~"maintenance::workflow"
: Improvements of the engineering workflow and release tooling like Danger, RuboCop, linters, etc.
-
- We will be consolidating Tooling into Maintenance, our chart is already accounting it in this manner so this makes the label more truthful.
Existing
We are also providing better clarification of the below existing categories
-
~"type::bug"
: Defects in shipped code and fixes for those defects. Read more about features vs bugs. -
~"type::feature"
: Effort to deliver new and improve existing GitLab features. Read more about features vs bugs.-
~"feature::addition"
: The first MVC that gives GitLab users a foundation of new capabilities that were previously unavailable. Includes good user value, usability, and tests. 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"
: Subsequent user-facing improvements that refine the initial MVC by adding additional capabilities that make it more useful. Includes good user value, usability, and tests. 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
-
-
~"type::maintenance"
: Upkeeping efforts & catch-up corrective improvements that are not Features nor Bugs. This includes technical debt and industry-standard updates such as Rails/Ruby upgrades. For example: Updating software versions in our tech stack, Recalculating UUIDs for vulnerabilities using UUIDv5
Review & Feedback meetings
- R&D Leadership
- Product team meeting
- Eng Staff
- Eng Analytics
- Eng Analytics x Data team
Communication
-
MR to handbook !99096 (merged) -
Youtube overview https://www.youtube.com/watch?v=TvUwsFIb9gA -
Slack announcement -
Email announcement
Label changes
-
Label creation -
Label automation
Roll out dashboard with 2 product groups
cc @kwiebers