 All right. Thank you. Hello, everyone. This is the weekly TSC call. As you, I think, all know, given the list of attendees we have or participants we have today, or as Gary, here is coming. So you all know that we have to live by the antitrust policy, the notice of which is currently displayed on your screen, and the code of conduct governs the way we're interacting within hyperledger and to stay out of trouble. To get started, I just want to start with a bunch of reminders. As we talked about many times, there's the newsletter is still up. I listened to the recording from two weeks ago when Tracy you know, chaired the call. You guys talked a lot about breaking silos, and it seemed like the newsletter was referenced a few times as maybe one of the ways that could be leveraged to increase communications across the community. And that does imply that people jumping into the opportunity to use the newsletter. So please do consider the newsletter contributing to the newsletter. The Global Forum, the first period for the call for proposals closed last week, at the end of last week, but they have extended it. So you still have a few more days if you haven't managed to submit your proposal before the first deadline. And then the mentorship program, on the other hand, the period for proposals has closed. And so we are now going to review by the TSC members. And basically, we were asked to submit a review by March 24. So you should all have all the TSC members should have received an email in that regard. Please do respond. I mean, there's a lot of interesting proposals, but it doesn't take that much time to go through them and get an idea of what's there. So that's for the announcements. Is there anything else anybody wants to announce now? I don't see anybody raising their hand on getting off mute. All right, so we can get going. So quite a few reports. We've received two reports. So Silas responded to my prompt. I pinged him, you know, as Tracy pointed out in the call a couple of weeks ago when I wasn't there, that, you know, I told her I was going to ping Silas and I did and he said, yeah, I'm busy with release, but I will do it next week. And he did. So we have a pretty comprehensive report. As I had indicated also, it was pretty clear looking at the inside dashboard that they had a lot of activity, even though we had not heard from them in Hawaii. And it wasn't, you know, because they were not there and they had disappeared by no means they have. They have actually been quite busy working on their code and they have added a whole bunch of things. And you may have seen the report that they have a piece that they would like to socialize beyond their project because they think it's relevant to other projects. It's called vent. And so I've invited Silas to present. It will will take 20 minutes or so of next week's call for him to present to everybody what vent is about and how it might be relevant to other projects. Okay. Is there any other questions or comments on this. Otherwise, there was the there was a report from the Ursa project. There was no specific comments other than the usual please, you know, if they are interested parties, we're always welcoming input and feedback from others. So, I mean, this was posted yesterday so I understand that everybody may have had a chance to look at that one but if there are any questions, heart is here. I'm sure you can answer questions on the first part is there anything you want to add. Did I do a good enough job but bringing us perfect. That's perfect. Thank you. All right. If there is no comments or question. Go ahead. You can't hear you. I saw it. Yeah, so you raise your hand and unmute but we can't hear you Sean. I imagine shouldn't fighting with this machine trying to figure out which level has been needed. I would just like to make the bar. You come through by the various crumble that you can try. Can you hear me now. Very poorly, but we can hear you. Yes, I just wanted to make the point that apart from then borrow now has complete. No, sorry. I'd like to take the point that apart from. It's breaking up too bad we can't really understand. Yeah. Could you ask in the chat. In the, in the TSC chat channel, Sean. Because I see that. It's something about the room, but I don't know. He's typing. There we go. Suspense is killing me. Maybe we should continue anyway and we can get. Okay. Thank you and keep an eye on the TSC channel for some input from comment from Sean as well. Okay, so that gets us into the discussion. Part of the agenda. There are quite a few items I wanted to bring up today. The first one is with regard to the implementation of the decision we had made regarding the common repository structure and the use of people. We actually have a decision that was recorded. That says something about the fact that every repository should have a copy of reporting to just son file. This is the configuration file. As we discussed a few weeks ago, you know, we've realized this is a poor idea because it makes it, you know, it creates like many, many different copies, and it's going to become a maintenance nightmare. As we had said, we should try to see if we couldn't all use the same, you know, common repository. I mean, repolinter config file instead. I actually spend a bit of time. There's a, there's a way for repolinter. There's a, you know, an argument that allows you to reference a URL. You can actually download the config file from the net. And so I sent an email to the maintainers list instructing people to try and do that. And the idea is that so in the lab in the community tools repo, we have this config file that we can all share. There are changes that need to be made because you know, nobody says the config file is perfect as it is. We should try to change that one common file. And so I have asked people on the maintainers list to try to, you know, to experiment with it, and several projects already have reported success in doing so. If you have problems, please pick up, let us know what's wrong and possibly make proposal for changes, you know, you can submit a PR against the config file. Just keep in mind that it should be usable by everybody. So it's not a matter of just taking out what's the relevant to your project. And that's maybe one of the challenges is when you know this approach requires that we tolerate things that are maybe not relevant to our projects and sometimes repolinter sense, you know, it will report stuff. And typically they're not flagged as errors. They are more like warnings, and just have to ignore those, which makes the, the output a bit more verbose and a bit more, you know, kind of inconvenient to go through to spot the errors. But I think it's a small price to pay. Now, there are people who have reported problems running repolinter altogether. I personally have been using it against node version 12 without problems. But I know people have had problems. Dano has pointed out there is actually the fabric team actually put together a container that you can use instead. And so if you're not on maintainers lists, or if you know, please you should subscribe. I have to give, I want to give the right credit on the maintainers list work he has done. He went through, you know, major, how do I say that update effort to try to add as many people he could find, you know, scrubbing all the different repositories we have around hyperledger and adding people to the list. And I have to say, I've never seen that maintainers list with that much traffic before which is very encouraging. I think we need to try and do that more rather than less. I think it's a good claim that this list was pretty much silent always. And so I'm kind of encouraged to see a bit of traffic. And so this is one of the topics that you know I brought up on the maintainers list and so if people want to have, you know, guidance on how to do this or if they have feedbacks on the use of people enter, they should actually go to this list report and do some calculations, you know, that kind of stuff. I think it's a good progress. As I said, there are people who have had problems running it. So I said it doesn't work with the newer version of node. I mean, I don't know what else to say on that one. I mean he was saying we need better tools, which you know it's hard to argue against but I don't know. But this, you know, is a complete showstopper either. So I think we probably need to get to help repolinter to get better as well if we can at the same time, repolinter is produced by the to the group, which is just another, you know, bunch of volunteers. And so if there is a, if there are problems, we should just try to fix them and improve repolinter as well. So I don't know if anybody else has any comments or questions on this. I wanted to give an update. That's where we are. If my my idea is that, you know, I'm sensing that we are still following the right thread here the right, we're on the right path. And what I would like to do is, if we can confirm that this is a workable approach, I would like us to basically make a new decision that would override the previous one which was, you know, which said that we should all have a copy of the config file in the repo. And instead, you know, change that decision to say this is the common use the use the file that is shared by everybody as the config file. But I didn't want to jump again and make that proposal already. I figured well at this point is might as well keep continuing the experiment. And as people get, you know, we can sort out the problems, then it'll still be time to make that official. Roy. Oh, yeah, I was just going to say I don't think we're ready for that. It did make modifications to make that work in areas framework go. I think that's one point I think another point is just go rules in this thing. And I think a third point relates to what we talked about earlier that I think there is customizations for repos about like how to exclude certain files test files these kind of things. And I understand the idea that, you know, it just shows up as warnings but those warnings are kind of useless when you can't customize it for your repo. I'd rather create them as errors and actually have a very specific to the repo. So that, you know, if there's a license missing or any of these kind of things, all the all the files for that particular language are properly ignored, and can be addressed. So I'm not entirely sure yet that it's true there can only just be one, one file and I am concerned that, you know, this, we talk about know it a lot but what about go. You actually just touched on a question that I have, which is, can we do code based per repo overrides, like can we specify multiple config files. So I think it's a, you get to a fusion of both right, you have like the main one and then on repos where the main one is kind of two per both. You have the per repo one. Yeah, I don't know the answer to the question I agree it's a good one and maybe, you know, maybe even if we pull into doesn't do it today maybe be a good extension to try to get. Because I would be more comfortable with that if we had like a common config file and then we can say well, here's the way you can, you know, override some of the roles locally, but at least it would still kind of, like you said right get, you know, the good of both ways. Any other comments. Maybe in the end, you know, the decision is well, try to use the common one and if you have really a good reason then create a local copy. And that could still be, you know, a reasonable outcome. I still think it would be better than the general rule of just create a local copy, because creating local copies just for the sake of it is kind of just creating a problem of for no good reasons. So that's why I didn't like, I don't like the the current decision that's on record that says create a copy. But I can appreciate that in some cases this may not be the right thing either to use the common one so there may be some middle ground that we can find there. Sean did comment in the TSC. I'll read this into the record. Sean Young says, I just wanted to point out the borough now also has E-wasm support. This means that with Solang we can compile Solidity and run on borough. It works end to end. This will also work with other E-wasm tooling since fabric sawtooth and a Roa already use the borough EVM implementation, merging E-wasm support as well should be easy. So this would bring E-wasm and Solang support to those ledgers. So that's what Sean said. Yeah, thank you for reading it out loud so it can be on record. Thank you for pointing that out, Sean. All right, anything else? Otherwise, I think we'll pursue the experiment with repo linter and yeah, it goes. But again, I mean, you know, we can't do that on our own. Everybody has to kind of chime in and try, you know, try for your own repo and send feedback. That's the only way we'll be able to make progress and come to a resolution that works for everyone. All right. If we're done with that one, I don't see anybody raising their hands. We can move on to the next item. So I sent an email about that. You know, so what happened is a Chris Anisek from the Linux Foundation gave a presentation to the Hyperledger governing board on Monday about the lessons learned from CNCF and Kubernetes. And there was a lot of very interesting information. And the idea was, well, is there anything we can leverage to make Hyperledger a better place, you know, learning from other projects. And in, you know, I'll talk more about that in the next item. But one of the things that I found, you know, as we was going through his charts is, you know, they were he was talking about the different phases they have in their life cycle for the project. So they have something called Sandbox, which is very similar to the labs, very low entry barrier, and people can create that pretty, you know, easily. And then they go to incubation, and then they go to graduated status so they use the verb so they say, oh, this project is being incubated or is incubating, and then they graduated. And then they have something like archived. And so it's not very different from what we have. But as you know, we use the words active for the status, which is like, you know, the main one after incubation. And I, we've always had problem with this. It's been a very difficult thing to communicate. People interpret it, typically the wrong way unless they've been educated the hard way. So I, you know, I thought, wow, this is such a much better word graduated. And honestly, part of me was like, okay, but it's just not worth the trouble of changing the names we have. They forget it. But then I was like, no, maybe that's the wrong approach, we should be more proactive and say, no, we have something wrong. It doesn't work well. And here's a better solution. Let's just make the move and change the name we have. After all, you know, we do when I'm sitting stone, we can make those changes and if it's an improvement, why not doing it. So I actually would like the TSC to consider renaming the active status to graduate it. And as I said in my email, I think it has actually quite a few advantages over the current name. You know, active is just such a poor characterization of what is conveyed, right. You all know what's in the incubation exit criteria. And there's a lot of things way beyond whether you being active or not. And so, and then there's this, there was this notion that it was brought up several times like, well, maybe some project that, you know, did got out of incubation, they wouldn't meet the exit criteria anymore. And that's a bit of a problem too. We don't have this way of, you know, reevaluating. It's a one time thing. And when I was thinking about graduating I was like, you know, it's exactly the same when you talk about graduation. It's a thing you have done at one point in your life, typically you graduate from high school, university, college, whatever. And that's all it says. You graduated at one point, right. And so I thought this is much more fitting than what we have today. So I, I saw, you know, there was one person who said, yeah, I like this. I think that's a good move and nobody else commented on the mailing list. So, I don't know. I really don't know if people think this is just silly waste of time. If they say sure it doesn't no brainer. Or what, even a room we typically speaks up on every issue we raise. And that's a good thing don't get me wrong. I'm not criticizing by the means, you know, has not said anything. So I would like to invite the TSC member to speak up on this issue. Tracy. So I added a comment to the proposal or the decision entry that you had. We currently use graduated in two different places. And you can find that basically by Googling. But we use it when we talk about labs that have graduated to top level projects. We use it when we talk about projects graduating from incubation to active. So I, my concern is that we've already used the word for meaning potentially something else. And I'm, you know, wondering if there's going to be confusion over it. Okay, that sounds like a very concern. Thank you, Nathan. I liked the explanation that you just gave our know about the way we use the word graduation for kids in school, and how it's okay to graduate more than once. I think it, I, my main concern was the same thing that Tracy expressed that the graduating from labs versus graduating to act or to active, or becoming graduated I don't know how we will say that all the time going forward. But I do really like the improvement in the terminology in the sense that right now active projects apply that the other projects are inactive, which is a very negative connotation and doesn't do what we want to do from a community where as working to achieve graduation or putting more effort in so you can graduate seems like a much more reasonable connotation. And I think my opinion of that is the same one that you expressed earlier that it's an improvement in the language. It certainly doesn't seem to be. It's interesting. It seems like it. There are some problems with it, but it feels like there are fewer problems than what we have now. So, you know, if we just decided to vote on it I would probably vote in favor. All right, thank you. Tracy. Yeah, sorry. So Nathan, maybe think about how we might reward if we want to go with graduate it. So right now we say graduate it to. We may want to say graduate it from so graduate it from labs graduate it from the incubation grace grace. Yeah, just echoing. I like what Nathan and Tracy have said about, you know, active is not. It's really misleading to outsiders, especially for projects that are very active but not haven't had that kind of promoted status. So in the proposal I'd love it to be more specific as Tracy said, for the language of, I think, I think cnc f does promoted to graduate status, and the promoted kind of, and that kind of indicates that process. I have a question though and I apologize if I'm missing something, but the, are we going to be taking this decision kind of separately from the badging proposal. I feel like we probably need a decision on both the to then decide if we're using. I know there are some conversations about getting rid of the active and incubation statuses for the project badging proposal. I'm not sure where that sits so then it feels a little premature to then have this decision if we're not sure if this process is going to stay around. Beyond that, but but I could be. So just wanted to clarify. This is absolutely a fair question and you know, I have wrestled with that myself. It's like, we are working on this badging proposal. And there was this, but we haven't really, I mean we have said well maybe that would eventually replace the phases the status we have, but we haven't made the decision. And, and there are people I've heard, and maybe, you know, correct me if I'm wrong but I think I've heard people say they were not necessarily comfortable with that. And so I have come to the conclusion that well this the future on whether badging will easier to stick and whether even further than that it will replace the phases we have is highly uncertain and I thought, well, this renaming is a low hanging can do. And if we get rid of the whole phases eventually, well there's not much home. It's a bit of a waste of time admittedly, you know, there'll be some effort to update the docs, but I think it's still fairly minimal. And so I figured, well, I don't think we should hold off on trying to make the situation better, just because maybe down the line will have the badgers. So that's why I decided to, you know, bring it up anyway now. You, you, you know, I would appreciate, you know, I'll respect anybody who says, oh no, this isn't the time. Let's just go for the end goal of badging and forget this. But, you know, I love me this is a bit subjective, because nobody has a crystal ball and will know how long this is here to stay on. So, back to the, the, I wanted to clarify what you said Grace on the promoted. Are you saying where can you repeat that part because it sounded interesting. Is that a solution which we can avoid that we're graduated the way we use it today for labs to project could we say they've been promoted to project and then we can keep graduated for projects that go from incubation to graduated with that solve the problem. Yeah, that was the proposal I was making just because I think in the proposal we want to be clear on, yeah, that exact language just so that way every project can be using the same thing but yeah that that was one one idea. I think this is interesting. Tracy, I mean you brought that up which is again thank you because I did not realize that to admit. That's why we have more than one person here, and it is good. But do you think something like this could solve the problem or do you think it's so entrenched people talk about graduated project or labs to project. We can't really fix that we have to use a new term. I mean, I don't know. I think we're still hanging on to people who want to use the word hyperleder or the phrase hyperleder project, when and at some point in the past, it was changed to hyperleder. Right. So, I think, sometimes changing language can be hard, and it takes a concerted effort for people to do that. I mean, I've, I'm more than willing to make the concerted effort, if that's the direction that we had so I just think that we need to make sure that everybody is thinking in that way because otherwise I do think that it can get confusing. Right, especially if you say a lab graduated to top level project. Some people might take that to mean oh they're in the graduated status right. And that's not really what was meant by that right. They have to really make the effort to say that a lab was promoted to a top level project. Yeah. And I mean you know there are other issues right I keep wrestling with the fact that I mean, and I don't blame anybody. I say that sometimes people talk about lab projects, and we have to say no. You know, a lab is a lab a project is a project there's no such thing as a lab project. But so it's a bit like this I think, you know, there's only so many terms we have at our disposal, and we have to disambiguate and sometimes it does require a little bit of, you know, like a brain gymnastic kind of thing to not confuse things. But I kind of like the idea of using promoter to talk about labs to incubation, you know project incubation, and if all the docs were clear on that. Maybe we should have an FAQ somewhere and say what has graduated me that we say, you know, people may refer to this but the reality is, and we kind of, you know, specify what is the right interpretation and the right usage for those terms. Could I ask what the potential downside is, because the people who are going to be reading these, you know, tea leaves from the TSC are going to be new contributors, new people who are coming on board, who unlike me, haven't been exposed to calling it the hyperledger project. So for people who have been here for a while, there will be this little bit of mental gymnastics when you say the word graduated. For people who are new, they're not going to have that baggage. I would just ask, you know, what is, what is the downside we say, you know, before this flag day, is that sorry for the confusion. I see how it said on the chat channel, what about using another term like mature or something else to adult. I think that was actually at some point this came out but I don't think anybody wants to be called. I have a mature project for some reason. It doesn't sound very positive to me. Hi. So when, when I'm not explaining about CNC, I find the way Kubernetes does work today. It sounded so simple. It sounded there are just three stages you start at one and then you eventually mature and then find final goal would be I mean, I hope project would continue but there is some archival stage right when there is no project we're going on. So it sounded very simple that everybody knows there are just three stages on in its life cycle. And, in fact, one of the comment which I added, I'm not sure probably I added yesterday night late night in their time on on that proposal is right now we do are when we are trying to solve this understanding issue, which is in with the using multiple proposals I guess this is the same question which is brought up by crazy and and grace as well right little while ago. So should we focus on one and then make it simple large should we make this intermediate. I mean for me this is kind of a interim solution, but we change naming and then we switch back to another proposal, keep working on it. One personal experience which I have seen within the community is because I also interact with many people here in India. So they kept asking me that areas is now become active. So people did not have that concept of activeness. They thought project became stable as part of this active. So until then people were saying, Okay, it is was still under development. Now it is kind of stable. Hyperledger has released it and they are recommending areas that's that's the kind of feedback that I heard within the community here. So these kind of words, they do make a difference on what we choose. So probably we take some time and then finalize on one approach. Yeah, I mean I agree that those those words are, you know, they do carry some weight right and but so you're saying you'd rather wait. I'm not sure what you're recommending in the end. Right, so since we are solving similar problem through multiple means. Probably we should, we should wait for some more time. So like doing the badging is what you're saying. What other ways that you're talking about. Is that what you're referring to badging. Badging. You're saying you'd rather we keep working on the badging and touching anything until we are sorted out the badging. Okay, because badging is also kind of defining maturity status and so this this word, the choice of word that we are making here active or graduated. It is also kind of defining the maturity status. So probably we should finalize and then I like this wording, there's no comment on that, just that I feel like we should finalize on one process. Okay. I appreciate that you know it's definitely a viable option. Anyone else. I mean Daniel you're proposing the badging. How do you see those things do you think that we shouldn't touch this, it's a waste of our time or are you okay with us doing this kind of change. Why we are experimenting with badging. I mean, I'm a mixed feelings of it. As far as badging my understanding is we were waiting on people who wanted to see the automation to come up with counter proposal. So that's kind of why it's called there, you know to get the details of what they were looking for in the automated values. So if, if we're going to change the name of the current process that does give weight that we're going to keep the current process so it is kind of forcing the issue of whether badging, you know, I really feels like we should do one or the other. We should either move the badging or we should change the name, because doing both is going to send mixed signals. So I think we really need to have to have a decision and come to a realization of, are we going to stick with the current process or are we going to change the name of the badging. And then from that, you know, we would move to one or the other. Yeah, that's that's just, that's my main concern is, you know, we're trying to do both is like not doing either justice. Right. Thanks for the input. Anybody else. Otherwise, I'll take a bit of time to respond to it because I have been struggling with that myself before bringing it up at all. But I think it's very differently because part of me. I kind of expect we will still have those statuses, even with the badging. I think the badging where I've started with a set of badges that pretty much trying to capture what's in the incubation exit criteria, but there is no reason to limit ourselves to this. You know, a lot of other things. And the problem is, you're going to have a whole series of badges, which, you know, is going to be practical for everybody to refer to all the time. But there's still some value in having some kind of high level label that immediately only capture one dimension, not all of them, but, you know, that I still might have some value in having that. So I'm kind of somewhat expecting that we might the bad, the badging won't put an end to the to the face. This is kind of where I am. I mean, you guys might say no, I know you're wrong. I think there's room for fusion in this to where to say to go to incubation, you need to have this set of badges at the same time to go to graduated you need to have another set of badges at the same time. And maybe we can even create, you know, a super, you know, call these project levels ranks, you know, you got incubating always going to keep it. You got graduated when you get graduated, you always have it. And then we could create this extra rank above it that have, you know, a certain set of badges above beyond the time and go. Maybe we have premier projects that have, you know, more and you got to renew that premiere every year. So you would need to change some of the expectation that these these ranks you have, you can lose premiere because you didn't keep your contributor decentralization up. You know, I think there's opportunity to kind of keep the care out from the projects if we, and then we need to figure you know what is coming on me like bonuses. I think there's room for this but I really think we need to get the foundation settle before we can really discuss some of these deeper possibilities. I think these are indeed the possible things that might happen down the line but yeah, this is interesting. Angelo has his hand up. Yeah, yeah. I must admit, I'm not an native speaker, English speaker so I don't see all the nonsense is the nuance between behind the wording. And the studies that there are different understandings of what's behind this, these words so to me, the word itself doesn't mean much as long as we have a clear definition written somewhere or what's behind this word. Now if it's active or graduate or any other word I don't mind I mean the if we change just the word but that we don't make the concept more clear. I mean we are not. What's the point of renaming the renaming variables I mean if the variable is still the same meaning. Either the meaning is not clear and therefore we have to write a better paragraph for for the meaning or otherwise, maybe I would agree that it's better to move to a solution that would deeper solution that will solve more problems like can be badges. Actually, even though I'm not very, I'm still, I didn't make my mind around that but I kind of agree that changing names and then proposing badging and do this and that I mean it probably can create more confusion that other things, but just my opinion. Thank you. All right now but I appreciate your input. Thank you. And just to answer one thing is, I agree with you that, you know, those things need to be defined anyway, no matter what term we use. And the thing is the problem today is there is no primary I think in terms of, you know, defining what active means the problem is people don't go to the definition to figure out what it means, they will infer some meaning just based on the name. And this is they will run with that in their head and talk about it with that kind of assumption base, you know, right. And what I'm trying to do is try to make it so that maybe for those people were not going to follow link and figure out okay what does it mean for project to be active or graduated that they would have a better or more likely, you know, a better understanding of what it might mean. That's all. But look, there's more things on the agenda. I appreciate the reactions and input from everybody. This is not, you know, I didn't expect a final decision on this. I just wanted to bring it up. I encourage other people to continue the discussion on the weekly page or in email whatever you prefer. And we can talk about it some more. Let it sink in and think about this. We have 15 minutes left. I wanted to touch on some other points that I got from this presentation that was given that is more food for thoughts. And it doesn't require us to make a decision per se, but it was really, you know, in keeping with so, you know, the crux of the presentation was very much like okay what are the things that a project like hyperledric and do to try to, you know, favor growing the community overall. And it's interesting because so they have very similar, you know, characteristics in some ways. So for instance, and there is a link to the charts I think you can access them. And the link on lessons learned from communities and see a CF point to the charts, and most of them I think self is explanatory for the most part. You know, there are things like I said, the number of phases there is quite similar. They also have this policy to allow competing projects to exist, let the market decide. And, and so there's quite a bit of similarity in some ways. They also have the situations where some projects are, you know, dominated by a single vendor. And I did mention in my email the GRPC case, which is highly popular, used everywhere. But, you know, Google is dominating GRPC and for that reason they're still incubation. And they're just being told that's how it is either you fix your community or you stay in incubation, which I thought was kind of interesting. But so, practically speaking though, they were in that presentation some tidbits that I thought, wow, this is really interesting. We really need to be aware of those things. We being hyperledger community and see if we can implement some of those, you know, activities within our own communities to try to improve and grow the community. So the first one was this idea of gamifying the issue triage. And the idea is to basically allow a broader set of people to contribute to, you know, prioritizing issues that are being tackled by the developers of a given project. And so there's different tools you can use for this. But fundamentally, it's like, you know, they have this triage party. There's a tool that was developed by Google, where you can have like, you know, the maintainers, they're sitting there and they go and they can vote and decide how, you know, what should be addressed as a priority over others. And this is done in a much more collaborative and dynamic way and also with input from the broader community. So instead of being just the maintainers decide, oh, this is what we're going to tackle next, you can say no, let's, you know, leave it to the community to vote on those issues and and try to sort out all the different issues. And then so I'll go through the different points that I wanted to raise. There's two main ones. So this was the first one. And the second one was to do with release manager. So they what they're trying to do is rotate the release manager. So within a given project, they tried to rotate the release manager, every word, every release. And in support of that, because what happens often right we most of our projects they have one, you know, dominating manager, and they typically are the release manager. And one of the reason I mean one of the ways to increase contribution from outside, you know, outsiders is to give them the control over the release. And in fact, it's interesting because it's not necessarily something that's that critical in terms of like, you know, it's not like a company is going to be necessarily worried about, or, you know, giving up control or, you know, polluting the code by, you know, that kind of stuff that sometimes people reluctant to to outside contribution. The release management is something very important obviously you need somebody who is dedicated to do the right thing. But at the same time, it's something that's fairly mechanical, and that you can actually train people to do. And so that's the other part, they have a shadow program where basically, they are making this effort, so that, you know, somebody who is interested in becoming a release manager, can volunteer to shadow the current release manager. So they go through a release cycle, maybe to depending on how they are comfortable, you know, taking over, and then the next release, they do it themselves. And this is a good way to bring all new people on board, making them part of the community. So I wanted to bring those things up. And ask, you know, if there are any reactions and this is the kind of ideas that I find refreshing and business school. Why can't we do this, you know, and we don't have to make that a policy I'm not talking about like you know making a decision at the TSC level saying yeah everybody should do gamify, you know, should give me find a solution to prioritization. I'm not talking about any of this. I'm really talking about like, hey, these are cool ideas, what do you guys think, and try to socialize them in a community, so that people can maybe be, you know, enticed to trying them out. Yeah. So, Daniel. I think it would be helpful, at least for the release process is to get our arms around. Who does the releases for each projects today is it one company always doing it they have a dedicated team, they share it around, you know, is their release process documented. Is it some magic checklist that exists in someone's head. So, even if, if we don't, you know, do this there's some stuff to learn about it that would I think help stabilize the projects because as far as release management goes let's say for example that, the idea gets out of software completely not going to happen. But you know can they still the project still live if other companies can release it. And that's the value I see, and having other contributors able to drive the release is what if the person who's got all the magic stuff in his mind, you know, which the industry that way if it's rotated around people, it increases the bus number from one. So, I totally support the idea of that, but what's on these things. All right, thank you. Any other reactions. And maybe, maybe there are projects that do this kind of stuff I don't know it also be, you know, it's kind of a prompt as well to others, you know, to everybody. I mean, to speak up if there are things like this you've been trying or thinking about that, maybe, you know, we would all benefit from using you know trying at least, I, you know, and I don't know how much of these actually works cost or any of this. But when I saw the presentation I was like, damn, this is really good interesting ideas, we should try that out. So that's why I wanted to bring it up. I don't see anybody raising their hands. Troy. I think sometimes these discussions based on previous decisions. We might forget that there are sub projects even though the TSC doesn't see them as sub projects and an official capacity. And I think what happens in some of the projects is there are different release managers for these different sub components. So I'm not entirely sure this ends up with only one company even within a project because some of these projects have multiple components to them. I agree but I think that the difference at that level to me is irrelevant because you make it at the repo level whatever you know there's always a point where you have some release manager and the same principle can be applied at that level. Same for issues and all right in fabric we have many different repos and you know we have issues are not all in the same bag right. So, you, you could imagine including implementing this kind of processes at the repo level. That's fine or sub project as you call it. So I think once you get specialized like that there might be less. I find this little bit in theory sometimes it's just when you have component breakdowns like that they're just isn't necessarily as much diversity at the so called sub project level as at the parent project level. So it's just a little more difficult. Okay. Nathan. There's something that's really a good thing to encourage and a good thing to promote, but it's, it can very easily cross and over into too much governance meaning too many rules or too many prescriptions that make it feel like to the developers there's just, there's more hoops to jump through than it's worth than it's worth the effort. And for most open source projects you want just enough governance and no more. The kind of less is more. And just because it's hard enough to keep track of the project itself, especially when you're working as a volunteer that if there's a lot of both work of the governance that's involved a lot of rules to follow. It gets to be too much really quickly. And that doesn't mean we shouldn't point to it and say this is a better way of doing it. And if you do it this way you'll have less problems and you can keep your governance smaller because it will go better for you. But I think if we start saying, here's the checklist that you have to follow, or, you know, if you if you can't stop and think about whether there's an exception to the rule here for instance, maybe you're in a sub project that doesn't have sufficient diversity for this to work. You know, you, you need to be able to think on your feet and apply these principles in an intelligent way. We don't want to just say do this or you don't qualify. If that makes sense. Yeah, no but and again I want to be very clear on this by no means proposing we make any of these things requirements or policies that need to be implemented across the board. They're really only meant as food for thoughts ideas. I mean, you know, you have to recognize that a lot of the reports from group from the projects, often call for help from the TSE to, you know, grow the community and so on bring new contributors and whatnot. And so I felt like a, here's some tips that you can take on, you know, in your own project and try to leverage this, maybe as a way to grow your community. So this is really what it's all about and nothing more I want to be clear on this, I agree with you. I think I wouldn't want to add extra burden in terms of governance requirements. David, and then we're going to close the call. Well I think this is great I mean bringing in good ideas from other projects is a really smart thing to do I think so thank you for sharing it and I think you know based on the comments it doesn't necessarily port over exactly like they're doing it there but I do think the idea of a shadow program, maybe for a range of different roles maybe beyond just the release manager or not even for the release manager does tie into things we've talked about in this call. But how do we, you know, foster more mentorship in the community so I think you know just the idea of a shadow program for any community role there might be is a good one so yeah I would encourage people to see how it might apply. So, and let's look at other, you know, things that are working well in other communities to bring in those ideas. Absolutely. And this is also what I mean, what I meant to do there is to say hey look, when you look around their ideas that can be worth leveraging for our own community so if you know beyond the lookout for other good ideas that we might bring up and maybe they don't get used that's okay but I still think it's interesting to bring them up. And that being said, thank you all for your participation. I'm going to close the call on this, and all of this is food for thoughts. I hope you'll find it useful. And we'll talk again next week. Bye.