[Usage Collection] Create rules to enforce common best-practices

[afharo]

Let's create a set of rules to ensure we follow common best-practices when naming fields, structuring them, etc.

• [ ] Prefer snake_case fields
• [ ] Do not include the name telemetry (i.e.: maps-telemetry).
• [ ] postfix date type field names with _date
• [ ] postfix _in_bytes or so for byte size number fields
• [ ] prefer using x_count instead of number_of_x
• [ ] never use _all
• [ ] avoid duplicating namespace in field; example workplace_search.workplace_search_ui_errors use workplace_search.ui_errors instead.
• [ ] ??

cc @thesmallestduck @alexfrancoeur to help me fill up the list.

Q: Should they error or only warn? I'd try with error first, and if there are too many, demote them to warnings. WDYT?

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[Bamieh]

what is the plan for handling all the changed field names?

I have some rules in mind:

• [ ] postfix date type field names with _date
• [ ] postfix _in_bytes or so for byte size number fields
• [ ] prefer using x_count instead of number_of_x
• [ ] never use _all
• [ ] avoid duplicating namespace in field; example workplace_search.workplace_search_ui_errors use workplace_search.ui_errors instead.

[afharo]

@Bamieh, thank you for the additional entries, I've added them to the description.

Do you think it's worth separating between errors and warnings?

what is the plan for handling all the changed field names?

I was hoping we could implement most of them with eslint-rules, so, ultimately, devs already reporting fields that do not match these rules can disable it for "legacy" purposes. What do you think?

[Bamieh]

Do you think it's worth separating between errors and warnings?

I suggest throwing errors if we will be only affecing new changes. I believe using warnings will clutter the logs quickly making it useless noise.

I was hoping we could implement most of them with eslint-rules,

Sounds good!