<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=396269) </details> <!--IssueSummary end--> The following discussion from !113724 should be addressed: - [ ] `@mkaeppler` started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113724#note_1311096791): > This is not really what I had in mind; you are still mixing GitHub implementation details with a generic class that is used for imports with a different source :thinking: > > I see this was already the case with `track_usage_event` before this change; let's create a follow-up to unblock this MR, but I suggest you discuss this with ~"group::import" since this is a design smell, given that `Gitlab::Import::Metrics` is used in all kinds of places unrelated to GitHub imports. It appears we have an implementation leak in this class; it is used for many kinds of imports (e.g. BitBucket) yet contains GitHub-specific tracking logic. Because of this leak, it uses defensive code such as early returns in cases where the source is not GitHub. A better approach would be to inject a specific tracking implementation into this class so that we can always delegate to it. In cases where we do not want to emit any events, we can use a [null implementation](https://en.wikipedia.org/wiki/Null_Object_pattern).