 Hello everyone. This is the weekly TSC call. So as you very well know, this is a public call. You can all join in and participate. I only see like TSC members and a few other people maybe, but so you all know this drill. The anti-trust policy and the code of conduct that you all know by heart and love. So you're aware of them. Let's move on. Announcements. I think you all know about the weekly developer newsletter as well. Maybe we can save, write the spiel. Thank you. I did want to highlight the fact that the common repository structure description, which is like the textual version of it, has now been merged and is available from the TSC website. And so, you know, in case you forgot to miss that, we had agreed to a common repository structure, but it was tied to support using RippleLinter to enforce it. We agreed to forego that requirement to use RippleLinter. And so we have now moved to this textual description of what the structure ought to be. And projects are free to use whatever tools they want, whether it's RippleLinter or something else. You can even do it manually if that's what the text, but, you know, so now this is what defined the repository structure and anybody, you know, any old project should follow that definition, be compliant with this. And if there are issues with the definition, of course, you know, you should bring them up. You can find an issue against the Ripple, but maybe bring it to the TSC as well, depending on the level of the issue. Either we'll handle it locally like we used to do for the RippleLinter actually. We used to have this config file and a few of us got into trying to implement it, you know, using it. And there were some changes that were made. We didn't every time go back to the whole TSC to get approval. And so I expect us to do something similar here. If there are some small changes that need to be done, they can probably be handled at the Ripple level. And then if there are major issues, we can bring them back to the TSC for discussion. And then there's the new chat system available for testing. Although I want to highlight that because it was a bit of a discovery to me. The way Rai presented it, the way I interpreted this presentation was, hey, there's this new possibility, there's a new chat system. You try it out, see if you like it. But in fact, what we are being told is there's a new chat system we are being transitioned to. And so you should just start getting acquainted with the tool. But Rai, I'll let you speak to this. Yeah, that was some confusion on my part. And I apologize for passing that confusion on. This is the future. And I think it's a lot better than rocket chat in terms of extensibility. And the clients are definitely a lot better. There are plenty of things about that I'm not a fan of. But help the LF beat this thing into shape and make it what it is that you need. So is there any questions about this? Because this is important, obviously. It's going to impact everybody across all the projects, including the TSC. And obviously, a lot of us are good. I mean, God used to use rocket chat. Like Arun sent me his regrets through rocket chat. So it's going to end it. So Rai, can you tell me more or tell us more about the transition? I mean, what's the expectation in terms of timeline? Okay. So right now, it's 100% manual. So channel creation and adding people as moderators for a channel, all that is manual. I have to ask someone to go and do the thing. There is a feature in the project control center, which is what we use on the back end that will enable that. It would basically just turn it into a couple of clicks. And then once that's done, we'll be able to begin the transition. In earnest, looking through rocket chat, it's definitely a power law distribution. There are a few channels that have a lot of participation. And there are about 100 channels that have essentially no participation. So I would like to cherry pick the very active channels first and see how many of the other channels we really need to bring over because if people aren't using them, I'd rather not bring them over. I agree. I mean, it would be a shame not take that as an opportunity to do a little bit of house cleaning. But so you said you were waiting for some of the back end stuff to be ready for more automatic migration. But do you have a timeline for this expectation? Are we talking about like a couple of months or? All I can say is Q3, which is next quarter. So this is like my interface to this. This is a tool that we use to manage projects. So there will be like here. There will be like an option where I can create mailing lists and there will be something like create chat channels and stuff like that. So that option is not there. So once that's there Q3, then it will be much easier. All right. I see that Mark has his hand up. Yeah, Mark, go ahead. So is this a Linux foundation developed tool? Is it something that if we want enhancements, we could write code and submit them? So this is using matrix and the client that is embedded is element. However, any matrix chat client that supports SSO can connect. So I've tested it with a number of clients. I find element to be the nicest client. But yes, if you submit patches to matrix or the client of your choice, I would expect those to be upstreamed. That's appropriate, right? Anything else, anyone? All right. If not, let's move on. Is there any other announcements? Okay, not. So in terms of quarterly reports, we have two reports that were still there. That was, sorry, that were already there last week, but they had popped up fairly shortly before the call. So I want to give people more time to react to those. As far as I know, there is no issues that were raised that deserves time to discuss here. If I'm missing any, please let me know. So, Bawa, you made a comment to the fabric? Yeah, I thought the fabric know that. Okay, that's good to know. Thank you. And nothing got added to so too. So is there anything anybody wants to raise now? Otherwise, I think we're done with those two reports. There are no other reports. If you look at the calendar, it doesn't call for any reports for this week. So I'm happy to say we are current with a calendar. And I have to give credit to the projects to keep up with us and do their due diligence and find all the reports in due time. So we're in pretty good shape. All right. Otherwise, the main agenda item and only one I have really is the incubation entry considerations. So there is a wiki page. It's linked from the agenda. And, you know, several people have actually been hammering some description of what they should be. We went through some of it last week. And there were a few changes that were done offline, but fairly little. And so I wanted to just continue this and see if we could get to, you know, a level of satisfaction where everybody can say, yeah, that's fine. We can leave it at that. So I mean, we are missing Tracy and Arun who both contributed along with Dan or the most part of the text, but hopefully you can still make some progress. I can say that there were several items that Arun had proposed to this that were moved off. And yes, you may have seen because you were tagged at least the TSE members, you know, he has created a new issue now for like expanding the incubation exit criteria for to eventually add things that we want to be part of the exit criteria, things that he brought up and people say, well, I don't think that should be a requirement for entry to incubation, but sounds like something we should have for exiting incubation. So some of the items that have been crossed out here pertain to this. I have to admit I forgot where exactly we were. So if anybody remembers, I forget. I remember we did the code base and there was, we had some discussion on the maintainers. I thought we were at the end. I'm sorry. I thought we were at the end. We went all the way to the end, you say. That's what I remember, but maybe my memories were wrong because I'm old. Well, I wanted to offer everybody to bring up any issue they had or are you happy because the default is, you know, if nobody wants to add any more comments, then we would agree to whatever is in there now and say, okay, this is what it is. How do people feel about that? And then since you have had quite a bit of your hands into this, if there are things you think are worth discussing here or that we ought to discuss before we can call it done, please let me know or let us know. I think we didn't get enough discussion time on overlap and charter documents. I think there's some things that kind of slipped in, but I'm not sure we want there. Mostly in charter. I don't recall a specific section on a project's charter ever being in any of the prior considerations. I mean, that was kind of implicit and what they spoke about in there, but that seems to kind of a bit new. And the bit about the TSC considering it, I don't know if that's a requirement or more something that you do to manage the expectations of projects coming in that they're not going to necessarily get a vote the first day that they submit. So reading through some of the changes we did since last week, and those are the two that stick out for most parts. But some of these are already implicit in the HIP document that aligns with the charter. Maybe it's probably good to make that explicit rather than implicit. Yeah, so I mean, if I understood correctly what you talked about, when you talk about the charter, I mean, there is no currently we have no concept of charter per se, right, for a project. We have a description of what the project is about. But I think maybe there's a problem there in the sense that, you know, if we start referring to a charter when we never really had that defined. It sounds like a different method of discussion we should have, because we also mentioned, you know, what if a project veers from its charter, you know, what if it evolves. And if none of the projects have had explicit charters, it's hard to veer from your charter. I mean, you can totally veer from your initial proposal, but the proposal sometimes is to build this project and get it working. And then, of course, the charter is going to evolve at that point because you have it working. You either go into maintenance mode, which is boring, or you add new features, which marry and not be in the charter. You know, the sad truth is when projects are getting code commits every week, some people tend to think that they are, it's a stagnating project. So it's a dilemma. It's like, you know, there's a mature product doesn't necessarily have code changes every day. They're fixing bugs as they come in, rather than, you know, presuming that nobody's using it. So it's a tricky thing there. But some projects might want to, you know, change their charter because they might have realized that it was a bad idea. I mean, ideally, you'd want to figure that out in labs, but they might get further into the implementation and figure out that what people really want is something slightly different outside of the proposal. I mean, the charter, I think, is too nebulous for us to put on new projects until we figure out what it means for all the other projects in hyper-leisure. Yeah, I think the one case where we have referred to charters is indeed the issue when we felt like, well, some projects didn't live up to the expectation in a way, you know, and the case in point, especially when we talked about projects that were presented as if they were going to support multiple frameworks and ended up on the supporting one, you know, and we said, well, they are not fulfilling the charter. And even though, I mean, I think we meant is, you know, what was described as what this project was going to do, even though there's never been a formal charter anywhere, the best, you know, the closest to it is the hip that's submitted initially, which has some kind of, you know, fairly high-level description of what this project is about, how it intends to accomplish its goal. And that's it. We do have a charter for hyper-leisure itself, but we have never had charters for the projects. Yeah, and that's probably, you know, the charter for hyper-leisure is something maybe we should revisit because the first point is completely done, you know, hyper-leisure's built fabric, which was one of the original charter goals. So, you know, the rest of it seems to support it, but I mean, it's almost like we need to consider a rechartering process for, you know, examining a charter of hyper-leisure and getting charters for all the other projects. That's a big, big undertaking that, you know, we need to buy in from all the other projects before we even attempt it. So there is an effort underway to revise the hyper-leisure charter to make it more in line with what it hyper-leisure has become, and this will be submitted for review and eventually as to be approved by the board. Is that a governing board so committee, I assume? Not a TSC issue? Actually, so this has been handled by the, what do we call it? Ellen has been leading this. It's the same task force that has been handling the revision of the website and the greenhouse. Marketing committee almost, yeah. Not quite marketing. Related to the TSC, but you know, obviously the TSC is not going to, is not the final approver for this. The charter is under the control of the governing board. The scope is greater than the TSC scope. So of course, yeah, that makes sense. So it's governing board that has control, right? Yeah. Yes. So, but so I, you know, then the second part of your statement was about, you know, creating a charter for each project. I mean, I would have to ask, what are we solving if we were to do this, you know? So, part, yeah, what we saw was we give the projects a clear scope. So it's probably going to be a really simple thing of going back to their proposal and taking it about and just rephrasing it. Because, you know, some, because we had that discussion of decharter, not dechartering of limiting projects who aren't meeting up to their charter. They don't have a charter. That's an ineffective thing that we can't hope. There's nothing to hold them against if we're going to do that. So right now, I don't consider that to be something that the TSC could do since nobody has charters. Yeah. So I just grabbed, this is just the top one. And I went through a bunch of these just now. And a lot of them have a, you know, the context, the motivation, the scope, right? None of them have anything that I would say is a charter. So, that's right. Yeah. Mark? Oh, I was going to say I thought the project proposals were basically equivalent of a charter, right? They're saying what the project plans to do. And this is, again, a discussion about entering incubation, not, you know, six months after you've entered, you're already, you know, this is to get you into incubation. So the proposal is what we have. There's no charter at that point. And then down the road, we could look to see if they're meeting their original proposal or not. But that's what I was going to say. Do we need a charter because the proposal does, you know, kind of fulfill the same goal in a way in describing what this project is going to be about. So I don't know that we need to define yet another piece of document. I'd be happier to avoid using the word charter and instead talk about the proposal, you know, that was set forward. Because the issue, again, in this case was, you know, oh, you've said, you know, the project was approved based on some expectations set by the proposal, and that never were fulfilled. And so you could argue, well, you know, you did us wrong, you know, relatively speaking. But I don't know that having a charter, we change that we can just go back to the proposal and say, look, we said we're going to do this. You didn't. Yeah, I would propose removing the whole section on charter for this. It's not I don't think it's something we need for a project to go into incubation, because we have the project proposal. So Dan, go ahead, his hand up and then Troy has hand up. Yeah, and that's about where I was getting to, you know, the discussion for charter implied, we have all the projects have a charter and since we don't want that, it's unfair to make new projects have a charter to hold a two different standard. So that I would support the proposal as well to remove the charter section. So I think the first bullet is important, though, right? I mean, it's kind of obvious, but it's very likely saying, you know, it's a project proposal, if the proposed project doesn't fit within Hyperledge or charter, well, we're going to say no, that's pretty clear. So it's maybe obvious, but maybe it's worth bringing up. Yeah, that first point is worth making explicit. Haven't we already violated that? I think we've brought in applications, which we weren't going to originally. That's a good point. But as you said, that's, I mean, yes. But it shouldn't be, Troy says, hand up, and I'll point out that Bobby has posted it. We had Troy first, right? Yeah, I was just going to agree that from the discussion I'm hearing, it's probably best to remove this section for now. And Bobby has linked to a document in the chat channel. Okay, the new chat channel, I'm going for every chat around trying to look for it. Yes, thank you, Bobby. Arun, welcome. Hey, thanks. Sorry, I joined in 20 minutes late. So on this section, right? So let's say, if we were to rephrase the charter, but what I would still like to have is for any new project that is getting proposed into Hyperledge, it's better to have a period of time where it goes through a public review process. And I'm not saying that it's, I mean, it's a counter thing that TSE would anyway do a review of the proposal. But it's better to have more rise and go through that proposal. So I guess we can combine this with the previous requirement, right? So in the HIP phase, sorry, in the HIP document, I see there is a section which mentions that project proposal must be floated around in the TSE mailing list before it gets proposed. So probably we can take that as a mechanism and say, hey, when you propose this through this mailing list, it probably enters into that public review phase. So you get all this ice, I mean, that period of time, and then you come to us, probably by then you have collected enough considerations, which community would expect you to have our expectations on the project itself. And it's just a better intense of process is what I believe. So I've been talking about the third point in within the charter that we go through a public review comments or a phase where we ask for comments. I mean, if you want to rename this from charter to something else, it's fine. I would expect a process like that to happen. So I agree with the intent there, but I don't think we need the charter for that. What people can do is what Tracy actually did, I think she mentioned that on her call before that they're working on bringing up a proposal to move the Blockchain Automation Framework Lab to a project. And she actually put the HIP together and she published it to the lab mailing list asking for feedback. And I think that's a good thing to do. It's like, well, try to socialize it, but you might as well do it with the HIP directly. So the applicant just said, and she says in her email, well, we'll bring that up to the TSE and before we do so, we'd ask for early feedback. So I think some of these things are good, but they're not specifically... So there's a mismatch, I think, in what's written there and what the intent of the document is about. We talked about entry considerations, right? This is not like real consideration. It's more like advice or recommendations to the applicants. You'll probably have a better experience if you do those things, but I wouldn't make it related to the charter in particular. I think some of this could be moved to a different section at the end, other recommendations or something like this, and you can list a few things that people should probably consider doing as they are planning to bring a proposal to the TSE. Would that work for you, Aaron? So I mean, do people really think it's... I mean, shouldn't it be a mandatory process or should we keep it as an optional recommendation? For me, it doesn't have to be mandatory because it's like, well, if people feel confident they don't need it, well, let them take their chance. I think the reality, though, is that in the past, this was done informally, right? So every project had this informal socialization phase. So I kind of agree that it's implicit. All the other projects have done this. Hart? Sure. Yeah. I mean, one of the things that I wanted this sort of effort to do is to sort of summarize things that people have done and things that are sort of expected of people implicitly. So I mean, we don't have to make anything necessarily an explicit requirement and, you know, after going over this for years, it seems like we're probably not going to be able to make everything explicit in our incubation requirement, right? But what we want to do is we want to give people sort of a good idea of whether their project will be accepted or not if they submit to the TSC. So I have no problem including things that are not hard requirements, but maybe recommendations in our, you know, final output of whatever this sort of documentation is, right? So it may make sense to say things something like, well, in the past projects have done this and people will appreciate it if you do it. Well, to add to that, it's really about setting expectations. And so, you know, even content that's like, here's kind of the way we think this is going to go. And these are the types of comments to expect is helpful when someone hasn't been through the process before. Yes, I agree. Okay. But so what I heard pretty loud and clear is that the charter section as it stands right now should go away. And then seems like there's agreement that some of the, you know, recommendations there could be saved in some other section. I want to go back to the first point because I think Mark kind of, you know, raised an interesting point. I'm still not sure how to what to do about it. You know, on the one end, logically speaking, you know, we should enforce that new project proposal fits in the charter. At the same time, historically, we just haven't. So are we precluding people from bringing something that maybe will make us revisit our charter by saying you must, you know, your proposal must comply with it or fall within the hyperledger charter, in which case we're better off not having that bullet. Just leave it out on purpose, not accidentally. I guess the the voices that I would like to hear from are I don't see in the list here today. And that would that would be from the firefly team or and like ask them if this had been in place when you made your proposal, would this have helped? You know, just because they were the most recent group to go through. And before that it was Bezu was the last project to come in, I think. So cactus. So I would ask the people who led the cactus effort if that would have helped or made it more clear what the expectations were. I mean, sure. I mean, we knew what we were getting into for cactus. So I don't know if that was sort of the best example because we had a number of people that had, you know, been around for quite some time. So like, you know, I've pretty much been around hyperledger since the very beginning. Tracy has been around since almost the very beginning. We had a number of people who had seen pretty much all of the project proposals from day one. So so we knew what to expect. I think the Bezu team is probably a better group of people to talk to about this because they didn't have that sort of community knowledge and they didn't know what to expect. And again, one of the goals of this is to try to formalize that community knowledge about what you should expect when proposing a project for incubation. So Grace had been calling into the meetings for a couple of months ahead of time to kind of get it a feel for how the discussion went. So but some things just wouldn't be expected. I think some of it was unique to the nature of bringing Bezu in. There were a lot of people that called in that don't call in regularly. And yeah, so I think it's, it is pretty unique to each new one coming in, you know, because bringing in another DLT was a big deal. Bringing in a six to one. So that was, of course, you know, that gets extra scrutiny as we've made clear will happen on this entry considerations before. So that would line up with our experience there that, you know, if we bring in another DLT, I don't know if anyone was looking to come in, but it would be particularly hard for them to come in right now. I think most of the scrutiny done on us was because we were at DLT competing with the other five DLTs. What if there was a role formal or informal for members of the TSC to work with projects that were that wanted to come in and say, not to necessarily smooth things over, but hard. Yeah, so this is kind of like the Apache champion role, right? I think I alluded to this in one of the comments here, that it might make sense to have someone or give sort of, sort of if you're coming in fresh, right? Maybe you start in labs, you know, this is like a community, I think I put the, maybe I, yeah, I put this in the, should we have a community section, right? So a project comes in from labs, you know, maybe they've just been working as a lab, they're not as involved in the general community than they want to propose for incubation, right? It might help them to, you know, talk with some people who have been there, you know, for quite some time to say, you know, like, hey, I think this is great, you should do it or, you know, hey, you know, maybe you need to do these things before you propose for incubation. But again, this just, this just streamlines the process, you know, it helps people get a sort of a reasonable expectation of whether they should propose or not and it, you know, an unintended side effect is it helps the community to know each other better. So, so I think something like this is totally reasonable and Apache already has a formalization of this role. Mark, so is that really an expanded role for the sponsors of a project coming in? It would seem so, yes. Well, so, I mean, Rai was talking about TSC members and I, you know, sponsors are not limited to TSC members. I don't know, and I don't know that we want to mandate that, you know, proposals need to have support of a TSC member to get started. Yeah, that wasn't what I meant. And now that I see Hart's comment that is more along the lines of what I had in mind of a, you know, not necessarily a sponsor, but a pathfinder. Yeah. One of my concerns with the pathfinder is I've seen the TSC reactions to these being highly unpredictable to these other proposals that come in. So it's possible the pathfinder could unintentionally give bad advice because it's hard to predict what the rest of the committee is going to rule on a particular subject, even when the committee's ruled the same way on it previously. Every situation comes in has been in a different context. So, I mean, we can do that, but we need to make sure that people are wary that it's just one person's opinion that may not necessarily reflect what the group will do. And it's kind of random, to be honest, some of the stuff I've seen. Well, I think it's unpredictable, doesn't mean it's random, right? Good point. It's not. I hope it's not. So, I mean, Dano, I totally agree with you. But I would say this is more of a, like, floor than a ceiling. It's not a, you know, you're totally good to go. It's more like, well, here are the obvious flaws in your current proposal, right? But I think Firefly had that because they were in talks with people ahead of time. And that didn't go the way they expected it. That's true. But so, I think this falls in the category of things we could recommend, right? We could say, well, you know, you might consider trying to get somebody who can help you, you know, review your proposal and make sure, you know, it looks good enough. And then point out that, you know, even though you can't, you know, their opinion alone cannot, you know, is not a representation of how the TSE will eventually go. I think in the past, Brian has helped projects, you know, most projects that have been brought up by Brian, or he had some involvement in getting them on board. In the case of Firefly, he contacted me and said, hey, here's these people who are interested in bringing a project, maybe you should talk to them. I had a call before and with them and tried to explain the process to them and that kind of stuff. They said it was helpful. And I was careful not to set the expectation as to the outcome because I really didn't know. I thought the project was interesting, but I was very careful along to say, look, at the end of the day, there's a vote and I can't tell you what it's going to be. But so I think it could be useful in this document. But again, it's not a consideration from the TSE. It's more like recommendations to the applicants, to the proposer to say, these are the kind of things you might consider doing, like sharing the hip, the proposal beforehand with socialize the hip, right? Get early feedback. And as part of this, you know, unroll the help of somebody like a TSE member or somebody who is knowledgeable about the community who can help you, you know, maybe get a better find your way more easily. So I think we have to be careful not to, you know, give people, make it sound like this is the perfect recipe for success, but more things that they might consider doing that, you know, to just get a better experience, independent of what the outcome will be. Because I mean, there is a lot of, for those of us who've been involved in hyperledger for a while, we have a lot of shared knowledge about how all these things function. You know, I found that through this experience talking to the Firefly people early on that they really didn't know, right? There are some really, you know, high level understanding of what a lab is, what a project is, differences. But they didn't really know how the whole process goes. And just sharing with them, you know, I think was helpful to at least, you know, get them, again, not to know what the outcome would be, but at least know how we would get to an outcome and what it would mean. So I think we need to did the document to make that section, move things around a bit, try to reward things so that it's more like, you know, it's clear what is considerations for the proposer and considerations for the TSE in reviewing the proposal. But otherwise, there were other things that I think were kind of left open in their comments from H.O.P. that were not answered. We just touched on the community. I'm not sure what the outcome is. Do we want to say more than do we actually want a community section per se? Based on the discussion, we just had H.O.P. Go ahead. Yeah, I mean, I don't know whether we want to have a community section, but we want to sort of, we want to somewhere encourage like socialization and basically say that, you know, look, the more your people are involved in hyperledger, the higher your chance of acceptance is going to be, right? So maybe what should be part of the consideration by the TSE is, what has been done to socialize it? Well, yeah, but I'm just saying like even without the sort of, you know, regardless of this is whether, regardless of this is like the right thing to do or not, generally speaking, projects that have sort of more hyperledger, more people known to hyperledger, working on them are more likely to be accepted than those that are not, that don't, right? This is, you know, maybe this isn't right, but this is just how it works today, I guess. And so this is sort of, you know, in a what to expect, right? You know, like if you're looking at sort of previous projects, right, you know, you can sort of compare yourself and see how this might affect your own route to incubation. And if you don't know anyone, maybe it's a good suggestion that you should meet some people. So again, like one of the things that I really want this document to be is something that people looking to apply for incubation can look at and see, you know, do I have a chance or not? And it doesn't, this doesn't mean it has to have, you know, hard and fast rules. It doesn't have to have requirements. It can have like soft things saying like, you know, projects that do X have historically done better than those that have done Y. But I would just like to incorporate this knowledge somewhere so people can find it without having to learn it firsthand. Does that make sense? Yeah, I think so. I think we have to, I mean, I would prefer that we turn those things, those, those observations based on the story, right? But just like you said, into actionable items. So if we, if the story is that, yeah, projects that do X do better, I think we should say, we should have a recommendation on the set. You should consider doing X because projects that have done that have historically been fair better. But it's, it's a formatting issue. I agree with the idea. And thanks, Arun, I saw you started using the document. So that's good. So there's the section on documents. And I was wondering, I mean, is it worth separating this from the code base? Because so this doc, this section says basically that, you know, all documents should be and in fact, it talks about the source code as well. And documentation should be made available, which I think we all agree. I'm just not sure there is much value in separating the code and the documentation from that point of view. Arun, can you tell us maybe why you thought of touching it in the different section? Sure. So when we talk about code, the other aspects do come into picture, such as the license part, the DCO part and whatnot, the committee's tripart. And documents may be lying in elsewhere. They could be in different formats lying at different places. Otherwise, it's, it's fine. We can, I mean, if that is not a concern, we can group them together. I mean, typically even for documentations, we request, we require DCOs, right? Oh, okay. So what I meant by documents over here is more for the review process itself. So that when a new project is proposed to hyperlegion, make sure at least your documents are in public so that we find anybody interested can review it. Maybe it makes sense that we move this to recommendations, as we say. So wait, the only documents we're talking about is the hip, right? That's the official document, right, as a proposal. I think what I hear Arun saying is like beyond document, beyond documentation, right? So your, your hip is not going to include design discussions, right? Those design discussions probably happened elsewhere. Bobby? It's also nice that when projects move out, that there's learning documents for people to review when they're interested in learning about the document, not in the GitHub repository, but maybe on, you know, link to the My Docs section that all the projects have. Okay. I mean, at the same time, you know, I'm a bit worried we're reaching to five, we say, hey, any discussions, any design documentation or discussion you might have had in the past should be brought to light to be able to bring this. And that could be a way to draw the line. I mean, you know, if you think of like, you know, I'll take the example of fabric, it started in IBM Research, they did a whole bunch of discussion and internal design discussions that I guess we never published. I wouldn't even have access to this myself. And, you know, at some point we said, okay, we're going to open source this and we put it out there. And then eventually we contributed this to Hyperledger. And there were documentation that came along, but not everything that had ever been done before. So we are, I don't know how do we specify, you know, this in such a way that it doesn't become unmanageable for the proposer. I edited the document, I remote make existing part of it. And I just left behind make relevant documentation and design discussions available in public. And I moved that section into recommendation section instead of having a separate document section. Bobby, is your up again? Or is it still up? Sorry, still up. It's all right. We've all done it. But so hold on, because now this has turned into a recommendation but Hart was saying this is a big one. So we shouldn't even consider proposal with these things are not yet public. We can't have that just as a recommendation if it's such an important requirement. Okay, Daniel is first. Oh, it's thumbs up. Hart, go ahead. I mean, I guess there's some discussion over what these are. I mean, I should, I guess I think I wasn't assuming that we were talking about as deep documentation as you were. But I should still clearly have enough documentation where I can understand the project, right? Yes. So I don't know like where we want to draw the line on documentation or what's required, but we can say something. Well, my on this is we just want to say something like we understand what it is that you're contributing. You know, it really feels like an incubation task to me to get to where we have, you know, how to become a contributor documentation and, you know, how to get involved in the various components. When a project gets out of labs, it often doesn't have all of those things yet, because it's only been built by kind of the core group that we're trying to figure out the idea. Yeah. So for me, the bare minimum is I at least want to see the code run. Design documents are great, not required. But if they're not even going to share the code publicly, I don't even want to vote on it. It might be a little extreme on that opinion, but that's how I feel about it. No, but I think I agree with that too. And we have that above in the code base section, right? Where it says the code has to be available. Yeah, code base we have code should exist as open source software in some form. So you would at least have access to the code. I'm happy to have a maybe what we need to have is, you know, sufficient documentation should be provided so that people can understand what this is about. You know, it may be a bit vague, but that could be a must, you know, they must provide enough documentation for people to make sense of the proposal. I think that's reasonable. Even though it's a bit vague, we could say, look, all you give us is a piece of code that's unreadable. You could imagine they could have and then what, what is this about? I don't know. At the same time, the hip already has some, you know, section that intend to capture at least at a high level, right? What this project is about, what is the solution, meaning, you know, what's the high level design of the approach? Arun, go ahead. Right. So just connecting this back with the recent proposal from Firefly, there were documents spread around across multiple locations. It was not just the hip document, but there were also few documents floated around on Google Docs, some of them on through PowerPoint slides. And there were references from hip to those other places. And I remember in one of the call, we even called out asking them to open it up so that everybody can have access to it. Yes, that's a good point. And maybe we should provide for, you know, pointers at least to the documentation, the relevant documentation, so that you have some kind of consolidated entry point. So you don't have to go fishing for relevant docs. I actually just see that we are out of time, that hours somehow went by quickly. So I guess we're not done yet. But this document, I really encourage people to try to do a bit more offline. You know, it's okay if we keep doing it that way, but we probably would be a bit more effective if we did a bit more work between the calls. Speaking of which, I won't be able to attend the call next week. Tracy will be chairing the call. So with that said, I'll close the call on this. Thank you all for joining and talk to you, well, personally in two weeks, but for the rest of you next week.