Hiero TSC Meeting - 2026/08/11

Hello everybody. >> Great to see you all again. >> Hello. >> Welcome back. >> Nice. >> Hello. >> You look so refreshed. >> Oh, I am. >> You're you're looking fine as well. So let me open the agenda for today. Hendrickk, you're back. >> I'm back. >> We almost did not survive it without you. >> Oh my. Now I'm back to make some trouble. Cool. So, let me um share the agenda for today and I'm so with just coming out of vacation. I know at least one point that is missing on the agenda where I had um a discussion with with Keith and and Jeremy who's especially for that topic here today add it. So let me um let's see open get votes any other business. So I assume let's hope that we get into any other business. Um and um then we can have a look at your project proposal at at that point. Um >> somewhere else it could fit as a [clears throat] just just to make sure it gets done. Oh, I mean I mean those is so uh Jeremy for you since since I was on vacation this agenda has been created somehow by by other people. So I I have not created that that agenda and >> I agree that it should be done. We have some some git ws here. I assume um communication channels will be fast. Um maybe we put it but the election is important I think because it happens next month. So let's start now and um get fast through the points because I agree with you we should come to that topic today. >> Okay. >> And with that um welcome to the TSC call. Um happy to be here again. And um this is as any other call we do in the Hyro project an open call which means everybody can join this or any other call we do for Hyrole. Um we have a public calendar you find the link in our agenda. You find it on our web page or on GitHub where you easily can um register for a call, join a call by clicking on on the Zoom link and even watch recording or minutes of previous go um calls because our TSC calls and several others of the calls we do within the Hierro project are recorded so that you can have a wrap up of it later. Um since we try to be as open as possible and try to bring in especially here in the TSC calls not only the voice of the TSC but of the whole community um we ask everybody to bring in your thoughts your concerns your voice on on any topic. So if you want um just raise your hand here, unmute yourself and and join our discussions. Since we're doing this in a as open as possible way, we have some kind of guide rules which is the antitrust policy of the Linux Foundation and the code of conduct of the Linux Foundation. And with that, let's go to the agenda of today where um normally I start with a short overview of the last TSC call since I was not there at the last TSC call. Anybody here in the audience is willing to you know give a one or two minute overview of the last TSC call. If not, it's recorded and anybody of you can have a look at the recording. I will do it for sure for the two. I miss Jessica. >> Hi. Hey, welcome Henrik. >> Hey. >> Um, so yes, I mean just a quick overview of the last uh TSC meeting. Uh, we discussed the two git boats that are over there. So, we passed them. Uh, one of them was extended. The other one is still on. Um I think it it should be probably closed uh sometime this week or it probably is already closed but that was mostly the the communic the uh uh conversation and also we were discussing about rare evil which uh went excellent so I can give you more updates uh later so that I don't take up uh much time and last but not least uh we did had a little back and forth on communication channels and discussions of what works better with the community. So I added that as well just uh yeah for reference >> quest question for that would it be fine if we move that to the back so that we have for the project proposal we have today a bit okay perfect thank you Jessica >> yeah go ahead >> see Jeremy we get it somehow handled >> okay perfect so um as as you oh before we come to that um are there any updates or events somebody of you would like to highlight to talk about where Hyrule is a kind of topic any any news on updates on events from somebody of you >> not at the moment but um we're working we're working with uh Angie uh to do a workshop on code rabbit that is going to happen somewhere in and >> yeah in another workshop that is going to be for October which is going to be the same topic that we talked in rare evil on open governance and open source projects. So uh just uh I'll be providing as as we uh uh build these workshops uh one of them is in September the other one is in October so I'll let you guys know more. >> That's great. Sounds like one workshop each month. I I really like that. Okay, so next topic are open git votes. So I've seen we currently have two TSC votes for hips while one has a lot of things going on. I've seen Richard posted um on it. Ty um answered on it. So um I need to have a deeper look in into that. That's why I have not voted so far. Um um I assume this one needs to stay open um because a discussion is currently happening. And then we have a second one that just received four votes um and it has been opened two weeks ago. So um can anybody help me? Was there a discussion of that in the TSC meeting? why the vote is still open or have people just missed to vote so far and I need to to send a reminder to the TSC to to vote on that. What's what's the reason why we only have four votes here? >> I think it's just attendance. Um summer a lot of people are on vacation. That's why we redid the uh the other vote. It got three but they were all positive and it was just a timing >> thing. And then um Yeah, we can dig into the the conversation with Richard. Uh, but this this one I think is just Yeah. Um, having time to vote. >> Yep. Stoan. >> Yeah. Hey, um, can we also open a vote on heap 1522? That's the one I presented a couple of weeks ago, but we still haven't voted on it. >> Oh, sorry for that. First of all, um, and my assumption is, especially with now vacation and all that, >> Jessica, is there a way that we extend those two like for two additional weeks and create the ones to mentioned but directly make that one longer because of vacation? >> Yeah. Yeah, for sure. Um yeah, I'll let I think the the default time is two weeks, but uh uh I can Yeah, I mean we can extend it if we need to. >> But yeah, I I can create that and I'll extend these two. You want to extend it, right? The ones that are in the calendar. >> Yeah, I think it makes sense because I was, for example, I had not the chance to vote. I was on on vacation. I do not see any negative vote. So if if we would have negative votes, I would say like extending, you know, like changing the rules a little bit is problematic with negative votes. Since we only have positive votes so far, I think all of us are fine to to extend it. And >> can we do the other one the 15 the for the the new can you can you write it in the chat maybe? >> Yeah. Yeah, I'll say anything in the chat. >> Thank you. >> Thank you. Thank you. >> Okay. In regards to hip 1522, actually uh Stoyan, sorry I not got back to you. We've been reviewing that hip as a team and we actually have some suggestions on improvements for the hip. I'll try to get those into the the PR uh this week this week. >> Um but yeah, I I if I could request maybe we hold off on the vote until we get it into a a finalized shape. >> Okay. But uh in general on the TSC we only vote on the first couple of sections like whether the keep is a good idea and all the details we can iron out later but uh okay uh post the comments to the keep and I'll have a look. >> Okay thank you. >> Okay perfect thank you all. So as as we said we will move the discussion about um communication channels a little to the back and now SDK concerns with maintainer activity by Diane. No Danielle not Diane. Um D. Oh, Danielle. Danielle, you are here. Um, so you you added something to the um agenda. >> Oh, I but um >> Oh, sorry. Okay, Jessica, go forward. >> Oh, no, no. I I But uh yeah, it's Danielle's topic. [laughter] >> Okay. Yeah, because this agenda, you know, I have not created it. So, at some points, I have no idea like this one or the next one. I have no idea what's behind that. Um okay so explain it to us. >> Uh yeah so uh we had a maintainer meeting last week and um we were taking a look at different reports. So uh in the analytics we go to see that uh yes this issue has been there but there are some uh urgent stuffs that need to be taken care of in different repositories where some maintainers are not active. For example we had a current had an incident of the of the runners uh and it's still happening. So some SDKs uh need like agent support and uh so if there is anyone or anyone who who can do that please cuz for example the swift SDK cuz when you go to all the workflows they are not like uh someone not working so please there is anyone who can do that help us >> I think I' I've seen it that something has been created I'm I believe you're talking about uh where was it? Where was it? Uh >> what's above >> above? Um somewhere there's an analytics about how many maintainers that have not done any activity with >> you. You have >> oh we have active maintainers and active maintainers. Is it like this? >> Yeah. >> So but what is what is maintainers and active maintainers mean? I have not looked deeply into that. I cannot believe that we only have eight maintainers. So I know for some of them there are mods. So um one month so I what are let me see repos where most one maintainer has been active in the selected period maintainers in the total. >> Yeah. Can yeah um you want to say something? I think that's not the the one the one I think it Oh, it's Yeah, I think that is the one. Yeah. >> How many maintainers, committers, and triage holded? Okay, let's see. All time repos SDK. We have nine maintainers. So this is the DI FDK for example where we have nine maintainers, two committers but only two active which means like the number looks high but there are not so many active. Let's have a look for something else. Go to the let's see like the C++ SDK three maintainers one commit and six active. uh because of the triage people. Okay. Okay. So, a lot of triage people are not active anymore. Do we have and I see Sophie is here and and I think she created a lot of this. Do we have a list where I say like see like maintainers active maintainers commits active m uh committers and and so on >> or a repo? >> Yeah. >> Uh not yet. I think it's just active maintainers. Uh okay okay okay and oh here and and the concern is so what is actually concern with the high SDK swift we have three maintainers but only one of them is active is is that the the concern >> all the data as well so if you want to look at like in the last month maybe this those figures will sort of change. >> Yeah. Yeah. Okay. That's what these time filters are for to help you see active within [clears throat] >> active with. Okay, this is act. So now I see how many maintainers are defined in the last month and how many of them have been active. >> Yeah. >> Okay. But for commits and triage I do not have but the two kum. So I do not have committers and active commits or triage and active triage. Right. >> No. >> Okay. Now, now I understand what I'm seeing here. Okay. And and we are saying, okay, we have some projects where we have um Yeah. Okay. Where we have some maintainers but not that much activity. And this is something I think Keith brought it up a month ago maybe here on on on the TSC and we had some internal discussions with internal I mean not in this meeting but um like I had some discussions with with people from chain who are maintainers. I had some discussment with with keys because we got aware of exactly um those problems and um already discussed how can we solve it? How can we um get more maintainers especially have maintainers in the project. if people who are working for a company are leaving that company and are not interested anymore and contribute to the project. So let's assume somebody is um an employee at at Hashcraft or at Rime Chain or whatever and works for two years on let's just take one let's take the hierohhedium just as a random example right and then that person leaves the company gets a not new job whatever and is not interested um work in his or her free time on the hierro project which is totally fine which means that person becomes an inactive maintainer and what we as a community need to make sure is that we have within the maintainers a high diversity so that something like that cannot become a bottleneck for us and I think and this is just a fact right so you realize things like that often when they happen for the first time and and that was what happened kind kind of a months ago because what you can see is that some of the people who worked on the SDKs stopped working on the SDKs because they changed job which is normal right can happen to everybody of us isn't something bad and um we realized and learned out of that yes it's a problem and yes we need to get more diversity to keep the active maintainers up and not um having a situation just because one or two people are leaving a company leaving a job the active maintainers go down like that. That is what we've already um seen and and we had a lot of this discussion and even um a lot of internal teaching regarding what are the roots we are in um what does it mean to be a maintainer to become a maintainer that was not even uh or what means not even that was not not clear to to anybody and we realized um a lot about that and I Keith Keith agrees that that we put that as a as an priority topic for us and we currently have people who contribute to those repositories with a clear goal to become permit us in near future. We do not want to get them directly maintain us because that would be totally against our roots and what we want to do, right? But we feel it and now invest into people to become committers as soon as possible so that we can close this bottleneck. Diane, >> so um what the the other thing um that was while you were away um and I'm not sure which which session it was somebody mentioned that um in the maintainers meeting the bi-weekly or monthly meeting uh there is no attend there's no attendance and so I think um one of the things we really need is to get um those folks who are active maintainers showing up for the maintainer meeting that is um a huge hole in order to build this community and figure out what it is um that's that's going wrong with all you know besides people leaving jobs we really need to get um I don't want to say mandatory but um uh some some there are you know there's Angie and Jessica were the only attendees at the maintainer meeting the prior week I think Daniel might have come to one but it's really not um it's not happening and um I don't know if if we can nudge the um from management the maintainers or Keith can nudge them to show up for that meeting so that they can have these conversations. Um it but that's really important. We can we can give them all the um love and things that we we want but um if they don't show up we can't help them. Sophie. >> Yeah, I think um I think we have documentation for general expectations for qualifying to be proposed to be like a committer or a maintainer. >> Yeah. >> Um I think those are more time based. So roughly three months for a committer, six monthsainer is a is a general rule rule of thumb. making some significant contributions and things, but I I think last time we looked at that document may have been a while back. Um, but having something like that's more sort of concrete and more sort of diverse and the things that we we look for, just having that on paper could also be really valuable. Um, in terms of the pipeline of triage and committers and maintainers in the Python SDK, I don't really have a very clear objective criteria. Let's say there's a few people who would be over the three months and the six months, but I personally feel that maybe, you know, they they don't yet sort of satisfy certain requirements. But but this this is sort of my my sort of individual judgment and I think I would really go with kind of Dian's perspective here that if you are going to be um like leading a repo, it would be great or maybe even expected for you to be attending some of the community calls relating to that. Um, and that's also maybe why I would hesitate to accept a lot of like emergency policies to install new maintainers maybe in the SDKs if they if they require it because the emergency policies I think might not prioritize the the broad goals and the broad sort of role expect we might end up with a similar problem just further down the line. Yeah, I I agree with with with everything you said. Absolutely. And I think it makes sense. So, we wrote the um maintainer and committer definition before we had the meetings. So, it talks about reasonable contribution. It talks about it's more just being commit. You need to take care about the community and so on. But since we now have those meetings, it would make sense to update the description of maintainers and committers to make clear like hey as a maintainer or a committer we ex or it's expected that you attend the project open project calls if possible. I mean it's not that you use your your committer or maintainer or if you're in vocation or just cannot make it because of of your job or whatever right but if possible you should join those meetings and for the maintainers we should make clear if possible you need to be part of the maintainer calls. I I think that's a good point. Um, we had I know Keith um worked on an addition about the um what what you just mentioned Sophie about this um emergency changes. I think that makes sense too. Um what I do not want is that those are used to you know like replace people. somebody from company A is leaving the job and then company A just puts in a person who never contributed to it as a new maintainer. That is not where we want to use those roots for. I think that is clear to everybody and and I totally agree that today we do not have any roots. What to do if out all of the sudden a project has no active maintainer anymore and we should have roots for that but those should go hand inhand with everything else and making the maintainer and committer definition more clear and take care about the meetings and take care about diversity. I think all those are very good next steps. Sophie, >> yeah, I think um you know this this raises the question once again. I know we've talked about it in the past and I know it's a difficult problem to solve and we need more automations, but that that does circle back to so if you if you scroll your way up to the top um Hendrick. >> Oh, sorry. [laughter] Uh >> like top of the file file. Yeah. And then this one here >> I I was able to add um so this chart's a little bit I want to change some of it but >> oh sorry about it. >> Basically >> you want >> okay >> is that >> what what do we see here? So can you >> yeah these these are currently open issues. So for example if you were to look at the C++ you're going to see 53 open issues. >> Okay. Okay. block node, you're going to see 453 roughly. And out of those currently open issues of of all time. Out of those issues, which ones have been uh split by difficulty? So green means good first issues. Uh the blue one is beginner issue, yellow is intermediate, and the pink red one is advanced. Um and I I think maybe this is why the C++ you said has a lot of triage and committers because um you know they've been able to on board through the good first issues through the beginner issues. Um but that might also like help to like you know highlight how there's going to be a pipeline problem in terms of training new maintainers. >> These are Yeah. Yeah. So there there are some repos that are not participating or um at least even in the Python SDK we don't have that many good first issues anymore. >> Yeah. Yeah. >> As well. So yeah that that that's it from from me. >> Yeah. Okay. Yeah. Make all sense. Um so I I think um I haven't looked into my calendar but my assumption is somehow the next two weeks Sophie Jessica and I have a meeting um and my idea is should we put for ourselves updating the maintainer and committer definitions on like the three of us do it create a PR and then everybody can can We view it and we bring in Sophie all the points you just mentioned into it. Perfect. Jessica, can you can you put it on our to-do list? >> Yeah, for sure. >> Perfect. That's that's great. Cool. Um, thank you. Um, okay. We have still half an hour. I think we're good. Good in time. Oh, Keith, >> just one quick comment. I I do understand like people don't accept attend the attend a maintainer meeting. I I don't attend a maintainer meeting either. I have to not have a lot of conflicts with that meeting. I would say that like if you want more people to attend like doing things like an agenda, having a like I don't think people just want to attend a random meeting that just talks about random things about random projects. I think that's the problem with that meeting. If there's a clear agenda with topics that maintainers need to discuss, I can see that like you'll get better more attendance. >> Thank you, Keith. Yeah, we we had the agendas going on. Uh you can see on the uh right side of the cursor of Hrik, but um but unfortunately yeah that didn't work [laughter] and I Joseph is brought up a good point where um it conflicts internally. So, for now, I just move it to 10 a.m. Pacific because there's other other calls that are on the same day, but that is just a placeholder. Uh Henrik, if you can help me get the input of what day and what time works best for the maintainers in general, that will be great. >> My my problem is so what I and I in general I agree with with Joseph wrote in the chat, right? So ju just for people watching the recording, Joseph wrote like, "Yeah, many maintainers have like time conflicts because there are internal meetings in hashcraft or lime chain or there are team meetings at the same time and so on." And my problem is like if a team let's say like the um people in hashcraft and or lime shame working at blog node have a meeting, I do not see that in my calendar. So I'm I do not have like an overview about what would be the best time frame based on on on team meetings otherwise I would directly tell you a date but actually I I have no idea how to do that. Um that's what I can tell you. Maybe somebody um especially from the people here being from from Hashgraph has a good idea. Um happy to do so then. Um but that was that is my problem here. And Keith are you have a new hands up or have you not done hands down? >> I I would just say there will never be a good time. Mornings are impossible. I would just say like if there's an if there's an agenda that's compelling, people will make time. if it's just like a random meeting on their calendar with like no agenda, they don't know what's going on. Yeah. Don't expect people to attend it. >> Okay. So, let's try to improve the agenda and share it up front and try if that helps and and see if that helps. >> Yeah. The other thing is that I also request maintainers to bring in topics. Uh but yeah, I mean that is a different topic of discussion where in email or discord I get absolutely no replies. Yeah. >> So it's very hard to come up with topics just by myself. >> Yeah. Yeah. Yeah. We maybe another item for the Jessica Sophie Henrik meeting. >> Okay. >> To come up with a good idea agenda. Okay. Great. Um next is Hyru process by Sophie and Angie. What's behind that? So we created a PR in the TCK initially. Um we requested a review from Keith and Michael and uh from you Hendrickk as well whenever you have a moment. We are trying to think of a more automated way to kind of track uh the hip implementations. One idea that was brought up uh came from either Keith or Michael. I can't remember who specifically, but they had suggested to use uh the TCK test spec as a way to kind of track the hip implementations. So Sophie and I kind of went ahead, we made a PR. Uh the issue that we started running into is the way kind of how things are accounted for. For example, 1261 isn't just uh comprising of one service. It's not just a token service. It's it's a fee estimator. So it naturally will involve the consensus service, the token service um more or less most of the services. So in this regard what ends up happening is when you create markdowns and you have it spanned across all these services, it doesn't necessarily create that accurate of a representation based on the testing alone. Uh the way that it also reads is kind of a bit confusing in the sense that implemented uh to one person could mean that the hip is implemented or it could just mean that there is a kind of test in place for it but doesn't actually necessarily indicate that the whole hip of its entirety has been implemented across SDKs. Uh so the thing that we are kind of bouncing around with. So we uh made a amended a commit to this. So she did go ahead and tried to take out uh a good majority. She was able to pro remove uh 80% of the manual overhead, but it's just kind of that 20% that we're still um going around about trying to figure out what would be the best way forward and how can we track this accurately. So the other idea that we have come up with uh that we were speaking about earlier before this meeting was having individual um what you call project boards. So for example we have the project board currently project board 46 that does do a lot of the hip tracking. It does it across SDKs, Python, Rush, Go, Swift, what have you. And then from there it just kind of gives you the most accurate representation of a yes or no. Is this secure? Is this not here? So the issue however that we are running in with that board is again this is a lot of manual overhead. There's not really a clear way to automate it and with machine learning some of time some of the times you need a kind of pattern so to speak just so you have a clear way of going and and the AI tool kind of knows what to follow. So from this point and everything that we've gone through so far, we've come up with another idea of having individual hip boards based on each kind of repository. So one for consensus, mirror node, python, SDK, rust. Uh so ideally or should I say uh conceptually this would be about 10 to 12 boards. This is going off off of basically what we already know in the sense that we already know it's in consensus. We already know hips are in mirror node and we already know that they need to be implemented for the SDKs. This does not culminate yet the did SDKs as we're still kind of unsure the entire hit process of that and if they follow the same kind of specifications but for the moment we've come to this idea of having individual boards that kind of would be manually or not manually updated sorry would be automatically updated given the respective PR or issue that is being linked to that board but we are open to feedback Uh we do ask to please leave a review, any suggestions. If you have an idea, uh please let us know. We are kind of bouncing ideas back and forth trying to figure out what would be the best way forward. Um Sophie, I don't know if I'm missing anything from there or if there's anything you want to add to that. Yeah, I think the the the key thing to emphasize is we are not going to have a automated way of easily tracking and accurately tracking hips until we can get each repo to probably mark their own progress or being helped to mark their own progress. Um, so I think as a TSC it would be good to get a sense of how valuable do you guys see as tracking hips uh and the completion rates and stuff and is that something that you would want to sort of recommend as a best practice for the the repos in Hierro to sort of try and stay up to date and stay communicating on how the hips are going in your repo. I have I have one question. The reporting that is created by by this pull request that you added, is there somewhere uh a sample how how it looks like? Um we don't yet have the infrastructure to actually calculate what hips would be completed for now. This would be a pull request that would create like the front matter to be able to do that. But there's >> okay the separate pull request >> and there's someies that have to be pushed into that first as well. >> Yeah. Yeah. Because for me um so I I like the idea right and and I like the direction it goes. My program now would be okay here's somehow uh uh a hip report ts a hip report JSON and I would really like to see what's the outcome like um okay we now have a report script that can somehow be executed and and generates reports about hips and for me the review of this and and and moving it forward would be way more easy if and even if it's just attached here as uh I'm oh actually I'm not oh I was too long not uh on on on GitHub um actually if if you um just add it as oh here's a PDF or here's a picture on how it looks that would be good enough right but just to have the idea how those those reports that that are generated are look like I think that is that that would be a um addition to it to to move it forward. That that's my point of view here. I don't know. I see Michael Gaba is is here. Do you have any any any thoughts on it? Do you see any any problems? >> Uh I I don't see any problems currently. Um but I would I would need some time to get into >> Yeah, that's fine. Absolutely. Okay, cool. So um um in that case Angie and and Sophie if you would be able to add an example to it to understand what the output look like I I think that that would be super beneficial here. >> Yeah not a bad one. Um Michael quick question for you Michael if uh if you have a moment could we please have a link to that PowerPoint presentation you had done back on July 7th? We're making a blog post and we had wanted to feature the presentation. If you don't want it featured or if it's private, please just let me know. That's not a problem at all. We just weren't sure of the direction you wanted to go with that and if you wanted to make that public. >> Yeah, I can I can send it to you. Um I'll DM you on Slack. >> Okay. Uh I don't have Slack. I tried to reach you in Discord. I hope that's okay. >> Or send it to me and I will forward it. We that's yeah um >> thank you >> we will make you and she get it for for the blog that is great thank you first of all for taking so much care about the blog and and bringing things like that to to the blog as as posts that's really great so since we have only 15 minutes left and we have the elections and the open project proposal is it fine for everybody if we cut that topic here. And Jessica, you talk five minutes about the elections. Will that be enough time for you? And then >> Perfect. And then we have 10 minutes. Um Keith and and Jeremy for the project proposal. Will that be fine for you? >> Yes. >> Okay, perfect. Good. So Jessica, go forward. >> Yeah. Could you click on that link for anybody that I I don't I do not >> I do not click on random links, you know. I have no [laughter] idea what happens. And >> it's not a scam. Don't worry. >> Okay, good. >> So, that link uh that information for September 2026 elections has been updated with the timeline and everything. So, I send the email to all the TSC members and just uh for them to give me feedback on how does this look like. But this is basically how it's going to happen. The nomination period starts on the August 25th uh at the start of the day and then it goes until September 8th and the election uh then after that uh the election time will be from September 8th on September 20th and the announcement of the TSC member winners will be on September 22nd. So there's um uh two three different positions. So there's two maintainer seats that correct me if I'm wrong, Henrik, but these two maintainer seats are voted by all maintainers and the TSC voted seat is a position that gets voted by the TSC members. Is that still the case? >> Okay, >> it's fine. I know. Yes. >> Okay. So yeah, this is the information and yeah, I mean we will be talking more about it as the time approaches, but if you if you want to remember how to nominate a candidate or prepare your nomination, there's the information over there and a sample, it includes also a sample of how to nominate people and more information on who's allowed to vote and how how to vote. So all of these will be clarified a little bit uh in more detail as time approaches. But yeah, for now I just wanted to let people know that this is up and announced. >> And Jessica, do we know um I know we had a discussion before I left to vacation. So >> um hope uh it's solved now otherwise uh we should solve it within the week. Do we know who are currently on those three seats? >> Yes. So one is yours, the other one is um Richard's position and Stoyan's uh position. >> Okay. So it's like Richard Stoan and me. >> Yes. >> To if they want to stay on the TSC need somehow between that phase um >> self-nominate themsel or >> which is totally fine just to say it, right? So self-nomination is absolutely not a problem here to self-nominate themsel or get nominated by by somebody because those receipts are the seats we will do the elections for. >> Exactly. Exactly. And yeah as you say people can nominate theirelves or can get somebody else to nominate them. So yes uh it's open for everybody. just uh double check the uh the links below, the information below on who's allowed to run, etc., etc., and who's allowed to vote. >> Yeah, thank you so much. >> Any any questions on that from anybody? >> Okay, good. With that, um Jeremy and Keith, um the stage is yours. Should I just open the um the issue or do you want to share a screen? What's your How do you prefer? >> It's fine. You can just open or or I can open. It doesn't matter. Henry. >> Yeah. Let me just find it. Here we go. That one. >> Yeah. So, may I start and then maybe Jeremy can uh who's the can help with this. So, um you know, my for those who don't know, my name is Keith. I'm a product manager at Hashgraph. Um, and in particular, this is about the Solo project. For those of you who have not tried it yet, Solo is our um, basically you can do a local build of a Hyro network to do things like testing or validation. Um, and this is a product that we've been building out for quite a while. And one of our new needs around this product is that we are requesting today to set up five new repos. Maybe you can just go down a little bit, Hendrickk. Um yeah here five new repos. These are the repository names. Um all of these are around uh uh repos to support solo actions. Um and also as part of this we want we actually have some existing solo migrations. Just go down a little bit more. Uh Hendrickk. Um we want to migrate some of our existing uh solo actions from the hashgraph repo into these new repos. So that's that's basically the the the summary of the requesting five new repos to support solo actions. And maybe we can just talk us about why we need five new repos because actually we want to list these in the Google marketplace and the Google marketplace requires that they are each their own project. So that's a big driver for why we need five repos. Um and then the migration. Jeremy, maybe you want to add anything else to that. >> Yeah, just a couple notes there. So, uh GitHub marketplace I think is a is a mism missed thing. He you mentioned Google, but it's GitHub marketplace. Um and then the other thing is is that those other two at the bottom, they're not actually actions. So what happens is the solo CLI or solo X depending on what terminology solo CLI is what we call it now because there's solo operator solo provisioner etc. So, Solo uh or Solo CLI, it uses um some Docker container images where we built our own and those are really for the uh consensus node, but um we kind of built them originally. Uh and so that's in the hashgraph/solo containers repo. We made it public, but we didn't finish the migration to hierro last year. So, this is just to finish the migration under Hierro ledger. And then the solo charts is where we're storing the helm charts uh for solo which a portion of that is for deploying the consensus node. Um and so that's in hashgraph/solocharts and that needs to be relocated to hierleddger solo charts to finish that migration. Uh both of those were private but we we managed to make them public but we just didn't finish the full migration um last year. the five um build actions I is what what our concept is is where where um we have a a solo TCK that we're working on uh they're designed for and so we essentially would have these build actions that can go that would might be used in that use case but additionally uh we already have cases where the like for for various projects uh there's complexities involved about how do they for example do a block node build and inject that in solo uh consensus node's a little bit easier because they just like they can just say like here I did the B build and here's the jars and push it but with block node mirror node mirror node explorer and JSON RBC relay is more complicated because they're using Helm charts and they're using docker images and they're building their source code then they're doing the docker build and then they're pushing and then they're and then they're making the updates inside the helm chart to do overwrites to pull those and so it's a lot more complex and so Nathan suggested and I was completely aligned with it is to just let's take it and and abstract that from them. So all they do is call GitHub action it bundles them and injects it straight into the silo cluster as it's standing up the cluster. So that's what this is for. Um the the use cases there's there's not only is it for the team that's doing it but like in the example of like the consensus node and the block node then the block node team might be doing their build but they also need the latest version of the consensus node to integrate. So they'll do maybe using both those actions and then expanding those use cases. You might have people building DAPs or other partner companies uh where they maybe actually requested a feature and so we're maybe like this would allow us to work with them so that they can use our latest version inject it into solo and they could test their app to verify that we're all on the same page or if they could see maybe some bugs before we ever pushed it to main you know those sorts of things. lots of use cases. Um, but there's GitHub constraints around it needs each each one needs to be inside of its own repo and thus the the spam of repos. >> Yeah, I I have a question Jeremy. It's um maybe you So, first of all, I think it all all makes sense. Um what I do not understand is the for the actions let's say like um the consensus node action as an example. So is this can I with that only and not in a negative way right only um for an integration test set up a consensus note and run against it or is that an action that uses solo? So each of that action sets up a full solo network. But with the solo build consensus node action I can parameize what version of consensus node should be used. So so I'm I'm just trying to understand um >> you're trying to understand like the actual flow. >> Yes. Exactly. Thank you. >> Yeah. Yeah. I mean uh I know we don't have a lot of time but let me I can summarize it real quickly. So >> yeah. Yeah. Yeah, that's totally fine. It's just for >> So there's two there's there's two main paths that we're looking at. Um and so one of the paths is is that um they they basically are responsible for standing up their own network. And so they would either use one solo oneshot falcon uh to do that for them and then they would supply like the um the consensus node they would use like a local build path under certain types of calls or if they're using like the block node mirror node and any of the other ones then there's like a uh chart directory uh override flag that you would provide into that. Um the other so that that's like one particular flow uh using like oneshot falcon or the stepbystep guide. Um the other flow is is that uh and this was something to take more offline with you u uh specifically is uh the g the this the har solo action. So, we want to uh at some point um and then we think we're ready for that uh to to have the solo team, you know, work uh more as developers on that um and building up um there's there's the the solo action is a bit behind um and it needs some some work. I think somebody had opened a PR to start the work, but then it never got merged and it fell behind. Um, and so we would look at doing that and what under that vision what it would look like is is that you basically call like one of these build actions and then that basically gets handed into the Haru solo action which takes it the rest. >> That would be awesome. Okay. Yeah. Yeah. Okay. So it's like you take one or x of those which set ups in the um in the runtime environment all the spec specific docker components shots whatever and if you then code soro those I use that is the idea right >> yeah so these are basically doing all building and prepping to do the handoff essentially >> cool yeah that that sounds cool I like it Yeah. Yeah. So, um normally we do like something like this, have a presentation and then do the vote the week afterwards. And when I look here at the list, I think we even do not have um chorum here. um question um for the two of you like um Keith and and Jeremy. Is it like um um needed as fast as possible? Um, or is it totally fine for you to say like, "Okay, we come back next week and if nobody had any questions after maybe having a deeper look into it or, you know, like thinking another day about it, we vote on it next week and and get it in because the other thing would be we could do an asynchronous vote if you say, "Oh, best would be to have it in yesterday because we have a concrete scenario that is going to work." >> Yeah. My my preference would be the asynchronous because the the the solo container and the solo charts is being done by uh the release engineering team and they currently have bandwidth but as we get closer to September and October they their bandwidth starts shrinking. Um yeah and and then these other actions we we my my team um we're basically plowing through work pretty fast and I and this unlocks a lot of work and prevents us from working on Q4 work and pulling that forward when we still have Q3 work that's just blocked and so >> Yeah. Yeah. Yeah. Yeah. Makes sense. So um which means we set up an asynchronous vote um for for that project proposal which means um in best case um it's done tomorrow or in two days when people had time to look at it and vote. >> Okay. >> And once I get a feedback on it um I will ping you and I will I mean you can even um follow it. I think I think Jessica, we can do the vote just here in this issue, don't we? >> Uh I think we've done it before. Yeah. >> Yeah. I'm I'm I'm not logged in. Can you maybe just do it? >> Yeah. Yeah. Let me let me check. I think I think we should be able to do >> Yeah. Because I think it must be an issue and this is an issue. So I assume we can just do it in in that one and and start it directly and people can start to vote. >> Can you for sure? Yeah. Yeah. Yeah, I'm working on it. >> Fast, fast, quick. >> Here we go. >> Thank you. >> I'm still in vacation mode. I can't do fast. [laughter] Okay, let's see. Yeah, I think uh it uh it opened the boat. >> I still don't see it. >> Really? Did I post it in the wrong way? [laughter] I I see it on mine. >> Oh, now I see it. Yeah. >> Oh, yeah. There you go. >> So So V. So Jeremy for you, maybe you have not seen it. So uses get vote to and um now the people from from the TSC can vote on on this issue. And what I'm now doing it I copy it and send it directly into the TSC channel so that um the people can vote on it. new adding vote. >> H uh >> yeah, we we we use this uh in that uh governance with when we do the uh update the um the maintainer committer YAML whatever that thing is called. Yeah. So config yl whatever. >> Uh oh yeah yeah from there you know it. Yeah. Yeah. Perfectly. So let's let's see if we get this to as soon as possible. Um yep good. Um with that we're one minute over time but we got everything we had for today um discussed. Um thanks you all for for being here and see you all again next week then. >> Thank you. >> Thank you. See you. Bye. >> Thanks. Bye.