@open-telemetry/instr-wg FYI.

@jsuereth An OTEP that is probably relevant to be in the Linked Issues list: open-telemetry/oteps#199

This is another relevant issue:

• Fixed Schema Telemetry Producers can't be declared stable #2606

I'd love to help with

• data-model + signal compatibility
• Semconv buid-tools

Thanks @lmolkova!!! I've added you to the staffing section.

I am a maintainer for .NET SIG, and can sign up for reviewing any prototypes in .NET.

I am a maintainer for .NET SIG, and can sign up for reviewing any prototypes in .NET.

Slight correcting : As maintainer, I am anyway expected to review all PRs. What I meant to say is - I can prioritize reviewing any PRs directly contributing towards Semantic Convention/Instrumentation stability

Thanks @cijothomas !!! added.

I'd like to help/continue working on Schema File related stuff. I am not sure how much time I can allocate to this, but at least I want to review all relevant PRs, even if I cannot submit them myself.

I've put myself as the Second TC Sponsor and assigned this issue to myself.

@tigrannajaryan Understood. Added you as specifically interested in schema-files. Appreciate the caveat on time and definitely don't want you to deviate from your current responsibilities here.

@reyang Thanks much for signing up as sponsor!

I'd love to be involved with this and can sign up to write any codegen targeting Java (whether the codegen itself is written in Java or not)

I am a Python maintainer and would be interested in reviewing prototypes in Python.

I can sign up as well, I'm a JS approver and a JS Web sandbox Maintainer and a member of the Client RUM Sig

I am a C++ maintainer, and if it helps, I can be a member to review/approve prototypes in C++.

I can sign up as well for the following parts:

• Signal experts (metrics/logs/traces) willing to work on data-model + signal compatibility

Especially in the context of open-telemetry/oteps#199 can help with classification of which fields work well for different types signals and backends

• Engineers willing to write prototypes / work on tooling

I've lead similar specification work to drive codegen @ Elastic, can definitely help scope efforts.
Most likely won't have time to actually put my hands on the keyboard to spin out a prototype though.

@Mpdreamz thanks! I've updated the issue description by adding your name. Which programming language would you prefer for prototyping?

Thanks to all folks who are interested. Please fill out this doodle of your preferred meeting time, ideally before friday as I'll be scheduling our first WG call next week.

Note: We are only selecting the timeslot not the specific date. The goal is for this meeting to happen every other week until the task list is complete.

I'm currently working to develop some go receivers and have prior experience with jinja+python, would love to join the committee.

For folks working on semantic conventions. Here's a set of guidelines for avoiding what we expect are breaking changes:

• Attributes defined for traces/logs that may be shared w/ metrics will likely have cardinality restrictions applied to them going forward.
• Attributes/Resource definitions will likely be rejected until we have better refinement on Resource/Entity (see Refine which attributes of Resource contribute to Metric Identity. #2775)
• Metrics definitions that mirror existing structure a likely to be ok (i.e. the report against a similar resource as today, the have similar labels). There may be changes to what RESOURCE a metric reports against going forward.
• There may be some changes that occur to match (or have simple mapping to/from) elastic common schema. This is less likely to affect metrics, but may affect traces/logs/event semantics.
• At some point, uniformity / machine-readable format will be required for all semantic conventions for all signals. Any table for metric/logs should match existing structure or update ALL tables with new fields + justification of the new field. Be warned, this means additional scrutiny and may be worth discussing separately from the semconv change itself.

Hi experts, could anyone share the latest updates on this project please? My team is waiting for the official version of instrumentation libraries to unblock roll out to production. Thanks!

I can join the effort as a code owner of the collector metrics metadata format and the metrics builder:

Go / OTel Collector code-gen

BTW I recently proposed guidelines and stability guarantees for that part of the collector, in case anyone is interested: open-telemetry/opentelemetry-collector#6358

@lsl-2020 you can check the meeting notes to see what was discussed in the last meeting: https://docs.google.com/document/d/10xG7DNKWRhxNmFGt3yYd3980a9uwS8lMl2LvQL3VNK8/edit

Closed as no longer relevant due to refactoring of semconv SIGs