Just want to bring this comment from @dmitryax from #212 (comment)

I'd also suggest bringing metrics currently emitted by Collector receivers but not defined in the semantic conventions. There must be plenty of them with pluralized namespaces. Maybe they can influence this decision. I can do that exercise if it makes sense

I think we probably should do that before moving forward with this? If that has a large impact maybe we should reconsider things? CC @trask @jsuereth

@joaopgrassi @mx-psi I don't think removing pluralization will be reconsidered (it actually already happened in the specification), but what we WOULD do is figure out how to provide soft/easy migraiton for users and avoid continual churn of this decision.

@jsuereth sounds good!

For the metrics we have today in the conventions I think we are fine, I'm just a bit worried with the ones from the collector, as described by @dmitryax here.

I guess we will just have to come up with new names for it, and probably a general guideline for situations where removing the s from the namespace, render the new metric name confusing/useless, like redis.clients.connected -> redis.client.connected. I think this will be a recurring topic.

@joaopgrassi I think the example you list is clearly the case where it should be redis.clients_connected or redis.server.clients_connected vs. redis.client.connection.count, i.e. i'm not sure client or clients is a viable namespace for that one, nor is it clear what it's referring to.

In other words, I think we should continue with merging this PR and work on clearing up semantics of existing metrics for clarity.