 Hello, I noticed there were two links in the invite, one of which asked for a password and one of which would be here right now, I'll poke him and I'll take this one. Hey, some people are having trouble getting in, it looks like Zoom is asking for a password for some people. So I'm going to keep watch, but it looks like some people are able to get in. There were two links in the invite, I got. This is the correct one. Yeah, there's a second one in there at the very top. Damien, I was just asked for the password for this call by someone, but I don't think we have the password. I have a password on this particular room, so I'm kind of confused. There are two Zoom links in there, there's like the CNCF, SIG of Seropility One, the SIG content here. Can you hear us, Richard? So either all of you are quiet or... No, you're good, you're good. Oh, I can't hear you. Okay, I'll do it now. I didn't hear anything. Okay, so I just got word from a co-worker that he needs the password to join the Zoom, which is kind of weird, and I sent him the link again. Just to make sure, you can send me... So in the calendar, you can link with the number, not with the observability something. Zoom is being awfully helpful. So I decided that we need passwords on all of our meetings. This is not as helpful as you might expect. Oh, I know how helpful I expect this to be. All right, it looks like most folks are coming on in, so I'll let you go ahead and get started. Yeah, it seems like. So, Matt is probably not here because he's on holiday, which means I'll probably run the show. I just need to open the doc, sorry. I was trying to fix my sound until right now. So, there we go. Generatorial, we can probably kill unless we have someone new who wants to do intros. So the other thing is just updated from CNCF. We had a CNCF TOC and sick chair call last week. And basically, the TOC is fine with us suggesting changes to pretty much whatever. We should just suggest it and they'll look at it. But it didn't sound as if they were too much set on any particular parts of the questionnaire of the template. But that feeling is there probably rather than whatever we whatever locals are always Amy, how, how did you perceive this. I couldn't join last week because I had a company. Okay. Yeah, that you see is fine being able to have suggestions put in. I am thinking. Okay. And the other thing sorry I'm jumping outside of the agenda, but I literally have back to back meetings today. I was a user survey by by Cortex in preparation also for the due diligence and such. Gotham shared the results with me it's like a lot of those questions are are rather text heavy and open for interpretation and not so not so metric heavy as it were. I was thinking to maybe even run a second one based on the Prometheus survey which was sent out last Friday, I think, because that also has like scaling numbers about how many, how many, how many metrics you actually run what's scraping interval how many, how many data points do you get per X amount of time questions like that. On the other hand running to surveys directly behind each other is kind of weird, but like learning from this and also feeding the spec adds yet another template to to see in CF to to basically have something to work with for future due diligence probably makes sense. The question is, what do the other think about this. Gotham also just tossed survey results in there. I suspect those is those are the anonymous anonymized. Yeah, I think they're anonymized. And it's the anonymous version of course the initial version or the original version obviously has has names in it, which is kind of no go. Yeah, so what do people think personally not a fan of running on other survey right after this, but we can do it if we really want to. My thinking is that in part we are we are spearheading at least part of the processes within CNCF and we already hit several walls. The process can be improved, let's say. And if we are able to to give a template for something which worked. Also in regards to questionnaires and user surveys. I think that actually makes sense and creates more benefit within CNCF. So that's why I'm why I'm even considering to do it twice. Like, we don't need to run the actual survey but we can create a new template based on the Prometheus one and the Cortex one and say this could be one of the template things but like what what do the other Cortex maintainers think Brian or Mark or Bartek. Yeah, I think I agree like let's get those learnings for the future surveys, but let's not spam users essentially. I think those numbers are on serious. I think they're larger than prom cues from what I have seen anyway so I think they're good enough for incubation. That's what we'd like to get from this survey for our purposes. So I don't think we need to repeat that. But yeah, that's my opinion. But we should have those questions for next ones for sure. Also, finally, just one point to note, I fully expect to see to then challenge why that new template hasn't been used for Cortex, which has an obvious answer but just to to anticipate the future. I'm, I'm willing to bet that this challenge will happen and it's like that's the logical thing. Anyway, let's run it if this to see challenges. Brian, what do you think? I didn't see the other template. Sounds like you're saying the key differences is that you wanted numbers. It's just the most prominent difference. I'll see if I can find the survey. Numbers don't seem, you know, yeah, it's data, but it doesn't seem critical to me. I mean, it may just raise more questions like, oh, your system is really small. Why did you pick Cortex for a really small system? Yeah, this sort of iterates. We can learn more and more and more about these. Well, yeah, we've got how many 20 responses now and you'd be down to five by the time you asked him eight times. So to cycle back, there are other differences, but if Cortex has consensus that not running in a survey is the way to go, then we already have consensus. No one else is speaking up. So from the from the working groups point of view, there is no reason to challenge the decision by Cortex. Like just to just to, of course, obviously I had my head off suggesting this, but now with the chairhead on, I'm completely fine with this. I'm fine with this. I don't have a strong opinion on this either way. Definitely share the concern of doing too many surveys back to back. So I mean, if it is if people feel like we should hold off, that seems to make sense. Yeah, I'm fine either way. Okay, so I hope everyone has read the document which we are about to dive into the due diligence document. Much more time since last time. We are on page 11, unless there's any substantial change above which we should be taking into account. There were some to do. Okay, so those been addressed. I honestly don't know. I didn't have time today. Yeah, we addressed all of the requests. And we commented on every piece that was addressed so maybe we can go through the commented beats maybe. Okay. So let me share my screen. So you should be able to see that document. Yes, no. Yes. Yeah, just asking us. That's basically. So just to make this explicit. I would say in the update towards CNCF to see I would just kill that question because it's it's not really phrased in a useful way. So document that the project is usual for close native deployments and degree that it's architected in a cloud native style. So yeah, so this is another super vague super open ended question like what does cloud native style mean and things like that so me and Bartek decided to have a smaller answer. I would be fine with this and would be doing the game of consensus last time. Just do a new date. Of course we just so we have a paper trail of what changed the proposal is is here the proposal for consensus. Basically that we are happy with this answer. Are there any, any other thoughts comments regarding this. In general, I question for the initial question, the incubation question in general, not the answer, but what is the, what's the goal of this, like, is the only concern if the answer is no. I kind of agree like you can make it pretty general but what is the hope of asking this question. I would tend towards saying that this is one of the questions which we will be getting back to you see on and suggest improvements because it's completely undefined in the scope of the question. I think the answer is a little bit blunt but but fitting. I think the CNCF would have a definition. It's just not in there so there would be like specific criteria like it has a declarative API as it can be deployed on a cloud native platform. It is available via containers that would be like actually a number of criteria that the CNCF itself defines for cloud native applications. They're just not part of this application so technically if you will say yes, it can be shipped as a container it can be deployed either via a CRD and an operator to Kubernetes and these kind of things you could actually list all the criteria that the CNCF defines for cloud native. But arguably the question does not put this one in there here necessarily. But can you link me to the criteria and then I can update it I just couldn't find. I can link you actually it link you to a medium post but it has to copy in there of the CNCF but just could not immediately find the CNCF one. But the CNCF there is a CNCF definition. Yeah, I like I tried looking for it and couldn't find it which is why it's super vague otherwise I would have done that. I found it before I just now did not immediately find it and I have it also in another document. But actually that's the screenshot from the CNCF website. Okay. Yep. I will update it to follow the cloud native style. But if you could find the original CNCF one. Yeah, I'm looking for it right now. So should we should be not make the current consensus for this one right now then should we wait for Galton to to update the document in the background or should we just say that in the scope of that question we're happy. I'm basically happy with all of them I just hope that we are able to to to actually either say yes we happy with the complete document or we're unhappy with the complete document at the end of this. Yeah, I think it's fine if they want to try to if we want to try to update it behind the scenes. I think that's okay but given the question the answer seems fitting. So then again call for consensus one actually object to this phrasing and just to make it explicit this phrasing is that as of today's sake observability is happy with. So we found the definition and posting it in the chat right now it's at the very top part of the CNCF charter. If you look at the mission of the cloud native computing foundation that also contains the cloud native definition. Okay. Yeah, but then still this question needs to be tightened up and actually refer to that blah blah blah blah so become it becomes a checklist cause currently it's sentiment. On the plus side we all agree with the sentiment so whatever. Yeah. Document that the project has an affinity affinity for our CNCF operates and understands the expectation of being seen CF project. Yeah, I think concrete examples were added by Gotham and I think it makes sense. 123. I think the argument with with several team members also being part of other projects, especially graduated projects as in Prometheus. And I think he can already holds water in it as of itself so I would also suggest suggest the same. The same phrase in for the call for consensus that as of today's sake observability is happy with this answer. Agreements disagreements agree. Yes, yes, so I was asked to. Well, I kind of propose to actually check if those maintainers in the list are actually active. I actually looked on the last quarter there was like a good, really nice dashboards griffin dashboards for developers stats. If you click link you can open up essentially the TDR is that most of the mentioned maintainers are quite active, especially the top three ones are like having at least, you know, seven contributions per day, which is probably comments and p or commits or reviews so I think that's definitely considered as active. No, it was time to agree. Someone already caught. Did I copy this or did someone else copy this in. You might accidentally move that. Yeah. Just point of order, please don't. It was probably me if it wasn't me please don't copy and call for consensus motions course else. It'll get super confusing. But again, it was probably me doing something wrong. Yeah so looking at the numbers and also looking at the actual requirement which is to have a healthy number of committers. I think that that the same call for consensus still holds as an as of today's sake observability is happy with this answer or agreed. Very good. Very good. So this one we we said that it's very it's like one to one which what with which what we propose in the PR. So the ring was supposed to copy the exact content. So by definition, I would say that that we are happy with this still call for consensus, given that this is literally the same text as as used before. Everyone agreed. Very good. Do you want to talk about this one. Yeah, so initially, like our famous architecture was because we basically added more and more components and complexity. But recently we've shipped a single binary single process mode, where you basically deploy a cortex process and then just increase the cortex replicas to scale up. And that simplifies or like that simplifies the operation a lot instead of having to manage five or six different microservices. So that's like one trade off we made the other one initially was that we were lacking in documentation. And over the past year or so we've added a website proper production dates and all of that but we still have a long way to go and we're working on documentation. Yeah, that's fair. So same proposal as of today's stick observability is happy with this answer is agreements agreements. Okay, so here is where we left off last time. Do we need to read through this or is everyone on this call prepared for for just walking through this at speed course they read the rest of the document in the meantime. Since the last call, it's totally fine if not. This is literally why I'm asking like obviously I would prefer that that isn't the case but if it's the case that's completely fine. So should we walk through this quickly or or read through it piece by piece. I have 15 people on this call and so I have at least 14 opinions. If anyone wants to have a slow readout, please speak up. Let's give it. Okay. Last chance but again it's completely fine if you want to do it slow I want to do this proper. I also want to be mindful of all our time but I also want to do this proper so now is the time to speak up. Okay. Do we believe that's a growing and thriving project. It's aligned with the scenes of values that it could meet graduation criteria that it should start at sandbox incubation level well that's kind of a stupid question in this context. And it has a sound documented process for source control issue tracking a release management that it's that there is documented process for adding committers that there is a governance that there are committers from multiple organizations that there is a code of conduct that does have a license that it does DCO. Can you add which license. I think it's a patchy but can you add which license please. I think it's a certain quality to inform the communication around the project. That's sorry I just that there is ample time or that there is just an answer to the question if there is time committed by the core team. How big the team is, if they're clear leaders, if there is surrounding community outside of the core team. It's easy enough to contribute if if they're especially difficult personalities to deal with and if there is a rate of ongoing contributions. So all of these after skimming them and after reading it on preparation for last last call, I would propose that we state that we are happy with all of these answers. All agreed disagreements agreements. I personally agree I read them through in details. Very good. Did you put the license. Yes. So users. Who uses the projects. We have case studies in as reference so obviously there and users. Also, by the way, as we had that coming last time and users are clearly defined within CNC as people who don't provide services for others so service providers are not defined as end users. I happened about to treat this sometime few days ago and I just remembered that we had this issue. What the strengths and weaknesses are this is the survey results so that's, that's fine. If it's used or not used, I think we can agree that it is used that the documentation has improved leaps and bounds I think we also have consensus about this. So same call for consensus. As of today's thing observability is happy with the answers in the above section. All agreed agreements disagreements. Just to add one more thing like if you look at the survey results, most of them, like a lot of them say that documentation was the biggest problem, but also a lot of the users say that the documentation has improved in recent times. Having said that we are actively working on documentation. It's much better than what it was 18 months ago, but we still want to improve it. And that's one of my biggest priorities. And taking off my Grafana my my chairhead and putting on my Grafana labs for a second. I know that there's actually actual time by tech writer being committed towards this as well. So I know it's true. Just for the benefit for the others on the call. So firmly taking off the Grafana labs that again. And putting back on the chairhead. So as of today sick observability is happy with the answers in the above section. All agreed context questions. Origin history of the project I think we are all aware of this. And also we are just giving that it fits the market and the technical technical ecosystem that it's growing. It's kind of obvious. If it's necessary and if it's adequate or not and what situations could comparing and contrasting to human to Pierce maybe other projects would be the better, the better phrasing. As you will be shocked to hear my suggestion for the call for consensus is once again that we're happy with the answers in the above section. Yeah, but it would be nice to have some till they are of this context like what's the outcome of this like essential outcome looks like that the product is growing and and solving the problem and is collaborating with kind of the nearest competitor. That's will be the deal. Yeah, right. Yes. I skipped that part on purpose but yes. I think that the comparison section is is is valid, especially when it comes to CNC F related metrics projects course like you have a ton of other players in the overall field but within the context of seeing CF, which is obviously the main context we are operating on within this document and within this call. I think it's fair to basically compare to Thanos course course. I'm comparing to permit this doesn't really make sense and you don't really have a lot of other metric solutions or platforms within within CNC F. But if someone disagrees and would like to see a more in depth review against other other projects now is the time to speak up. The only comment that I could maybe make on this point here, it might be interesting to have like an end user point of view of this environment and user and I want to choose between Thanos and Cortex. What would be it right here by the one project over the other. So right now the feedback is very technical and related to some of those pieces. Okay. Is this something which you would like to see within the scope of six six observability or within the scope of this document which is required for due diligence for incubation. I think it might be like one of the feedbacks that you're getting okay as an end user would end up want to use which of the two projects. Okay, so the comment is in the context of it's back to to see as an improvement of the of the checklist and question. Or would you like to see this document. I'm not sure I'm getting where you're very trying to get. I would. I mean it was just a proposal I might want to put it into the document if you have somebody just reading it I would like answer this question. Is there a value of having both and my good with that like two projects that do pretty much the same thing. From an end user's perspective. Sorry. Why would I pick a versus be. Okay. I mean we can we can request that that this is put into the section as well because I can see the value. The question is are we still happy with this section even without this or should we call off the consensus call until until that is added. Are we happy as long as Bartek and or go through edit. It's kind of hard to add it. Like you can use both to do the same things. There's an entire prom con talk on the different trade offs and but we we deliberately avoid saying you should choose this or that because like context is aiming like it's hard to say to tell a user to pick a or B. What do you say Bartek. I think it's harder every day because like we are collaborating so much that we are literally starting to use the same API and having the same features, like very detailed features like we cash the same things we we use exactly the same format and you know, saying that hey you should use this versus that is just just some another argument for separation, whereas we're trying to go go kind of together. And yeah the differences are very, very small and they are getting even smaller so I think this is very unique situation. So I'm not sure if this will be helpful for people like right now it's very, very similar experience. It's not a multi talent. Thomas is multi time as well. So the big philosophical business. The philosophical differences is that the cortex centralizes all of the data. That's true because the receiver is product production ready and have the same so those boundaries are getting you know, blurred. Yep. So even they have a ring and they have the industry at like it's getting closer and closer. I think suggestion is best. Also I think quite honestly this is outside the scope of the discussion we're having about the due diligence of cortex. I think I think allies general point makes sense and I just added some verbiage, which which gives gives some some hand holding. Beyond that I think it shouldn't be in a technical document for the technical due diligence on a member project I think it should be in kind of an overview or maybe a best current practices document or something which goes more into depth about the trade offs and about the design goals. So, as soon as we are out of the document I'm fully fine discussing those deeper points but as long as we're in the document I'm trying to compress and to to try and focus on that document or else we will end up talking forever without actually having final closure on the document. Anyway, I think it's a valid request. Let's add it to the github issues or something like that. Let's create some best pattern here. Therefore this document I already added a small section, which I'm currently highlighting in the screen share. We also have a question in the chat. I don't know if you saw the question. No, I didn't. Thank you. Oh, where are we? Should we motivate by considering two projects doing the same thing then? It's in the Zoom chat. Oh, okay, sorry. I was looking at that. I can't see the chat and screen sharing. So let me stop. Yeah, well, that's that's actually a good question. It's again, unless it's something which blocks from moving into incubation, it's not something which should be discussed within the within the due diligence call. So unless, Stefan, unless you disagree, I would actually tend towards jumping back into the document, finalizing the document and then jumping to a good question. That's another question. I think there is a good answer to it. But I would just like to close the other thing first. Objections. Yeah, I think he objects. You know, it's funny, like a due diligence consideration still. Okay. In this case, as CNCF is explicitly not about came making and as CNCF is explicitly about having a an open or a level playing ground between the different projects, which are members. You can argue that maybe only one of them should graduate for but for incubating basically leaving sandbox and getting into incubation stage. I don't think it's a consideration which the TOC would be would be making. We can jump back into the document and discuss it actively. Yeah, so I think the point is now also in the chat. I think it's not a problem going forward because to your point which is not one of the criteria where it has another project was in CNCF that does the same thing. This shouldn't be the case. We could just make it as a really recommend and I think there's also a lot of statements in there. So the collaboration between the projects. Which is great and obviously we recommend that we there's a clear step step forward at some point between the project but I think it doesn't matter for due diligence. The question is about project quality, not about whether there's another project within CNCF that does the same thing. And again, CNCF even explicitly encourages this by stating and repeating that they do not intend to be the king makers. There should be competition between the projects and if a project withers and dies that's that's a normal lifecycle of a project. The point is just that there should be at some point a distinction between those projects. Or you might consider at some point merging that what happened to open sensors and open to them to open tracing at some point if this is something or if there is a clear distinction might still persist. Well, you should know we tried very hard to merge the two projects. Over years, there are, it's not an easy thing to do. Let's get back to this question right after because I think it's a it's irrelevant the good question and I have tons of opinions about this. So if you allow me just this is Stefan just one comment. I am new to the process here and by no mean do I suggest that, you know, it is something that's a problem or not. All what I'm suggesting is that that justification or that acknowledgement that the project overlap and why they overlap and it's not an issue should be stated in the document that's all. I don't think it's needed for this document but I don't object putting it in so so the best course of action is probably to just put it in. Actually, it's already in there. This is further aided by the large overlap of Prometheus Cortex and Thanos Maintainership and close coordination between Maintainership code and close coordination between all three projects. Stefan is this phrasing which you would be happy with. Well, I still believe that you don't say why it's not an issue that those projects overlap. And I think that that would be valuable to stay. That's all. Yeah, I think that makes sense if you are new to this process because we had the same kind of thing and discussion in the beginning where we move those two project to sandbox and we totally discussed that so far but if you are new, that's definitely worth to rate the rate. Is this a phrasing you would be happy with Stefan. Yes, thank you. Okay. Two times explicit. Cool. So, call for consensus sick observability is happy with the answers in the above section. All agreed agreements disagreements. Great. So we can jump out of this document. Of course, we are through with this document. I just need to find my meeting notes. Here we are. So what is the next steps. Me making call for consensus for two more things on the document or on the meeting note level and then we move on to the next step. So first was. Okay, so the first call for consensus on this level sick observability is happy with the user survey and does with the cortex user survey and does not request another. I think we already have agreement but I just want to make it explicit. All agreed. Good. So the first actually non genitalial thing which we as a sick achieve which I think we are doing in the second or third officially instant instantiate call which is quite nice. We accepted the cortex due diligence document or accepts sorry accepts the diligence document and will submit it to the CNC FTC for further discussion. All agreed disagreements agreements. This is good but like I would mention that we are kind of put it as our recommendation as well because this is what we will do in the next TLC call. We agree to like the sick observability is making recommendation that this project should go. Okay, yeah. sick observability accepts the cortex due diligence document will submit it to CNC FTC for further discussion and suggest moving cortex to incubation stage. All agreed. Okay. I think that was Steve's thing. So yes, it is perfect. Yes, happy to. So I by design actually have not shared this out broadly. I will ask people to review it for the next sick meeting so we can discuss in more depth. I just wanted to talk about it at a high level to kind of ensure the same agreement and understanding. So there's a doc that's attached. Please feel free to comment everyone should have rights on it hopefully make edits modifications so we can discuss it more in depth. It's very high level it's more like a charter than it is like a deep dive on the specifics by design. To ensure that it's aligned with the direction that the sick believes that we should go in. So basically the proposal that was made at a very high level was around kind of promoting and providing more awareness of sick of observability projects in CNC F and what that might look like. The goal is not to duplicate any efforts that CNC F already has, or, or like promote a single solution or like best practices or what have you so there are some like non goals listed at the bottom as well. But the idea is just to kind of show off specifically the observability products and how they tie together and the types of problems that they can solve. So I listed a few goals here at a very high level like how would content be shared. How would we track that content. What would be the guidelines for contributing contents because we don't want to kind of be a free for all. For example, it's not about like vendor pitches that should absolutely not be the goal and needs to be explicitly called out the different types of content that we might want to share. Whether it's kind of basic getting started stuff for a much more deep dive of like solving real world problems that exists as a result of using these technologies. And of course kind of opening this up to a broader audience so that anyone can really contribute and get involved. It shouldn't be just about maintainers or just about like no name people that typically do blog posts or what have you. The goal here is really to to share and collaborate and to provide more visibility as to what is possible and what people are doing with these different technology stacks. On the second page again very high level I listed a few open questions. I'm sure there are more so please kind of post them in here so we can get them added as well. Some of the big ones that come to mind would be just any overlap with CNCF. So for example I already crossed out one of the potential categories. As it turns out today CNCF already has a way to promote new projects new releases and graduation type stuff. I don't think duplicating any of that effort makes sense. And then the second one if people are not aware there's a proposal out to change how a sandbox is done in CNCF that could have repercussions as to what is possible from a social media type type stuff. For example sandbox projects may not be eligible to participate in this as a result of some of the upcoming proposals that are being made at the CNCF level. So I guess at a high level does anyone have any immediate comments or suggestions or do people think this is a good idea bad idea heading down the right path the wrong path. I'm just trying to get some initial feedback as to whether folks think this makes sense and whether it's worth pursuing more in depth. Yeah I think it's amazing idea. The question is how we can what's the actionable thing that everyone can do after this meeting to help this look forward. So I think the immediate thing I would ask is please review this doc and please start commenting on it on things you think should be added removed what have you so we can get to a more concrete like yes this makes sense let's move forward with it. On the next meeting what I'd like to do and I guess we can talk about kind of more specifics determine if there were whether we want to have like a sub working group here where a subset of people kind of get together and propose an initial charter or whatever term we want to have here to make this more official as to who's going to help like design and develop these ideas and then present them more broadly so we can get consensus on whether or not we want to move forward with the proposal. And then just to start lining up content I think in general whether we have all these criteria done or not. I think getting some initial content or some initial people that are interested in providing content writing content takes time. So just trying to get alignment for that by next meeting I think would be beneficial. Other comments. And if people are aware like hey my project's already doing XYZ it's been good it's been bad like that's helpful to, or people are aware like I've worked with CNCF and they suggested the following. I've talked a little bit to them in regards to what they have in terms of blogs and webinars, but I don't know all the specifics so I'm sure there's a lot of knowledgeable people here. Please, please add to this. No, I'm super excited I'm planning to create a new meetup observability meetup in London. So, I'm looking forward to collaborate on this together. Nice. So, you know, are you planning to rename the Prometheus one or like nearly creating. I'm kind of, kind of in the same boat for the Berlin one and I was just wondering about this again. We should like, eventually do this, not that we have been running. I want to keep this very high level just to kind of socialize the idea I will share this on the list so people can review it for the next SIG meeting, and hopefully we can spend some time to get to some real specifics as to who would be interested in kind of working on this subgroup you're kind of define the criteria and anyone that might be interested in sharing content that could be used initially. Thanks. There are no more comments I think we will go to Bartik. Yeah, this is very short one. So I think initially we created about having some rolling docs idea where we kind of put the things that are ongoing that we are doing right now and who is doing what and where people can just get in and maybe help if they have some spare time. We didn't use this even though you created those documents and I think the problem is that, yeah, we kind of either the idea is either we don't know how to use it, how to properly get advantage of it, or it's actually unused for last month. So I would propose actually to stick to GitHub issues where you can label them. I think it's kind of, you know, you can have some discussions so it's not that bad so I think that would be actually even easier to spot the areas the task that someone can help with today and just bring it to and just do it in the spare time. So I would suggest this instead of like rolling docs and then we can think of something else if that would be not enough. So what would you think? I'm deliberately trying to get others room and time to answer. It probably makes sense. My one, yeah, that the one thing which which I don't want to fall into a trap of basically hiding to lose and stuff in in the document. I guess it will just as soon as it's all of you people forget about it will stop being tracked with updated. So I can see the idea of working but then I think we need someone to volunteer to actually follow up and go through this living document and make sure that all to do is are either handled within a certain amount of time let's say until the next call, or moved into an actual issue that we basically maybe this even has the advantage that we kind of incentivize people to do stuff within the call cycle and not just let it sit. I have less overwork in getting back and closing stuff. Yeah, the issues you can assign you can it's more verbose. And with the rolling it off because exactly the same issue you need to go through the living dog and kind of paste into rolling dog I guess I just feels more natural. The github flow and we can just start and then see how it goes. So my they're going to be asking for actual X items because issues work better. We still need somebody to create this because I think all of us have too many different projects that they're already getting issued from. So it would be like part of the review cycle for every meeting that you go over those issues and it would have to assign them. I also created a dog is good for collaboration if you want to discuss something that you may would write a white paper. An issue would be kind of a weird way to handle it but if there's like this quick item that you want to handle that you want to work on I also think that issues are the more natural approach to that. The key is great to correct me to push it to people because that's what I started to see as people these days are part of so many different projects. The amount of issues is just still overwhelming so somebody still needs to get stuff done. Unfortunately assigning a github issue these days to some extent is not just going to cut it. But so good idea. Thanks to somebody needs to curate it. And for the split for me is it an actual working document and it's fine for certain tasks. But that's the output artifact. It's just following up on the task and the issues the better. I think the creating would naturally live with with the chairs on this delegated. Yes, happily delegated. But by default it falls on to the chairs on this. So. Unless unless someone volunteers. Yeah, I can do that as well. I can essentially make sure that those issues are up to date and assigned and it's kind of. Yeah, could be taken responsibility as well. That was my thinking course if you're the one who volunteers then we can just delegate this. I mean, we don't need an official dedication. We're thankfully far away from this level of complexity and operational model, but consider it. I think we're actually overrun by two minutes. We're actually overrun by by 12 minutes course this meeting ended 10 minutes early. Should we actually have those short meetings or do we want to use the full hour. I would tend towards using the full hour and not having not this weird 50 minute thing, because we actually need that time. So, anyone opposed to me asking any to change that invite. So, I know why he's actually doing it and it's actually a good reason. The reason is that you're for people who have to continue right after this meeting and some of them like my meeting meeting at least have a 10 minute break for whatever is necessary, but we'll be doing 10 minutes. And so usually plan for the 15 minutes and then we'll run over it. So I like to practice of having like 10 minutes in between two meetings that are kind of planning and still meeting to run over your fine. So if you run over people will just randomly start to disappear, because they have to be never meetings again that's why I'd like this idea of like having this 10 minute buffer in there, and not actively planning for it, which would get me down to like a zero minute buffer. Didn't you just say you like the possibility to overrun and then say that people drop off course they don't if you don't have the overrun so I give you like block for the flower. Because that's usually when you start to block that any next meeting most likely started the next full hour. I think you have this 10 minute buffer in between but you're not actively planning if you plan for the flower people where you often just drop off at full hour, because nobody's taking a minute meeting for 10 minutes, or really that's my point. So like the 15 minutes. It usually gives people time to prepare for the next meeting gives you 10 minute overrun possible people will not abruptly leave. But they wouldn't scare and yeah. Yeah, also fine by me. Both are fine. Any, any other voices or. Okay, then we just leave it is and we'll try and see if, if we are on the future or not. Then, thank you very much for for your time and for for your brains. See you at the latest in two weeks and let's try and get get feedback to Steve. Yes. Okay, thank you. Bye bye. Thank you. Bye.