Should new metrics and attributes go first through SemConv?

[ChrsMark]

Component(s)

No response

Describe the issue you're reporting

Right now there is no specific guidance on whether new metrics, attributes, resource attributes etc should go first through the Semantic Conventions project.

However for some components (i.e. hostmetrics receiver and the k8s related components) this has been a "soft" requirement recently. Some examples:

• [HostMetrics Receiver] Add support for process state opentelemetry-collector-contrib#33731
• Extend Kubernetes Attributes Processor to support Container Ports and Container CPU Request opentelemetry-collector-contrib#37862
• [receiver/k8scluster] add attributes to node and pod entities opentelemetry-collector-contrib#36862

This has also popped up at open-telemetry/opentelemetry-collector-contrib#40191.
Also it seems that there is no related guidance as part of https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/scraping-receivers.md#defining-emitted-metrics.

It's still to be defined how Semantic Conventions will affect components' stability as described at #11878, however prior to the stability concern I wonder if we should update our contribution guidelines to cover for this "soft" requirement already.

The requirement can either be that new metrics/attributes should first be added as Semantic Conventions or make it more lenient and just ask for filing an issue against SemConv project so as to keep track of them. Both can be an option depending on what components' code-owners judge for each specific PR.

[ChrsMark]

Raised that with Semantic Conventions SIG on Monday's May 26 2025 meeting. It seems that there is agreement that we should seek for coordination between the 2 projects sooner rather than later. However, each case should be considered separately and I believe it should be code-owner's responsibility to drive this.

I have filed #13101 to propose this "soft" guideline.