 And let's move to the code of conduct. We don't have that today. There you go. Thank you. So again, after that's the other piece that everybody needs to be familiar with. Welcome to the TSC call. This call is open to everyone. And everyone is welcome to participate. But please do respect the code of conduct, which essentially is asking everybody to be decent person, which I don't think is too much asking. But nowadays it seems like we have to remind people. So there you are. You have been reminded. All right. So I made actually it for those who just opened them. The agenda you may have noticed that I've shifted things around a little bit. But basically, I think we can do the reports first before getting into the discussion. We have a whole bunch of issues we could discuss. I apologize for last week. I could probably have made the call, but I was in Japan. It was really late in the evening. And I thought we could use the time offline to make progress on the issues. I'm sorry to say we haven't seen, I haven't seen much traffic or not as much as I expect or hope. But so we'll try. I think there was a flurry, right? When you say there were some, there was some. Yeah. And I appreciate the, you know, those who took the time to comment. Thank you. But so in any case, I think we can start with the, the announcement and the quality reports, which, you know, should be pretty quick. And then we can go as much as we can, you know, given the time left on the discussion topics. So with that further ado, let's talk about the maintenance summit. Is Dan back on with sound? I don't see Dan. I know that Salona is on Salona. If you want to address this. In regards to maintainer summit. If you want, you can click over to the pages on the wiki. Dan and others have been organizing it. To sit there and see where the. The location is and what the registration and the agenda are. And notice the pre-registration was coming up on us very quickly. Do you know how many people have now registered? As of yesterday, we had 40 people registered. So we still have room for more. Yeah. We're quickly retaining the size of the venue. Yeah. No, I realize that, but okay. It's so that we set the right expectation. I don't want to encourage people to register for really over, overflowing. It's like. So there's still room if somebody wants to register. Yeah. If we have a few more people, that's probably fine. We have, you know, 50 more people that's definitely not fine. Yeah. Is there, is there something in the registration page that will not allow you to register if you pick warm. Okay. I see Dan has joined. Yeah. Sorry about that rejoined. You want to talk about the maintainer summit was the status. Yeah, it sounds like you guys were just talking about, we're right about at capacity. So I think if there's, um, you know, you can just go ahead and do that. But I think I'm, I'm really happy that we've gotten a really strong turnout and there's a good starter list of topics. And I've got a couple of ideas that we haven't put on there yet. All right. Thank you. That's what we wanted to know. Any questions, anybody. If not, we can just move ahead. So the next is the bootcamp. Sorry. Yes. So everything is up and ready to go in regards to the bootcamp Russia. The main thing that we're doing now is working on getting out. People to join. We've got a lot of session leaders. We've got a lot of different sessions happening. We've got a lot of different people visiting. One of the major changes that we did is because of having currency issues. We took away the sign up fee. Um, because there were problems with credit cards going through and there were problems with the ruble and et cetera, acknowledge them. So that's the major thing that got changed. Um, but other than that, where I think at, um, about 40, but we went to get to closer to 200, but we just had one of the banks that they're and say we want to bring 30. So we're getting there. It's just a bit slow on the signups. All right. But it's all organized. Okay. Any questions? Anyone? Does the, uh, dropping the fee impact everything for the budget. We can see anything. The fee has never, I'm going to mute Chris first. Okay. Um, the fee has never been anything significant to us. It's only been $25. Um, the only reason we do it is to make sure that no one takes up a spot and it doesn't show up. Um, Okay. That makes sense. Yeah. And as I recall, uh, we, I, for years we never collected those fees. Um, it was more of a, of a theoretical stick. Uh, that may have changed, but. It changed. We do actually, we do actually. We do actually collect those rye. Um, it's that, uh, previously we, um, would occasionally refund them, but we were, we didn't, we haven't been doing that this time. We've just been doing the different fees. Um, so for this one, we refriended the 10, uh, fees that people had actually paid because everyone else would sign up was a session leader. Yeah. So they didn't actually pay. They just used their session leader codes. Um, but for the other people, we're now, uh, we've actually waived it because there were so many problems with payment that it was actually affecting the registration, the ability of individuals to register. Is there anything that needs to be done to make that more known and crank up the registration number? Uh, we're going to go and contact all of our members that are in that area and we're sending them materials. And then we're also going to, uh, work with the meetups as well, because each of the meetups have about 700 people in them. Okay. Any other questions or comments on this? If not, thank you. So now let's move on. Okay. So, uh, I'm going to send an email to the list. About the DCI working group having drafted the survey and requesting. Input of feedback. You want to say a word about this? Yeah. Um, so from the DCI, this is kind of the first thing that we're trying to, um, Produce and what we've been working on for the last, uh, the last couple of months. So, uh, I think our idea here with the survey is to kind of get a baseline of the community. Both to figure out. Kind of what are the demographics that we have, and then also kind of understand what their experiences are like in the community. Um, and we're hoping that if we can come up with a format and a list of questions that we can repeat. Year after year, we'd be able to see. Or gauge our improvement or. We'd be able to see some of the different kinds of actions or motions to kind of improve. Uh, diversity, civility, inclusion in the community. Uh, so just kind of getting some general feedback, uh, would be great. And then I think we would want to kind of put this up as like a discussion item in the future TSC meeting. Um, I realized that we could probably put the little review. That after this meeting to add our names. At the bottom. Oh yeah. Sounds like a good idea. All right. Thank you. Any questions or comments for the sweater? Um, hey, this is Silas. Yeah, I just had a few. I just quickly had made a few on there. Um, So I'm. So I understand that. Um, I'm just part of the survey is about setting sort of more statistical baseline. And I think the section two stuff, this is the table that seems fine. The first section of questions. I struggled to find, uh, sort of engaging. I mean, my answer to them was like, yes, it's extremely important, but I feel like in answering it. Uh, I'm not sure that the, the, the. Um, I'm just learning much about. You know, what I think should be done about it. Um, And I wonder how useful they will be as quantitative questions. And if they're not useful, particularly as quantitative questions, could we recast them as. Uh, tell us about a time when you felt excluded or tell us about a time when you X, like something, maybe a bit more anecdotal, anecdotal that might guide more statistically minded questions. I don't know. I find them kind of. Not engaging questions in the current form. Um, I don't know what other people think. Um, I just don't think I'm giving a lot of information in my answers. Um, Oh, and then we're blessing, uh, maybe I shouldn't batch them together. But, um, yeah, the demographic list looks like it's missing at least one continent. Um, I wonder if a demographer could help with a contemporary list of ethnicities. Um, Um, We don't want to be exclusive in the inclusion survey. Um, Definitely we'll look at the demographics in terms of the first set of questions. I know this has kind of gone. Uh, we've had discussion about what is the value or what are we getting out of it? And I think, um, that first set of questions, the whole idea was if we surveyed the community and perhaps they are a little bit boring, but if they do say, Hey, you know, gender diversity, regional diversity, civility are not important to us. It kind of gives us an idea of. You know, there, those are not people we're going to be able to change. But those are not the people we're going to be able to like make differences. Like it kind of is some of the blockers that we would have to deal with in trying to bring diversity, civility, inclusion. At least I think that's thought process. Uh, behind those questions, but I do think we can have more discussion about that. Um, I'm sure we will discuss it. They spoke offline in, in our next meeting. Okay. So one suggestion that just coming to me, she's saying that, um, I think it would be much more, uh, perhaps interesting if you change them into a ranking question, if that, if that's what you want. So rather than having everyone kind of voting from motherhood and apple pie, um, uh, you know, rank these different forms of inclusion in priority order, I think that would be a much more interesting signal because it, you know, it forces people to, uh, trade against them rather than just answer, as I expect a lot of people with that, you know, they're either important or very important. Okay. That's an interesting idea. I kind of like that. Um, again, definitely we'll take it back to the working group and then we can see how that kind of fits in together. All right. Thank you, Silas. Thank you. I mean, I don't mean to get into too much discussion on the content. I mostly wanted to take advantage of the call to highlight the call for feedback. That's what I sent out on the mailing list. So I invite others to follow through and. Come and come into on the wiki. All right. Thank you. So let's move on. Quarterly reports. I just wanted to, I don't think Sophia, I didn't see Sophia on the call. I did have some email exchange with her. You may have noticed last time I pointed out, I was confused because, uh, she had filed a Q two smart contract working with report, but she said, oh yeah, sorry. That's just a mistake. So this is now been renamed key Q three. And she has answered some of the questions comments that had been posted to the wiki. And she didn't have any specific issues she wanted to bring up to the TSE otherwise. So they are facing like many other working groups, I would say. Issues with regard to participation, but there's nothing unique to it other than that. So we'll see if she ever, you know, if he joins in a third year call, we can always, but I mean, if you have questions, the best is to post to the wiki. She is now paying attention. She actually as was moving and she was busy and for low white, she was not so responsive, but she has fixed that now. So. I think they also just posted a rough draft to a white paper that she was asking people come and help contribute to. Yes, I saw a note about that. So that's good to bring it up. All right. So the report has all joined. So. I posted a report for Ursa. There was one point he wanted to bring up to the TSE. It's written there right in front of you. If you're watching the zoom window. And it has to do with, you know, trying to get other working group or other projects to use it. And to care. Which is a bit of a challenge. Yeah. So one thing we've been talking about there is we had started off with, with two ideas. One was where we're all doing some basic things like digital signatures. That's an easy area for everybody to start using the same code and we get some collective strength out of. We're lying on a more redundantly reviewed set of code for the project. But that's also a little bit less interesting maybe for some projects because it's not giving them a new feature. It's just having them maybe replace something they were already satisfied with. That we did recently see this addition from. And then the second area are. These newer kinds of cryptographic features. And. They're not actually in their, in their use case pipeline yet. Or they're, they're just not. Aware to share those with, with Ursa so that we can help provide those features. Yeah. So there's a call for. Yeah. So there's a call for. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. So there's a call for input there from the maintainers. The other projects. You know, as to what they might want to see out of Ursa. That would make it more interesting to them. If anything. Yeah. And it can be fairly high level. I mean, you don't have to mention a specific cryptographic technique or algorithm. It's just like, if there's some use case that. Could be satisfied potentially by a cryptographic use case, then it's also pretty likely that, that one of us can help pull something out of the literature for that. Thank you. Then anyone else. Any reactions. So scary. So I guess. I mean, I know this there was a discussion way back when, when the Ursa project first came out, but do we really think like writing everything in Rust is actually the best way to get everybody to use this? Well, there's, there's language bindings. And we can have language bindings. I mean, I get how to use it. Don't get me wrong, right? I mean, so, I mean, there's like two variations, right? There's kind of like this approach, which I think is one approach and probably makes sense to start out with to a degree. And then there's like, you know, the, you know, the MCL project, right? Which actually, and I'm not saying they did a great job either, but you know, they created, you know, their crypto stuff and they wrote them in like three or four different languages. Ironically, Rust wasn't one, but I know a lot of the original, like, you know, indie crypto and stuff like that uses, like the BLS thing, interesting things like that that were over there. I guess, you know, that's, you know, that's all it's kind of a concern. I mean, granted, Rust is, you know, cross compatible or whatever that's in there. And then, you know, I guess maybe one of the things like you said, like maybe some of the newer, cooler or more interesting, you know, algorithms become more of interest, right? So that people don't have to, you know, go figure out how to do this. But I don't know, I just, it becomes, you know, tougher to do that, right? I mean, the only onus, for example, on like a fabric side that we would have for swapping out a crypto library right now is if somebody gave me a FIP certified library. Okay. For the crypto we use today, which by the way, as an aside, I kind of have through Red Hat. So I think those, I mean, we can talk more about that, but you did ask about those from the TSCN, maintainer on the other side, right? I think that's kind of where we got to, I do like your thing of like, you know, where the roadmap of the more advanced, you know, crypto stuff, I think that becomes probably more intriguing right? So that projects don't have to implement those things themselves. Yeah. So AMCL, if I'm thinking of the right project, they were able to do a lot of languages and that's pretty cool. But they do that by having a non-optimal approach. So sort of an anti-goal for them is optimality. So they're not trying to, you know, really push performance. And that's a totally fine design goal. Going with rust is a little bit different that we are hoping for some performance benefits, as well as the threading safety and so forth. So it's a little bit of a trade-off. You can provide bindings or you can do stuff directly. I don't know if we'd be at a point to switch thinking on implementation language, but right now, as far as the contributors we've got, it's all sort of rust focused anyway. See, is there a request more around specific language and then being able to provide that binding for that language? Is that a me, Tracey, or? Yeah, I mean, it's like, we want it written in Go and therefore, or we need the interface would go and therefore we need the bindings for Go. Yeah. Yeah, I mean there's, you know, the bindings thing is okay. And I think that would probably be, I mean, that would be an amenable approach that's in there, right? I guess, look, and we have our issues right now, but look, just like anything, right? Anytime that you add additional stuff, right? There's always issues, right? Yes, we have Seago, right? So clearly we can create Go bindings via, you know, C interface into this type of stuff, right? But, you know, you're always going to get into, anyway, right? Anytime you try to do stuff that's cross language, cross whatever in there, just add additional, you know, overhead and stuff like that, right? And, you know, if you're really looking to build cross platform, right? Look, I mean, some of this is on the open source side. Some of this, I can, I'll speak, you know, selfishly as a vendor on some of this stuff, like, you know, we, you know, so we have this and while the world runs on x86 and there's a lot of great stuff in there, we have to build our stuff to run on other platforms, right? So, again, it just adds an additional layer of complexity, right? Into, into builds, right? Even if you have cross language bindings, right? Because you're still loading something, you still have to compile the other stuff to source, etc. Yeah, I want to make a point about this. I don't know what, how Fabric feels about this, but certainly, I mean, at first, I am supportive of, you know, you know, you know, Fabric feels about this, but certainly, I mean, at first, I am supportive of Rust, if there was going to be one language, things written in. For Borough, we hang on fairly jealously to our single pure Go binary. See Go is, is not free in a bunch of ways. You can, fairly well documented in particular building for like muscle instead of Lib C. You lose a lot of the benefits with some of your reflection and, and stuff once you switch to See Go, it is a, I mean, it kind of looks the same up to a point, but there are a load of gotchas with See Go. So that would be a blocker for me using Earther directly in Borough. Although I think probably we do have a C compiled mode for like, we use SQLite as an option. So if people want that and possibly we could use it in our proxy kind of wallet service. But currently it, there'd have to be something that I really needed in Earther to, to drop C, to be willing to have See Go binaries. Yeah. And I think that's exactly the way to think of this question is, we know that there's obstacles, whatever they are. So what is something of value that would rise above the, the obstacles for you? And maybe it's with, you've got itemic stuff in, in fabric, right? Right. So we have itemic in fabric, right? And that's your point, right? You're exactly right. Again, on optimization, right? We took the, we build the, we take the Go stuff, right? And then you're a thousand percent correct that if we took the, even if we took the C version of AMCL instead, we would probably get much better, not probably guaranteed. We would get better performance. Yeah. So what I was actually getting at is, I think that itemic stuff that you have is like RSA style, they're CL signatures, but they're using these, these bigger groups. And so there might be newer stuff that we're doing with elliptic curves. So I don't know if that's interesting. I don't know if there's even an awareness of that, but just, it may jump here. So this is Angelo. So we are using already elliptical. Okay. And we also have an implementation with delegatable credentials for, for in Go directly. But do you have an estimation of how much can be the penalty of using the, the, the bindings? I didn't quite hear that. How much could what? The penalty of using the bindings. So suppose that we want to use that, or someone wants to just fork fabric and then wants, or any other project and wants to use this Rust library. So what would be the penalty in for, for, because the Rust can be efficient, but then if you pay a lot in the, in the bindings, you know, you are actually losing. So what's, do you have an estimation for that? I don't have any reason to think that there's much cost, but I don't have any, any numbers to back that. Do you have a, I was thinking to this other aspect, you know, if it's very, it's very interesting to, to have the same library shared by multiple project, but it also poses a risk in the sense that if the library has a bug, this bug will be immediately, will immediately be effective on all these platforms at the same time. So is there, I mean, sometimes it's, you know, it's better to have the implementation of the same algorithm done by multiple people like you would do in the, in the distributed algorithms. And then, you know, if one has a bug, you still have other platforms without, without the bug, this kind of thing. So any, any thought about that? Yeah. So the idea is that if we've got more review focus on one library, that library's more likely to be robust. Whereas if we, each project has separate implementations, then it's more likely one of those implementations has a flaw. In order for the logic to hold that you've got multiple implementations leading to more strength of a network, then you have to have that entire network drawing from those different implementations. So like if you've got a fabric network, but that fabric network is only using the fabric implementation, it doesn't matter that sawtooth also has a separate implementation, because those aren't on the same network. All right. So I don't want to get too deep into this discussion. I'm happy to see some technical discussion for the technical steering committee. It's actually not that common, unfortunately. So I didn't want to get it short either, but I think I'm happy we're having a discussion. And hopefully this can continue offline. Yeah. I thought that was good and helpful. And so if anybody wants to do that live, we've got the weekly Ursa meetings. Otherwise, I think general preference towards a sync communication on the lists or chat. I think that would be good. I think this is what the Ursa working group project is asking to have this kind of interaction. So they understand better what might be the resistance to using Ursa or what might make it more attractive. So I think it's good to have this discussion. All right. With this, let's move on. So there was a report posted by David fueling on quilt. He actually brought up a question in his report. I think we mostly addressed it in comments. I know David is on, but essentially, you know, he's, he's repeated what has been said before that he's back on the project and is hoping to be able to make progress. His question was mostly about, you know, not being sure what is expected of him in terms of free port to the TSC and all. And basically I reassured him saying, you know, it's not like we're trying to kill it. And so if he can make progress, you know, we're definitely going to let him do that. So I just encourage everybody to look at it and comment. I don't think he's online. So on the call. So you can risk, you can post comments and questions to the wiki page. If you have any questions. Moving on. The last one is caliper. I did a posted the report. He didn't raise any questions or issues for the TSC. I don't know if anybody has any. I know he's on the call and he offered to answer questions that might be raised during the call. Hearing none, I guess there isn't any. Well, thanks for being here and anyway. So let's move on. Let's get to the discussion part of the agenda. So first, Gary, you, the one who missed the call last time, as a new member of the TSC, I invited all the new members to take a moment to tell us what they would like to see the TSC do maybe differently than we've done to date. And so what's your interest in the TSC, you know? Yeah, I guess on a few things, right? I think that's why I went into the rat hole on that one. I think it would be interesting to have more technical discussions. Right. And maybe we can figure out, you know, to bring up, you know, subjects and things like that on that. I guess it's a fine line between, you know, having those discussions as, you know, in the actual projects themselves or sometimes on some of these reviews, even maybe a project, right? It could be, you know, discussion kind of like we had there. I think it's kind of interesting. So I think definitely, you know, more on the technical side and I guess even some technical stuff on, you know, things across projects, I mean, even tools and other things like that. I personally, you know, find that we're too loosey. I think we're getting better. I think we're too loosey-goosey on expectations set across all projects from a technical perspective, both from life cycle, et cetera, et cetera. I'd like to see perhaps more of that, more similar to Apache. And then having a TSC actually come up with ideas in that space. All right. That was good. And, you know, I'll say, I'll repeat what I said last time because you weren't there. It's, you know, from a technical point of view, I don't know anybody who would like, who wouldn't like to have more technical discussion just like we had. And so the problem is we do have process-oriented questions like what's left on the agenda for today that we still have to tackle because we have a gap. Hopefully, you know, this won't take us forever to solve an address. And then once we have put those to rest, we can focus the agendas to more technical matters. I think everybody would like that. So I'm definitely, you know, in favor of that. Don't you come up with the agendas, Arnaud? So do I have you to blame for the non-technical nature of this agenda? Yes, you can. But hey, the agenda is a wiki page and everybody's invited to participate in putting it together. So thank you for giving me the opportunity to remind everyone of that fact. And take a look at the decision log or the backlog at the bottom. Right. And anyone can add to this backlog. These are all wiki pages. So if there's a, something that you want to bring up to the TSC, you can add a page here trivially. I would like to echo Arnaud's statement there. This is also a wiki page. So if you don't like where it's going, you know, jump in, make an edit. Yeah, I have a question. So when I took a look at the agenda yesterday, I was surprised to see that there were some discussion items that we were probably going to end up loading on. You look at that backlog, it's in alphabetical order. Is there some way to know what it is that we're going to focus on for the next meeting so that we can make sure to spend time on those items before we get to the point where we're like, Oh, we want you to vote on this. So my point, the way I'm looking at this is what's in the discussion is highlights of some of the points that are in the backlog. And this is what I hope we can vote on. And we might get to the rest if we ever, you know, have more time. But so far, this has not been, you know, historically, as you know, the TSC usually is pretty short on time. So we don't really have that luxury most of the time. But that's the idea. I do highlight all these things. Product life cycle issue six, TSC co-chair, TSC size, items that are in the backlog. And they are the ones that have highlighted for this today's call. I guess what I'm saying, I don't know is I understand that they were in the backlog. I just didn't understand they were the ones who are going to focus on this week. And so I didn't spend time on them until yesterday evening. And I have some thoughts about at least the TSC size one and the discussion that's been going on there. But like, it was late last night when I looked at it and I haven't been able to comment on it. And so I guess I'm just saying I want to make sure I have enough preparation time on the items that we are going to discuss for the week before, like the day before. Okay, fair enough. And, you know, I, I don't actually, I mean, the fact that I put them on the agenda for discussion doesn't mean I just expect a straight vote and nobody has the right to comment. And so you may very well say, Hey, I'm sorry, I'm not ready for us to vote on this today. And, you know, I will totally honor that request to defer, but, you know, or even stop the discussion with, you know, that's the right thing to do. Or if you're ready to do that. So, you know, and I appreciate, you know, this is kind of a new process that I'm trying to put in place. So we'll have to get used to it. And, you know, I didn't, I pray could have done a better job, but communicating the process I wanted to try and use. So no worries. We'll work through it together. Okay. So any other questions under the process or how the agenda is set up since we're talking about this. And, you know, I very much welcome feedback. I'm myself trying to sort it out and figure it out. Right. So just a wine. I missed the push model of the TSC agenda getting email. I got so many compliments emails a day that it's hard to figure out which ones are just someone creating a page to see if something works versus. Here's the TSC agenda that has been set now and it's not going to change. Yeah, I, I have the same complaint markets. I don't know, Rye or Solana, if there's any way of cutting down on the spam from the TSC agenda, I don't know, I don't know. If you go under confluence and go under notifications, you can go through and customize things pretty dramatically. So I would, yeah, I would go in and yeah, it's for each individual. Each individual has complete control over their notifications. And you can go in and prioritize and do a bunch of different things in regards to that. So I highly recommend going in there. I think though to Mark's point, it would be maybe nice if either Rye or I know or whoever would send out a specific email saying here's the agenda. Yeah, I can do that. That's fine. I almost did it earlier yesterday. And so I'm happy to do that. I was already tempted to do it. So it's fine. I can do that. When I put the agenda together and I feel like, okay, stable enough, I'll send an email saying, hey, I'm going to send you a book and see if you want to add anything or what there may still be changes to Wiki. So anybody can make changes. I can guarantee that, you know, it's not going to change at all, but at least I can send you an email to say, hey, you know, I think that's the most of the news is there. All right. And some of this is like changes. That's when you get, that's when you get notified. Anything you change, you get notified automatically, by the way. Yeah. Yeah. So I think this is proactive and designed to be asynchronous. So like as you have time during the week, going in and checking on the backlog on the items that you haven't reviewed before. We're checking in on conversations that you have been engaged in. And it's sort of less important when the final agenda is built because you're already up to speed on those things. Yeah. All right. So let's try and make progress on some of the issues that I've highlighted. Yeah. So the first one, or the first ones have to do with issue six. You know, so we have had quite a bit of discussion over time as to whether we should have some kind of formal sub project structure. And the heart for one was a proponent of, you know, making that happen. And there was quite a bit of discussion on the profit, you know, as part of the project life cycle task force. You know, my feeling was, well, at the end of the day, we didn't really have any form of consensus when we're another, but it seemed to me the majority, you know, didn't seem to be in favor of creating a structure. And so I after quite a bit of rambling, I put together that one resolution that says, well, we're not going to have formal sub projects. And so that's the proposal that I'm putting before the, the TSC today. So as an implementation detail, what you mean is that I just want to make sure that this is all like spoken, right? So for instance, fabric can create a sub project called fabric SDK foo. And not have to get any blessing from the TSC and not generate any reports. And furthermore, if the fabric group, if the fabric project decides that fabric SDK foo is deprecated, they can archive that without any say so, or anybody having a vote on that, they can just do it. Yeah. And that also means that when we do TSC reports from the project, they should include, you know, reports on all the different sub projects like the, like the different SDKs and things like this. And so just to finish the corollary to this proposal is the 6.2, which basically says, okay, there were historically we have had some projects being, you know, presented to the TSC as new projects. So they were actually proposed through the heap process and approved, but we never really handled them, managed them in any shape or form lack top level projects. Right. So we don't have reports from the, the chain tool project, for instance, and, and, you know, so there's a, there's a corollary proposal, which is to say, officially we are rescinding these from top level projects nomination, even though they are not surfaced. So it's really purely administrative at this point. We're just saying, okay, all of these things are really part of fabric. I don't know if any others that are, it seems all of those are related to fabric in fact. Yeah. So, and so the go SDKs actually made a request. I missed the last maintainers meeting. So I don't know the status of it, but to actually join fabric. So it would become a sub project. Of fabric. Python SDK is still sort of independent. I mean, again, we could look at that. I don't know if that was on or anybody from there, we could look at doing that chain tool. I don't even know if that's still being used to be quite honest. I know. So I had a discussion with Greg about the, during the migration from here. You found it. I did surprisingly. And I asked if the project should be deprecated and he said it's still, he's still willing to do it. It's basically stable. So they're going forward. I don't know what they want to do in terms of becoming a sub project. But yeah, he's alive. Okay. But I would consider it really can't become a sub project because we've removed support for it in fabric. Right. Exactly. So. Okay, but hold on. Let's not get too much into this right now because. So there are two parts. Right. The first is we don't, we agree that we are not going to have formal sub projects. But we are not going to have a formal sub project. So we are not going to have a formal sub project. We are not going to have a formal sub project. And we're not going to have a formal sub project with a structure. Right. So high article projects. Right. And so, but what I wanted to say, again, going through these things. I think if somebody comes along and they say to the fabric maintainers of the sawtooth maintainers, Hey, we'd like to create a project. You know, Fubar. As a sub project of sawtooth or whatever. And the sawtooth maintainers decided, you know, the future of the project would be the future. You know, if somebody comes along and wants or, you know, we're not really necessarily prepared to support it and so forth. Then I don't see any reason why somebody couldn't come along and say, I'd like to create project food. Just as a top level. No, and that's correct. And in fact, I hope I was trying to find where that is. the leadership of Dan actually is the chair of the TSE, he you know we have had a few proposals made where we said well that looks like very fabric specific why don't you talk to the fabric maintainers and see whether you should really do that as part of fabric or is it a lab and so all of these are still possible we're not saying you cannot exist outside of fabric if you're somehow related to fabric yes that's that's resolution 6.5 yes i think that's the last one yeah it's all one really i think it has to be one thing so i think one of the issues i'm struggling with internally is to me things like fabric and sawtooth are top level projects right maybe we need like a different category for projects like a major project and a minor project well just so you know if i want to come in and propose something well just propose something for sawtooth that sawtooth doesn't want and suddenly becomes a top level project and gets the same publicity as sawtooth and fabric where it's really you know a wrapper around one of their apis or something you know so if they don't want it automatically becomes a top level project and well it still has to get through TSE so yeah there's feedback like hey this is just a wrapper around sawtooth and hopefully committee shuts that down but sawtooth doesn't want it so but i need it for what i'm doing therefore does hyperledger just say no we don't want it go somewhere else with it well no but i think that that's a function of many of the labs in fact or you know sort of small extensions or whatever you know um that uh you know either wrap the SDK or whatever and add some new functionality um there's there's a lot of those out there and i think that's a healthy thing okay well i just you know where you have you know ascension and again many labs i i i i wrestle with the whole the whole concept of you know a lab or a major project a minor project uh some labs are you know really just here's a sample and they that's the end of that then other things it indeed may be some sort of an extension that's only useful in one domain that doesn't really become part of the core but it's still very valuable but so the proposal the first we have to agree is the six one which is we don't have hierarchical projects we have a flat structure we have different categories indeed we have labs and projects and we can still play with that for certain things that feel like okay maybe we're not willing to put that as a top-level project and i've as mark pointed out all the resources put into this whether it's pr ci and you know security our deeds and all this stuff yeah for for me six one is easy because it's meant to stop the situation where sawtooth or fabric says no that doesn't look like it's architecturally consistent with with our project we we don't want that feature and the tsc says too bad that's part of your project now indeed so can we agree to that i would like to put that one before the tsc as a formal proposal can i can i ask a question about sure this one sure so uh so i kind of see this pattern between there's a lab there's a high level project and then there's these things we don't want to call sub projects but they still kind of exist um how are these top-level projects expected to govern these not sub projects not minor projects but whatever you want to call them i guess part of my question is you end up with maybe two levels of maintainers in this situation you can see that with fabric and a couple of the whatever you want to call these sub projects you can see it in aries where there's multiple framework projects with their own maintainer count um what what is the actual role of the top level project and something like aries or what we call the maintainers of those i i think i'm sorry this is brian i don't mean to jump in but um but i'd put this in a comment um i think it is important for you know the maintainers of a project like fabric to be kind of a single set and that set should include the maintainers on these um additional pieces of code if we don't want to call them sub projects um i um you know and that you know that group of maintainers is still what's accountable to the tsc they still work together to create the report that sort of thing um but i wouldn't want to see precisely what you describe as kind of two levels of a of of maintainership or one group of maintainers the reports to another group of maintainers um it should really be just one unified group and that's partly the basis for deciding should this new code base be within this project or not you know those existing maintainers are essentially adding to their the responsibilities and and hopefully adding to their their population as well yeah and to clarify i find this a bit disturbing because i realize you know there's different ways you can interpret the pose resolution i mean the proposed resolution is actually to avoid this kind of hierarchy so if somehow we end up with the sense that there is some hierarchy that the stk go maintainers for fabric are lesser than you know the fabric core maintainers i think this if it's the point it's i'm thinking of this we have a flat list of maintainers of all the different fabric related to repose i think i i i i mean but that becomes problematic i think that becomes problematic right i mean you can say well maybe it isn't because people are in there and then they you know they only do they only end up reporting on whatever i i mean i'm not just not the fabric but let's just talk about i mean sdk is a probably a big thing because areas is going to have them and whatever right and again i just go to things that i know i look at kafka kafka says look we're going to be the kafka project and we're going to provide a jive a java sdk that's officially supported as part of our thing and that's what's under a patchy patchy kafka they have a official kafka release they have a fish of java release there's 10 other sdks out there now half of them are created by the guys that linkedin bought or that's influenced apart from linkedin and other stuff but and they create their sdks over there and they test them and they say what's certified on them so i think this is where things get you know tricky right because if i'm a person on a project right and people come in and have a project and have this stuff my expectation is that anything that's in here and classified as release or whatever it is should work and on the other side right i think that a lot of people don't go in and i mean maybe it's not a problem because you put one big list and you say that the people are in there but i'll be honest most people aren't capable of reviewing some of the stuff so why would i want somebody merging something i mean we can revert and get into battles there so i mean maybe it's a trust thing i don't know so brian if you suggest we have one massive list and then you have co-owners and assigning uh that that could work i guess i'm confused with gary gary i didn't mean to say we have everybody be maintainer of all the repos because that's what you seem to be describing well i thought that's kind of what that's kind of what was implied yeah i think then it becomes clear that then we don't really have agreement on what this means um i mean again you know to taking gary's point though there's also examples where there is a sort of a top level project and then there are a bunch of projects that are definitely related and typically you know sort of go with the flow and but they often have different maintainers um and that's simply because of area of expertise right so i mean i take a look at for instance open stack the open stack of the defined release structure the release of open stack itself though was defined by the um the architecture technical committee um and uh but then each of the projects had different set of committers or maintainers and um and in fact in some cases you even have different parts of the code base for a particular sub project whatever you want to call it a strictly repo that people had authority over and so you know i i think again within a project i think it's entirely uh likely that you're going to have you know a java expert be responsible for the java sdk and a go expert as the go is and so on and so forth um and they may be different people and maybe they are maybe they aren't part of the top level set of quote unquote maintainers but um and that's a project it's to sort of decide for itself how it wants to be governed yeah i mean google code review don't manage this they have a package level permissions like an owner's file that says who can who can sanction say i mean that's partly i mean they're because they're a monorepo but um i mean i don't i think there's a case where like maintainers get actively antagonistic towards each other but presumably in the majority of the cases is governed by consent so i i just wanted to mention that i brought up fabric and aries for two reasons one of them is because i'm personally involved in them but also because those are two distinct examples of different kinds of projects fabric having this kind of um you know top level project and sdks and components kind of um in an ecosystem but aries is is a different animal because you end up with kind of this peer-to-peer system and there's not really a top level project to speak of it's just you know a bunch of frameworks and and sdks that should talk to each other so um they're definitely distinct animals and um it's not entirely clear to me what we mean by maintainers of the project as a whole versus uh code owners of a component if that's what we're what we're talking about now because i think that makes sense but the point of this is that as the tsc we don't need to get into that what we're not going to do is the tsc is force some project or some community into an existing one right but then i'm going to say that we can't vote that there's no sub projects because clearly they're not sub projects they're just projects right i mean i i think you have to say that look i think there's a there's a defined life cycle right i mean maybe what you're really saying here is there's projects and there's not projects we can classify stuff as frameworks or whatever that's not up to me but you're either a project and you're you're either a lab or you're a project and if you're accepted as a project you're either an incubation uh brand will save me but you know whatever the life cycle is right that's i think that's really what six want to say no uh so yeah well this is what this is about is do we continue to have things like you know fabric go as dk officially labeled as a top level project or is that just considered to be part of fabric i think that's hard to resolve if we don't just if we don't resolve what are kind of rules in a project and what does it mean to be um is there a second class of maintainer at this point what i'm hearing here is there's there's not a second class of maintainer from the tsc's perspective and from a project decision-making process we think of all the maintainers of sub-repositories as maintainers of the overall project and then those maintainers need to figure out how they're going to work together and how they're going to manage whatever pecking order they think they need to accomplish their project's purpose and and you know i think you mean from i thank you net this is correct this fits my mental model and to me it's not different than what's happening today today we have different repos of fabric and every other project they we all have different repos and not mean the maintainers are not the same and all the repos right so i don't think anybody is suggesting we change that what i meant by you know we have a flat list there is no second citizen the second class maintainers they all are maintainers on the same level and that's yeah it's a status quo thing all right so we're running out of time but i'm glad we had this discussion clearly we still have to do some clarification about what is meant so i guess we'll close it for this uh for today on this i encourage people to look and use the wiki offline we'll get back to it next week hopefully we'll be in better shape to have a crisper proposal that everybody understands and we can vote on and the same goes for the other topics that are in the in the discussion section of the agenda for today all right i will close the call on this so we respect everybody's time thank you all for joining me talk to you next week thank you goodbye thank you