### Summary After investigating how merge request widgets work, I have taken a short video to report about my own experience using them and the comments I got from other engineers about how they currently use it. You can see the entire presentation on [YouTube](https://youtu.be/jFhvf4hiE0U). The main problem I found is that **we report data in a way that does not align with what the user needs, nor what they expect** there. From a user perspective, the merge request widgets should only show changes and their impact, introduced by that specific merge request. This is currently not the case. A merge request that only contains simple CSS changes can lead to merge request widgets showing degraded code quality, changed report metrics, newly introduced security vulnerabilities https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30513, and worse performance metrics https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30477. | Changes | MR widgets | | ------ | ------ | |  |  | There is no way the CSS changes introduced in the example above can lead to the consequences mentioned in the merge request widgets. This leads to users ignoring these widgets, assuming it's either broken or irrelevant. | It's broken | It's irrelevant | I'm ignoring it | | ------ | ------ | ------ | |  |  |  | This means we are training them to ignore the warnings, so that they then introduce security vulnerabilities without being aware.  Even worse, the way these widgets constantly are fighting for our attention, even though they report data that is irrelevant to users, means that the rest of the page becomes less usable. | I'm ignoring all warnings now | I can't find the actually import actions anymore | | ------ | ------ | |  |  |