## Context At a discussion with Peter about logging offenses being reported in GitLab pipelines, we noticed things we need to clarify: ### CODEOWNERS When the logging TODO file is modified, ~"group::development tooling" or LabKit domain experts are not notified. This prevents us from giving additional guidance or noticing anomalies in the TODO file. We could think about adding them to the CODEOWNERS of that file. ### Validator behaviour The Ruby logging field validator seems not to behave consistently. Some jobs report more offenses than others, making it difficult to have a complete baseline. A root cause could be the stubbing of the `AppLogger`. We could think of adding a Rubocop rule to prevent the logger from being stubbed. `rg "(allow|expect)..*?Logger.\.to"` ### Deprecation definition The current definition of deprecated fields seems to punish developers who add a logging line. This is because the application context in GitLab adds more logging fields to every logging line, resulting in a bloated TODO file where several call sites are added that do not emit the respective field directly, but indirectly. We could think about identifying fields that are added by the application context and collecting them as a single offense to prevent more incorrect or misleading offenses. Furthermore, the current deprecation definition seems to be wrong as we also marked fields like `meta.remote_ip` as deprecated, even though this [ADR](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/18208) mentions that it should be nested inside `meta`. After correcting the deprecation definition, a good idea here is to add the [ADR](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/18208) to the [README](https://gitlab.com/gitlab-org/quality/tooling/labkit-spec/-/blob/main/README.md) and connect more dots. ### Investigation After the [LabKit version pump](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/232654) on GitLab, new offenses were added to the logging TODO file, since the version includes new field and deprecation definitions. However, the MR didn't include all offenses, and several other jobs showed untracked offenses (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/234179). Apart from this, probably being related to the application context added to each new logging line, we need to investigate how offenses can escape to master without being tracked.