-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to reflect experimental features to spec compliance matrix #3976
Comments
Related comment from @carlosalberto: #3984 (comment)
What I'd like to see:
|
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). |
We had a discussion in the 9/25/2024 TC meeting. The direction we would like to see: use YAML to capture things in structure and generate the matrix and docs using tools + automation. Breaking it down, these are what we need:
I'm willing to tackle item 1). We can use this issue to socialize the idea and who is willing to cover 2) 3) and 4). |
@reyang I made you the sponsor of this because you said you will tackle item 1). Re-assign sponsorship/assignee based on who is going to tackle the other items. |
This has been on my mind! Ruby has experimental support for metrics and logs, however, we don't have a great way to communicate what features have been implemented. In addition, some features have been released, others are in progress/under review. As a first step, I transformed a table I've been using in a Google Sheet to track metrics compliance into a markdown table. The rows in the table are copied from the rows in the spec compliance matrix. The GitHub column represents either an issue or a PR related to that line item. I don't think this is quite the right solution, but perhaps it gives us something to build from. open-telemetry/opentelemetry-ruby#1746 I really like the idea of using yaml to track this, it seems much more maintainable than a markdown table. |
As discussed in the 4/2/24 Spec SIG, the spec compliance matrix is ambiguous in terms of how to represent experimental features:
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.
The text was updated successfully, but these errors were encountered: