-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add and enforce analytics naming convention #9318
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
馃憦馃徏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 馃殌
(Assuming the existing exceptions will be added before merging?)
[documentation on them in our handbook][analytics-handbook] | ||
[documentation on them in our handbook][analytics-handbook]. | ||
|
||
> [!NOTE] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL the note syntax!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're there, but the changes are extensive so GitHub's changes preview collapses the file. |
changelog: Internal, Analytics, Add new naming convention for analytics events
70947c9
to
5bfcff1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Would track_event(__method__)
be acceptable or is that too opaque? (For the record, I am 馃憤 with this PR as-is)
Hmm, interesting idea! I don't personally mind it. It does come close to being "clever" programming, but I can't really imagine a scenario where I'd probably lean toward keeping this as-is, but I don't feel strongly at all; mostly just care about having it be consistent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for doing this!
I can imagine that in the future we might want to require the method name as the first part of the analytics name and allow additional words afterward, but we can always add that later if we find we want it.
I'd be curious what this would look like, since my instinct would be that if it should be included in the event name, it could / should also be reflected in the method name? |
Thanks all for the feedback! As mentioned in Slack, I'll plan to merge this and we can see how it works out. I'll also try to search for open pull requests that might fall victim to this if merged to main without accounting for the new linter. |
馃洜 Summary of changes
Adds a new custom Rubocop linter to enforce a naming convention for analytics, expecting that the first argument to
track_event
should be a symbol with the same name as the method.Good:
Bad:
This was discussed in Engineering Huddle 2023-10-05 (see notes).
The proposal here would not retroactively update existing analytics, but would enforce against all new analytics events moving forward. This is done by adding inline Rubocop disabling for existing events.
馃摐 Testing Plan