Liudmila Molkova

We are now focused on shipping core features of OpenTelemtery and getting to the stable version. We will definitely consider Dapper collector after that. In the meantime, we accept contributions...

We also use [Distributed Tracing Extension in Azure SDKs](https://docs.microsoft.com/en-us/azure/event-grid/troubleshoot-issues#distributed-tracing) and it would be great to see clarification on how it should be used in the CloudEvents spec. I have a...

> One tangential way to help with this is Telemetry Schemas. By allowing to formalize this changes in Schemas we make the change more manageable. What we are likely missing...

/cc @joaopgrassi @blumamir @pyohannes @dpauls

> Have you thought about how this would be represented in the protocol? The same way as today (in both cases) - using [span.links](https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.proto#L224) that already have all the properties...

@Oberon00 agree that if we follow 0-span duration path, backends need some heuristics that tell it's a span created for message. I believe we can do it with PRODUCER kind...

Attributes should be on links to message context, not on spans. Reasons: - messages can be forwarded between brokers preserving the context (i.e. span is created on the first service,...

> I don't understand. If we used zero-duration spans, of course it would make sense to put the attributes on the spans, and have the publish span as parent, and...

> Why can't service B not create a messaging span? Service B can create a span, but then it has to modify message context as well. Now let's assume ServiceB...

> This multi-tenant/multi-vendor problem can & should be solved with per-tenant/per-vendor tracestate entries. Sure, but let's make sure we keep the routing/replication/forwarding/sharing discussion on. Service-meshes would be first to hit...