How to reflect experimental features to spec compliance matrix

[jack-berg]

As discussed in the 4/2/24 Spec SIG, the spec compliance matrix is ambiguous in terms of how to represent experimental features:

• Should experimental features be given rows?
• How does a language indicate the stability of its implementation?

By representing this information, we can use the spec compliance matrix to track implementations of experimental features, which are a prerequisite to stabilization. Additionally, we can convey to users that stability of a particular feature in a language.

[jack-berg]

Related comment from @carlosalberto: https://github.com/open-telemetry/opentelemetry-specification/pull/3984#issuecomment-2037422772

A good question is whether this should be updated once a feature has been released as well.

What I'd like to see:

• If a feature is experimental in the spec, flag that row with a symbol indicating so
• If a language's implementation of a feature is experimental (regardless of whether the spec feature is experimental), indicate it with some symbol (maybe the test tube emoji 🧪?). That would mean that each cell can be checked with:
  • + Language has stable support
  • - Language does not have support
  • (blank) Language has not yet indicated status of this feature
  • N/A Feature is not applicable to the language
  • 🧪 Language has experimental support for feature
• Only set status to be 🧪 or + if the support is released. Feature branches, PRs, etc don't count.