## Participants * @splattael ## Overview There's a great deal of fragmentation in terms of logging approaches and implementations used within GitLab - this has manifested itself in the form of numerous incidents as well as increased friction when attempting to investigate and marry up logs being emitted from different components. This epic will capture the work necessary to resolve this issue holistically, as well as lay the foundation for future strategic Labkit work that the developer experience stage will facilitate. ## Outcomes * [x] We have defined a pattern that addresses the problem of inconsistent field naming conventions across all of our main language runtimes * [x] We have a document in place that helps to guide developers on the best practices * [x] We have investigated any possible duo linting or danger checks that will prevent further high-dimensionality fields from re-surfacing ## Important Considerations * We want to ensure that we have consistency across all of the language runtimes that we cater for today. Go, Ruby and Python should have the same intuitive setup to make it easier for developers to jump from one project to another. ## Considerations * Implementation and delivery of a Go-based linter for fields isn't within scope for this epic - this will be done only once we've migrated all of our core systems over to the v2 LabKit package so that we can get the most impact from that work. ## Want to chat? Feel free to join us in the project channel - [#devex-log-field-migration-efforts](https://gitlab.enterprise.slack.com/archives/C09JQ7L1QDS) - on slack ### Status <!--STATUS NOTE START--> ## Status 2025-12-17 :clock1: **total hours spent this week by all contributors**: 27 :tada: **achievements**: - Doug and Peter have made great progress on the Ruby linting process. We've talked through the high-level process for deprecating fields in production whilst ensuring we're not blocking our engineers. Some additional details on current state can be found here - https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/4094#note_2959843366 - the tl;dr is that we need to finish validation and do some final tuning of the implementation :excellent: :arrow_forward: **next**: - Continue validation of the initial implementation and ensuring it's fit for purpose prior to rolling this out to the monolith. - Once it has been rolled out, we'll be walking through the process with a few select, high-impact fields. _Copied from https://gitlab.com/groups/gitlab-org/quality/-/epics/235#note_2958571442_ <!--STATUS NOTE END--> ##