 Perfect. Thank you all for joining on time, so nothing better to do. All right. Well, welcome everybody. This is the weekly TSE call. It is a public event. Anybody is welcome to come and listen in or even contribute. If you have interesting things to say, there are two requirements to doing so, though. The first one is to be aware and lead by the antitrust policy, the notice of which is being displayed if you're connected online on Zoom. And the other part is the code of conduct, which you should be familiar with. It's linked from the agenda and invite you to have a look if you have never looked at it before, but essentially just ask you to behave like a decent human being and respect everybody else. So with that said, let's get going with the meeting person proper. I haven't heard of any announcements. Is there any that anybody wants to make now? Okay. I don't see anybody jumping up and saying, yeah, yeah, yeah, please. So let's move on. In terms of quarterly reports, I'm still waiting a report from the Kaliper project. I don't know if anybody from the project is on, but please let them know. We did receive a report from the Avalon project. I saw earlier that it seems like most DSC members looked at it. I haven't seen any questions being posted. Is there any questions? And I don't know if Eugene is on, but if there's any comments as well from the project that they want to highlight, there was no TSE questions raised in the report. So I think that's pretty much, there is not much else to say about this. So with that done, first thing we really have to do today is a bit of housekeeping. Rai, who always is busy to keep us on top of things. Thank you for that, Rai. I pointed out that the, we actually moved the project composer to, we deprecated the composer six months ago, and according to a project life cycle, after six months, if nothing happened, the next step is to move it to end of life. I actually did check with one of the maintainers, Simon Stone from my BM, who says he's fine with that. So with that, you know, I mean, I'm not aware of any reason not to do this. And as Dan pointed out in his email to the list earlier, I think it's a good thing for us to practice a project life cycle. And it's a show, it's a, you know, to me, it shows the maturity of the project to be able to get those projects moving. And so with that further ado, I would like to propose that we do move the project composer to end of life. Is there any comments or questions in this regard? Okay, hearing none. I think we can just do a year on a call, but somebody should second the motion. Second. I'll second it. Mark. All right. So can anybody in favor of moving composer to end of life says hi. Hi. Hi. Anybody abstaining. Please raise your voice. Hang on. Anybody objecting to this. Okay. Hearing none. This is anonymously approved. Thank you. So this is the first time we do this, by the way. So I don't mean to celebrate per se, you know, moving a project to end of life. But again, I think it's a, it's a good sign that we do this. I think we're able to go through this process. So from that point of view, I do think it's, there's some kind of celebration behind this. Okay. So with that done, there is really only one agenda item, which is the long-term agenda slash framing question. We already talked quite a bit about this. We had a presentation a couple of weeks ago. I didn't see much discussion to say this either on the mailing list on the wiki. There was a little bit of a discussion on the, on the rocket chat channel after the meeting. And it was kind of between during the meeting. And then it bleed off a little bit longer, but I also had a couple of discussion with people. And I mean, my view on this is that we could, you know, there's general agreement again, that this would be a good thing is to hide, to identify gaps and, and possible areas of coordination between the projects. This has always been true. And I haven't heard anything to the contrary. I think the challenge remains to identify, you know, exactly what we could do. I saw, for instance, Chris, I mean, we talked about the programming language, you know, the choice of different programming languages, making it difficult for certain components to be reused. And especially when the components are in the form of libraries. And so Chris, I think at the end of the call pointed out one area that could be prone to maybe some collaboration between the projects is the SDK, because indeed from an application point of view, at a high level, you know, at a level high enough, at the end of the day, just connect to a, you connect to a network and you submit a transaction and you wait for the receipt. And there's a bunch of events that also tell you, you know, what's going on in the network, what the updates are. And so if you take it high enough, this should be pretty much universal. And it could be an area where we could indeed have some kind of like common project on defining some kind of common SDK API, that all the project could then adopt and implement on top of whatever they have today. I think, you know, I'm not so keen on spending another hour discussing the ins and outs of what we might do, what the challenge are. I think we've kind of gone around this quite a bit already. And unless somebody has an urge to bring up something that they think will make a difference, I don't care to have more of that. I am interested in hearing if anybody has some concrete proposal. And if not, I would say one thing we could do is, you know, along the lines of the proposal Chris made with we're getting the SDK is kind of start building a list. And we don't have to do that now online necessarily. We could do that offline, but kind of build a list of the different projects that could be taken up. There's another idea I'll just throw it in now. And I was discussing this offline with Chris. And it was, you know, I think there is some lost opportunity sometimes when projects take on new tasks, new developments, it would be easier at that time to have some cross projects coordination or collaboration on developing common code. If this happened early and because once you have code that already does fulfill your needs, it's the cost of switching to another library or component is much higher. And people tend to be entrenched. And unless there is a significant gain from switching, it's just easier to stay with what you have. And so one idea that came up in our discussion was maybe, I think most projects now have an RFC of our RFC process where new ideas are being debated put before the project community. And maybe if we could advertise those more widely across Hyperledger, it would at least signal to the other projects, hey, this project, whatever it is, you know, is looking into this area. And if you have an interest, this would be a good time to express this and maybe rally forces around doing something that's not limited to a single project that can take into account other projects' needs. And that would become more natural. And, you know, it's like we wouldn't have to come afterwards and try to, you know, not force people we can't, but, you know, even like try to convince them that switching is a good thing. We would do that preemptively by, you know, encouraging corporate or making, allowing, you know, these opportunities for cooperation to happen more naturally earlier. So I've talked enough, I'm going to shut up now and let you guys react to any of the above. No reactions whatsoever. I don't believe that. Oh, I think you pretty much captured my thoughts. All right. Yeah, I agree with Chris and that in with you. And I think the big thing is just to make sure that people are aware of what other people are doing in the project. Yeah. And in this regard again, I mean, we have these quarterly reports and it does give us a little bit of insights as to what's going on. Project do say, hey, we're focusing, you know, what's coming next? We're doing this and that, but that, you know, I'm not sure we all pay attention enough to this, or if comes in a form that makes it easy for people to realize, oh, they are starting this. This is an opportunity maybe to cooperate. And so I think we should discuss a practical way of highlighting again, maybe the RFC, the start of an RFC is a good time, or some kind of signaling that would be stronger that would allow this collaboration to happen if there is any chance. And it could be, you know, the kind of things I'm thinking about is either we make it more obvious in those reports, but maybe every quarter is not in often enough. Maybe we ask the projects to send an email to the TSCG saying, hey, watch out. You know, the fabric project is tackling this. We have a new RFC. I don't know. And maybe there are other ideas that we are happy to hear from you guys what you think, but. No, I think you're exactly right. And I think the RFC is the right way to do it because you want, you know, it's much easier to collaborate if you haven't started yet, I guess. Yes. Right. And I think, you know, just maybe notifying, hey, there's a new. RFC for project Prubar. Covering XYZ. You know, it would be one way of at least raising a little bit more awareness. I don't know if we need to sort of then just sort of. Maybe just on, you know, a five minute, you know, reminder to people on the TSC that, hey, there's these new RFCs. You might want to take a look at them. You know, just, you know, because I think a lot of times we just get sort of so caught up in our own concerns, their own day job and our own priorities and stuff. And you don't have time to look sideways. Well, and this is where I think the process is helpful, but the more important question is, how do we make it compelling? Cause, you know, a lot of the maintainers that really could use that overlap in that discussion, you know, don't usually pay much attention to the TSC calls. Right. Do we do something like an RSC chat channel? Where people who, you know, so if you have an idea, you could post it there and get reaction. I mean, if people knew to look there, then, you know, there's a better chance they would see it. Yeah. I think a chat channel is too, too noisy. I don't know. I'd rather have an email sent to the least personally. Or we could have a wiki page that points to things, but you don't want to duplicate the whole RSC process either. So. I believe that you can subscribe to notices for a repo. And, uh, and get up. So I think you could, could control that yourself. Yeah, but I don't know if we can rely on that. Unfortunately, because I mean already today, anybody could just follow what every other project does, right? But it's just, that's too much. It's hard. I mean, I only know Brian who subscribed to all the mailing list. Yeah. And I guess the thing is, if I'm watching RFCs, you know, I don't want to see say like every RFC that fabric does, I want to see the ones that are relevant to me, right? Well, but how do you, how does anybody know which ones are relevant to you? That's what I'm curious. Yeah. Yeah. So you have to sort of be your own filter. Yeah. So I'm just wondering what the best way to, to be my own filter is that's all. Right. That's how I was sort of suggesting though, is, you know, new RFC foobar project X covering and then just, you know, really just a one liner. What is it? So you don't have to open the thing up and read through five pages of stuff to figure out that it's not interesting. Yeah. That's a great idea. I mean, if you just say like this RFC, you know, affects X, Y and Z and these are general topic areas. And if I'm interested in X, Y or Z, I can dig deeper. And if not, then I just read one sentence and move on. I think that's a good idea, Chris. But so where do you see, where do you find this, Chris? I don't know. I mean, it could be an email to, you know, the TSC, it could be an email to, I think there's a maintainers channel now. It could be, you know, somebody suggested a chat channel. I think that was Nate. That might be a good idea. I don't know. Certainly I think that the RFC process needs to stay inside the projects where it's happening now. I think moving those RFCs somewhere else would be difficult. No, I'm not saying to move them. I'm just saying to, when you create one that it, I mean, and that actually could be, automated, right? You know, when there's a new, you know, a new pull request added, you know, maybe you can, you know, write a little bot that just. Yeah, I was, I was wondering if maybe just like we're doing promoted releases, maybe we could have promoted RFCs where a project says, Hey, this is something we would like comments from the broader community for, or this is something that's significant enough to us that we want people to understand what that is happening now. That way we could tag them or send them to whatever forum we think is appropriate for it. I, I, I just, well. Interesting. The challenge I think though is that I don't know that. It's easy for the maintainers to understand what might be. Interesting to somebody else, right? You know, it could be that you had, I mean, I'm just sort of, you know, sort of. Top of the head here, but. You know, let's just say that. You know, project A decides, you know what, we're going to go off and we're going to. We're going to go off and we're going to change the. You know, swap out the, the consensus for a BFT. And it could be that other projects were also similarly considering that, but, you know, maybe, you know, that's a little bit bigger than a bread box, but you get the point I'm trying to make is that you don't know what that is. They may not have put out an RFC or whatever. And so that may be interesting to them. If you're starting something new, that they're starting to sort of mumble about is what I'm saying. So another similar type of thing. You know, and it was, I think it was Mick who sent, no heart sent the mail out about the lab, Biff. We don't, you don't necessarily have a lot of visibility into what's going on in the labs. And I think, you know, some of these labs turn into projects, which turn into libraries or whatever. So is there a way to increase awareness of the labs? On a regular basis. So, you know, I think it was Mick who sent, no heart sent the mail out about the lab, Biff. We don't, you don't necessarily have a lot of visibility into what's going on on a regular basis. So people know what's going on down there, at least with the active ones. Because that would be the time to get the stuff in, right? When they're starting to form it. Yeah, I have to say on the lab front, it reminds, your point mark reminds me that we had started doing reports. I say we, the stewards, and I have to admit Tracy did all the work. So she really deserves the credit, but she did it on our behalf. I'm one of the stewards of our essay. We, and I don't think we really have been very good at doing this on a regular basis. But if we did get better at doing a lab report where we kind of say, hey, this is the status, you know, you had the new projects. We had so many and we retired this one and that kind of stuff. That would provide us a report we could point to. You know, I think that could be advertised publicized to like the maintainers community so they could be more informed about what's going on there. I do think, you know, what the point to Chris made about sending this to the maintainers list or channel or whatever. It reminded me, sending it to the TSE may not be good enough because we want really the maintainers to be aware of this big overlap between the two. But it's obviously not all the maintainers on the TSE and not maybe not all the TSE members are maintainers. And so that we, I don't know that the TSE is a good, is the right target for that. But probably should be involved in some way, but maybe it has to be both the TSE and the maintainers. We do have a maintainers mailing list. That's basically unused. There are other options. You know, we could set up a yet another mailing list, right? We could have an RFC announce mailing list if you want to follow other, if you want to participate, go here. But even though that would, you know, give you a much easier ability to fill through the mail, it's yet another mailing list to lose track of what to do. So I don't have any strong feelings about that, just an idea. That might not be a bad idea. And we could subscribe the TSE and the maintainers list to it. I wonder if we could just use the maintainers list directly just because it's not that high traffic now, is it? No, no, that's right says there's nothing going on. So I agree we could use it for that. Question is, if the TSE members were not maintainers, want to follow what's going on? I think it'd be good for the TSE to also be aware. You can join the maintainers group. Because like I was a part of the maintainers group and I just joined in. So it's not limited to the maintainers? No. But so that's a pretty good solution. So we can use the maintainers list and have whoever is on the TSE is not a maintainer currently and maintainers list can join. And then we can make it policy that when projects take on new RFCs, they should announce it to the maintainers list. So the other advantage of this is that for somebody who wants to just come in and start working on a project that RFC announcement list gives them a really good idea about the kinds of things that are happening in the places that they could contribute. Yes, we if. Okay. So if you were to tag. I think we underused tags in our mailing list. Right. So for this maintainers list, if you send your mail into there and you just put like hashtag RFC. Right. Then when you go to the list. You can see the tag. You can see the tag. The tag. The tag. That hyperlegia.org. Page. You can click on that tag. Even as a non-subscriber and see the traffic on. This tag as an RFC discussion. So I didn't even know that exists. So yeah, so we could maybe just use an ounce then or something. The thing that I was going to go with though is it seems like this would be right for just a simple bot. Yeah. Yeah. Yeah. Yeah. Yeah. When somebody posts an RFC in one of the projects. They just bought that's that sends a notification. At least the ones that are using RFC. Have a. A repo for it. So you just detect a new poll request and you pop it up. We could do something similar with the labs as well. But when the PR gets merged, if you will. Right. And the new lab is created. Sure. So I. I don't know if this is true. I don't know if this is possible, but get up actions are available. I think everywhere. We could have a get up action here. Right. That says if the PR is new. Send the mail. I'm not. Completely sure if I could send. Email from get up actions, but just another thought. We might not have to do a lot. To make this happen. I think you're onto something there, right? I might also suggest that we. Not only when they're new, but just significant life. Our life cycle events. Because like, you know, an RFC will get proposed and then it gets worked on. And then when it goes to sort of final acceptance. Right. For the design, I think everybody would want to know that too. It's like, Oh yeah, right. I forgot that was going in. I better go see where they're at and weigh in before it becomes final. Right. I was going to say you, you don't want to do, you know, just send the mail out when the code's getting merged. You will. You want to have the ability to. Potentially influence the design of the fix, right? I would think the design of the fix. Right. I would think the design would be more important than the code. With that, would that suggest having a process that's triggered off of a certain kind of a template in the wiki. Then rather than as a, an RFC posted in a, in a GitHub repo. Maybe, but our projects are already using RFC repos. I mean, just look at Ursa RFC. Indie RFC. We already have a pretty mature process there. Well, we thought about the RFCs because that seems to have become the norm for new, new big things to take on, you know, in projects. Most about RFC processes have those two milestones, but the rest can be kind of sporadic or chunky. Usually there's a, it's ready for everyone to look at it milestone. And before then it doesn't make a lot of sense to bring in the broader community because no one really knows what the. What, what parts of it will gel? And then there's the phase that Dave was talking about where it's kind of the request for final comments before we decide that this is how we're going to do it. Okay. So I think that's good. I mean, we don't need to drill more into this now. I think I'd be happy for the staff to look into what they could do. It seems like everybody is jumping into trying to solve the the solve the problem of how to do this notification. But fundamentally that means we agree that this would be a good thing to do. So I think it's worth spending a bit of time investigating how this can be done. And then we can look at this again. I haven't heard people comment so much on, you know, ideas otherwise, you know, such as what Chris said about the SDK, are there other areas where we feel like, Hey, this would be a good place to do some kind of cooperation. And this is more in line of the TSE kind of providing its opinion to the projects as to, Hey, you know, things that could be done. Obviously, you know, this can only again be proposals and we would have to see if the maintainers of the projects are interested in working in those, but. So yeah, I was going to say everyone has been speaking, you know, like you said, more how to solve it and all, but I guess the initial question would be, is there anyone that's against trying to get more cooperation between groups? I don't think there is, but you know, if there's someone that's against it, why, you know, I never heard anybody express anything like this, but this is interesting question to raise bluntly. I just, I just don't want to, you know, go forward on the assumption. There's been, you know, four or five of us. Yeah, I think the question has never been the principle. It's been the effort, you know, you know, how much, how much of an expectation is there to lift a finger to do that? And I think it's always going to be a mixture of carrots and sticks. There should be something positive for, for projects that want to collaborate this way. And I think like the RFC kind of argument is great because who doesn't want a broader audience for, especially the early part of an RFC process, right? Everybody wants that, I think, or should want that. I think things like the repository, Linter or repository structure, working group are also a positive move. And that could be more on the, I don't say stick side, but kind of like saying, okay, these are the standards now that we're going to expect every project to follow, you know, not to add bureaucracy, but to make it easier to move between projects. I think moving, moving those kinds of effort forwards and bring, you know, kind of a floor of commonality between the projects is, is a big way to help, help people move between these projects and the projects find ways to work together. All right. Anything else? Otherwise, I think we're going to close early and call it a day. I don't have anything else to bring up. As I said, if, if there's nothing else on the agenda moving forward, I will bring up other issues that I'm kind of interested to address that I did bring up last week and at the Hyperledger Global Forum, where I was talking about the roles of maintainers, what does it mean? How do they come on board? What's expected of them? That kind of stuff I think would be good to kind of nail down as, if not again, you know, the, the mandatory policy, at least some default expectation that could provide some guidance for all the projects so we could have a bit more harmonization around those things. How it's done, that it's properly documented and as much as possible consistent across the different projects. And if there are other issues, you know, I've heard loud and clear, several members saying, hey, we should be talking more about technical issues. Again, the, you know, the door is open. People are free to make proposals on issues they would like to tackle. Technique, they doesn't have to be limited to the process. It can be technical. So please don't be shy. Bring up issues. Unless anybody else has anything else to add, I will close the call on this. I guess if you guys don't mind looking over the BIF stuff that I sent out yesterday, that'd be awesome. Yes. All right. Hearing nothing else, I will call it a day. Thank you all for joining. We'll talk again next week. Thank you.