LF Decentralized Trust TAC Meeting - 2026/08/27

You're good to go. >> Hello everyone. Welcome to Linux Foundation decentralized trust technical advisory council meeting on August 27, 2026. Before we get started, a couple of reminders for us. The first one is antitrust policy. This is a reminder that we have participation from across several organizations and we request everyone to abide by um these laws. The second one is on welcoming everyone. So we do have because of the diversity we have we will um request everyone on this call to be respectful of each other. If you have any comments or anything to say, please feel free to raise your hand. With that, moving to the announcement section. We do have a developer newsletter that goes out to large developer community every week. And if you haven't already used it, this is a great forum for you to communicate about your project. ask for um participation or maybe requesting for comments involving within the project. Could be pull review request, could be announcement of releases. This is excellent forum and um all you have to do is click the wiki link that is listed on the meeting agenda and u leave a comment on the wiki. It will be picked up. And the second announcement we have today is the nominations for the pack elections the for next term which is 26 27 is open or like will open soon. Um um the nominations will be sometime in October. I mean the elections will start soon after that. And uh this is a request to tack members and um community members to nominate yourself or identify those who you think uh would be best represented in the tag. Okay. So with that moving to the next section [clears throat] we um we do have a annual report to be responded back by the project team and um this is just for everyone's awareness that um similar is I mean this request was also raised in one of the recent um leadership meetings and there has been followup talk with the project team. We'll learn more as we hear from the project and having said that I know couple of projects with one is on the Mapova and the other one is smooth. Um we do see participation from the project team but it's it has been hard for us to get a response from the project team. um or like even report in case of Minor for instance and um just wanted to let the fact know that um per the governance policies there is an option where TA can initiate um a stricter action if needed I would say or T can initiate talks asking project team um that they may or if they're not meeting the current standards for uh graduated project status be it in incubation phase. Any thoughts from anyone um on these two projects or any recommendations on how do we proceed? Matthew. >> Hey Arin. Um, yeah, I guess I guess this has kind of come up a few times for some kind of projects and some reviews. Um and I think partly relates to some discussions we've had about different project [clears throat] life cycle status. Um I think quite a lot of quite a lot of uh discussion time on the calls tends to be around kind of um uh questions about reports or delayed reports or or comments on reports not being kind of um uh answered in a timely fashion. Um, but it's really hard it's really hard to to push on some of those discussions or push on some of those issues with maintainers or projects um without having a kind of a clear path to what what kind of happens if reports aren't completed in time. don't I don't think there is a particularly clear path um uh in in TAC projects for for what happens what happens when that's the case and that's maybe because it's not too not too often that that's been the case but I do wonder if it would help if we formalized what what happens and then it's not so much a a chase and then now kind of process as much as a you know just communicating with the community is there's a clearly defined process where reports aren't aren't aren't received or or aren't mergeable within a given period of time and here's here's what happens and maybe it's a maybe it is a status in project life cycle which isn't going back to incubating which again I think we've talked about is a slightly unusual step to say well it's kind of going back to incubating it's not really that but I do wonder if there's there's a link here with the the life cycle states for for projects but I think I'll pause there because Hendrick's got his hand Yeah. Uh totally agree on on most what you said and I assume that there is no process so far. um happily shows that there was that problem not in the past which first of all is good right but um I believe that we should now create a process because you know like we could even wait three more months and we've seen with with the past that or we assume that no change will happen here. So maybe thinking now about how how a process could look like and and defining that process would would totally make sense before we do anything. Right? So first we need to define the process and agree on the process and have it written down somewhere and and then we can take action on on that case. And why I agree like bringing something back into incubation maybe um is is not the thing. Another thing we could do is move it to reps. So instead of having it directly in the RFDT, move it to to RFDT reps just to have another um thought about what what could be done. And since you have hands up again, give him back to you. Um, yeah, I think I agree with both. I think we need process in place. I do think that the process should include something like a three strikes out type of model where the ways we've communicated with them or recorded somewhere. So regardless if it's Arun reaching out on Discord in a private message or public channel, I feel like we need a place where the warnings have been accumulating over time and it's not just a TAC call. There's an actual verbal like question to the maintainers, a reach out etc. where we've actually showed the evidence that we've tried to get these reviews through that we tried to reach out and then that gives us a conclusive um like paper trail in an open like discussion on GitHub or somewhere like an issue somewhere that gives us the ability to make a decision based on that paper trail. So I feel like it's very easy to say, "Yeah, yeah, yeah, we we already told them." And then we go through multiple rounds of weeks of meetings and we have that in the back of our heads, but we never realize the whole paper trail has happened maybe over a year, over two years when we've been reviewing these projects. So I feel like we don't have a place where we have a continuous paper trail of these of projects that across years and across reviews. >> Yeah. the um the um like I said that the kind of idea of three structures and you're out. The problem is I don't even know what out is yet. >> I don't think it necessarily has to be out. >> Yeah. >> In the strictest sense, but I think I think it there has to be a three strikes and something happens. And it's nicely clearly defined. Um and and I agree with Hendrickk that that defining that first is probably more important than exactly what we do these particular projects. Um Marcus, you got your hand up. >> Yeah. So I think I mean we have some kind of process already defined. I mean in the definition of the dormant state uh which would be the one which would be the next thing for smooth maybe I don't know there we clearly defined that everyone can suggest a state change uh for a project into dormant and then the corresponding parties they can basically uh let's say um object or I mean start a discuss discussion towards the tech uh and say something about that and then the tech can decide uh well if that's a proper I mean if that's a proper case to put a project into dormant or not and but yeah I agree u with what he was said we don't really have a formal checklist where we say okay three times no answer then well then you're out or whatever right I agree with that but uh I mean we we could have I mean in this particular example here someone could say well we propose to move the project to dormant well that should be recognized by the maintainers they could say no no no we don't want to do that we are active now or if they don't um communicate I mean if they don't react on that well then the tech could say well I mean this project must be dominant because nobody cares because we were proposing it right and then it's kind of dead anyway Okay. Um maybe Rama >> I I do see we have that clause written up here. Uh I think in the past we've u our test for dormcancy has been u inactivity of the project rather than just not responding to the responding to the TAC. Um I I just looked at Mininoava and it seems to be fairly active. Uh but for whatever reason they're they've just not responded to the TSC members. Uh I see Marcus you you messaged them about a week ago on the uh Discord channel but there was no acknowledgement of that. So yeah I'm not sure I think for project like this do they do the maintainers even know that they're supposed to be submitting these uh uh reports? Uh I looked in the repository. I don't see a maintenance file there either. So yeah, I don't know bunch of things that are at least process wise they're not fulfilling their duties. So it seems to be an active project. >> Thanks. Yeah. Yeah. I mean, so yeah, I think um so I think Arin and and Sean, you've kind of pasted in the the definition of, you know, what happens. Um so in some respects, I kind of think I think the the answers to what we do with these projects is is just automatically following that policy. Um if we if we think either of them meet th those criteria about not submitting within two months or not responding within 3 weeks, I think I think we know what we're doing. And if if they they have then um you know they've responded to comments and we're still going a bit to and fro on it that's fine. But did did does uh does SMO meet this does Mau meet this this um criteria for being moved to Dorman? Right. So, um I know there was an active thread on discord channel um where [clears throat] David recently mentioned that he would reach out to project maintainers through email like outside of the regular channels that we use. Um, does the staff have any updates or do we want to wait for some more time before we take an action? >> We did reach out to Smoot. We sent an email and we are going to have a call with them. So, we haven't had that call yet. But I think in general my approach is that I like the direction of this conversation. You know, I think there's a larger issue. It's not just we have to think if it's not just the maintainer not responding to attack. I'd also be concerned is this non-responsiveness reaching out to people in the community. So I do think you know that's part of it too. If we look and see for example that there aren't any responses in the project's channels. I think that's also part of it. Like I looked at the Smoot channel on Discord and I don't think there's been any activity from my maintainer in a year. Right. So I think you know if one thing for the TAC to consider again is this responsiveness just not responding to the attack or is it not responding in general in the project and that would could feed into the discussion about if if it's dormant or if it moves to lab or something you know I I think my concern is we don't want to send community members to a place where there's you know no activity no response. So just I would you know look at the larger picture around the responsiveness but as far as SMO goes the specific uh uh question was we did reach out we haven't had that phone call yet but we'll we will let you know once we do what we hear back from the maintainer Matthew Yeah, I just want I guess one one point on that I guess is it's um uh there is maybe a distinction between the project is moved to dormant and the project is marked as is is on the pathway to being moved to dormant at which point there is it's a bit of a it's a bit of a hard cut off if some communication has been missed or someone hasn't noticed a question on discord to then go right now it's dormant. I think I think there might be that kind of precursor step needed of that that avoids the need necessarily for the TC to keep having the same discussion about the same projects on the on the cause which is to say it's met the criteria for move to dominant. [clears throat] Um we're going to mark we're going to mark it as such and we're going to put that in the the project report as the last comment currently there. um if there is a if there is a report and and then and then potentially it's kind of it may maybe it's like a at the end of the year that's when it's actioned or 3 months later or something something that allows the TSC to stop discussing it because it it goes comes up over and over again but does does at least make it clear it's kind of on the path to this um and you've got a small window where if if it's if it's some kind of communication error or something that there's at least a chance to kind of address that. So, thank you. So um sorry so if I heard um right we want to give one more chance for project teams to respond and we also want to wait for um the electricity staff reach out to the project maintenance to happen. There is one pathway possible for us just like um just like we adopted a new practice recently like any new governance we are going to have a public comment phase we could start receiving public comments on uh both of these projects I know two of these projects they are in two different phases this mode we did receive project report uh project report has been acknowledged like on the review at least on the review comments. It's just that the project team has not yet committed to addressing the gaps that were identified and um they have been nonresponsive since then. On the other hand, on the Minocoa report, project team did um ask us for an extension, but again, they since have not responded it. Um and it is a valid concern that if um staff or the TAC itself is unable to reach out to the project, what would a new contributor or like what if a community member in the LFT space would like to go and start on these projects? What kind of response would they receive? Um I would propose that we open up that two weeks of public comment kind of a phase for both of these projects and we do make our best efforts both in terms of email and discord or um even leaving up GitHub issue when tagging those maintenance and whatever is the best medium possible and um we revisit the these two projects in two weeks from Wow. How does that sound? And definitely we want to keep project growing and um if the project is just not ready for the u incubation or graduated status, we ideally want them to try and and um apply for graduation as well eventually. But for now we can definitely have those projects grow further uh in lab space and um once they mature they can come back and yeah um I'm going to feel quite opinionated but um well first of all we shouldn't be treating the same things to a project that has submitted on your review and there's been a bill discussion and they're addressing comments but they're not answering much to a project that hasn't even submit a new review and we're 8 months almost 9 months into the year. Right. That is shocking to me. Absolutely shocking. So for me is we move into dormant. Absolutely right. It says it in our guidelines. If project updates are not submit within two months of their scheduled due date, it's it was due in March. We're almost in September. For me, we should put a motion to move them to dormant, right? And that should force the maintainers to realize that. Um, so I'm I'm being quite opinionated because I think we need to be right. We we need to set high standards in LFT when it comes to projects. Um, so five months of review and we need to start addressing those. So I don't know how other people feel, but I would I would think we should just vote for it to be moved to Dor at this point. >> [snorts] >> Um I I agree with um what you said that um we should do something and and that it should not be ignored. Um, as as said, I would so I would really like to to have some solid I don't know like paperwork documentation for that before we make that that step of um vote for it because I mean we discussed that now since 3 weeks or or four weeks whatever right and I would say if it's now one week longer is is not the the problem here right So maybe instead of doing it today, let's rethink what should be the praise for such a project. So where should it um you know like um go to and and uh define it in in our documents and then happily do a voting on it next week. as an example with always making sure that if a project comes back and and maintainers come back and so on that we are more than happy to to reward whatever we you know did based on that but we've been punting this for weeks right for months we've been saying yeah mant is going to come back in a week in two weeks it's literally >> it's in our guidelines Hrix has been saying the chat that If they're not submitted within two months of their scheduled due date, then project will be moved to dormance state and they're not reported within three weeks, right? We it's already our guidelines. I understand that we might want to refine those and we want to have better guidelines with a more auditable approach, but I see commits going into Minoa. It's not a project that's not doesn't have um a community around it. So, so why is the reason they're not raising an annual report, right? After I see loads of commits going on in there. So, we need to like for me I feel like we need a stronger stance to this because we've been pushing this week and week on like, yeah, we'll vote next week and then we don't have quorum and another week comes on and we don't have quorum again and which means we're just punting this, right? And it's been 5 months. So maybe I'm I'm the most opinionated here, but I just feel like at least something we need to come out from this call and if the vote happens next week, at least we need to record somewhere publicly that we have a stance on on on the Minawa on your report. >> Yeah. So So I'm I'm in general with you. I I think the big big difference is that that I saying okay maybe we should you know like prepare oursel to the vote saying now hey we will vote on that next week. kind kind of that right because for example that it's written down I totally agree we see it here and I I say yeah that is as it is so we don't need to add anything to the documentation and and with that totally fine to to vote on it um the question should we do it today or say yeah we now have all the informations together and um everybody has one week to think about it In best if you have any concerns do it as synchronously because in best then next week we could just do the voting as an example. Uh so I just wanted to inquire has there been any communication with the maintainers like I looked at the discord channels and there's no acknowledgement to any of the questions asked by the t members whether it be by Arun or Marcus which I noticed. Uh I would like to get at least some acknowledgement from a maintainer before um uh triggering the open vote. >> Um sorry this is Daniela. I'm sorry Roma. What was it that you were requesting? I was just wondering if there has been any communication with the maintainers. Have any maintainers? Okay. >> Um so, uh David Boswell mentioned on Smoot, we actually have a call tomorrow with the maintainers, um and the executive team behind that project. And we've had uh multiple uh discussions uh with the Minawa maintainer who also happens to be a tech chair member. >> Okay. So yeah and I was specifically inquiring about Mayor Kawak because that's the one we are considering for dormcancy now. So >> Mhm. it's been >> it's been um escalated up to uh the executive team that that maintainer works for. >> Okay. I mean if you have made good paid efforts and uh they've still not um submitted a report yet or even given justification for it then I'll be fine with uh uh voting on the motion. >> Yeah. I mean I think that the proposal is to give a oneweek notice. Is that correct? Or two two week notice. One week notice for next next uh tech meeting next Thursday. Is that correct? >> Yes. So um >> say yes especially when you like >> um meet with them between now and the next tech meeting. My assumption would be that you can say that we discussed it and we want to vote next week. Um but I think it would be bad if you meet them tomorrow and said oh yeah you know yesterday they already vote on it. Um so especially with that I I would say let's um get the consensus here that we decide to vote next week on it. If not based on that meeting or or whatever something happens that that changes everything. I think that would be a good good way to do it. >> Great. we can relay that message to both of them to both projects. I see a lot of thumbs up. So what we'll do as a action item from this meeting is put out a public communication saying that hey if you have if you have not been responsible or like have a ETA for completion of some of these asks then the tag is going to take an action uh in two weeks time from now and we're not asking project to fix everything in two weeks but at least acknowledge and and be responsive And we'll also wait to hear back from the uh meeting that is with the staff and we'll get an update from staff. So we'll table this decision for two weeks from now with hopes to receive more information. >> Do you mind putting that into the chat to make sure everybody's aligned? Yes. >> Great. Thank you. >> Okay. U sorry I I just got distracted. I saw some notes on the chat. Moving to the uh next section on the media reports. We did receive web prior report this week. Um and there has been a question or maybe notes from web3j team and one of the one of the things to highlight from the report is that web 3j labs or like web3 labs is no longer funding for web3j maintenance and however maintainers are willing to say they want to continue maintenance of the project. Any thoughts or suggestions on this report? Marcus, I saw you had a review of this project. >> Yeah. Well, I mean, when I read the um the the review, I mean the the outcome is actually pretty nice, which I think was also acknowledged by Enika. But yeah, the biggest concern as you just mentioned that uh that three labs uh got the funding essentially. Um but yeah I think I mean for my side well we should be concerned as a tech and should continue to monitor things uh maybe I mean give them a voice uh to ask for help using all the channels available in LFTT to get either funding for those contributors or get more people on boarded whatever. Um and yeah and then I think I would I personally would then also uh improve the the review. >> Okay, Marcus. >> Okay. Um I know the three reports that we have received, they were also in pending phase for review for a while now. And um so previously I mean media report is a new concept this year but previously when we had this concept of quarterly reports the way we went ahead with those reviews were uh once sufficient number of track members had reviews via the pull requests the report was deemed to be accepted and um and if we think similar practice is sufficient for media report. I request all pack members to take a look at these pending reports and once we reach the quorum of six uh reviews we'll consider the project report to be accepted and uh just like how we requesting project teams to submit their reports on um due date it also becomes responsibility of us as a tag to review and then share any review comments in time or at least in let's say two weeks from the time the report has been submitted. That's pretty much what I wanted to say. Any um concern or any other things that you wanted to bring up? Anybody wants to bring up on any of the other project reports that we have for review. um wanted to bring up maybe one more topic for discussion. This was about the Aroa project. I understand um previously we had a concern at least during annual reviews that I 2 and I 3 are completely different. The project report seems to be indicating that everything is going fine. Um things are good. wanted to hear if um the T had the same opinion. Okay, don't hear any comments. So, it could either be that there are no concerns or it could be that we haven't reviewed it. I request uh T members to take a look at project reports and we'll we'll see based on number of approvals on the report. Okay, with that um we'll move to the next section I understand. Um we'll we'll go to the discussion of on the overdue reports. Um thanks for highlighting that on. So we do have number of project reports overdue. Um I would need help also from Henrik maybe if you can also reach out to some of these projects. um our or since we have representation from majority of these projects on this call, I request you to take it back to rest of the maintenance or the TSC of the project and uh get us moving forward on on this. Okay, we'll move to the discussion section. Um so I know in the um last week we brought up this topic on the EU cyber resiliency act and that needed at least one notified change how project teams operate or maybe one update on governance started. I wanted to keep this topic again for discussion and hear if there are any more comments um that we need answer for. I request um for us to update our governance charter to include the u change as a standard practice. >> Arun Hendrick has a hand raised. >> Oh, I see Henrik. >> Thank you. Um yeah, I I had a comment to the um CIA to the to the Cyber Resilience Actually. So sadly, I was um um my internet got down last time for the last like 15 minutes. So I was not able to to attend that part. Um but what I think would be very beneficial because uh uh let's let's start differently. So um I think our goal must be to have all projects and especially all artifacts we create out of those projects to be ready to be used in European projects. um under the guidelines of the or however you want to call it registration whatever and of the cyber resilience act which which means um what I think would be good um to have a kind of overview about our artifacts that that we provide and and a checklist where we can see are those components ready to be um be used in software that is sold within in Europe and used within Europe to fulfill the the cyber resilience act especially since the cyber resilience act introduces a kind of role which they call opensource stewards um and I would say we are here as a cube to fulfill exactly what what that role within the cyber resilience act describes because we're like the stewards of exactly those projects um which are under the LFDT and um one thing we as stewards could do to make the life of everybody who's depend on the project and build on the projects um is to to help them to make any um certification and and stuff like that more easy. Actually, I hope that there will even some kind of attestation that hopefully comes um with the cyber resilience act early next year so that we as AFDT and then maybe even more global RF um could give out attestations for subp parts or for for artifacts we are creating so that um it's easier to use and I would really like to to be prepared for it. So I'm I'm have as you might hear from from what I saying some kind of knowledge about it because I'm in the Eclipse Foundation in in the cube who is working on it actually somebody already opened open SSF I do not have the deep understanding within LF how that topic is is being handled. So totally happy to to discuss on that topic and and help and try to move that forward. Henrik and and sorry before Hri answers Henrik I know Art has an answer for your question. Enrique if you don't mind is it okay if Art can answer first? >> Oh Enrique can go first. That's fine. >> Okay. Sounds good. Thanks. Um no just this is great. Um I'm not that patient. I think I wonder if the next step is some sort of draft PR or PR against governance just understanding um like what are the nonfunctional and functional requirements that projects would would have to prepare themselves against this. I now see there's an open SSF thing I'm going to read which I hadn't read um that they have some some ideas on how to prepare but you mentioned some nonfunctional things as well such as having I think you mentioned someone that acts as a a specific role within projects. So it' be very it really good if we have a where we can discuss what are the sorts of things that projects might need to do in order to to support this always linking back to the official regulations. But I think that'll be a really good starting point. um in my opinion. >> Thanks, Enrique. >> So, Enrique, all the materials that Sean shared answer a bunch of those questions. Um, so I definitely encourage you to check them out. Um, there's also a free training course you can take. It's like an hour long and it basically, you know, forces you to go over all of the relevant content. Um, I would say there are kind of two roles that folks here will be playing. Uh there's the steward which Hendrickk referred to. Uh and this is sort of the the open source community open source maintainer role. Um the requirements of a steward I would say in a nutshell. Um, and it this isn't of course exactly everything, but but just sort of summarizing is like run a proper security vulnerability pipeline and uh disclose bugs appropriately and in time to EU authorities. Um, some of the timelines on that are pretty quick actually, like they want initial notification of 24 hours of some bugs. Um but um but in general if you're running a good security reporting pipeline already uh which many of you are then sort of that sort of part of the obligation you know isn't too much. It's it's not too much more than you're already doing. Um there is another role which you also will probably need to know although not necessarily in your open source software capacity which is called a manufacturer. And this is if you make or sell commercial software. Uh you have a whole host of other responsibilities. Um the training course also goes over that. So I definitely encourage you to to check it out uh if you're curious because it will probably be useful to you in your business life uh if you're doing business in the EU. >> Um and again it's free course. Uh you can just sign up and take it. um and listen to uh David Wagner uh tell you all everything you need to know about the CRA. Um does this make sense? Like I'm not a lawyer, but I'm happy to take questions on the CRA stuff. Uh if you all are curious. Yeah. In summary though, take that training course. It's about an hour. uh and you will have a lot less questions about the CRA afterward. >> So, so there's a discussion today Arun that we want to understand how we would document this in our um as a TAC on how projects should address this. What what is the the what does a TAC as a TSC want to do with with this? Is it like tell projects about it and share the material that Hart is very kindly sharing with us or is it we want to write some sort of um document um explaining this to projects? >> It's both of those things. Um I know like couple of years ago we adopted this this practice at least on the vulnerability reporting or introduce this the new role within each project where we have u representation from project teams and and being responsible to address those comments and like we set timelines on these should be addressed within x number of days and so on and so forth. Um I agree to heart like this is kind of formalizing that or like reinforcing that kind of an ask and um because of I mean because of the um the governance beyond LFT angle. So this needs to be um a bit more strongly worded where needed within our governance documents and bit needs to be strongly enforced across our project and and um that's what my ask would be and yes let's share these presentation and the training links to all of our projects. Um I'm sure um like maybe we could open a GitHub pull request or a discussion item with this information and tag all the mainteners and um and see what others may have any more questions on. Um, so if I may dive back in Rune, I would say it's definitely a good idea to have the TAC have policies around this. Um, you know, in particular, what this means is, uh, you know, we will want to be aggressive with projects that are not responding to their security vulnerability disclosure reports. Um but I would definitely recommend everyone you know read up and and take the course before we start uh writing. So this is going to be you know a big part. Everyone here has seen GDPR and seen how it's affect them. you know, this is going to probably be, you know, uh, affect folks even more. Um, but the nice thing is if you're already doing a good job with your security vulnerability disclosure pipeline, then it's not too much extra work. And if you aren't, well, you should be. So, does anybody are there any other questions or >> I'm hearing silence. Arun, you want to take over? >> Show. Um I would welcome if somebody wants to take a lead on this activity and um get a proposal up for us. I know um could be like minor modifications in our governance documents but more stricter enforcement on how we get each project to be um involved in in this process. Right. Anybody wants to volunteer on that? So um happy happy to to work on that. I I think as as hard said and I'm just started the course. I I totally missed that if has a free course there. Um maybe we do it and and then in best maybe next week or in two weeks everybody has done it and and and then we can um dive dive deeper into it. But I would totally be happy to be included and if my time allows it's something I need to check even even happy to take a read on that. >> Thanks Henrik. Okay. Um I saw a message from Ry. I did not realize were joining us from OWF. I want to give them an opportunity to um speak. Um do you have any questions on OWF migration or like any recommendations for us on what to look forward uh to within the uh OWF suit of projects and then um any process suggestions like anything you may want to comment on. I also see a note from Sean that um we will have larger forum from joining this in one of the upcoming sessions as well. Is ace. >> Hello everyone. Um I'm Ace. I'm the um I'm the tech chair of uh open wallet foundation and um yeah uh I would like to uh have some topics and uh schedule some um meetings or agendas if possible for mapping out how the existing open wallet foundation projects are going to be migrated into um LFTT and also how the the life cycle would be and would that require or any reviews and everything. So, um I'm here for full support on getting open foundation projects well migrated into LFTT and um yeah there there are two main questions. Um the first one is um have we have LFTT tech already discussed about this um migration from open foundation to um LFTT? And the second one is do we have any um scheduled dates uh for uh discussion or the forum you mentioned Aron? Um yeah >> please >> I can take that one Arun. Uh Ace we're working on the plan right now along with the dates and also the requirements for uh the overall plan for migrating from Open Wall Foundation to LFDT. um that I'm hoping to get done this week if not early next week, Monday, because Tuesday, Wednesday, and Thursday I'm going to be booked up and uh we're going to we have not shared that with the TAC yet. We have told the TAC this is happening, but we have not shared the plan because the staff is still working on it, but that's coming because we want to get this moving. >> Um thank you Sean. So um is is there going to be like a discussion um dealt uh around this uh during the tech um meeting in LFTT uh or is is there going to be some other like special schedule? >> I think the goal would be for us we're going to have a listening session for the WF community anyway to walk them through the plan. Um, we would definitely present this to the TAC so they're aware of not just the form of what how things are going to work, but also the format and timing. Um, we want this to be a managed migration, not a rush. So, >> yeah, thank you. And um my last question today here is um I I've seen the upcoming election for 2027 uh 2627 um tech for LFTT and I I believe I I know some folks who are interested in nominating as well. Um and one of the requirements uh are to to be self-nom nominated or to be nominated is to be active uh by definition to be having the contribution to last 12 months of um any LFDT project. So would this um open wallet foundation contribution would be considered as active as well? >> I'll take that question. So we haven't had a formal discussion on that topic but I would want us to be um considering all the contributions that has occurred on OWF and I would hope we um get an OWF projects where maintainers are interested in participation within the LFD tag be approved and be a LFT project by the time the nomination period is over. Right? that gives an opportunity for for the project teams to be represented with an LFP team. >> Yeah. So, uh up until like October 12, if if I remember correctly, um if if all the projects are migrated to LFTT, then it will be automatically um eligible. But uh if not, then um yeah um probably worth agenda to uh to be discussed in tech. Yeah. Sean, do you know um any insights on when we are going to start reviewing OWF projects? Yes, >> our goal is to give the TAC um as well as the OWF projects a plan which includes timing. Um it would not be in the next two weeks. It would probably be the week after uh the Labor Day weekend. Um so I'm assuming se the week of September 14th at the earliest is when the process would start. Our expectations this because there are 13 to 14 growth and impact projects and 14 plus labs that it would be you know it's not going to all happen at once and we don't want it to all happen at once. We want to make sure the TAC has time to review the proposals talk to the teams and in the case of labs you know have the right uh interaction with the stewards. >> Okay. Um I know we agreed on T election proposal the timelines in one of our previous T meetings but um given the question from ACE if let's say OW of project reviews would not complete by the time the T nominations period ends. Um maybe in one of our upcoming sessions I would want us to bring up this topic for oat with the current tag and see how it goes. But let's see if we can prioritize and if you have any suggestions on who is going to nominate we can definitely prioritize those projects and um for voting or review. Thank you, Aru. And thank you, Sean. Okay. So, we do have 3 minutes in the meeting, but I want to e that time for today. Thank you everyone for participation. We have a couple of action items, and I look forward to seeing those. moving forward. >> Thank you, Ar. Thank you, Hendrickk. And thank you to the TAC members. Have a great day, everybody. >> Thank you. >> Bye. My