@KSarabia-WMF: Assuming this task is about the MediaWiki-extensions-WikimediaEvents code project, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects. Please set appropriate project tags when possible. Thanks!

Tagging data products per https://www.mediawiki.org/w/index.php?title=Developers/Maintainers
The conflicting eslint rule is a little confusing and leading to schemas using both camel case and hyphen case so it would be good to get aligned here.

Currently, about a couple dozen WikimediaEvents event object keys have camelcase values causing us to have`/* eslint-disable camelcase */` in multiple places.

At the time of writing the are 10 instances of eslint-disable camelcase in the WikimediaEvents codebase.

I do think that it's worthwhile reducing this friction/confusion but I think that we should be clear about the scale of it.

This also doesn't match the secondary schema requirements which does not accept events with fields using camelcase values.

But it does match the MediaWiki Javascript coding conventions around naming variables. That said, there are extensions in production that do defy the convention: https://codesearch.wmcloud.org/deployed/?q=camelcase&files=eslintrc&excludeFiles=tests&repos=

In T347357#9200481, @Jdlrobson wrote:

Tagging data products per https://www.mediawiki.org/w/index.php?title=Developers/Maintainers

Thanks!

The conflicting eslint rule is a little confusing and leading to schemas using both camel case and hyphen case so it would be good to get aligned here.

Legacy EventLogging placed no (or very few?) restrictions on event property names. The Event Platform enforces snake case for event property names but those Legacy EventLogging schemas that were migrated are ignored. We will have this confusion for as long as we use migrated Legacy EventLogging schemas.

With the above in mind, can I propose that we disable that we disable the rule for property names only (e.g. variable names using snake_case would still trigger an error):

{
	"root": true,
	"extends": [
		"wikimedia/server",
		"wikimedia/mediawiki"
	],
	"rules": {
		"camelcase": [
			"error",
			{ "properties": "never" }
		]
	}
}

This would reduce friction for instrument developers working with all schemas while following the coding conventions as closely as we can, leaving developers to review concepts and implementations.

can I propose that we disable that we disable the rule for property names only

Yes that seems like a good idea to me!

@Jdlrobson Do you need anything further from us?

@WDoranWMF as far as I can see we didn't implement https://phabricator.wikimedia.org/T347357#9203630
My expectation was that Data products would be responsible for doing this. If not, let's discuss and retag accordingly !

Change #1020863 had a related patch set uploaded (by Phuedx; author: Phuedx):

[mediawiki/extensions/WikimediaEvents@master] modules: Disable camelcase errors for properties

https://gerrit.wikimedia.org/r/1020863

Change #1020863 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] modules: Disable camelcase errors for properties

https://gerrit.wikimedia.org/r/1020863