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: #3984 (comment)

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.

[codefromthecrypt]

I would like to see a description section on notable language patterns of how to address pre-supported specs (e.g. those using experimental or otherwise gates, but having code available). These could be one or two word summaries that link-out to a language SDK repo.

After that description, I would like to see a chart of one line per spec per language which is a summarizing status. This would include both a representation of WIP (even if only a PR), and a link to where to track further (README, PR, tracking issue, etc).

The combination of both would allow people to quickly gauge how finished a spec they may rely on in a SIG is, even if they may not know if it is 6 months a year or longer out. Importantly, the links can help them contribute towards completion.

---

Currently, the compatibility matrix has no summary table, which means you can't tell a notion of work in progress independent from no progress. Nor can you tell, yet where to look for status for the same reason.

We also lack a description of language-specific norms, such as some having experimental or incubator, where as others implement a spec via integrating PRs

The above combine into a situation where new contributors or those unfamiliar with this have a hard time assessing the landscape, especially overall status concerns that lead to promotion (such as 3 languages implement X). Case in point is the LLM SIG, which recently relies on the Event/s API, but has no clear way to indicate to users how WIP anything is at this point. To that end, I've attempted to replicate a status including where to participate in a tracking issue, but think it should be top-level and part of norms instead.

To me, this is not solely about knowing for example that there is work at all on certain APIs like Events, but also how to help. So, that's why I'm not just asking for a new character, but one allowing a link. I would go so far that in a cool world, the completed status also have links as it is not always intuitive where to look, but want to start with this as it has come up twice for me (event api, file based config).