represent API and production maturity of the many components of OTel about opentelemetry.io HOT 5 CLOSED

Some thoughts -

Externally, it seems like the most important things to me would be an 'overall' gauge of readiness. We should be able to hide the details in a dropdown or collapsible row. We can also do some iconography/badges to represent maturity/doneness. The following illustration is a rough sketch of what a collapsible element would look like, I think.

In addition, we can link from the language to the registry for that language.

from opentelemetry.io.

It may make more sense to represent non-language-specific projects like the collector and operator as items under individual headings rather than making them part of the main table, but I don't feel strongly about this

from opentelemetry.io.

@mtwo re

It may make more sense to represent non-language-specific projects like the collector and operator as items under individual headings

Totally... had the same thought. I don't feel strongly about that.

IMO the most confusing thing about my proposal is that we have two concepts of "an API"... both for context/trace/metrics, and then for every component across the board as part of the "maturity level". From a nomenclature standpoint that is not great, even if the distinction can be defined. I don't have a better suggestion, though, or I would have made it. ;)

from opentelemetry.io.

left unspoken in my prior comment is a general question of 'ok, so what's the "overall" doneness and imo it should be the SDK maturity

from opentelemetry.io.

This is basically accomplished for overall maturity, and each language SDK represents this info in its respective place. The statuses get bumped by maintainers as well, so the system seems like it works! I'll close this out

from opentelemetry.io.