Fix ownership information for metrics and events
Problem
Currently we have 1175 out of 2698 metrics defining a product_group
that is not defined in https://gitlab.com/gitlab-com/www-gitlab-com/raw/master/data/stages.yml.
The situation for product_stage
and product_section
is almost as bad with 504 for product_stage
and 1026
for product_section
.
For event definitions product_group
is wrong in 286 out of 396 cases.
Here are all the definitions counter and grouped by product_group
.
product_group |
count |
---|---|
integrations | 341 |
273 | |
package | 166 |
monitor | 98 |
import | 89 |
configure | 79 |
memory | 26 |
environment | 14 |
container_security_group_was_removed | 12 |
license | 12 |
distribution | 11 |
editor | 11 |
release | 10 |
manage | 7 |
gitaly | 6 |
certify | 5 |
integration | 4 |
plan | 2 |
five_min_app | 2 |
acess | 2 |
access | 1 |
create | 1 |
continuous_integration | 1 |
enablement_distribution | 1 |
team_planning | 1 |
And the same for event definitions
product_group |
count |
---|---|
group::package | 62 |
group::incubation | 37 |
group::environments | 24 |
group::product_planning | 24 |
group::conversion | 17 |
group::expansion | 14 |
monitor | 14 |
group::compliance | 13 |
group::editor | 11 |
group::optimize | 8 |
7 | |
group::package registry | 6 |
group::adoption | 5 |
group::monitor | 5 |
group::pipeline_authoring | 4 |
group::static_analysis | 4 |
group::code review | 4 |
group::pipeline execution | 4 |
group::import and integrate | 3 |
group::global search | 3 |
group::ai framework | 2 |
group::activation | 2 |
import | 2 |
group::foundations | 1 |
group::authentication and authorization | 1 |
integrations | 1 |
group::global_search | 1 |
manage | 1 |
group::source code | 1 |
ai_assisted | 1 |
group::knowledge | 1 |
group::ide | 1 |
editor | 1 |
group::composition_analysis | 1 |
Desired Outcome
Update the metric and event definitions to point to existing groups.
Create a procedure to keep the data up to date
Potential Solution(s)
An outline of potential solutions to get to the desired outcome. These solution(s) can still be adjusted throughout the implementation as long as the desired outcome is achieved.
How to verify
How can we verify that the desired outcome has been achieved? The instrcutions from this section should be used to move the issue from ~"worfklow::verification".
Further actions needed
Any further tasks that need to be completed after the main work of the issue is done, such as announcing the changes or updating documentation.