 Well, how are you? Not too bad, not too bad. She said, you might be a couple minutes late. Constance, you're in the wrong section. You need to pet yourself further up. That's me. That's me. She was on the call last week. I just realized she wasn't added to the attendee list last week. So I just fixed that too. We're in that Google doc and adding attendees. Michael, at this point in the morning, like I don't function. So like Steve knows he's just going to start taking things for me. You have to excuse, but here it's five p.m. So I don't have that excuse. Well, no, you're just adapted to our time zone. That's all. You're being very care, like, you know, very caring about that. Very empathetic about it. I like that. Anyone following the ambassador rename for CNCF. There's a renames or ambassador. Well, so, so ambassador is trying to donate the, it's component to CNCF, but the company used to be called something else, but the company renamed themselves to ambassador. As a result, they can't upload a component called ambassador for IP reasons. So they had to rename the component that they're uploading. And it's now called emissary ingress. I'm not sure how I feel about it. So the company was called something else. They created an open source project called ambassador that became popular company became called ambassador. Now, if they want to go in the CNCF open source project that they're now named that they're now named after needs to rename it. That's funny. Emissary ingress just rolls right off the tongue. So I, it does. The course has the best zoom name. Yeah. Yeah. Yeah. The one with the glove with all the little pretty. Is that the one? Yeah. I think he's really into jewelry. What's going on? I know this, the project was actually named because of that, right? To, I would assume. Yeah. Yeah. I thought it was the other way around. I thought Marvel. Named it after you folks. I think you had like some. Yeah. He said he will be running late. I think we might need to start otherwise. Sure. Yeah. A very ambitious agenda, right? Yeah, exactly. Okay. So hello everyone. And let's go with the agenda. And the question first question would be, you know, what, what would be the order? That makes sense. So there are some quick topics potentially. That we could get first. What do you think about doing that? That probably makes sense because otherwise like the hotel stuff's probably going to take up most of the call. So if the other ones are kind of quick, let's, let's try to jump through them. Okay. So next one is like our tour. Alternative for streaming API monitoring. How much time you would meet for that, let's say. I think this one would be better to leave to the next meeting. I was expecting some colleagues to join me, but they couldn't join today. Okay. Moving to, to the next one. And then we have some quick checkup on the white paper observability with Simone and you. Yeah. So. So maybe I turn on my camera when I speak. So we have, we have parked this, this paper for, it's been quite a long time. We have talked about January, but then we, it started quite well. So the beginning of the paper, I'm actually quite okay with the content there, but then we started having gaps because we were not sure about today's structure. It was basically Arthur that did most of the work here. So, so credit where it's due. But then he didn't have more time to continue. Edit in the paper. And I think we should, we should continue and have one version for, for people here to review. So this, this has been abandoned a little bit. And I, I think we should, yeah, we should take it up. And some people have experienced in more areas than others, maybe more in, in application others, more in infrastructure. And I think, yeah, this is how maybe we should share a little bit, it's more sections with people that have more experience in different areas and then the load is not too much. I mean, writing one, two, three paragraphs and then somebody stitching the text together. It's, it's not a big something big to ask. I think someone needs to step up as some sort of leader. And I was trying to do that some months ago when I was unemployed. But since I am now employed, I have limited time. Yeah, maybe you can share the link in the chat so people that were not here before can open the article. Yes. Thank you. Okay. I guess we are looking for someone unemployed them. But someone that has. I mean, someone that is willing to do the work. Well, I guess, I mean, calling calling for contributions and. I mean, stitching the text together and trying to get like a readable version, I can do that. But I cannot be the main person feeling the gaps that we currently have. We have some. So, at least where we start more in the part of data visualization and exploration. They're basically empty. So there are some names that were written here as candidates. I think Michael was one of them for use cases. Arthur was also here. Like just writing something about beginners approach. But there is there, there are some other sections that are still empty. I think that's a good direction, right? Like, first of all, there was no expectations to like, I don't know, finish it super, super quickly, right? It's community driven. So it's okay for some periods to be taking longer, right? So I would see this as like some community driven piece of documentation about observability. So I think we just need to announce it more and maybe split essentially interesting topics that have gaps in it. And just, yeah, try to ask personally as well, people who might be interested. So proposing candidates, I think that's, that's really nice solution. But yeah, Arthur and Simone, it's not no expectations that you will write that on your own. I think that's, that's definitely not what's happening. So I would say announce it better and, and try to gather more people on, on those. And, and kind of one way would be to also make sure that people are motivated. So some kind of goal of this document is, is well established as like, you know, this, what, why we're doing this, for example. Yeah, so. So the initial motivation of this document was basically to consolidate to have something that comes from CNCF when somebody talks about, you know, observability, but also going a little bit more into details, like use cases or if you're perspective, if you're an application developer versus you are an infrastructure engineer dealing with observability and some other things that are happening in the community as well. So we don't, we don't have a very fixed structure there, but I, I would very much like to have some input from people here that's working in various areas to, to make this document happen. And when you talk about announcing Bartos, you're talking about using our select channel or going wider with that than that, actually. Yeah, I would, I would, you know, mention this wider and say, you know, we, we can definitely, you know, make sure this has some structure and go into good direction, but we can definitely ask, you know, and say on Twitter and hey, join our group and yeah, just make it more known because I think it's only, you know, a few people or like at least this observability that is only kind of seeing that and just having more traction will you know, give people more motivation to also contribute. So that's, that's my idea. That's what usually worked before. There's definitely interest from the wider community as well. I'm looking on the Chinese version of the observability community and they also expressed interest to contribute there and then subsequently translated into Mandarin. So, I don't know what, what the best way is a tweet or, you know, maybe we can even do a webinar or whatever on it, but I agree, we should definitely broaden, broaden the message out there. I know I have jumped in, but like from a gender or initial thing from the, from the working group, we said that, we're sick, we said that the canonical places are slack and the mailing list with the mailing list being a must and the slack being recommended. That being said, I do think that we would benefit from, from also having more public channels. So I think we need to split between people who take active interest of working within and moving within the sick and then external communication of the sick. But again, I'm jumping in, in the middle course, I had a leadership thing at Grafana, which ran over and I'm sorry. So I don't know if, if that was helpful or complete hogwash for the context of right now. I think it was worth it. We were, we were, we were not thinking about mailing list. That's a good idea. Yeah. And do you have other groups that I mean in, in the observability realm that would be interested here as well, Richie, that you have been involved or others as well. Open telemetry or some other folks that are in other groups that are, but are not here. I mean, there's a bit, we have Prometheus and the wider Prometheus community, which we can leverage for stuff. We have open telemetry. There are some friendly conferences, which, which we can also try and put this to the main channel. I think it's just talk to CNCF and I can take that action item to see how, how they want to amplify stuff which we publish. Yeah. No, I can share it. I can share it with Thanos community, Prometheus, Jaeger and like totally. It's observability topic that. Yeah. I mean, at least from the tracer from tracing parts. I forgot his name now, but the guy from Jaeger, he could, he could do some, I mean, he could at least read something here and say this is rubbish or, or give some pointers that would be interesting. Yeah, Yuri. Yeah, definitely. Yuri is his name, right? Yeah. He doesn't need to write himself, but if he gives some, some shape that we, we can follow that, that helps. This morning do you want to talk about more in depth on Slack later? Yeah. Okay. But mailing list and other folks in the observability groups that are not here. That would be probably my first bet before we go on Twitter. We've, let's say, a document that is not in a great shape yet. I would go on Twitter if it's for calling to call for people that would be like something that doesn't have so many gaps that we have now. But if you're okay doing that, I think getting feedback early is good. So as long as we communicate, communicate clearly at what stage any particular thing is we should, we should try and be aggressive in getting feedback early. But also I'm taking a little bit of a time check because we spent, I think. Yeah. So just to, to have the one thing because I do expect that hopefully finishing the due diligence for open telemetry will take the rest. NNA who might be on the call or might not be on the call took a step at writing a, a end user guide about distributed tracing. So just look at it give feedback if possible. And I think that's already it what we, what we're talking about that. So let's, let's start with, continue with the open telemetry due diligence. See, that's perfect. Yep. I'm here. All right. Here we go again. Welcome folks. Number three. Richie, do you still have the action item here? I mean, we talked about it on the TOC call. At least Bartek and I were for there. Do you want to follow up on this one or what's the next steps? Number three. I failed to follow. You mean on the, on the question of sub project? Yes. No, I failed to, to email them as you probably noticed. Did any guidance come from the TOC call? What was your take? It's a, it's a good question. I think there was nothing, no clear decision. There was like one opinion from this was that. Yeah, it's, it's kind of, you know, important to make sure that, you know, the incubation is high bar. So we expect things to be, you know, kind of stable, but she other mentioned other aspect where, you know, and there might be communities and some features are alpha and it's graduated. So it's fine. And then kind of I navigated that, you know, metrics and logging are kind of important parts of the observability space. And, you know, missing those are kind of a major, major kind of part of the open telemetry. However, Steve, you pointed that there are so many other aspects like SDKs. The whole collector stuff is like many, many things. And, and there were two interesting experience kind of from Argo, I guess. And to be honest, I didn't get the direction of it. Was it that yes, we should just if, if there was a movement behind that, if there is like a strong community that we can trust that, you know, those big even chunks of unfinished work will be worth kind of recommendation. And I think that was the message, but I might be wrong, Steve. So maybe then to take a step back, would it make sense to, on the sick level, just say that there needs to be a decision from TOC and just bouncing this out of, out of sick level. Cause I mean, I think that makes sense. I think that makes sense. Yeah, I think that's a good point. The way I read into the Argo thing is it looks like Argo is going up for graduation and has a similar problem in that it's a big project. There are plenty of aspects that are experimental or alpha or whatever you want to call it. And they too have to deal with it. So I don't personally, I don't think that sick of the ability needs to solve this problem. Just raise it to the TOC. And the TOC needs to make that call. Bartek, would you also be friends with us? Yeah, I'm happy with that. Yeah. I think that's a good approach as well. So, yeah. Okay. So let's revisit that point, I guess. Also, we should close all the old comments. Ideally during the call. So we have a paper trail of them being closed. So. We leave it as such. Request a decision from CNCF TOC. We can just leave it. Request a decision from CNCF TOC. So we can just leave it as such. Should we strengthen that? Clarify maybe. Okay. How about. Okay. We just market in a different color, put it on top that we request this thing and move on. We will not. Resolve this within this call anyway. So we'd much rather optimize for, for a speed within, within the document. but I will so call for consensus. I'm marking this orange and I'll also copy it at the top as a reference of the document and then we just bounce it to TOC. All agree? Anyone disagree? Good. Regarding the comment above, since we do want to clear things out, right, so the we have the adopters page updated, there was a request around adding different signals. That's a little bit harder because adoption is on a client library perspective and I've already received feedback from the adopter saying look we're not going to keep updating that page every single time we change something in our environment. So I'd like to propose the update that I basically wrote which is that given tracing a stable instrumentation libraries adopted are for the tracing signal today and for the collector adoption is for tracing in metrics today. So I've clarified where we are without actually updating that page because I think it'll be a one-time update that's constantly out of sync. Adoption is from the components perspective, not necessarily from the signals perspective. Yes, Steve, that's a good point. Yeah, that's helpful. Thank you, Steve. Cool. So any objections to resolving this comment? Can we look at the table just once more because I'm already looking at this from your link, but I'm happy to. Okay, there's still a few on the adopters page. I haven't been able to track down yet to update their specific areas, but I will get that done once I get back. So just from the formal standpoint, does it make sense that you also just say this is current as of timestamp? So it's clear if it's out of date, but not an actual problem. So just it's clear as of what time the current state is given. So I checked adopter pages for other CNCF projects. No one has such a mark. Like I would just use the history. You can kind of see when things are committed, you can go back and check it. Okay. Okay, so as we have the comment that we need to review this, then at least we need to make a call for consensus on if that is a way forward given the project, but I think yes, but so should we resolve that or let me rephrase? Unless there are objections, I will just close the comment and to do with the basis of what Steve just said. All agreed. Anyone disagreeing? Very good. Awesome. Next one. There's a question about fork repositories and such. So everything in the adopter's page is adopting upstream. There's no easy way to kind of track this aspect either. I mean, open to suggestions, even when vendors are listed, like vendors are adopting it internally as well. It doesn't necessarily mean it's a distribution. The solution here long term is there will be guidance from the governance committee of a hotel on distributions, and it'll be a lot clearer. To date, it's just a, from the adopter's page perspective, the assumption is you're using upstream today. But there are distributions. So your statement is that everything, all distributions are equivalent to the distributed, sorry, all distributions are equivalent or considered equivalent to upstream as of today is that. Yeah. So if you go to the community page, a list of vendors supported on open slimetry, and so here are all the vendors, and if they have a distribution, links to those things are applied, or if they just have exporters, then it would link to the exporter specifically. The goal long term is that the hotel will likely certify distributions, just like Kubernetes does today. It's not doing that currently. Yeah. I mean, just to add to Steve's point, we are working on the requirements for certification of distributions, and we'll be publishing that clearly, but keeping in line with similar guidelines that Kubernetes also has. So as Bartek raised this, and as Fish is not on the call, Bartek, would you be fine if we just added this to that section, as just said, and move on? Yeah. I would be curious, can you tell quickly, roughly, how the certification would look like? Maybe I'm not familiar with Kubernetes one, because the concern is that those distributions can be anything right now, and just claim open telemetry incubation, incubated someday, you know, stage, and they will do anything inside there, and we don't have any control, because it's like, yeah, some other projects. So I wonder, yeah, what are the measurements? I mean, some of the measurements, again, are obviously not only clear guidelines on, you know, what is integrated from a component standpoint, whether that's the collector components, whether that's Prometheus, you know, end-to-end support, or other components which are in the SDKs, that is the library implementations, but also stability guarantees, whether those are, you know, performance guarantees, testing guarantees, support and maintainability guarantees for long-term support, and really requirements, you know, itemizing each one of those, and then being compliant with the baseline that is set up by the project. Yeah, and again, we're not trailblazing here, like here's the Kubernetes one, it's a GitHub repo, you can take a look at kind of the instructions, they have automated processes that you run that actually conforms, make sure that your distribution conforms to the guidelines, it publishes results, like we're not going to influence something new here, we're going to follow something very similar to this. Yeah, so we can just write one or two sentences into that section, and that would be enough for you, Bartik, that basically we don't have to discuss in detail how it's done, that just that it is done like Kubernetes? Yeah, totally, yeah, I mean, I mean, yeah, I mean, I don't want to, you know, block too much, I feel, no, I definitely just helped, it gives me some, there is some kind of constraint on those. Also, just to add a bit of color, just from working at two vendors on this project previously, and talking to the others, like just because the project is so focused on data collection, I think most of the vendors and contributors are racing as fast as they can to have as little proprietary code, like trying to push as much as they can into the core OSS, so that they don't have to continue maintaining it, and so they can share it with everyone else. If this was a project that had to head back in for processing, I think the incentives there would be very different, but because it's just data collection, most of the vendors don't want to specialize in data collection, and they really don't, they honestly do not want to have their own data collection systems long term. Yep, absolutely. Yeah, I added a quick one sentence with the link, if that works for folks. Yeah, most of the opinions from me and Open Telemetry guess here, and I wonder if kind of, I invited Peter, maybe Peter, you want to give some, I don't know, I don't know, some, what do you think about that, because I kind of, I don't know, like I feel like you had a kind of nice experience on those monitoring and collection stuff already. Yeah, I can say a few words here, I'm here as sort of like, Bartek and I were having a conversation about this space, just kind of informally, and we touched on some of this stuff, and so I'm like here, I guess is sort of maybe just an outside perspective, I don't know if this is actually what anyone wants or needs, but I'll just happily summarize just a few things. When I learned about this whole initiative, kind of the points that got raised in my mind, so just a bit of background, I like was for a long time deep, and it was really stuff in kind of like Go World and Functional Microservice universe, and I actually can claim that I was the one who invented the three pillars of durability, if you can believe it, in one fateful meeting with some key players back in the day. So anyway, accolades check. What is interesting to me about this whole conversation is that what it reveals about the role that the CNCF plays as it selects projects to like put little gold stars on, right? Because my understanding was that the things that it lifts up into incubation, and what are the other like, statuses that there are, there's like approved, vetted. Unboxing, incubation, graduation. Graduation, yes. So my understanding was that as projects like move through those stages and get like checkmarks from the CNCF, it is because they have proven themselves in the like developer space, like they are in use, they are like de facto standards for these things, and maybe not all, maybe all of them have to be all de facto standards, but like basically that's what the CNCF is doing is like saying, hey, these things are good, you can trust these things. But what it feels like is happening here is like there are a collection of expressed user needs that are real and need solutions. And the open telemetry group is like collecting them and then like trying to suggest products that solve them in various ways, ultimately solve all of them, but like haven't yet done so. And so it feels like either it's super premature or it reflects that the CNCF isn't actually about what I thought the projects that lifted up the properties of the things were, it's actually something else. It's actually like maybe building solutions that it's like customer companies or whoever is like following the CNCF to things they need, maybe it's that, and maybe that's okay. I don't know, but that's not what I understood. Anyway, yeah, this is my perspective, and like maybe the most concrete thing I should have maybe opened with this is like, so like before Prometheus was in that process, I knew like tons of people who use Prometheus in my space in my role. But like, I don't know anyone who uses open telemetry, they know of it, but I haven't met anyone who like has ditched their Prometheus instrumentation library for our hotel, like a couple of tried, but like it just hasn't happened yet. So that's what's interesting to me, and that's, I don't know, maybe worth discussion, maybe it's all already been said, I don't know, what do you think? I think, Peter, again, you bring up some good points, but I would say that, you know, having rolled out AWS's distribution for open telemetry, we have several customers who are using not only open telemetry as an commodity agent, if you will, but also, you know, using Prometheus, and it is an win-win for both ecosystems, it's not, you know, replacement necessarily, it's also, you know, several customers, large customers moving towards building out their Kubernetes based ecosystems, as well as other compute support. And I don't think it is fair to say that, because there are several customers, and I'm happy to bring you a list if needed. My understanding is that they're all private, though, is that correct? Like, corporate customers, yeah? No, that's not true. This is from the adopters page, but also like, so I think also, so Peter, wondering, like, who are the people you talk to? Because I think one thing that we need to actually address about open telemetry, and what CNCF has actually done is CNCF is used to only talking to, like, niche cloud-native companies, right, who are used to implementing everything on their own, but where actually CNCF is going is actually bridging the gap from everyone who used to be on-prem. And that's where open telemetry is actually making the biggest in-road, where it's actually bringing all these companies that like, because if you look at the attendees at KubeCon now, and a lot of the open source summits, there are a lot of companies that like, they're banking companies. There are a lot of companies who like, still are kind of doing on-prem, but moving causally, and they're going to be actually, wait, right, and they're going to be actually not using their own implementation of things, but trying to find like, libraries there. And also, especially when it comes to observability space, where like, you know, like, okay, yes, coming from Splunk, like, we are, we are quote unquote, you can call us evil overlords, right, but all a lot of our customers don't have time to implement their own, like, implementation permissions. They're going to want to use libraries, because from their point of view, it's not worth it. And that's like, and our adopters list is actually showing that we have companies that are using our instrumentation and our collector. And the one other thing I'd add is like, the criteria for incubation. I don't know if everyone's kind of familiar with the CSCF terms, but there's no criteria of like, in the incubation status, being the de facto standard, replacing other standards, like being the only solution, none of those are criteria for incubation. I didn't mean to imply like, like, the only choice or like, whatever, but, but like, wide adoption. And the question to me was like, who am I talking to? Right, which is completely fair. I totally, everyone has their own like little lens through which. Yeah, yeah, exactly. So like, the people I talk to are largely like open source communities and adjacent, like Slack rooms and mailing lists and GitHub issues. So like stuff that is public in that sense, often products of corporate environments, but largely not. And I think at equal measure, a lot of small, medium, some large startups and companies that I consult for, often in a go capacity, often in a observability capacity. So actually, that's interesting though, is that go tends to be like adoption of go tends to be more associated with a cloud native company and not for those who are in, right? And as it's like shown from part of our adoption list, it's actually people who are bridging the gap from coming from on-prem and hybrid worlds. Right. The people for whom open stack has completely failed. So on to the next thing, here we go. Let's try it again. Yeah, for sure. Yeah. So like, I don't have this ability into them. And if that, if that is your like user base, then I can't speak to it, right? Cause I have no idea. Well, it's part of it, right? Like that adoption page shows like we have people like Shopify, like massive cognitive company. Sorry. You mentioned one thing, which is a little bit worrisome for me. And that is standards. CNCF is not a standardization body, right? It's not a standardization body, like W3COITF, right? It's not about we are not creating, you know, here declaring this is the standard. I view and based on the conversations that I have with our customers, I can vouch for that, that there is certainly a huge interest there, especially around standardization across different single types. And, you know, the clear mandate that we have here in the SIG is to provide that your diligence in terms of the requirements that we see here in the process. And that is adoption. And that, to me, looking at what is there is clearly given. I really don't want to get into that standardization discussion saying like, you know, there is a standard and, you know, is OTEL the old dominating standard or not? We have already seen that. I'm sorry if you're bringing the word into the conversation. Yeah, it's not. Let's stay clear of this standard. There it is a specification. And there is a clear uptake in the deduction there. Yeah. But okay, so maybe this is an important point. Does that uptake have to be organic? Or can it be sort of like outward sales driven, for lack of a better word? So for the context, it is much more about the direction. And I don't have any problem letting this discussion continue. I just want us to use the time deliberately so we can also focus back on the document. Or we can discuss this more. Both is totally fine with me. Maybe one point. And obviously, I have like 20 heads and I'm very much torn. From my perspective, most Prometheus and Prometheus ecosystem users are not truly cloud native. I would say more of them are in the brown field data center space just because of sheer numbers. But oh, no, I'm already going into discussion. So should we continue back with the document? Or should we discuss the points Peter wrote up? Both is fine with me. I just wanted us to be deliberate here. Yeah, I guess my comment would be if it's directly related to one of the questions in the due diligence that requires consensus, then I think we should absolutely drill into it. If not, then we should probably either create another dock like Bartek did or like schedule another time to have that conversation. Because I think the goal is to try to get through this dock from a consensus perspective. And if it's related, like if it's an incubation criteria thing, and we're not going to meet that criteria for whatever reason, that's the primary focus I think we should have for this audience. General feeling of the room? I mean, I still think, you know, that's the product of production deployment that are high quality and high velocity. We kind of navigate that for tracing gas, but for rest no. And then we saw it's worth discussing, but that's only my opinion. But based on what the TSD said, that's a good point, isn't it? So should we, as a possible consensus, should we then just say that yes, tracing has the adoption, the rest is coming? Can we do that? Can we do it from a signals perspective? Like, do we have consensus that tracing is adopted? And maybe we don't have consensus that metrics and logs are and explicitly call that out here? That's where I'm trying to go. That we have a consensus position of everyone in this call here that is a statement. Of course, again, I have 20 different heads here. So I'm very deliberate about which one I'm currently varying. But for the tracing aspect, I do think there is no debate that there is wide adoption. Yeah. So, okay, then let's, okay, let's try this. And then we are overriding the other thing again. So bear with me. This is just the first step. And Steve, I think you need to reload your screen, because I'm not seeing what I'm typing. Yeah, it's pause. Sorry, there you go. Yeah. Perfect. Thank you. That's similar to how the Prometheus things work. If you saw the recording there, we nailed down one consensus and then we built possible consensus on top of it. Of course, that has shown to take the least time to discuss. So as a first point of consensus, new consensus, of course, we're actually revisiting, but okay. Sick observability has consensus that there is wide and organic adoption of open telemetry tracing. All agreed? Anyone disagreeing? Okay. Just for the record, I'm uppercasing that one T. Okay. So should we make a, what's the positive statement here? Steve Bartek, do you have any wording suggestions? You want to basically note something about metrics and logs without making it sound negative? Is that the pitfall? Yes, of course. Yeah, I don't believe in making, yeah, precisely, but while still retaining the concern of Bartek and Peter. Yeah. I mean, yeah, I would say that maybe from what I say quickly, yeah, metric and logging are not in incubation kind of quality in state. That isn't, but based on what the TOC said, right, is that there could be parts of the project that aren't at the same level and everything. Maybe there's a statement about what we, that's not making a statement about the whole project. This is just trying to split out the subcomponents. So we in the sick can find a consensus and then just bounce this to TOC and they can decide whatever. Because I don't think we want to be making progress otherwise. And I would like to finish at some point. Yeah, I guess one suggestion I would have is that there, I kind of raised this on the TOC call. So some of you were on there, some of you were not. So I think I'll just repeat it for the entire audience. From an open symmetry project perspective, all of the SIGs have components. Those components are adopted or not adopted. The primary components today are the instrumentation libraries, which are language specific and the collector. They are a reference implementation on top of the specification. So you have a dependency on the specification to make that work. All of those components are then tied to signals. I feel like the last two meetings in this audience, we've been focusing a lot on the signals. But it says, does the project have production grade deployments that are high quality and high velocity? For all of the components, the answer is yes. The nuance there is that that is a yes for tracing signals. And I think that's what we've all kind of gotten hung up so far is that, well, what about the metrics and logging signals? And then there's kind of the back and forth on, does that matter or not? So maybe one way to approach this is, do we have consensus that all of the components in open symmetry are adopted? First, then we could make a note about the tracing signal specifically, which is what the line in green currently captures. And then the final one would just be more of a note. Metrics and logs are not stable yet and are not part of this consensus or something, like just articulate that there are additional signals that exist. But that's separate from the project as a whole, right? You can still adopt and be in production, regardless of whether or not you have those other signals. Right. And I think why I'm pushing this direction is that you're right, those components might be adopted, right? But it's still only one signal is implemented on those components, like collector, the most kind of implemented base and the most adopted why people use essentially SDK and collector is mostly for tracing capabilities, right? So all of this is across all the components. I don't agree with you about this because what I can say is that we have built instrumentation around AWS monitoring backends such as CloudWatch or which handles metrics or Prometheus, our managed service for Prometheus and the collector components that exist today are being added, are being used for by customers for again supporting metrics. Now, there is a clear roadmap for metrics, which is being currently worked on by the project and a very clear roadmap and milestones that are, you know, have been established in the past few months and work is in progress. And so is that happening for logs. So to say that there is no support is inaccurate. Well, there's more than a few, right? Like a lot. Yeah, like, like Google, for example, when they have customers who come in of Windows VMs, they tell them to use the open telemetry collector and they went and added like Windows system metrics, right? Like it's more than just a handful. Is there an overview? Like a lot, I feel as if part of our problem here is we're discussing on qualitative statements a lot and not going towards quantitative statements. Yeah. So is there, for example, a list, an overview, a matrix of metric signals and of logging signals being used in production? Of course, I do think that this would alleviate part of Bartek's and Peter's concerns. Part. Yeah, I'm going slowly here. I'm, I'm cat herding hasn't been on my or has been on my. It's impossible to deal with me. Yeah, I understand. That's not the statement about you. It's just a statement about spending two decades in open source. And always trying to get people to agree for those two decades. I mean, Richard, again, I agree with you that, you know, we are happy to provide any quality quantitative, you know, measures or whatever that means, if we can define that clearly. And, and, you know, the specification because the implementations as Steve pointed out, follow the specification, there is certainly a compatibility matrix or a matrix of features, which, you know, actually can be highlighted if that's helpful in terms of support. Right. Okay. I think, you know, yes, I mean, definitely the number would be super nice. But my my worry is that, you know, I always, from the beginning was, you know, excited to see open telemetry, you know, protocols to be, you know, kind of the factor of standards, right? We know what to use for logging for replicating, you know, log lines across systems and from client to the agent, let's say, the same for traces, the same for metrics. And suddenly we totally are, I mean, open telemetry looks like it's very unfocused on this point because we are adding collectors with tons of APIs. And we kind of, we, we, we want to find the quality of if it's incubation or graduation by amount of APIs, this is not healthy for community. So actually, it sounds like your, your comments are more that it didn't meet your expectations, right? Like, as you said, you had these expectations for open telemetry, either not meeting them, but it's like, we, but that shouldn't be blocking incubation. Let me chime in just one sentence here. And it's like, if we have more projects in this pattern of, you know, the maximal feature set and the maximal set of integration, like, is that going to take the CNCF to a good place or a bad place? And like, for me, there's a clear answer to that. So I just, I just want to make, clarify something we talked about a few meetings ago, like, we should consider the logging part of open telemetry experimental, like the community has very purposely sort of put it off in a thing where we're slow walking it and very slowly working on it because we're very focused on tracing. Tracing is now GA, metrics is next. But I don't want to look at our ambition of eventually bringing in some logging components and doing some work in logging. I'm worried that that's really distracting from the core project, which was SDKs, collectors and protocols for traces and metrics. And tracing. Yes. And we're actually at that point, if you reach incubation, that was our main goal is deprecate open tracing. And by actually, that's not reaching incubation. This is impacting the CNCF where open tracing has been maintained in two years. And this is also impacting all those users. The other thing I'd add is, I think we're also blurring the lines between incubation and graduation. This is not a graduation conversation. If it was, I think many of the points being raised here are completely valid. Like, you don't have any metric support that's stable yet. How can you graduate? But that's not what we're talking about. We're talking about incubation. And the criteria for that is having production deployments that are high quality. We do. It doesn't say it has to be high quality for every single thing. Like it is high quality to the point where customers today have adopted in production environments. So I'd like to make a proposal. I made an update here and I put three separate bullets that we can try to talk about to see if maybe this gets us closer to a consensus. So I'll read it aloud just so we can talk about it live. Just a moment. Did you delete the other thing? It's this line. It's the exact same line. I just moved tracing from the end to here, but I didn't make it green because I think we should talk about it again. I agree. Just as a point of order, everyone who touches a green line, please talk about it before you touch the green line. Of course, they are present. It's fine. We caught it. But this is like my whole system is built on the green lines never ever being touched, which is why I made explicit also you added signal in hotel. So that's my point. Like I literally talked about making the tea uppercase to yeah, please don't. Yeah. So I removed the green so that way we don't even have consensus on it, but I won't touch it again. Sorry about that. So I put a paragraph here at the top that people should read real quick to see if there's any disagreements with that. And then we can talk about the three lines. The one point as I usually, but this is without my head as most of you will know, I usually focus on the wire formats first because this allows you to freely interchange back ends and libraries. I think they're the underlying thing of everything else. But I'm also fine with this order. Back on. Yeah. And from a stability perspective, that's how hotel kind of treats it too. So the specification has to reach stability first before the actual implementation can. The specification is where like that data model and wire formats live. So we follow the same model. It's just we kind of bucketed the whole thing underneath the signal, which makes it a little bit confusing here. But okay. In the interest of time, let's try this. So basically, given that there are components and there are signals that the components are being used for, I try to distinguish between them. So maybe Richie, you want to kind of lead it. If we want to go back to this one specifically first. I would actually suggest that we put the signal first. Of course, the wire format obviously includes the data model and as such, this is as you said, the basis for the rest. Okay. So as this is a slightly changed line, SIG observability has consensus that there is wide and organic adoption of the tracing signal in open telemetry. All agreed. Anyone disagreeing? Agree on my side. SIG observability has consensus that there is some adoption of the metric signal in open telemetry. Yeah. So this one might need clarification, right? Because the specification is not stable. As I was pointing out, there are people using metrics in production today, though. So I'm not sure how to draw that distinction. I don't know if Artic has some suggestions on like maybe explicitly saying the specification is not stable, but there are production users of metrics. I don't know how you want to phrase it. Yeah. I would still, yeah. I wonder if we would just cope this incubation bar on just metric. Are we happy as a community, as SIG observability, to kind of put this label on metrics? And I'm not sure about that maybe. But that's interesting. I think it's worth having a conversation about that. What if we do just have line right now, lines one and line three? Do we have to say anything about metrics and logs? Is that a requirement? Yeah. Sorry. I mean, with all my heads on, at the same time, metrics, logs and traces unification in a single set of unified client libraries, collectors, and a holistic design is the core goal of open telemetry as far as I understand it as such. It should at least be looked at. I'm completely fine just saying, well, it's future work and be done with it. But I think it should be mentioned. No objections. And I try to have a positive statement baked in. That's what I'm currently marking. Oh, nice. I'm good with that. Okay. So let's try for this one. Also, we are way over time and I have a hard cut in two minutes. But let's try. SICK observability has SICK observability has consensus that there is some adoption of the metrics signal and open telemetry, but stability and compatibility with open metrics and premises has not been reached, but it's planned. Richard, it's work in progress, right? I mean, it's being actively working. Yeah, yeah, yeah, yeah. Yeah, that's fair. It's not only planned, it's also being work. Yeah, no, you're right. That is, and takes... Yeah, makes sense. I can't type when people watch me. How about this? Thank you. That's even stronger. I agree with that. Okay. So let's try again. SICK observability has consensus that there is some adoption of the metrics signal and open telemetry, but stability and compatibility with open metrics and premises are work in progress and SICK observability takes note of premises working group in open telemetry. All agreed? Anyone disagreeing? I will change the green in a second. Is this a fair statement and I'll make it non-green in a second? It's experimental better than future because there is technically some amount of support for it already. Yeah, and there's work. And there's ongoing work that is actually already in flight with the stanza and logging agent being integrated. Yeah. I mean, we heard voices that it was, yeah, postponed and delayed so far, so. But Bartek, as we said in the last meeting, we actually show that there's a log SICK, right? We talked about this in the last meeting. There is a log SICK that's actually being worked on, right? And so I'm kind of missing the point that if we've shown that there is active work on it, how is that being viewed as being denied if there's actually work in a doc in Kodos? What do I mean, you're shown like, you know, I mentioned that he joined a meeting and there was nothing there. That's no, no, no, no. Jonah also proved log SICK. Yeah. So we also asked you for proof last time and you didn't give us any proof. Jonah, Jonah said he joined the community call that was deleted six months ago, but was still in his calendar and no one was there. Okay. And I followed up with him and Jonah started joining the maintainers meeting, which had replaced it six months ago. But the log SICK does have people. It's a very active amount of work happening. I can send you, you know, specific projects that we have done, as well as, you know, the log model, log data model, as well as the stanza component being integrated into the collector right now. Also, Jonah proved log specs. Like he is actually viewed as like participating in GitHub PRs. So that's like, I don't think we can use, like Jonah's quote might have been misplaced at the time, but I don't think that's fair to use anymore. He mentioned the community meeting. It was, someone had modified it and it went back to the calendar. I would like to avoid he said, he said, situations. How about Alorita takes an action item on, on putting some quantitative data on this as far as, okay, perfect. And we will try and actually finish this the next time. Can we schedule an ad hoc? This has taken two months. Right. Like this has impacted hotels ability, ability to actually be a part of coupon North EU in terms of the maintainer track, which was one of like, which actually impacts this ability to like get more participation. I heard this, you know, by the way, I heard that many open telemetry docs were actually approved where others were As the coupon co-chair, so I would You mean as coupon co-chair, the person who spent all of last week approving these talks? I mean, I would, I would love to know that because I heard, you know, the other open, I mean, yeah, this is like, there are no, but there's a difference between maintainers tracks and actual talks accepted talks acceptors those based are people who submitted things open telemetry as a sandbox project is allowed as maintainers track talk. I understand. But I'm saying that I suppose that, and that's fair that, you know, open telemetry talks where I agreed and like kind of approved more on the normal track because there are not part of the maintenance track. There are so many rejections because Thanos and Prometheus and Jagger and others are already on maintenance track. Let's be fair, that actually isn't the actual process. Glad to walk you through the process is coupon co-chair who walks through choosing the talks. But what we do is we actually from the observability, there's a program committee that gives us a top 10 to 15 talks and we go through right based on their rating and then after choose those things there. Yeah, yeah, I understand. I just want to, I think that would be fair that, you know, to give open telemetry voice because of there is no maintainers. But I'm telling you that's not how we do it. As the person who chooses the talks, I'm telling you that's actually not how we do it. So I'm sorry, I don't know where like you're getting this information, but that's not how we do it. You can talk to Steven and I whenever you want, but that's not how we choose talks for coupon. I think you're discussing on the level of process and on the level of perceived outcome in parallel. So, yeah. For the. So Richard, would it be helpful to highlight, you know, what we are, what opportunities we are missing also very quantitatively, you know, in terms of the project opportunities, which are really important for the project and, you know, help in the work that is being done on the project to make progress. I mean, I think the qualitative discussion. On the level of extra PR, yes, no, I don't think that matters on the level of the due diligence. That being said, I do note that we take quite some time to discuss this so completely orthogonal from the formal point. I do think it would make sense to try and speed things up. And if interjecting a meeting helps with that effort, that seems to make sense. So the same time slot next week is open telemetry metrics data model sick. That's the only clash, which I can see off hand, but it's not my call to make. It should be off the call here. So can we do a show of hands for saying, yes, no, on lost half of the people. We lost half of the people. Yeah, let me do gallery view. Just a second. I mean, we can talk offline on the mailing list. Yeah, we can definitely make it more often. So everyone who's in favor of having this call next week as an interjection, please raise your hand. Please send out via the email list as well. Yes. Okay. Anyone who's against? Okay. So like for the recording, two thirds are in favor. No one is against. Does anyone want to abstain? Perfect. So now it's the nation's. So I'll talk to Amy to put an intermediate thing into the calendar. But Bartek's point is also valid. We should try and as always move more out of the calls and into the mailing list, into the document, blah, blah, blah, blah, blah. I would much prefer to just go through comments and such and just close stuff, which has been discussed during the week and consensus has been reached, then discussing everything in depth every single call. Okay. Thank you very much and see you in one week, too. Thanks. Thank you, thank you. Thank you.