 A wild Ted appears. Hello, hello. Welcome back from your vacation. Yeah, it's good to be back. It's also really great to be on vacation. I'm excited to get caught up. We just put everything on hold while you were gone, Ted. No. So. The only major decision was to remove O-Tep 66. No. It's officially troll Ted day. I am particularly excited to get caught up with the state of the point three spec and beta planning. I don't know how much that is relevant to this meeting. Point three specs. I would say very, very. And that is mostly because we are behind. The expected date. I think it's a little bit of a shock. On the other hand, we only have a pair of issues to mention about that. So we don't have to spend the entire hour. Oh, good. By the way, but yeah, it's great to have you back. It's good to be back. Thanks. Okay. So let's wait a few minutes. I would recommend. I think Bogdan is probably going to make it. Okay. So I'm going to sign in on the agenda. And please add any agenda items. I know this sounds super weird, but it is vaguely unsettling to be one of like four people with their video on. I can start my video. If that makes everybody feel. More in line. I'm guessing people's time zones for the quantity of light. Yeah. I think we can start one more minute and then we can start. Okay, I suggest we start. I think that we are not getting Bogdan nor jury, but we could go ahead. It's due. Right. Okay. So the agenda is that the first item is the tagging, you know, for this release. Yeah, I hope we can actually make it. We still have to on the context propagation side, we still have two items. One item is the tagging. They have been receiving a lot of reviews and we have been writing both Alex and me on each PR. And I feel that we are very close. They're having minor details in the last days, but I do feel we are very close there. The only problem is that we need to get more actual approvals. So we need to be very careful when the time comes. Yeah, but I'm pretty confident. That if we focus on the very, on the most important parts of this PR, we can merge them for this milestone. There will be other things that we might want to probably improve, but that can be done. On the next milestone, you know, things that are not so important. And then we have the metrics update. So maybe you want to say something. Yeah. Hi. So 430 PR 430 has an update to the API, adding observer moving age. And is I think ready. I addressed all the comments I had pending last night. And so if you're part of that review, especially Chris and Tyler. And the rule. Very appreciated. I think please take another look and approve. Okay. So I think Chris has approved at this point, but I've, all the feedback was very supportive. So I think it's, it's ready to go. And then I just want to mention that I think it's okay to snapshot. 0.3 right now. With that in, there are two documents that are out of date still in the spec. They're not controversial. It's just that there's some, there's, there's extra text about all the user, all the API that is not updated yet. And I think it's okay. Perhaps what I should do is send a quick PR to say, to update those documents saying these are out of date. See how I'd like to see what other people think of that. Yes. Okay. Specification. We'll come next. That's a work in progress already. It's PR 347 or something like that. I'm at this point interested in help. I've become a little, a little fatigued by all this metric. Spec work. And it seems to me that. Others are both motivated and able. So I'm curious if there are volunteers who would like to pick up any of these tasks. That I just mentioned. Because it, I seem to be the bottleneck at this point. And I have a few other responsibilities. So anyone who's interested, please talk to me. And I think that's it for metrics. Yeah. Maybe we can get somebody, you know, he's already involved with the way to do that. That would be great. Yeah. I have some people on mind. I just don't let them talk to me. Nice. All right. Okay. That sounds good. So yeah, it sounds like we can do the actual tagging this. By the end of this week. So that, that sounds, sounds great. Yeah, I agree. There's a chance that I could update those two documents really quickly. And nobody will disagree and we'll just get those merged, but we'll, we'll try. Right. Okay, great. Okay. So I wouldn't get started. We probably with either Ted or Bogdan or you, Josh to prepare the actual tagging. Okay. We can talk about that. Okay. The second item is about actual reviews. And this is something related to the, to the, you know, to the premiums PRs is that we really, really, really need more people paying attention to that. As I said, we really have a lot of people actually, you know, providing feedback, which is great. And it's something we really need. What we also need approvals and because of the requirements, you know, I would have expected that he wouldn't have been so hard because we only need to approve us at a specification level, but still it has taken a lot of time. And one related issue is was filled by Judy about. That he's, he's feeling that there's not, you know, a consistent state regarding votes. Judy is not here. So I guess we can discuss that offline, but it's basically about the fact that we need less votes on the specification PRs. And we need more votes, like four or five for the, I agree that's irregular and odd, even though it's been convenient to get, to get work done in the spec repo, I would, I would support changing it to be the same. Well, if you ask me, I think that Oteb related changes should need more votes. And other minor things in the specification to vote is fine, but Oteb related changes, they should need more. But first, we need more of you. Yeah, I think you're probably right. There's a judgment call. Like for example, my metric spec is a big change right now. And I think it's, you know, I think you're probably right. There's a judgment call. Like for example, my metric spec is a big change right now. And I think it's, it's probably something that does deserve that many reviews. Please review that PR everybody. Yeah. Yes. And yeah, I just, just remember that I think that everybody's concerned about speed, but if we don't get approval, as you know, this is going slower. So please. I think that if we could try to actually put more attention on this, this would be really nice. You know, especially with the, with the beta that we are trying to target. That was mentioned last week, you know, prior to cook on or to console. Yeah. Okay. The next one. Okay. Low priority. Race issue with at link after creation time. I'll step in on this one quickly. I wasn't present to the original discussion when this characteristic was removed. I think it was removed last year. I think bogged down put in the PR. I just wanted to highlight a scenario where this would break the type of scenario I deal with frequently and wanted to get somebody to consider it to see whether an amendment is worthwhile or not. Having said that, obviously you guys have your hands full with all of issues. So no brushes wanted to kind of raise it as an issue. That's all. Yeah. I think there was some discussion of allowing samplers to reconsider the decision, but I don't think that's in scope for 0.3. So I think that we should probably punt this. I think the lasting solution is, you know, reconsidering the sampling decision, but we won't have that for 0.3. So let's punt. Happy with that. Can you just give me some rough understanding of when, kind of, would you be looking to address this type of issue after 0.3? No pressure. I just wanted to understand when the right time to jump back in. I would hop in and say, we want to release a beta for us, the languages that got an initial, whatever that initial five or so languages. And if people are mostly satisfied with 0.3 version of the spec, we kind of want to get those into beta. And then we could start looking at, well, what's awkward here in terms of practical reality? What do we need to shift and have that be for the beta work? All right. Thank you. Ted, just to kind of clarify on that, it's mid-March is what we're looking for the beta, right? Okay. I think so. I actually added it, the last agenda item, like what's the current state of beta? Yeah, mid-March, mid-March. All right. Thanks for clarifying. All right. The next item is please review. Sam gone for messaging systems. I mean, is Armin here? I am. Great. Okay. Maybe you want to elaborate on this? Well, it's the semantic conventions for messaging systems. And I opened it like three weeks almost. They go and didn't get any reviews so far. So please take a look. Okay. Yeah, makes sense. I think you got an approval from Josh. Okay. I will review that myself. Yeah, definitely today. Sorry. Okay. Yeah. It was a follow up for Kevin Brockhoff's PR. And I think he got approvers for his PR as well. So yeah, it kind of goes together. Great. And yeah, please. Yeah, Josh, you know, and we work at the same company. So we need people from different companies giving an approval. So please review guys. Okay. So the next item is. Please reopen RPC send calm issues. Yeah, I mean, maybe you want to mention this as well. Yeah, those were closed the second time without actually being resolved and I think Christian commented to have it reopened but that was missed apparently. So please do that. It's because RPC semantic conventions only cover and only allow G RPC so far and not RPC systems in general. So stuff like the RPC system being used and maybe also the RPC method being called should be part of the spec. And those were the issues tracking that to do. Yeah, I am not up to date. So we'll review after this, this call. What if anybody else. Yeah. I'll have to take a look, but I'm, I'm going to make it my priority to be very responsive on specification issues. Seems like the biggest bottleneck. Yeah. Thanks. Great. Okay. The next item is whether it is acceptable for six to add language specific. So is there a specific method like convenience methods without specification change? Yeah. I raised this one because of a question in the go say yesterday. And it seems like in this particular case, there are other sigs encountering the same issue. So it is appropriate to raise it the spec level. The question is just, is this blocking or is this a thing where we can do our own things and then harmonize after. Is that convenience methods on the API or just in the SDK? I'm API. Yeah. This is a night, something that's near and dear to my heart. I haven't been talking about it just because I didn't want to distract, you know, from getting like the core beta stuff at the door, but. It's certainly my experience from open tracing that there's lots and lots of convenience to be had. And that we absolutely should have a package of like convenience and helper stuff. As far as like, should it be mixed in with core API stuff or should it be separate package? I don't know. I would say the. One thing I'm curious about is to me, there's like two kinds of convenience. I think the one where I think there should doesn't need to be any approval or much too much thought is any. I would define a convenience method is one that calls down to lower level API methods, right? So as long as it's at like a higher level of abstraction than like, of course, I think that's fine. And, you know, you don't need to have a spec change or something like that. If it's something that can't be implemented. In that manner, I think that's sort of like a yellow flag of like, you know, is something really missing or wrong here? Okay. So it's then encapsulation boundary of if we're chain mutating private methods or otherwise allowing access to underlying things you wouldn't otherwise get great. Okay. That would be, yeah. If it's not doing that, then I would say it's like totally fine. Yeah. I've approached this in the spec work by making a bullet in the spec that says optional. This is something that languages should probably consider if they're going to do it, then do follow these recommendations. If you're not, there's justifiable. Like I was thinking about it last night. We've introduced a notion of a timer metric instrument, which is just a measure instrument where you force the units to be correct and you, and you force the, you know, the type to be correct for the built in type timing type of the language. This is just a convenience, but you can imagine there's SDKs that just like don't care if there's, if there's no built in time type of your language, maybe you don't care. There's no time. I mean, like you have an execution environment with no clock. Maybe that's possible. So it should just be less, I like to list those as optional in the respect. I would say this is a little bit of a segue to the next item on the list. If people are ready for that. That particular method, what I looked at it was about recording an error on a span. And I just wanted to highlight there are, there's some work in flight about recording errors. The first two bullet points there are recording them as events. And the first one is mine. It's, it's really simple. The second one is kind of an extension. That's this guy, Vladimir made. I think there's been less eyes on it, but it works for logs in general. And I think it's definitely worth looking at. And yesterday, just to try to convince myself, if one was a clear winner over the other, I wrote a little bit of code, which is in kind of the last comment on both of them. And I felt like both of them were actually super reasonable, but I felt like that code looks kind of like boilerplate and could definitely live in something like a span record error or something method. So I think once we get conventions around recording errors, we may find that we want one of these methods on our spans, most of us. But at any rate, have a look at those things, comment on them, especially look at Vladimir's, because I think his approach covers a little bit more than mine does. And then there's also an approach by, by Kevin Brock, for type span events. I think between these three, some sort of fusion between them, we can probably come up with a reasonable story for errors. I think it's probably not a V zero three thing, but probably definitely a V zero four thing. Yeah, I agree. I don't think, I don't think there's enough time for this milestone, but this is something really important. And yeah, we really need to get more eyes to really include this in the next one. Yeah. Okay. So to prep things back around to this instant case of the go stuff, basically we should go for it. And then if we need to change it for 0.4 when there's more specification around how we handle errors, we can tighten it up. Great. Yeah. Yeah, great. Okay. And Matt, do you want to elaborate more on the errors part? I guess that's all for, I don't know if you want to. Yeah. I think that's all I had to say. If you do look at those comments and you look at the code that I wrote down there and you wanted to like write some up for your language too and just paste it in for fun. Yeah. Yeah. Yeah. So just to help kind of like, you know, lobby for one over, over the other, like that could be interesting and help us make a decision. Great. Perfect. I have a request on that topic. Actually it's a little off topic, but I would like to have a new getter rooms to discuss errors for one and sampling for another. I think that these, I don't know how to make a getter room though. So if someone could help, I'd like to create new two new rooms. And I have things to say about both of these. Sure. I can help you with that, Josh. Thanks. So cool sampling and errors. I said, you could just mention that in the general channel. So people are aware of that. I'll be happy to do that as well. Yeah. The final item on the agenda is a better planning. Like what's the current state. So yeah, I don't know who, who wrote this. I wrote this. I'm just getting back. And I did hear there is. Some planning. I didn't think I saw. Something Morgan had written down, but I was just curious. Like how widely all of that's been discussed and sort of what the current current state is. I don't think it's been discussed in this room enough. We did mention it. I think last week. And I have only part of the conversation. To speak to right now, but I know that in the middle of the call last week, there was a little bit of discussion about metrics views. We use this term to describe sort of alternate configuration of aggregations, potentially multiple aggregations on metrics. Since this open census had this and I was a little, I guess this things, things went unsaid since last summer, but, but basically I always considered this to be an STK. So, because the mechanisms you're going to use to implement these are going to very widely the supports that you're going to have are going to very widely. But that's not necessarily. Open and closed case. You certainly can identify a subset of views that are sort of universal at some level. Calls for a way for users to be able to configure. So, you know, this was said without any further discussion that that is a requirement for the beta. And there's just not time. And I'd like to call it an STK API, even though. I don't, I don't know what people think, but I see like with sampling, there are so many ways to implement this. So, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, the different types of views of the beta. So, you know, like with sampling, there are so many ways to implement this type of functionality that we're, we're hurting ourselves by pinning it. Pinning down an API right now. So I would like to leave this out of the beta. And I hope other others agree, but I don't think that the OpenCensus team quite realized is that this has happened. And for the most part, I think we need Morgan to get on the call and talk to this. Okay. but something that we need is what it sounds like we need like two basic things. One is like a posting of like uh what does it mean to get a language repo to beta like what do we want to see in there before it gets called beta and then I think the other thing is once we're in beta does that change like our release patterns or return to to tighten certain things up. uh Liz I know you had done some work in the past sorry I caught you just as you're eating I know you had done some work in the past on on proposal for like what a beta would mean but I think you would walk it back a little bit is maybe being too complex I'm wondering if there's been yeah what I had originally proposed was you know having this discussion of like hey you know beta does not mean that you're not going to be expected to update your SDK right like you know please update your SDK regularly or else you will potentially be sad and broken so we may as well you know be proactive about breaking you rather than than have you be surprised and sad okay but then I walked it back because it was excess of complexity at the time okay so there's like how do we run a beta this seems like that's still something we we need to get down on paper and get some agreement on yeah right like it's a two-way contract right it's the contract of our users need to understand that this is stuff that is evolving and then on the flip side we need to be prepared to release often and on a more predictable cadence than during alpha great I also I was just looking at the list of the launch notes there like I just think we're setting ourselves up for failure by saying this can be done in mid-march unless we cut scope and like some of the stuff in here is hasn't even begun like no language implementation has an otlp exporter right now and it's pretty close to march so I'm just like and that's not an API change either so is do we really need to get beta on saying every language has specced every feature plus all this list of like support that is not already API I think it's it's gonna create a miss essentially so I would vote to cut scope like otlp export doesn't have to be done in mid-march but maybe that is the thing that we should all be emphasizing and focused on right in other words there's there's two kinds of things that we want one are like big lifts right like adding metrics to the API or like a big SDK or API change to conform to the .3 version of the spec so maybe we should say the conforming or implementing implementing the .3 spec is most important and then things like exporters and other stuff where those are purely additive changes right not necessarily things that are related to the spec you don't necessarily have to gate the starting the beta on having those things beta is more about saying like this API this SDK kind of looks the way we think the final one is going to look and so please try it out so it seemed like a good interpretation of your request was that a question to me yeah this question I don't know gatekeep on just implementing the .3 spec but not on like there's like additional stuff like yeah there's a lot of stuff listed there that's not really quite in the spec and it's like it's stuff that the SDK spec says so that's that's kind of the high level for me is are we are we finishing the API and the SDK for beta right now or is it just the API? I just think just the API is reasonable but I think the rest if we just throw all that in is hopeless not that I would add into the collector by the way and the protocol right you mentioned or well the collector work is underway like that looks like it's going to happen but but every language I mean this document says every language is going to have an exporter for that and in addition to other things that we've you know have in fight okay it's your point cool okay I'll I'll follow up with Morgan and I think we have a community meeting tomorrow afternoon maybe we can get a hustle going and have some some kind of proposal ready for that community meeting because I would like to get that nailed down and then like up on the project project status page of the website in a way that's a little more concrete oh by the way there was some related action in the community repo there was like a maturity matrix I think Liz you and uh BHS were working on like yep that's correct uh BHS was proposing that we publicly communicate the state of each of that we don't have to reach beta across the board for everything that we can declare individual pieces beta ready piece by piece instead okay great I'll have a look at that that seems super relevant to this at least making sure there's alignment between what we're saying in that maturity matrix and what we're saying like a beta is yep that would be super great to have um yeah we put the change in the community repo but it's not uh firm and committed so we can make changes to make it conform to the launch plan okay what would help if this beta release plan was a little bit more like prioritized rather than just kind of a list of here's all the things that are going to be here kind of like an ordering of like here's the order in which you should probably do things um in case you are going to miss at least you have these like you know critical components or are you know at some reasonable level down that list just a thought um Liz are you interested in working on that beta contract I personally believe that it would be most appropriate for someone who is on the technical committee to drive it I am on governance but not technical okay I will find so that this is why Ben and I like proposed that this thing exist but you know we are not members of the technical subcommittee yeah I can probably help with that yeah well really we can collaborate you and me we can discuss that offline oh and there's a link to the maturity matrix do people have other questions about beta it sounds like basically getting a launch plan to like a proposal stage hopefully for the community meeting tomorrow to get sig maintainers to sign off on and then getting that up on the website is the next big step so I'm going to try to find that so just to clarify uh is the open telemetry specification repose milestone for zero dot three the list of prs remaining in order to close up to beta good question uh well yeah sorry the two ones related to context propagation are listed about metrics George might know I'm sorry I missed the question so if we're looking at the the actual milestone in the specification repo for the point three release question is that is that accurate is there issues missing from it uh I mentioned earlier that there are two documents that have not been updated they will be glaringly inconsistent um and it's either something I can do like in three hours or it's something that we should just update to say this is out of date we're going to follow follow up in you know a week and it's like there are two documents on metrics one was this is the high level big picture this is what we're doing and then here's the sort of detail on each method for a user's perspective that has not been updated that second document okay and then there's a missing document that would do the same for the sort of SDK facing API like these are the methods that you can call on a meter here's how you get a meter and that sort of thing like detail okay and those are actually listed uh they're not there's no there's no issues for these things that I'm talking about a couple more issues that have to get listed here okay I'll follow up with you on that thanks one other question on the the beta do we want to have the standardized attribute names for various attributes in the like the API as part of the beta you mean the semantic conventions yes that's the one uh I wouldn't keep starting the beta on having all of those in there but I guess that would be my reflexive answer getting back to like cutting scope okay because if you change those you're not breaking the API right you're just changing the data that's getting reported again that's right it's actually some kind of API right the semantic conventions yeah we'll probably have helper methods and things right to to produce this data yeah with it being key value pairs it looks so so innocent but actually it's an API it just doesn't have method names it has key value pairs yeah which is even worse yeah it's true um I think maybe related to that this is maybe under beta planning or maybe a separate agenda item but just writing starting to build the ecosystem and writing plugins for various libraries and frameworks I think there's been some debate about like where do those go should those be in like the core language repos or should those be in separate repos do we do one thing for the beta and then move them out somewhere else later just from talking different things it seems like different working groups have different ideas about what they prefer there but I'm curious does anyone have like are there any sig maintainers on the call who have like questions or issues around uh where the plugins need to live for the time being hey Deb uh yeah I would love not to make that a beta issue um it's it's at least in the python slug it's easy for us if we can keep them all in the same repo for now and then split it out in the templated repos later especially because as we make changes to the api it's much easier to test them when we're all using the same you know bit of ci sure okay this sounds great it also becomes impossible or very difficult I should say to fix plugins one at a time when they're different repos if you're making sweeping api changes still so I think putting like we can't start separating these things until beta is here otherwise it's just gonna lead to broken plugins great yeah actually we have the same for the open tracing sheen layer and it works great so yeah I could I could support these we can split them later okay um I do have uh one request on that front uh it's not a huge deal but we have the registry on the website and it would be great it's maybe just a background task for someone but it would be great to start listing all the plugins that have been written uh up in that registry um I'll see if I can get some people to help with that um just to start adding visibility to the project people come to that website so let me make a note here and likewise if if you want to write plugins somewhere that aren't in the core registry and you're just maintaining themselves maintaining it yourself because that's easier uh this is a way to to not have those plugins just get lost uh so it also suggests for people I think this maybe came up in the java javascript sig where they were trying to put the brakes on writing plugins because they didn't want to maintain so many I'm not sure yeah we just have a lot already yeah I've approaching 20 now 15 something like that more than anyone else I think for sure yeah so this would just be my suggestion rather than saying like don't write plugins like you could just put them somewhere else and then list them in the registry and then you know if they get broken or out of date it's just the responsibility of the plugin maintainer to to to deal with that can I ask a dumb question yeah what do we mean by plugins this isn't the term that I've been heard I've heard it all kicked around in these meetings at all maybe I think we use the term plugin and instrumentation maybe uh interchangeably do our exporters the same those also exporters are I think we have two kinds of plugins really right now one is like an sdk plugin like an exporter and then the other are um maybe we should actually standardize our language here but um the ecosystem that consumes open tracing has usually like libraries and frameworks you have some kind of like instrumentation library that you're plugging into that framework or it's wrapping that framework so basically all the instrumentation packages maybe that's a better term and those tend to then get consumed by the auto installers that people are building and languages that support some form of auto installation in the open tracing special agent we had had to pick up terms for these we call them instrumentation plugins and tracer plugins I don't know if that helps yeah thank you well three I'm just going to include a link to the open telemetry registry here cool beans well it's good to be back just just from this review right here it sounds like you know the main thing is we need to make sure we're being responsive to discussions in the specification repo and we need to to kind of uh batten down the final details of like what an initial AP uh beta launch would be uh so I'm going to go around it and try to do some cat herding uh on on those two fronts over the next couple of days so uh uh expect to hear from me and get her by the way uh Tristan added a comment like need a glossary yes yes yeah I just started looking at the registry stuff and we definitely need some better documentation on how to add stuff to the registry it's extremely sparse at the moment okay but yeah basically I think you just make a yaml a yaml file um and yeah I'm sure I can figure it out we just probably need to write some documents so it's easy yeah cool okay yeah in general the the website needs more more content and links to explanations for a lot of these things we're about to do so kind of cleaning the website up and making that a more useful resource for the community and all the people coming in on on our way to beta that's that's also important that people want to help with that um uh Austin Parker uh light step tends to hold it down I'm gonna help him uh but I'm sure we could use more hands on deck uh just writing explanations of all of this stuff for the community we got 15 minutes left but it seems like we're done with our agenda do people have any vital items or do you want 15 minutes back well well you know a lot of reviews can be done in those 15 minutes yeah go approve my PR 430 please cool cool cool well we're we're can be done now okay so but but specifically the the um the very first agenda item those those PRs listed there those are the highest priority things right Carlos yep so if people and they get off the call they could go look at those items that would be great I'm gonna go blast those into Gitter just to get everybody everybody's attention great thank you okay see you all the community tomorrow have fun guys see you bye