Productivity Analytics - Consider "WIP" label when determining time-to-merge statistics

Problem to solve

For the newly released Productivity Analytics in version 12.3, Gitlab tracks the time-to-merge which is the number of days from the time the MR is opened until it is finally merged. This statistic is very helpful in determining overall productivity of particular projects and/or groups.

This statistic, however, also seems to incorporate new Merge Requests that are opened with a WIP: title prefix to indicate the MR is a work in progress. While for some people this may be the expected behavior, for others it may not be. Our organization often uses a WIP: merge request prefix when needing to compile/test large changes that would be too slow on a local machine (example: we have a monorepo setup, so some minor file changes could cause a build to be triggered for all services in the repo). Additionally, some engineers may throw up a WIP: merge request to simply see the effect of their change in a temporary environment.

Intended users

Proposal

Ideally, the time-to-merge statistics could exclude time for which the MR had the WIP: prefix attached to it. A formula like the following:

Relative Time to Merge (TtM) = Total TtM - hours w/ WIP prefix

The logic could include cases where the WIP: prefix is added and removed several times over the lifetime of an MR.

This feature could be enabled by default, set with an optional checkbox, or exposed with a filter when viewing the statistics in the UI.

Permissions and Security

No permissions or security changes would be required outside of what is already configured for the Productivity Analytics feature.

Documentation

Dependent on which solution is being implemented. The feature documentation is already available here: https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html

What does success look like, and how can we measure that?

A product manager, team lead, or data analyst would be able to achieve the following:

Determine the most-accurate time-to-merge metrics for a specific group/project inside of Gitlab.
Know how the metric is calculated from a more technical level, to account for discrepencies or assumptions when using the metric to guide internal business decisions.

What is the type of buyer?

Premium, Silver (the already existing tiers for the feature)