 good morning everyone good morning i noticed that i i don't have access to the public calendar anymore any ideas i feel like something crazy has been going on with that calendar so i clicked that link and i was told that calendar is not public i don't have access like you're not allowed to look at it or you're not allowed to update it i cannot even see any like meeting there it's all empty on the open telemetry public calendar yeah i can't share my screen midori i love wherever you are can you see my screen thanks my backyard yeah i can see your screen then yeah and i don't have information it's a public calendar so sing and chance you can try that in like an animal's window i tried a public calendar you probably it's uh it's like some like uh region specific problem i guess so this is john watson i think what i what i've seen is that the general link at the top of the dock is fine and goes to a calendar that makes sense but the individual links to the individual meetings don't go to something that is not visible like you just showed i see i'll try again so probably we need to update that read me document so the links in the community read me yeah yeah some of the links already expired like we have the teams meeting there but nobody used the teams meeting anymore yep okay that sounds like there's an action item i feel like morgan has been trying to uh deal with some of this stuff um bring it up with him but i'm just gonna put this in calendar right now like so i feel like the calendar continues to have problems uh old links sounds like what old links and community repo are broke uh i feel like we need to have something about if we're going to use these cncf zoom meetings i was trying to recreate the go uh sig which was part of the disappearing meetings from the calendar and realized i wasn't totally clear to me how to uh uh what zoom i should be adding to that i was too kind of in this problem or you need to help i saw that um you responded i haven't looked at your what you wrote yet uh serge but yeah it seems like if if we have a set of zoom meetings can we like have them posted somewhere maybe in the community just take a look at the screen yeah yeah oh and marking it with a color so these are why the meetings are different colors now yeah i'm trying to uh i mean otherwise it's really hard to like distinguish these numbers there is no names in the link serge could you maybe give us a quick brief where could we find info on oh it's still in pr so basically what happened is uh uh we spent a little bit too much time on configuring zoom rooms but now we have three zoom rooms they all start recording automatically you see this blinking recording light when you join so join host is not required to join uh but the only problem is um and there is no limit for 40 minutes that we used to happen have before so oh yeah great as the only problem is um you kind of have two meetings in the same room at the same time so you need to so i suggest to call color code of the meetings in a calendar so back-to-back meetings so meeting held in the same time wouldn't be um sharing the same room oh great thank you so much yeah i just glanced at this pr i pasted a the pr serge made into the the meeting notes here um thank you for doing that yeah yeah and the only thing we need to validate i mean we kind of tried it already with one of the like uh person who helped us on cnc outside uh how to post the recording so hopefully after that meeting this meeting i will try to like follow the procedure and try to post it yeah um just fyi serge since you're looking at this stuff there's been something going on where the meetings have been like disappearing from the calendar and we haven't been able to get to the bottom of like why that was happening it was either people updating the meetings and maybe not like forgetting a couple when they updated them or maybe like there's the degree to which this stuff might be attached to like some google room calendaring stuff or something like that where there's some automated system that might be mucking with them but just so you know there's been some funny business where the the meetings have been just disappearing from the calendar okay yeah so just fyi if you see that we haven't quite figured out what what what's been causing that okay so we've got the zoom meetings old links in the community repo are broke maybe that's like it for now on the calendar stuff uh riley i'll try to follow up with you later to confirm that we've fixed everything thank you appreciate it sweet i just got back from the woods so i don't have an agenda for this meeting uh i can throw some things on the agenda um and i know there is definitely some spec work in flight at the moment uh that imagines some people who want to talk about um i think both of you right yeah bogeyms here we got josh here we got we got the whole crew here um so maybe if people would like to just spend a couple minutes adding their spec items to the agenda just uh please paste in anything there that you would like eyes on either to discuss in this meeting or to get approvals just to make sure we can fast track the remaining spec work i think all the items in specs are are important so everyone who has a prover uh at least the prover status for specs and uh rfcs please please put more effort into reviewing all these things um i will not necessarily call one more important than the other but i think you everyone should review for them we're also sort short of uh reviewers and approvers in the go repo like there's only sort of three active approvers right now um and ted's like practically not involved but has been like helping out by approving things when i nag him so i'm trying to get more people there as well um and paulo and someone i don't even know are are like listed but not not present so we got to get more people in there okay i will do i will call i will talk to paulo and if you're on sj steven karris i don't know who he is actually but but those are the other two are currently listed and then i'm gonna try and nominate uh krasimir that we've been working with who did the open tracing bridge as soon as he finishes that big pr i'll check with paulo and steven thank you okay uh digran also if they don't have time you you may want to replace one of them if you are if you have time or yeah more more go reviewers would be very helpful sure i'll check with him and great yeah and uh maybe a reminder in general uh because we've got some sig leaders here consider um it may have been a while since uh people in your group were nominated to be approvers or maintainers or something like that so if you're uh leading a sig think about whether there's people who've been contributing lately who could be added to those ranks so that you can kind of broaden access yeah we did that for for javascript mayor did a good job of adding two or three new people that prove themselves very very active and everything so awesome we have Python as well sweet yeah and to remind everyone in order to to add someone you have to do a pr on the community add the person to the list of contributors with the status that you you are proposing and put there the links to the prs and work that they did and try to match the requirements that are defined in the community membership sweet um um there's a related thing just around uh uh we don't have to talk about it a lot right now but trying to help out with just sort of backlog triaging in general we have some people who could be helping more with just like project management and backlog management it seems like it would be nice to have some kind of role that was like a community manager role or a triage a role where it would be possible to get uh backlog access like across the organization I think there's like actually a triage or github level that lets you do things like set and remove labels and manipulate issues and prs but you can't merge or do some of the other things um so that's another way we might be able to get uh some more help on this project if you have somebody in mind let me know yeah well we've got uh Midori here on the call who's uh uh joined just joined my team at light step uh she'll be doing a lot of uh engineering management which will include a lot of like open telemetry project management okay so she can definitely help with that but I don't know if we had like a concept for this kind of access that we wanted to to add to the community repo that's something people have been thinking about per repository basis so uh basically every maintainer should just allow her into group and it's fine yeah an easiest way to do that is to add into a progress group but don't add into code the owners file this way uh you'll be able to triage but you wouldn't be able to merge anything so basically become an approver for every project but not a code owner yeah and to clarify I'm actually um a director of Eng over here at light step and I'm going to be working with the hotel group um I'm not sure that I'm actually going to be that community manager uh I don't necessarily have that kind of time um but it's something to take a look at and and delegate down so stay tuned for that in terms of what we should do and what process we should follow yeah welcome anyway thank you yeah we have a couple other people who can help out in this regard but yeah I don't know uh we don't necessarily have a dedicated community manager person over here just to be clear um but we do have uh like another Amelia uh who is like director of marketing here and doing a lot of open source work and getting involved with open telemetry she might she's going to be helping out more too around stuff like the website and things of that nature so we'll be looking maybe for access for people like that uh who won't be looking to like click the approve button but might be looking to help out uh just like uh direct and manage uh people working on stuff cool well while while we're announcing new people uh so I'm John Watson I'll be I'm gonna be here from New Relic uh as I've heard some people might be leaving so I'm gonna be uh helping out hi John howdy do we have other new people on the call well I won't force us all to go through random introductions right now I'm I'm new because I'm so I'm a new person um okay so should we should we uh start with more questions the community and the concerns and other things and before we go into that do you mind if you uh briefly go into milestones because like all the triage work that we need to do needs to fit in some milestones and yeah everybody fine with uh milestones I place it's a link it's basically like it's a very uh I mean it's not like uh some important document I can share my screen if you yeah go for it uh can you see it hello yeah I can see it yep you're good uh so yeah uh we're all talking about alpha release so you know we already shipped in the beginning of summer we shipped the api proposal and after that we have we established the OCHEP process and we uh merged couple OCHEP's proposals already so we have a process in at hand how to uh go forward and move this uh procedure forward now we're talking about alpha release and when I came back from parental leave everybody saying like alpha needs to happen this month however after talking with many people I realized I realized that there is no uh documentation is not complete for what we want to call alpha so even if language will ship alpha specification is not there yet and I think optimistically we can try to get the api spec to alpha release like this week if we will all work hard and like we will merge metrics proposal completely we will merge a couple more pull requests and flights it maybe we can uh hit the date um and then after that I think in one week optimistically again we can do SDK spec uh that will include some deepkin and yager and primitives data mapping uh I noticed somebody already started deepkin data mapping and it's really cool I mean it will help a lot to implement it in different languages and then languages I mean optimistically like people can like Python group recently met and I talked to them and there is a good chance that they will finish everything this week ish so like specifications updates they probably can update um what they're shipping so maybe they even ship like the same date 10-4 but uh realistically you need a little bit time to clean up so maybe 10-11 is a possible date date for alpha and I think uh to get like uh what alpha is released is about and I I know there is a agenda item about like alpha and uh by the definition so maybe this um I want to talk about spirit of alpha I think spirit like we want to get alpha so we can demo something so we can uh start showing it to people we can uh give it uh somebody to play this and uh try out implementing adapters implementing data collectors are trying out in applications so it should be demoable kind of product yeah and I would say not just demoable we need to exercise it right yeah and demoable all the way to like some uh open source uh data collector ideally some prometheus and nizip can jagger uh something like that should be there I think if you have a demo you can exercise it before you have a demo you cannot really exercise it yeah yeah and then uh for beta release uh looking at dates I mean sorry for photo whiteboard but basically you have like if you finish uh 10-11 uh for um all the length like alpha version you only have one two three uh four five weeks before cubicon and uh if you will target beta releases uh proposed in otap to be uh very stable almost like a release candidate kind of quality of apis then we probably will exercise all those five weeks to get it to this level um so I think um and I discuss with bogdan I haven't talked to anybody else yet but I think for beta we can target uh specification complete for cubicon and then by the end of the year probably it will be like languages can uh implement it uh giving all the vacations and hard days thanks for doing that guys I really appreciate it so I think uh if you can for now we can start creating this uh milestones like uh one two three like a api spec completes this dk spec accompany the language alpha and uh then for bait and probably just big uh uh milestone overall kind of uh milestone and then we can split it uh further and start aggressively triage what goes into api spec sdk spec and language alpha so let's try to hit uh these dates uh if if you feel that these days are completely unaccomplishable we probably need to move it and again they're quite optimistic in my mind yeah um I place a document link to the documented um notes so yeah so okay I think that looks great I've been keeping some notes not anything official but just some notes that I share with people and what you wrote here looks similar to the notes I've been keeping uh so I think this feels realistic to me um I'm happy for us to be shifting the milestones to say we're we're gonna have something more like a beta not a one point no at the end of the year um just realistically the amount of exercise this stuff is going to get uh the being able to like get it feature complete I think we can definitely do that but you know there's like that last mile from feature complete to you know something that we're saying is going to be stable with some long term support guarantee or something like that so this makes me feel more confident my one concern is just like november december I think are going I predict those two months will just be a total wash um because we've got cube con we've got thanksgiving and then all the christmas vacations so I think like the number of actual work weeks in those last two months will be like like one or two weeks there's something crazy small like that so we might want to consider not whether or not you know anything realistically will happen in november and december let's see how it goes that's why I don't want to create beta milestones yet like what it detailed so we can just have a catch all kind of beta milestone um I'd like to add a graphic to the website let me see if I can just post this into the meeting notes it's funny thing first I gotta download it upload it so this is something that Austin's been working on kind of uh so I just dragged a proposed graphic into the meeting notes as something to throw on the website um that kind of is a sort of at a glance where we at with the different projects there was some request maybe to remove the release candidate stage but just alpha beta v1.0 uh obviously there's no details here but as like a first step um once we start releasing alphas it would be great to get something like this up on the website um and along with a definition of what alpha means what beta means maybe shying away a little bit from promising dates to people I feel like we should maybe focus more on like what what's going to be in these steps and maybe move a bit farther away from promising exact due dates uh because we're engineers and we're poor at predicting exactly when we're going to deliver things but it would be better to maybe yeah get some more concrete information up onto the website about what expectations should be for alpha and beta I think I think if we don't have dates I think dates would also help to push us a bit more on on on some focus more let's say and I don't think dates are necessarily that bad as long as we say that this is tentative data whatever you call it but yeah some some qualification I I've liked that having these these deadlines have like I agree they pushed us but I've also had some other interactions with people who it's for whatever reason they were really baking into their plans they were going to get some stable open telemetry thing in the next couple of months so I will make a like miles I'll create milestones and I'll start triage and issues uh please don't take offense if you mis-triage something just like let me know if it's a lot of issues it's like so many of them so it may there may be mistakes uh if you want to participate we can uh definitely do it together uh maybe we can like do first uh round offline and then like meet and discuss uh questionable issues I'd happy to be happy to help you with that okay so up to the next topic sweet um oh and there is a um a O-TEP proposal for beta from Liz Fong-Jones I don't know if you saw that Sergei but yeah I mentioned that uh I saw it but I I wasn't uh sure who proposed it but yeah okay moving on um named tracers so this is a proposal along the lines of components or somehow name spacing uh uh contextualizing traces and perhaps metrics right uh does someone from Dynatrace want to talk about this yeah so once again named tracers we we overhauled the the proposal quite a bit recently and just uh day and the last days we incorporated the last uh feedback we got from you guys especially from Boxer and then Yuri and I just wanted to ask if you could have another look at it and and see if your concerns have been addressed hopefully so that we could probably and finally get into get it into a proposed state great I think this looks great but yeah uh I think the action item here is just everyone have a look at this thing I don't know that we have enough time to discuss in detail on this call yeah I don't think it's necessary so I think we have a couple of uh approvals already but if you could take your time and have a further look at it it's good it does look good I I do agree with uh Bogdan at a glance that like it would be good to understand how metrics can be uh correlated or contextualized with this stuff can I comment like the only thing that I want is almost all the arguments there if you replace tracer with meter and spans with metal they're all mechanisms so I would propose a very small change but uh yeah anything else looks good yeah this is something I'm trying to grapple with a little bit which is uh we have added a lot of this contextualization and context propagation stuff has traditionally been on the tracer but now that we have metrics and maybe logs and these other verticals some kind of lower level context propagation object that contains these kinds of correlations and namespaces and resources and stuff like that seems like would be the better place to put this so that all these different kinds of observability can have access to this information because it seems like you want to know what metric like if a metric is in a component you want to know that too um so that's like worth discussing how how these things actually I definitely agree with so if we're saying that we're we're adding context so that people can can correlate information later and so we're adding something that's like a component level context where we're saying there's a set of resources and um any observation that comes out of this part of the program uh can be correlated with this set of resources right so it might be spans that are coming out of a component have these you know component resources on them but also seems like if you were making a metric in that component you know doing a count or gauge you might want to use those resources to correlate those counts or gauges in some way and so there's just a question of like is that are metrics being correlated by traces or are all of these things using some shared way of correlating each other similar to like the distributed context stuff right it's not like that first of all we do not want to correlate every event so for example we're not gonna we're not gonna know uh we we know only when a metrics is created or a span is created the component correct for example when you when you do add one attribute to a span we do not know that that attribute was added from this component from the other we're gonna attribute everything to the to the component that started the span because that's the only operation for spans that happens on the tracer all the other operations are happens on the span so we assume that everything belongs to that span so so and it's true for metrics as well so with these components we just mark the the creation of a trace of a span or metric with the component that created them correct it's so we're not gonna we're not gonna correlate events with this we're just gonna know the the entity that created the span or created the metric we identified the the creation of this we have not identified requests or between requests or anything there is no correlation across requests does it make sense what i'm saying it's i think we're kind of saying the same thing though maybe we're using different words just you you have some entity like a component that components got a bunch of you know it's got like a map of keys and values on it i don't think i don't think we should do a map in values for the moment we are pushing hard on only having a name and a version yeah that's the last piece of input i incorporated so we were talking about using resources earlier but as it looks like resources are going away from the api surface so we uh i'll back a little bit here and basically the creation mechanism is to trace a name and an optional version but that's it so that's all the the context information you would get out from the the creation creation time yeah right you should read it uh yeah i'll follow up i wasn't aware resources were totally going away totally going away it's just moving to the sdk and they they will hide the so we will use them to describe the process and the the overall service the binary that is running we will still do the same thing but we we believe that at the eki level people will not know where do you run or or things like this so except the component which is one small thing that people may know at the compilation time or sorry not at the compilation time but at the library instrumentation at the instrumentation time they will know which component they are in that's the only contextual or environment thing that they they can configure a bunch of other things needs to be configured in the main file or when you run the the binary correct yeah i personally feel this is a little too restrictive but i'm happy to go forward with a restrictive proposal like i do think that there are attributes that belong on the static tracer slash meter slash implementation that an implementation might want to vary inside of a process that are not dynamic context so it's equivalent to a component or a service label but they're sort of effectively resources but i'm totally okay with us punting on that discussion yeah that's the the reason why i'm leaning a little bit into having a separate old tab for metrics and for logs because probably these arguments you supply at creation time they they could vary and we have to think it through for the for the other use cases and so if you have a working proposal for for traces we have a reduced focus reduced scope so it will be easier to to think all the corner cases through and i think we should do that same truly mean for metrics and logs later i i would feel very bad having completely different apis to get a tracer versus a meter because that's what you are proposing right now i mean you are proposing changing the way how i get access to a tracer and for meters will be different and that's very bad experience so so we either have a consistent we try to keep them because very consistent in that regard and having them completely different ways to act to to get the interest of a tracer is a meter it's probably a bad experience okay so you're rather looking for the same one single factory for producing all these signals or whatever we may call it or would you be okay with a metric factory let's say because then couldn't change that much so you will probably you will be a meter factory you have a tracer factory you will have a meter factory but i want to have i have to i want to have consistency between these two two two things i want to have consistency as well but i but i wouldn't throw it all into one otep because what about logging for example we don't know a lot of about logging right now so i cannot have a a complete spec for it at the moment this is sort of what i was getting at with feeling like i i yearned for what Bogdan was saying is like we should have some kind of consistent form of of producing this stuff and i i wonder whether or not all of this stuff like what component you're in and all these things could be a lower level thing i don't have a strong proposal for that but it's more perhaps a plea for consistency and simplicity on this front like the way that i go about getting a meter and you know saying it's in this component or it's correlated with this or that hopefully is similar to how i like get a tracer and interact with that or get some logger thing if that shows up later yeah so i think i think we should have the same mechanism to get a logger or a meter or a tracer now now there is a good question that erased here by by Josh and Ted if we want to allow people to set extra labels besides the name inversion which i i'm not against so for for me the main the main idea against this is do we really want people to understand our concept of resource so here here i'm talking about a library developer that instruments that library do i need to to tell him what resources and why these are are merging with the other things and so on so for me for me was like even though we add even if we add people to add more more labels or static labels or whatever we call this the fact that everything becomes a resource and things like this we i don't need to teach everyone in the world so only people who are like gonna configure these need to understand all these things i don't know that was my my my mind like i'm trying to limit the amount of informations that people need to to learn in order to use this API and then yeah in order to to configure and run in production you will need to learn a bit more but this um this did come up in open tracing uh we didn't have this concept of resources or component and in fact in general because it was just an API you know when you initialized your SDK whatever that was that would be the place where you would stick all these resources so this proposal of moving the resources back to the SDK rather than the API looks very much to me like using Jager with open tracing um you know that was or using a the light step tracer with open tracing and that worked fine uh it actually avoids some awkward issues around initialization potentially so um i just want to say the one thing though but people did actually miss having some more standard way to like talk about that information because it wasn't part of like the open tracing API there was no way to the same over forming semantic conventions and stuff around yes but the difference now the difference now Ted is we do gonna have semantic conventions for this because it's part of our SDK and as part of our SDK we do provide semantic conventions for this and everyone who is using the SDK as the as the core implementation for their for their exporting like for for light step if you are using this you will have the same resource as somebody who is using for Zipkin or for for for Jager so at least we assure consistency even though it's not in the API it's in the the SDK we we do achieve one of the things that we do gonna have semantic conventions for this yeah and that might be totally fine um i'm also fine being conservative about what we've put in the API and starting with things in the SDK and we're like uh it really would be better if we expose this more like changing it later uh so i'm fine but i just want to note that yeah people did miss not having uh some way of describing this stuff through the API when they're using open tracing maybe it'll be fine because we've got a more standardized SDK now so people won't feel like it's as weird but that was the feedback that we got from open tracing josh were you going to say something i saw you unmute for a moment well yeah okay i think it's really complicated this issue and i and i i think we should settle it whether we're going to be conservative and go with the minimum at this point i i do think that users are going to want to have an SDK independent way to add resources but we can wait on this it's very complicated the core thing is global initialization first yeah getting this component concept in there in just any form i think is the important thing and so starting with like the tiniest form we can come up with i think is but that's that's really the core problem was not having this concept so yeah and ted you and i have discussed how there that there might be this third thing which is sort of like shared by both the meter and the tracer which gets your resources for you and it sort of represents an SDK the hardest part was putting a name on that and i and i don't even want to have this session right now yep cool well i think we've talked about name tracers plenty uh people please uh have a look at that uh oh tap uh next up uh span kind as an option during span creation who put this one up i put it on the agenda because i was looking through all the open items today and i think this one looks basically done so it looks like ready for for emerging if nobody has any uh anything against it so yeah the only thing i would wonder about this for people to consider is whether or not this information is like metadata that you're adding or whether this is like stuff that's like a concrete part of the span we ran into this question in the bridge so the open tracing bridge has a semantic convention declared called span dot kind and if somebody sets an attribute on open tracing span span dot kind how do we represent that in upper geometry it gets back to the same thing you just said don't have yeah one of the reasons i was looking at that today is because it's basically implemented in some of the the languages for example in dot net already so this is part of the spec is actually behind or out of sync with some of the implementations so we should therefore have a look at it and decide if you want to have it there or if you should change something in their language implementations i think this was decided when we do it did the first bootstrap uh ted i can where you documented this uh so uh this was decided as part of the porting from open sensors because we had this and we we we agreed to keep it there and i think i think the the purpose of the pr was just to document what we know what was there and now we are proposing to change this i'm happy but i think we should document what we have in order to make sure everything is documented and happy to to accept a pr that changes these and make it attribute and we can argue if that is the right thing or not i i think it's a small bike shed either way uh but uh yeah cool but i definitely think it should be there one way the other is an option during span creation i guess is what i'm trying to say uh if it ends up being on the span object and you know it would have been cleaner to put it as an attribute i don't think that's actually a big deal in the long term proposal to separate context propagation from observability this is my garbage that i have to update uh this is just trying to get a very high level description in there about context propagation and uh the way you could have several different systems using context propagation so an observability system and then a baggage system that's separate from it the main idea here is to figure out what actually needs to be shared between uh these different systems what actually would need to be in a context object versus up in an observability object and it's also an attempt to kind of describe it in a way that looks like a little more formal than a little bit farther away from like the java spec version that we've been doing so far um so i need to take another pass at this today to add in feedback from people i've been talking to over the past week um but if people have any general feedback like what the fuck is this thing or anything along those lines like please please let me know i've had positive feedback that this has helped people wrap their heads around like the general shape of this project so i think it would be useful to go into either the spec or the website in some form like that i don't know i didn't add this to the agenda uh today so if someone else added it because they wanted to talk about it then let me know otherwise maybe move on to metrics yeah all right um so i posted a large specification draft on friday and uh it has received um several people's feedback already um my i want to kind of have a meta conversation here because it's not to get down to the details but the question i have is sort of like this there's already too much feedback for any one person except me perhaps to follow in this pr it's going to get out of control very fast um so i think like in the otep's repo where we kind of had a practice of merging prs and then getting fresh prs to start to start new discussions to kind of keep everyone synced up with the current state i'm wondering if we should have a practice there for the specification repo or whether i should kick this back into otep's and sort of like create an otep that says here's this draft for a new metric specification in its full form please comment and using the sort of procedure that we've developed there um or could we have a kind of work in progress directory of the specification repo where i could get this merged uh so that we aren't creating a center thread of feedback that is hard to jump into um that's my question for the group i think i think there do things here one is that there's like a different kind of feedback on the the spec and in otep's like a lot of the feedback on the spec is is not um you know about about the ideas in the otep's and whether you should approve them but like at least a lot of my feedback on the metrics spec they are uh was about the wording and the presentation of the ideas and you know things that i that i left out but described in the otep's yeah yeah yeah so i appreciate your feedback Chris and i think that what i'm trying to say is that i can go through each of your feedback points today and and right revise the text there's some big questions and some sort of smaller questions um but i'm afraid that any i can't really go ask other people to kind of join in to this conversation because it's if you look at the github conversation it's already quite long and um as soon as i make a change and push it like the comments start to kind of stray from uh from the current head i guess um anyway i guess i'm it's more a question about procedures than about um semantics of this so i think this this procedure that we've gotten out in the otep's uh repo doesn't work um because we're emerging things in and then there's not really any nice workflow for commenting on uh like on documents that have been submitted and not approved so i think everybody has this nice workflow for prs right where we can comment on a proposed document but you know we have a procedure that doesn't actually match the github workflow right now where we're supposed to comment on uh proposed docs and even in the otep's like repo right now i see many more comments before a document makes it to proposed than i do in between proposed and approved and that suggests to me the process is wrong here i yeah i think we haven't quite followed the process that we described though so there was an idea of creating a work in progress pr for every proposed uh otep chad you were gonna say something well i was just gonna kind of plus one what chris said is i think the original proposal here was yeah we would quickly merge these in so people could see the proposals and there may be issues to discuss the stuff but yeah the way github actually works you have all of all of your commenting and review tools are kind of on the pr i'm wondering if um the new github action stuff might help us with some of the automation like to speed things up since we could automate a bunch of the steps yeah i wonder if we could just simplify i noticed that like for these otep's unless they are like too big it seems like it's possible to review them in a single pr so it could just be a simplification where you know you submit you have a review and then um you know it gets approved as part of the pr or if it can't get approved in that set then you know you go back make an update make a new pr reference the old one um and then we use like the the pull request history to track you know what happened to the various proposals um and so what actually gets written in uh to the repo are submitted prs that have only things that have actually been vetted and approved uh it seems like that's sort of the process we've actually been following um and that seems like it works uh i don't know what other people think about just simplifying to making keeping the same rfc like template that we've been using but just simplifying it to you make a pr and if everyone approves it then it's an approved rfc i don't know the answer but i the question also applies for the specification repo and i think it's a not sure it's the same problem though i can see a funny thing happening where you get your rfc is approved and then you bring it over to the specification and there's a certain amount of like review about how does the wording work at that stage and i think that's totally fine but we should probably be wary about maybe re-litigating issues like i wouldn't want the the meaning to change between like the rfc and what goes into the spec there's there's a temptation to change names though because people are finally seeing everything put in the one document and it's sort of like as i say it's it's hard for people to follow these lengthy individual rfcs so for example michael who's on this call uh got to reviewing the specification yesterday and has raised some things that could have been discussed in the rfcs but just kind of weren't so my question now is like are we re-litigating should we go back to the design drawing board i don't i don't think we should but i i've always believed that we were not going to make everyone happy so so i think i think we should mark something but but if there are problems with the people not understanding the wording i think we should resolve them before if there are changes about uh for example uh we decided to make a call something gait and now is not a longer call stages 2 then i think that that is a separate issue and i think we should create an issue for that and discuss it separately so i think comments about hey this should not uh like something that i commented there like try to not put uh implementation details necessary into the into this thing this can be resolved because like literally we try to keep a standard of what is in the api what is in the SDK and stuff like that or somebody suggests like hey better to save way to express more relevant things i think this should be fixed uh but comments necessary about changing the the decisions that we had documented in the text i think they should be uh create separate issue i mean we should not ignore them we should create separate issues and we say hey let's move the discussion about it where do you think where do you think those issues should be filed uh specs okay yeah so like for example the the major one that was raised is one that has been discussed like there's history here but it's sort of like about how you configure your aggregations and so i'm on the one hand maybe we've just like we're only halfway there in the sense that we've designed then or specified the api but we haven't talked at all about how the SDK gets configured and like what you might do with or this mythical views api or something like that might help um yeah i also i also posted in one of the issue in java something related to that i think i think you just picked an issue and i will also add more comments there and everything but but for this kind of things you should you encourage people either you create the issue copy pasting their comments and stuff or you ask them to hey move this to an issue whatever you feel comfortable with but i think this kind of things that are not relevant for for your main i i see i agree that sounds great so i will make issues it's probably better for me to phrase them than for the individuals um but uh that sounds good i'll do that today let's go ahead i don't think that we should actually be adding things to the specs repo that we don't intend people to implement because there is like some outstanding issue about some aspect for the spec um i i think what's going to happen i think we already see this happening like in the javascript repo is that people use the spec as justification for implementation decisions and they don't check the history to see if something in the spec is like still in flight or well defended or has some open issue so i think anything that actually goes into the the specs repo that gets committed people are going to start implementing and so i think we should be very careful about what actually goes into specs yeah the most substantial question that michael raised was really about how you configure aggregations and i you know i personally think it'd be nice if you could specify options for aggregation just uh sort of specification in the metric instrument as you declare it but it's something that could be added as an option later it's not requirement to do this and i know you've got the the like the otap that you didn't include in this one on aggregations and i think yeah that that keeps coming back right yeah i i think that one is worth opening in an issue in specs to say like the reason that aggregation isn't defined that'll that'll be the first issue i file today yeah great yeah i have nothing else to say on that okay i'll open an issue after after this call to propose simplifying the the otap's process um do you have any other action items to draw out of this around like the spec procedure seems like that was the main one oh um one question that i had uh and maybe worth discussing a bit here is the the rfc about version which i think indian became like super small rfc and i'm like concerned that if for such a thing we really need an rfc or directly aspects modification will be good because uh it yes it started as a as a proposal to add a uh type called version uh which would have been something probably would require an rfc for this because we want a new type into the at the salon but it ended up as being just a format for a string to be like same var column whatever and the git column whatever and stuff like that for these kind of things i mean i feel like having a rfc just for a semantic version conveying a semantic convention for this version attribute or label it's too much do you want to put a link to that that in the meeting notes we can have a look yeah related to that uh we have not up till now been explicitly versioning the specification um given that we're moving closer to like an alpha thing um i think there's going to be a need very soon to be able to express you know the tracing stuff we have is this version of the spec but we haven't updated the metric stuff yet so it's at you know tracings at 1.1 metrics at 1.0 or something like that um i don't know if anyone has a proposal for how to version the spec going forwards but it would be great to see something like that start to happen soon so yeah i added the otep uh that is the version but anyway for me it's like this is now at this point it's super super trivial and probably not controversial change do we really need an rfc for this or are we just gonna go with the with the specs in this case yeah if i may give my opinion i think that yeah we should make it easy enough you know to have these kind of changes just directly in specification and only redeem them important enough to the entire pipeline yeah that's my feeling as well i feel like i feel like uh austin worked too hard for such a small change so yeah like how do we just make small direct changes to the spec without having to go through rfcs and stuff like that yes yeah and then how do we version the spec when we do that yeah i think i think the versioning of the spec we should start once we get to alpha i think we should start to have a uh uh what's what's the name of that uh a file where we keep all the changes changelog changelog yeah changelog kind of a changelog for all of these things so and then and then when we tag a new spec from the changelog we should at least put all the major changes that happen into the the new tags and people can at least read that that makes perfect sense a changelog even a changelog that just links to the issues or prs or whatever you know would be great i mean with this more explanation of what change yeah kind of a tldr for everything yep tldr and then github gives us more deeper history cool well i don't want to take time away from dot net which is spinning up now in nine a.m so everyone thanks good seeing you all see you later