 Hey, yeah. Test, test. Yeah, we can still hear you. Hey, everyone. OK, David, Jessica, why are you here? Is this because of the document? Or I've never seen you before in this call. Yes. Oh, yeah. So I thought I'd enjoy it because I saw Arthur's post. And I thought, yeah, community-driven white paper about observability comes up. Interested in the days of connection loss. And market days to connection reestablish. Oops. And then just in the previous meeting that I had with Jessica, I said, I'm going to go here now. And then she thought I would also be ready to join. So cool. Here we are. Yeah, we're from profile apps. So I think we have enough people. Let's get started. So Arthur, I took the liberty of moving that one segment upfront, but we can also move it back. It's just we shouldn't spend ages on it. But on the other hand, we should not talk about anything else either. I still maintain its weight early to split stuff into a separate call. But like synchronization on what the next work packages in such or make absolute sense, your choice. You can also just move it back at the end. But we should actually try and get some time for this as well. Sorry if I have background noise just continuing. I'm not really sure if we have on the next meetings, we can have more time to discuss that. But if open telemetry due diligence continues to take several weeks, I'd prefer to have a separate meeting. Ideally, it should just be finished. So yeah, but that's not the direct answer. OK, so let me rephrase. If I time box you to five minutes and you do your pitch and your synchronization and everything, and then we get going on the due diligence. So you don't have to wait. So let's time box you to five minutes. And let's accept my own suggestion. Also for all the new joiners, I put the document into chat. Please write yourselves in if you want. You don't have to. But you're hardly invited to. I love seeing so many people. That's great. So if I kick it off and I'll time box you. So we start now with the answer. Yeah, go on, Arthur. First of all, thanks for everyone who don't here to work in the White Paper. It's really awesome to see so many people willing to help us. Let me share my screen. I plan to have a call really similar to the sake of observability. We have these questions, what we wanted to talk about. Many people have contacted me saying that they want to help, but they have no idea how to do so. So we get questions as per way. And we can talk together to get going. Another thing that I wanted is we have a lot of suggestions and a lot of things to reveal. And those calls we can do reveals as synchronously through the document. But I don't like the idea of accepting or rejecting suggestions without being loud about it. So I don't want anyone to open the document one day and see that suggestions just disappear or I don't know. I like to be transparent and make sure everyone knows the direction that we are following. So on this call, I expect to just go to all suggestions, talk about it, see if it goes in, if it goes out. And yeah, that's it. I was planning to do a doodle to decide on schedule and what time we should do it. But I didn't have time to do that. I can do that by the end of the meeting. So I wanted to ask people, do you think these meetings are going to be useful or should we just stick to a synchronous communication? So then let me reply from the last point. Historically speaking, it's always risky to just have more meetings. In particular, of course, you will run into issues with other people maybe not having the time. Maybe they made time for this time slot, blah, blah, blah. So I would strongly encourage you to define work packages, to work on the mailing list or in Slack, to make it possible for people to chip in. Myself, I'm deliberately not doing it, so work gets more distributed. But I look forward to actually working on this as well. But yeah, I would strongly encourage you to do things asynchronously. Of course, you will just run into scheduling issues no matter how you do it. And you also see a lot easier who is driving, which parts of the discussion of the document, blah, blah, blah, which enables you to travel more easily who is doing what and who delivers how quickly. So yeah. Yeah, and I think it's fine to have like a meeting for reviewing the work and synchronizing. And we can use sync observability for that if there is a time. But especially around the suggestions, Arthur, maybe you can just limit the permission to yourself and allow others to just put suggestions into documents so everyone can collaboratively review it. And then you will be the blocker. So hopefully you will have time to be on those kind of meetings and kind of apply, maybe have more people than just you. But yeah, that would be nice to get track. And maybe also be careful because there could be malicious attempts, whatever, as well. So just limiting permission would be necessary. Just a wild suggestion or idea, given that we only meet every two weeks if we change the cadence to every week, then we would have an additional time window or is that too much, at least until everything is sorted. The thing, again, unless we actually meet the time, we should be extremely worried of having interactive in-person real time meetings. And historically, we had even the problem of the work queue being too empty. But now that we have a lot more people here and now that we have more work packages starting, maybe we will actually get to the inverse. I think the open telemetry due diligence is a little bit of an outlier. So let's try and see how, yeah. Also, we have time, actually 30 seconds over. Just one comment. So if you are not doing those meetings, everyone who has any doubts, just ask away. I'll try my best to answer everyone. And for everyone, again, Slack and the mailing list are the official channels of communication. We can also find them in the document, which is just above the thing. And you also like where you just wrote yourselves in. So please subscribe to the mailing list and or come to Slack, because then you have this asynchronous communication. Moving on. Steve, you want to share your screen? Sure, why not? You don't have to. I can also do it both first. I know, that's fine. So I will give you a point of order. I'll just read it out, at least paraphrasing. And everyone who only came here for the document by Arthur, you can also reclaim your time. Of course, we will be talking about this for the rest of the call, I think. I don't think we will, or I think it's clear to everyone that we will not be finding full consensus on the complete utilizations document. So instead of both sides trying to convince each other, I would suggest trying to focus on finding what can be points of agreement and very simply not done to two different views. And then hand this to TOC, because they need to make the final call about this anyway. That being said, as more and more people come into this call and add more points of view, I'm also extremely worried of just shutting down any discussions as they ensue. Just try and be mindful of not going completely circular. It's not an easy balance to strike. So let's dive in. So I guess given that we were on three, we have points one and two where we reach consensus. Then we had a break. So do we want to address the comments on the break and then try to tackle three and four? What would be the best way here? The elephant in the room is obviously that Bartek put the statement on top and there was discussion on the thing. Yes, I guess my recommendation for that or my proposal would be, what if we throw that into another Google Doc like the original work that Bartek did on the due diligence? And that can be linked in here as well. But I'm fearful that we'll rabbit hole on that for the entire conversation, ideally making progress, I think, on the sections here where there are comments directly related. And then we can discuss how we want to handle the additional feedback things in the separate docs separately. I'm not against it. I'm just noting that we did try this in the past and ran into the same discussions, just distributed amongst the document as opposed to having this discussion in a distinct block and then being able to get rid of them but basically to acknowledge it and then just move through the rest at pace. We can try both. Yeah, we can try both. So, please. Yeah, maybe, yeah, from my side, I would just make sure that, you know, I mean, we don't repeat, yeah, in cycles. So we make sure we acknowledge that, you know, those are the statements that are there and to every question that says, hey, is there any concerns in design or incubation or like whatever, I have the statement that, yeah, I have concerns. I have free major. I kind of reduce them to like, you know, very minimal to not spend time on details which are less actionable as we noticed like last week. But there are like free major points that I don't think we agreed. So that's why we propose to just put it on the top. So anyone else who is looking on this doc, it has a clear vision what sick observability is thinking about that. So I don't want to, yeah, hide that as well. So I don't necessarily have a strong opinion if we put that in a separate document or not, but we should be 100% certain to make sure that whoever reads that does not get the impression that the sick observability has that opinion. It is one opinion. And the way it is phrased where we say, you know, we and our and so on, whoever reads that and you see might get the impression that this is the opinion of the sick observability and it's not my opinion. So that's something else. Also, can this actually just be like an again, like maybe, so maybe not having a separate document, but like this is for incubation. And so maybe the final thing of this page would be like, what are the like takeaways, right? Like, okay, like, you know, we highlight this is one person's opinion. That was the main goal here there. And then this is the other people's set of opinion. And then after we can break it down there and have it at the end as a summary, right? Because by going in, so there's two things that could impact like that impacts this project negatively is one, is having such a negative statement in the beginning or it predisposes people to look at this under that bias and then view things there versus viewing, right? Like this is supposed to be looking at all the information and then gathering own opinion on it. So if you have that at the end of it, then people can go through it too. And then after say, you know what, I like, you know, these are the different like people's different conclusions. I either agree with them or don't. But if you have the conclusion that front, right? That shapes everyone thinking to think that's the only way to do it. It's an only way to go forward. Yeah, I agree. Okay, I think, yeah, that's actually understandable. We are negotiating on, you know, how it will look on further steps when TOC is looking and is that, and we are negotiating, you know, how likely whatever outcome it will be. And I think I'm happy with whatever will be discussed this. I just want to add one more thing is that, yeah, I, okay, that looks like my only opinion, but I gathered them from the CIC observability members as well. And I understand Michael, you are a member as well, but there are members with, you know, that would agree with my point of view. So I wonder, yeah, how we say what CIC observability actually thinks in this case. So then... I think the consensus is the markings in green on this document. If people want to form a different opinion, I mean, I think it's fine to have that document and maybe everyone that's willing to put their name on it can, but anyone that doesn't, like you can't just have a blanket we, I think like people should either own up to that they agree with that point of view or not. I guess that's the main point. Yeah, how do we do it? Yeah, very implicit. Go on, Michael. Well, you can, we can, for example, I'm just saying one way to go about it is if we indeed take whatever is at the top, which at least you put together. I mean, I'm not saying that you're the only one, but the we and our feels like it's inclusive. And at least I do not subscribe to that. Yeah. And let people essentially say like, you know, yes, I agree with that part. And we already said that in the agenda, right? There won't be an overall consensus on that. And that's perfectly fine, right? It's okay to say I support that view or not. Let's just not make this blanket statement, we and then everyone gets the feeling it's the entire seek of stability that has this feeling or this view. I'll try to unwrap this because I feel we're about to go in the circle again. I fully agree with Michael's point that the we needs to be specified or removed into an eye as far as I can see, it's not a singular opinion, but there is actually a little bit of split within seek of solubility. So Steve's suggestion of putting names into specific areas or under specific statements can make sense or most likely does make sense. Of course, then we can move on functionally or not functionally, organizationally speaking, unless there is consensus, we won't mark it as green. And historically for the three other due diligence documents which we did, we put the summary on top. So I would, I mean, I get consensus point on this potentially being the rest of the document being read under the lens of having that statement above on the other hand, that is precisely the intention as far as I gather. So, and as it is not an opinion, and it is like, I'm the first to agree that- It is an opinion though. Let's be clear, this is all very like, unfortunately we all have to admit software engineering is very opinionated even though we're all trying to be very technical and unbiased, but it is opinionated. Yeah, it is very subjective. Yeah. So I'll make another proposal to that, right? I mean, I think Bartok putting together a proposal on like thoughts and gathering from other people is perfectly fine. Why don't we do the same thing on the hotel side, maybe the GC or TSC or whoever wants to get involved. We could work on a response that also gets added to the summary to the top. That could be a way of kind of reaching a compromise of seeing alternative views. That makes absolute sense, precisely, but yes. And just so you know, I think that was, I think Bartek was saying that was fine. And I kind of agree, there should be the assessment. And then at the bottom, there can be a section that contains all of this information labeled as to who put it in and why they think it's important. And then if we want to have, as part of that also, the Open Telemetry GC, just like addressing these concerns, I think that's also a reasonable thing to have at the bottom. And I don't think we need to have anything more than that. It's like, these are the concerns that were brought up. This is what the project leads to say about those concerns. And that's that. I have one minor tweak. If you scroll a bit further up, Steve, please. The first sentence, imagine the whole, whatever is now on top, is rephrased into not like, I Bartek say this, but whoever signs up to that thing, like, okay, the group of people who have that opinion, currently it reads, I Bartek say, I can't recommend that. And then there is a we. That is kind of like inconsistent, right? Whoever goes behind that should say, okay, here's the group of people who subscribe to that. And already some pointed that out in the comments, pretty straightforward to get the names there. And having these two positions in there, clearly saying like who is behind what would, at least for me, fulfill all needs there. Then we can move on. I think it's fair to have two statements. Steve is absolutely right there. Functually speaking with my chairhead on, I do not believe that we should be putting any strong statements which color the rest of the document by design should be put on the bottom. I think they should be part of the summary. But I do think that Steve and is absolutely right that there should not be only one document or a statement that can easily be two, that actually makes sense, like a lot of sense. And then we can also stop discussing endless details of the thing above and hopefully move through the rest. There's one thing which I found I need to officially take off my chairhead for a second. There's one comment by Steve from today about how Open Metrics was not released until November 25th of last year. Given that, and more than keep me honest, Open Metrics and Open Censors have met in 2017, in 2018, in 2019, I was in a majority of the cause of the first half of Open Telemetry Metrics of the first half of 2020. I don't think that is a fair statement. In particular, since if you go back to 2016, the public communication of Open Telemetry and Prometheus from day one was if you do Prometheus, then you do everything right for Open Metrics. If we look at the breaking changes of Open Metrics versus Prometheus, A, timestamps are different. They're not millisecond anymore, they're seconds. And timestamps are explicitly discouraged within Prometheus. And B, you have a underscore total is now mandatory for counters and transparently done by the instrumentation library. That's it, which is also why Datadoc, for example, was able to just take that code base of Open Metrics and just re-implement Open Metrics in their own thing. So with my Open Metrics head on for the last four years, I have been really trying to get together. And we have the same discussions. And if you look at Prometheus WG, you see precisely the same discussions we had back in 2017. And again, Morgan, keep me honest, please. It's like the only major two things which I saw progress are A, that this maximum guarantee of 90 days of stability, which was initially the plan for Open Telemetry is gone. And now we have long-term guarantees for the API, the data model, the wire format and everything and not this maximum of 90 days. And B, the histograms. And I would ask everyone, because I'm really trying to be fair here and it's sometimes really hard as chair, I would ask everyone to be fair in their assessment. And that part is just not true. Objectively, provably true, not an opinion statement effect. Period, putting the head back on going to 0.3. Sorry, but I don't want to shut you down. So, Richie, you asked me to keep you honest, but you mentioned that several things. I wasn't, which one did you want me to keep you honest? Yeah, we had those two-day meeting in Long Mac then. And we tried to walk through all the open questions. Was Jeremy and Bogdan, yeah, yeah, I remember that. Precisely. So, yeah, I had to get that off my chess course. That seems to be something which is recurring and it's just not factually correct. And everything about how Prometheus metrics work have been in the open since 2014 when it was stable and hasn't changed since. Which point on the dock are you replying to? I can put it into the chat just a moment. And reflect. Here, right here, this one. I feel I have... Oh, that one, okay, got it. Yes, let me also put it into chat. Yeah, sorry for that one. It's just that that has become really, really, really tiring and old from my perspective. So, wait, question though, since open metrics did go up for incubation review, what was the TOC's feedback? Currently waiting, of course, they have concerns about our openness. Of course, we closed our talks or our meetings, which, funnily enough, we did to maintain the focus on Prometheus. Yeah. So, isn't that kind of addressing the point that it isn't as transparent as... No, it's not, as the code was open. But if we want to talk about open metrics, we can, but then we stop the due diligence for a second person, because then I need to stop wearing the chair hat and I need to reply with my open metrics at home. If we want to do this, absolutely fine. Of course, there is massive confusion about the history of the projects. The summary is Prometheus has been open all the time and it's a reference code and it's been in production since 2018 in Prometheus. If you use Python with Prometheus, if you use open metrics for three years now. Yeah. So, can I jump in here and say, like I can see why these kinds of comments are totally annoying, Richard. And I think we should stop sniping around, like which came first or anything like that. I think that's not remotely helpful. I think the focus here is like, is open telemetry like trying to support the Prometheus ecosystem or is it not? And we believe we are trying to support the Prometheus ecosystem. We have a proposal for how we're doing it and we're actively doing it, but it is different from saying, does the project like use open metrics as its internal format? And we're saying like, we're not, but we are trying to support open metrics the way we're trying to support stats D and everything else. And we're putting a lot of effort into ensuring that there isn't some work we're doing in the metrics field that's gonna make that unfeasible. Right, right. And we are fully committed to that, Richard, as you know, I mean, very, you know, very glad you're joining in as well as others from the Prometheus community to make sure that the telemetry fully supports Prometheus, right? Yeah. And I think that intention, like that's literally reason why I've been, in particular myself, have been trying to make this work somehow since 2017. Right, and I think we should just remove anything that's implying that somehow there's some technicality for why it's right or wrong to support open metrics. Like, I don't think that's helpful at all. The question is like, what are these communities doing today and are they trying to work together? And there is, we have our approach, it's fine to have a critique in there, which is saying like, that's fine, you're doing that, but it would be better if you used open metrics internally. I think it's totally fine to leave that as a critique, but let's not focus on like the history of these projects and like timelines and stuff like that. Yeah, and you might have seen the roadmap at Slink there as well, but it does specifically call out both Prometheus and StatsD as being the minimum goal for metric support in the project. Yeah, yeah. I mean, I can talk for hours about like how I thought at that time, I just feel like that's a good discussion. We should have a drinks or something it's not, it's just not relevant to this work. Yeah, my opinion is that is very relevant to this work because since I seen so much background that this compatibility stays there and while activity increased to resolve those incompatibilities, I don't see the community have a trust that it will be that quickly done. So if it's so soon, like it's planned to be, I guess some discussions we're talking about some May that some compatibility, so not using directly, but like just compatibility will be there in May. Let's wait for that. Let's see if this is there and then this will be a good point and indication that incubation and adoption, there was no essentially concerns for widespread adoption, right? That's my kind of the goal. But at that point you're not being objective anymore as a tech lead of the CNCF SIG, you are taking sides and that's not acceptable. I'm taking sides of the CNCF and of the cloud native solutions that you have already used. Hang on, hang on, time out, time out. I don't, this isn't gonna be useful. I just wanna step in and I actually agree with Bartek in the sense that it is fine to say that we have a plan to fully support Prometheus, this is our timeline. It is fine for Bartek to have a comment on there saying, I think it would be inappropriate to move forwards until we see that work is actually completed. We have the counter content comment, which is like we're not releasing metrics until like that is a requirement for us releasing metrics. So we don't think it's a problem, but I think it's fine to just have those comments on there. I think that that's the part where we have the objective reality. This is how open telemetry plans to support Prometheus. That's the objective part. And then we have two divergent opinions on whether that means we're ready for incubation or not. And I think we should just ensure that it's, the objective part is put into the doc and then however we're going to do these, this commentary like at the bottom, we put the rest of it there. And I do think it is fine for Bartek to have this opinion as someone working with the CNCF. I don't think he's actually trying to be unfair on this point. It's fine to say that it's like, we just need to clarify there's a difference between opinion and the actual plan the project has. So if other people want to make their opinions better plan, they could do so. Yeah, yeah, good point. And, don't get me wrong. I think steel open metrics is not perfect. I have so many features to add there that are required to, like even better iterations on it and kind of improvements. So I would love to see community kind of joining efforts and continuing under one specification, not two. But anyway, it looks like we are going in this direction, but because it happened to be like three years already that nothing happens, I want to be just extra sure that this is going well and maybe put some, I don't know, there is some kind of motivation to get there sooner as well and collaboratively. Hopefully that's kind of the intention as well. But, you know, I have like a bigger question because that's the one point, but the biggest point we are iterating over is that, hey, tracing is stable, but metrics unlocking is very kind of barely, well, there are certain things that are working, but there was not big adoption there, right? And open telemetry, you are arguing that this is not needed for incubation because this is planned ahead. That was a plan from the beginning, right? So my question to you is that, how do we suppose to kind of fulfill the goal of unified signals if we just have one signal there and we don't have a proper data models designed that will actually allow us to even kind of understand if this solution is even achievable, if we can even unify this under single deployment because those signals have different characteristics as well. So that's kind of my point why I don't see adoption of everything and why I feel it's important that all the signals are at least the specifications and the APIs are there, or like, sorry, network protocols in my sense. And this is, yeah, please. So I agree with that. Sorry to cut you out. I think, because I feel like everyone on the call is like aware of this, but I actually agree that it's, that is a totally valid opinion to have and it's fine to have that expressed. I just wanna make sure that's clear. I think to answer your question from the open telemetries project side, we have done a lot of experimental work like a significant amount, including running this stuff in production for a long time in open census. And I would point to the work we've done around stability and backwards compatibility and how we add signals. The work that I think is relevant to incubation is that we have a plan for how stability works and how new functionality is integrated without affecting the stability of what's already out there. That to me is really important work that we did to ensure when we say to people, tracing is stable, you can depend that you will get no breaking changes related to tracing in the future. At the same time, we're developing metrics with that in mind. So this faked into the architecture of the project and it's in the spec. So, but again, I think these are two, the factual part is tracing is stable, metrics and logging are still experimental. We have a stability and support roadmap that describes how we manage all of this from an architectural point of view. And then at the bottom, we have opinions, open telemetry group thinks it's fine because we have plenty of prior art that says, it's gonna be fine. And Bart, maybe others say, yeah, but we should, the bar for incubation as opposed to graduation should be that these are complete. Like, I think it's fine to have those as opinions at the bottom because they're both valid opinions. The TOC can look at those and decide where they think the bar is for incubation versus graduation. And whether this is like fine for incubation but we're not gonna graduate unless we really do it right or this is not ready for incubation. Yeah, first set. Yeah, I'm happy with that. So maybe we can, I don't know how we're going to follow this up by actually doing this work. I think maybe Bart, you could do a pass at like moving this to the bottom, maybe or Richard is the chair. I'm not sure who should be tapped to re-organize this talk. I'm super careful not to touch anything, any wording unless I'm in suggestion mode and or in the actual called where everything is seen while we do it. Why does this question was ongoing? I put two things into the, it's currently in the to-do but we can just put it into summary or whatever. If you go to the relative top of the document, there's a suggestion for two new lines. Technically to put statement of descent into doc and hotel to put statement of descent into doc. Of course, then we have two places where both sides can make their statements. And for the intent and purpose of walking through the rest of the section, both sides can simply say, well, we refer to our document. And then we have this in this long and this is then basically not taken as a consensus position of the SIG. It is just basically pointing to that thing as context of why consensus couldn't be reached, which is not precisely how ITF works, but I get to pull a little bit of a magic trick. Of course, we have a TUC behind us or above us or however you want to look at it. So we don't need to declare rough consensus and everything it actually have the ability to just refer certain bits and pieces to a third party, which is not the case in ITF, but we have that. So let's use it. So unless there's objections, I will put those two in and mark as accepted and maybe let's call it summary or let's call it statements of dissent as to where to put it. That's one of the few cases where I actually make a call as the chair, I strongly believe these things belong at the top to give context, but I also strongly believe that all sides should have their say as long as it's technically or it is valid on a technical level, not technically valid. So unless there's anyone dissenting, I will also accept that statement of dissent. One point, as I said, I'm fine with at the top, if that's your preference, I don't care too much, but I did put a comment on that first paragraph and I'd like to see that honored. Which? If you scroll up all the way I said, in terms of consistency. You need to scroll up. That's fine. Right, because as I said first it says partic and then it says we and ours and that is just, think of it like someone from talk looks at that and says like wait, first it says partic, it says our, we like, what is it? And let's make it very explicit, very clear. It's not just partics, personal opinion, this is, you know, here are the whatever people that have that opinion. In the same way that that object clearly call out who is behind that saying for the auto, she's the order. Yeah, I mean, Richard again, I would like to complete what I was saying earlier. And then, you know, as to what Michael was also pointing out, I'd like to make a note in the doc that the technical lead for the CNCF SIG of the ability needs to have a clear neutral in the doc. Okay, so for, okay, this is serious. Okay, so just to make it clear, you're stating that you think that the technical lead has a non-disclosed conflict of interest and as such as assessment is void. Is this correct in my work? I would at least like to note that on the document. I think that's listed because it says tennis creator, Prometheus maintainer. If you're thinking about those two, that's literally part of the first sentence. And I understand, but I would like to note that on just as an observer and participant in this discussion. Okay, Bartek, are you fine with this? I mean, fine with what? I don't feel, you know, I'm particularly, you know, I was not even participating in open metrics also or whatever. I'm a user of those things because I'm user of cloud native, you know, open source solutions. And probably most of us are using Prometheus. So all of us cannot, you know, state our position. And also we are talking about logging and tracing here. So I'm not sure what exactly made me, I don't know, too biased, but I would be happy to, to consider, I don't know, like, yeah, you can talk about that, I'm not sure. No, I just want to note, I just want to note on this document, there is, again, I think that you are clearly displaying the conflict of interest. But I am not. Could you elaborate on the pattern of behavior to which you are referring? Again, you can look at the recordings from the last, you know, four discussions that we have had about the project and the incubation process. And I understand that, you know, you have a lot of predetermined, you know, understanding of different projects. But it is, you know, again, just in observing, I'd like to note that you are, you know, as a technical lead, supposed to be fair and walking through the details step by step, quantitatively. And I see and observe that, you know, you are clearly, you know, bringing up a conflict of interest, which is overshadowing your neutrality as a technical lead. And I would like to note that in the document. With that strength, I think we actually need to balance this particular question to the TOC course, if that, like... One potential proposal, Richie, and others is, I mean... No, sorry. This, Alurita, is this a personal statement or is this the assessment of open telemetry as part of the due diligence? I just want to be super careful and precise here, because this is... This is my statement. And I would just like to note it. Okay. Okay, okay, that makes it easier. Okay. So to file... I'm not sure I'm gonna say COI per se, but I think my observation in these conversations, not that I've been in all of them, but I'd say I've been in about half, is just that there's a lot of sort of first-person discussion of the particulars of the integrations or not between various pieces, particularly around metrics, for me, it's open metrics and open telemetry that's being made from the standpoint of like the observability TL role. So I mean, whether that's a conflict or not is something that could be interpreted. But I mean, even today, I think you've been referring to your own personal experiences in the sort of actual, like histories of these projects. I think that's probably where the grounds would come from, just that you're not approaching it as a third party. It's like you've actually been experiencing this and I think it probably, and it's fine to, this is both speculation, but I think feeling certain frustrations about it as well that are coming in prior to the discussion of incubation and this review process. So I think that's probably what the ground would be, as opposed to say, oh, I don't know. I mean, if we approach someone just on the overall CNCF, TOC, who had nothing to do with Prometheus open metrics or open telemetry, and they were to approach this in a sort of more entirely objective way. I think what Ted said, I would agree with, but I personally think that you're completely entitled to have opinions about these things. And in some cases, I think they're very well informed. I would just say that they're coming from a place where you're actually involved with some of the technical conflicts that we're discussing. And it's not that that makes you like a bad person or something, it just means that you are going to come in with some sort of technical bias because you're one of the parties in that negotiation. So I want to clarify, it's not like a value judgment, it's just sort of like almost an objective assessment of your role in some of the technical discussions, like historically that are now becoming relevant to this review process. That's how I see it. I don't really want to weigh in on whether that's literally a conflict or just sort of a complicating factor, but trying to be more precise pair Alex's comment, that's kind of how I try to be more precise about it. And I'm speaking for myself, not broken telemetry, but I hope that's somewhat like clarifying in terms of where that perspective would be coming from. I think that that makes sense to me. And it's like, for example, when I hear Richie saying certain things, he always very clearly says, like, you know, with the hats, right? You know, this is with my metrics head on or whatever, making very clear from what point of view he says something. And, you know, arguably, you know, being chair and tech leaders on the same level in terms of responsibility. And in that sense, I think I agree, right? We should be very, very careful to say, like, is that my opinion, is that as a tech lead, is that as a principal engineer at Redhead or Tano's creator or whatever, making those things very, very explicit, both in the course of this recording and in the document. Absolutely a good idea. So observation as chair and again being very careful about the heads. I think I'm the first person to agree that there are some handwerkliche Verbesserungen, improvements in the specific style of the document or of Bartek's statement. I would disagree that the overall behavior is so strongly on any side of conflict of interest as to really raise this flag, because if that was the case, I would have done it myself. I would also like to note, because Ben was referring to emotionality. A lot of those calls were emotional on both sides. And I suspect it's probably not easy for Bartek to be on the receiving side of, like just now we had four or five different people speak their piece and he is alone more or less. So I can also see how that is not an ideal balance of power. Also we had time, but we are probably running over the usual 10 minutes. Actually can I chime into that? So one thing like as like being, I don't think, so you made a comment last week about how like COVID has made things definitely harder and stuff like that, but that doesn't excuse being rude, right? And there has been incidents of like the interactions in the SIGS, especially when it comes to the hotel route that have been rude, like on both sides. Yeah, okay. That's not okay. Which one were rude, sorry? Because I think that's your personally attacking me too much again. And I don't think I was rude. Sorry for, but like, yeah, I'm at this point. Sorry, but it's not a real apology. Anyways, I just want to say that like, it's not an apology. Let's be very clear. Sorry, but it's, you know, you say, but to actually contradict the statement beforehand. That's not, yeah. I just wanted to say. Anyway, I think at this point you are, I mean, yeah, I feel there's no comment on it. Okay. I'm sorry, we're deep in territory very honestly as a SIG we shouldn't be. I think it's fair that Bartek writes down a statement of noting down potential conflicts of interest by listing the various heads which he has and then the reader or a watcher of recordings can make their own assessment of this. I don't think either side was rude, but I would say that all sides have been heated and honestly I myself was heated just now with the November 25th, 2020 comment and responding to it. So either we point to specific cases and we do this properly, like raise it officially and actually look at it and have other people look at it at specific comments or maybe we all try and get the emotions down a little bit and just work on the document which would be a lot nicer to be honest. But like some things which have been said are super serious and if they're meant as seriously, then in my opinion they need to be raised officially and if they're raised officially, they will bubble up at least to TOC, most likely to CNCF proper. So then they need specifics. And those can just be comments, right? Like nothing prevents like taking this top thing and adding a comment here and saying I feel that blah, blah, blah is happening. I think that there's a conflict of interest. Like you can express comments I think and that can be taken by the TOC as well. But technically the due diligence is owned by the TOC sponsor, at least per the CNCF incubation guidelines. So I think like putting this into a doc linking it and handing over the material and with the TOC sponsor decide probably makes the most sense. There is not even a TOC sponsor. I would love to have a distinct person who I can talk to about this. But that's where this doc is going, right? Yeah. Oh, sorry. I'm on point for getting our TOC sponsor. That should happen next week or so because they're re-assigning, they're getting more people like the full TOC board on Thursday and so they'll have actual understanding of what their capacity is. So we should have one by end of the week. That would be a great question. We can also short circuit most likely a lot of those discussions. I know we're close to time. Do we want to try to meet again next week so we can hopefully chip away at some of the sections and what do people feel? I would honestly prefer that we make progress on the actual document and write them stuff. I mean, I think- Yeah, I'd like to propose- Meeting. I think we had the fifth meeting for due diligence for open telemetry. So whatever curse we are under, we are not really making a lot of progress. Yeah, I'd like to propose the following. Like, Bartek, if you could put your comment into a doc like you did for the other summary and then link it, like we talked about in the summary, I guess we would go here. That would be great. And then if Hotel GC or others want to work on a document as well, that can be prepared in parallel. Ideally, what I'd like to see for next meeting, if at all possible, is that we focus on these sections. At that point, we will have two other documents that already give alternative viewpoints. And I'm hoping that we can focus all of our efforts on these sections and getting to consensus on these areas without rehashing the differences of opinions that we have. Yeah, and if we get those two statements written down and then acknowledged by the other side, but not necessarily accepted, just acknowledged for existence and that both sides acknowledged that the other document is not outright wrong or just based on hearsay and opinion, but with actual statements and also whoever wants to support either document puts their name in. And then we can, if we don't reach consensus, we just bounce to those two documents, refer to them and hopefully move. Yeah, so can we try to meet next week? Does that work for folks? I just checked personally, I have a conflict I need to check, but I need to, it's not work related, it's private related, I need to, does it work for everyone else? No, I would prefer to meet a normal cadence. I spend so much time on it and the only gratification I got it is personal attacks. I feel we should stick to the standard cadence. I have other duties than just fighting with this, so that's my personal view. So many things can spiral when they get off to the wrong foot and fear, uncertainty and doubt can lead to so much animosity that doesn't need to be there and I think wouldn't be there in other circumstances. I know this from the open telemetry project itself when it was open census and open tracing, there was just a lot of fear and concern that the other party was gonna zig when we wanted to zag and the two things weren't gonna work together and it was just gonna be this big mess and that led to a lot of crossfire and escalating into personal attacks and it sucked, it absolutely sucked and when we did the work to actually get to know each other and started to actually collaborate with each other actively eventually leading to the merging of the project but even before then, a lot of that evaporated and it was just shadows on the wall to begin with and I have not been here through all of these conversations but I feel like I'm experiencing one of these trigger spirals again and it's not possible to unwind the past or do anything like that but I do think it is possible to figure out again, how we could move forwards both personally and professionally. I'm not gonna propose anything because we're at time right now but I just wanna say that I've not seen anyone be a complete monster in this situation. I have seen people get hurt by the things other people have said and that does happen when emotions run high and people don't know each other and there's not a lot of trust but I think these are things that we can potentially move fast but it takes work. So hopefully we can get, I actually think what's left to do on this document is fairly simple and straightforward to be honest and I hope we could have a session where we can just move through that and if there needs to be additional work which I think there does need to be due around just healing and having people have an opportunity to be heard. I think we should discuss this possibly with the CNCF or find a venue in order to do it because I don't think it's good for us to all walk away from this project feeling wounded by what happened here. I think we should do some effort to make that feel better but I think we should set aside some time to do that that isn't in the time we wanna spend to just get the last bits of this doc off our plates because I think everyone wants to get this off their plates at this point. So if we can do that asynchronously through just finishing the docs and email I think that's great. If we can't and we do need to have one more discussion let's try to have a very clear agenda and keep it short and sweet. So we can follow up through Slack or through email or through another channel. Yeah, yeah. And please feel free to ping me on Slack channel or CNCF link email, CNCF email list, whatever. So yeah, I'm actually working better even asynchronously. So please, yeah, let's communicate more maybe asynchronously as well. Yeah. We are at time and the agenda is set and we need to walk through a document live because as we cannot have consensus on it but this regarding those knits we have met for nine months now since September. And I think Ted just said the best thing on all of the calls ever combined. So thank you. Thanks. See you all on the internet. Yeah, thank you. I'm still reading the comments here in the chat. Author, are you still there? Present. Okay.