 to respect the people who did show up on time, so. The recording has started, the floor is yours. All right, thank you very much. Hello everyone, welcome to the TSE weekly call. As always, I have to remind everybody of the antitrust policy. The antitrust policy notice is displayed on the screen for those who are online. Please do make yourself knowledgeable about this. This call is public, open to everyone, to listen in and even contribute, but we do expect people to follow the rules. So there is two aspects to it, the antitrust policy that I just talked about, and the other piece is the Code of Conduct, which is also linked from the agenda. And so please, you're welcome to participate, but behave. So with that taken care of, there is in terms of announcement, as far as I know, there's only one reminder. As we've discussed before, there is a DCI survey going on. Everybody is welcome to participate, invited to participate, encouraged to participate. I know that last week, then asked people from different projects to spread the word around in the different projects. I've seen evidence of at least some of that happening. And if you haven't done so yet, please do follow up the link and answer the survey. And yes, you might even consider doing that while we're on this call, if this is really what it takes. Even though I don't encourage distracting yourself from what's being said on the call, but I think it could be tough. Is there any other announcement that anybody wants to do before we move on? Sorry, I didn't put mine on, but I'd like to reiterate the fact that we are getting all the HGS signups for the tables, the kiosks and the videos. But I think most of y'all are aware of that by now because I think I've pinged everyone pretty much individually. But if there are other people who do want to do the tables especially, this is the part that's going to be a little bit more unconferency life where you have control over it. And you can suggest topics. Please sign up on the wiki and I'll add that to the notes, the wiki link. All right, thank you, Silona. Anybody else? All right, otherwise let's move on. In terms of quality reports, there are three that are due according to our calendar, but none of them have been posted yet. So this is my way to highlight missing parts. Sorry, sorry, Iroha has, it's a report already. I published it a little like a few hours ago. Yeah, I'm a little bit late, but still we have the report and we're here on the call to present the report if you have time. All right, well, it's okay. I mean, given that it was just posted, I can't imagine many people have had a chance to look at it. If it's okay with you, we'll just keep it for next week. I will carry that over to next week's agenda. So hopefully people will have signed then to have a look at it. And if there are any questions, they can raise them by then. Is there anything from your side? That must have been Sarah, right? Yeah, that's me, Sarah. No, we don't have any questions about that. I mean, it's a very short report. Things were, they were not like hibernating, but it was a little bit slow, a little slower than usual. So the report is kind of short. So yeah. Okay, no, but that's good. I just don't want to miss if there's anything you wanted to talk sooner rather than later. So that sounds good. We can wait for the next week. All right. Anything else on the report? So otherwise, please do keep an eye on the calendar. The calendar for the upcoming reports is posted thanks to Rai. They put all the reports into a couple of wiki pages. So there's a chance for everybody to see what's up. And I keep adding those to the agenda week after week. So you can easily quick click and see when your report is due. So please do keep an eye and let's try to keep the right pace on these reports. Otherwise, you're just holding it back. We've gone, I'm sorry, there's like no push in this at all anymore. Everything has to be pulled. So, you know, we used to get an email reminder or something on the chat channel that, hey, your report's due in a week, right? Haven't seen anything for the performance and scale. And so it's just, I mean, it's becoming harder to run these things when you have to sit there and pull to find out when your report's due and stuff like that. All right. Did we agree? I thought, so I thought we said we didn't need work group updates. Okay, so that's two different questions. All right, and I apologize. I didn't see that one just came out a day ago. So this morning at 3.30. I understand. But so on the first part, obviously, you know, Chris's question is relevant because if there's no report, then we can forget this whole discussion, although it still applies for the projects, I suppose. I mean, my understanding and right can tell us exactly what the status is, but we've used years. He actually went in the calendar and put calendar reminders for each projects and working groups. But it was kind of a pain to keep doing this and maintaining it. And they kind of gave up and put everything in a page instead. Is that right, Roy? That is, that's the shape of it, yes. However, I do, the reminders do go out to the mailing list, just not to every individual mailing list. So I think the reminders are only going to the TSC list. I'd have to look to see where it is in the calendar, but maintaining, because of the way that groups.io works, it's a super pain to set this stuff up. Like I can't have a calendar event that sends a mail to two lists, for instance. Okay. No, Roy. I think we received the, sorry, I think we received the mail on our Europa list, but it was like a few days ago, like we did that a lot of time. I think it wasn't like, as usual, I believe that previously we received it in like, in like more than a week even, but this time I think we received it like, pretty recently, but maybe I'm wrong. So yeah. Yeah, I doubt that you're wrong. Roy sent me a reminder for the fabric, or you know, me and the maintainers, but. All right, so maybe if Roy, you can have a look at how long before it's due, you send the reminder and maybe that can be adjusted. But it sounds like the reminders are going out. So at least we have some. I think it was at least a couple of weeks. I think I did mine because you sent out the reminder of the reminder, so. Yeah. Well, yours was a little bit weird because, so the issue with yours, Chris, the one for fabric was that it was dropped on the floor, right? So that's why yours was hand-delivered. Oh, okay, fair enough. The one, everyone else is talking about calendar reminders. Yeah. All right, so I don't want to spend every time talking about this detail, but Roy, can I ask you to follow up and check with the statuses and maybe if there is some adjustment that needs to be made. And if you have experienced difficulties with this and a feedback, please contact Roy, and so he understands that you are. Please contact the community architects mailing list or on chat, like. Okay. That would be awesome, thank you. Yeah, this is to be Roy, although Roy seems to be stuck with it. All right, so back to the question, Chris touched on though. I mean, I'm a bit confused by your statement, Chris, because this was my idea a few weeks ago. I said, I don't know that we need those working group reports anymore. And I believe you said, no, no, we still want them. So are you saying now we don't need them? Okay, so I'm just maybe misremembering how we decided this. Maybe we need to decision. Yeah, so maybe this is something that should be formally discussed and then decided on because there seems to be, we seem to be going back and forth. I think what I may have been, and again, I don't remember exactly what I said, but maybe I was focusing on those that are delivering stuff, right? That, you know, again, we sort of said there's a loophole and if you're a working group, but you're delivering stuff, then we probably wanna keep tabs on how that's going. Yes, so I mean, just to make sure it is on the same page. The reason we're discussing this is because we recently changed working groups, right? And remove the requirements or the expectations for working groups in general to have deliverables. And if they have deliverables or want to have them, except for a few that were grandfathered, they would have to create task force, which are chartered approved by the TSC to deliver within a certain timeframe. So for those working groups that become just discussion forum, does it make sense to have quality reports? And that's really the question that's up now. And so it seems like now Chris is saying, I only meant to keep the report for those who are grandfathered and are delivering products like documentations and whatnot. Yeah, I came away with the same impression as Chris. I don't know if that's technically the right impression, but that was what I was operating under. I was able to get that impression as well that reports were not due unless you had a task force. All right. I mean, we can agree to that and then just, that's it, you know. Why don't we just make a decision? I make a motion that quarterly reports by projects, I mean by working groups are only good if they have a task force. I'll say got that. Can we, does anybody disagree? How do we know it has a task force? We approve them. So we should be aware of that, right? We do. Yes, the TSC should approve task force. That's part of the process. Okay. Is there a way that we could have this recorded in writing in regards to decision logs so that this can be a little bit more clear because I'm having a hard time writing out what this is specifically. I will type it into chat. Is that good enough? We can actually, we can create the decision log entry after we see that. Let me put that on the Wiki here, hold on. Of course I can't find anything. No, but we, I don't want to get bogged down with the details. Now I think the proposal is pretty simple. I'm happy to create the log afterwards to capture the decision. The proposal is, let me rephrase it or restate it. The proposal is to say that working groups that do not have deliverables or task forces do not need to submit quarterly reports. Are you creating the proposal for us? Yes, I am typing it now. Do not submit. All deliverables so we can catch the grandfathered one. Okay. Who's trying to avoid having to do that live, but. Formal proposal. Paste. Yeah, it's a good idea. Do we have to do anything to get the review by? Don't worry about it, just save it as is. Publish. Page needs a name. Oh, page title. Working groups reports. Quality reports. There you go. Okay, that will do. Everybody sees it, Rai is displaying it on the screen. Working groups that are purely decision group that needs to be the quarterly reports unless they have deliverables or task forces. Can we agree to this? Quickly? What did I say quarterly or where did I say weekly? No, no, I said quarterly. Oh, okay, sorry. No, I say, can we agree to the, no, no, what I meant is can we agree to this quickly? Oh, quickly, I'm sorry, sorry, yes, yes. I move we vote. Whatever the question. Okay, we have the proposal. It's in the, it's in the wiki. I second it, third it, whatever. I want to vote. Does anybody disagree with this? Does anybody wants to abstain? Everybody else agree? Say hi. Hi. Hi. Hi. Hi. All right, we're good. It's approved. Thank you. Let's move on. So I think a function of this then is that the calendar needs to be updated. Yes, so that'll be an action item for this, but this can be done after. That's not what means stuff now. Let's move on. Do we want to leave it in the calendar just so there's a placeholder if they get a task force or schedule them when they get a task force or deliverable? I think that'll be confusing to the chairs because they think they have. I think when they, when we approve a task force, then we can add them. And if there is a group that already has deliverables, like we have at least one, they can be kept in the calendar. That's how we do it. Easy enough. All right. So we'll do a cleanup of the calendar for the time being. Let's keep on moving. I have two items that I was hoping to be able to make formal decisions on. The first one is replacing major releases with promoted releases. We've been through this one quite a few times now. Last time I had put a formal proposal, revised the proposal based on feedback. I didn't want to call for a vote because it was, I had just put that up before the call, but we discussed it. It sounded like there was general agreement. So now I would like to formally propose it. There was one clarification I added based on the discussion we had, which a heart requested, which had to do with the fact that they are promoted releases, I expected to be initiated that the request of the projects. So, is there any further questions on this proposal or are we ready to vote? I also added a link to the criteria for promoted release, remaining the same one, the same as the ones currently defined for first major releases. So there's no ambiguity as what's there. So. I move we adopt the formal proposal. Thank you. I second that motion. Thank you. All right, maybe we do a formal vote one by one on that one, right? Can you call? Sure. Angelo. Ian Muth. Arno. Yes. Chris. Yep. Dan is out. Yes. Gary. Wait, was that Angelo answering? Yeah, it was me. It was me. Okay, that's fine. Thank you. Where were we? Hart. Yes. Mark. Yes. Nathan. Yeah. Swetha. Yes. Tracy. Yes. Roy? Roy's still not here. There you go. Have we heard Gary? He's not here. He's here. He is here. Gary. Yes, Nathan. Yes. We haven't triple muted. He doesn't know it. Nice double secret probation. He's oddly silent. That's not him. Yeah. Well, regardless, the proposal is overwhelmingly passed. Yes. Anybody opposes it? No. All right. Thank you. This is approved. All right. Let's go back to the end, Jetta, then. The other one is the one about the repo structure. So we have had that project that was led by Chris through a task force to define a common repository structure, and at least a set of files that people expected to find or to have in every repo. And so there's been some discussion, and I want to address that point now. I mean, Dan, you may have said, well, I didn't think we were ready for this because we should get feedback from the maintainers, but we have had the proposal up for a while. We discussed it last week, and there doesn't seem to be any showstoppers. And I want to be clear, just because we agree on the general idea doesn't mean we cannot amend the details later on as feedback comes in and people gain their experience. So if there's a file that people say, oh, that we don't need, or we should read that one that's not listed, we can make those adjustments. This is no different, in my opinion, than anything else that we do. I'm always in favor of incremental approaches. So, but Chris, I'll let you talk to the proposal. Yeah, so this is the, yeah, if you scroll to the bottom here. So, well, before you scroll, hold on, hold on, wait a minute. So before you scroll, so yeah, so the recommendation in my proposal is that we adopt repo linter, which is a tool that the to-do group, which is a group that was formed to sort of define some best practices for using GitHub and open source. And they developed a tool that basically goes through and does a check and says, do you have a license file? You have a contributing so on and so forth. And in some of those files, it's looking for a specific criteria characteristics of the file itself. It also does a sort of a cursory check of things like, do you have a license and copyright header in your source files? And so, if you run this tool against your repository, it comes up with a little report and tells you whether or not you pass or if you have any things that are exceptions, like in the report that I posted in here for fabric. And what I've done is if you scroll down to the end, I've mod, one of the things that we talked about all the way to the bottom of the comments, yeah. What we talked about last week was so, we wanna sort of see what would it look like if we ran this against everybody. And so I did that. And so if you click on that, just you'll see a report of every repository under the Hyperledger organization has been linted. And some of them are coming through with some errors, but those things need to be remediated, right? Like there's no copyright or license file on a bunch of these per borough. And there was a few for fabric sub-projects and stuff like that. So my recommendation is that, well, what Dan I think suggested was, let's run this by the maintainers and we have to present a note this morning pointing to the proposal and to the report that I ran here and sort of asking the maintainers, are you guys good with this? I think, as with our know, I'm happy to socialize this but I think, and actually what I found was you don't actually have to modify your repository to do this, right? You could actually run this from a directory that has the configuration file you wanna use and you can just run it against the GitHub URL and it downloads a temporary copy and that's it. And so I actually wrote a script right that you could use to just do the whole bunch periodically. Yeah, when you were mentioning that, I was thinking this could just be a GitHub action that runs on a cron job. It could be a GitHub action, yep, exactly or it could be built into your CI to make sure you're not uploading a file that doesn't have all this stuff. And so it is what it is. I tweaked it so that it created a warning if you didn't have an issue and they pull request template. I don't think those are required, they're nice to have and I think I created something else as a warning. I'll have to go through and look at the config file but basically what I did was I submitted a pull request of fabric to add the config file although you don't have to do that. Again, you just have to whoever runs the report just has to have the config file in the local directory from where they run it and there we are. So last week I remember there was some discussion about creating a local fork of the tool. Yeah, you don't have to do that. You just have to have the config file in the directory that you're running the command from. So your experience has been that with configuration you can adjust the tool to our needs. Yeah, it didn't seem like there was any way to you would have to fork the repo to change the config file but I read through the source code and see what was going on and apparently if you put either a file by the name of repo lint or repo linter.json in the project that you want linted or in the local directory from where you run it it uses that file. Okay. It's not documented but that's how it works. All right, thank you Chris. So any kind of reactions to what is being proposed? So I like this. The only thing that is confusing is that we have this task force page that doesn't match the decision page. So I believe we're just making a decision here based on the task force page? Yeah, that's my bad. I put the proposal in the task force page. I'll go back and paste it but basically yeah. Yeah, we probably need to update it but there's a link to it at the bottom. It says C. You started the task force before the decision log was created. Yeah, yeah. So that's a minor administrative detail we can tackle. I'm more interested in another aspect which is, so I don't know what Dan's concern really was because it seemed to be concerned that we would be adopting this too early and for me it's like, well, I only see benefits but part of this might be whether, I mean to me the goal is not to give a black eye to project that look like or reported as non-compliant but it's really providing guidance as to how to improve your repositories and it raises the question of like, how is that implemented on a practical basis? You guys just talked earlier about maybe having like a regular run of the tool, a linter on a regular basis but I mean at this point, I haven't heard anybody, my interesting is that we're not trying to enforce this and again give black eye to projects that don't comply as much as providing a tool for people to be better at it. So I think, yeah, so you raised a good point. So there are some files that are nice to have but then there are also some files that are required like license, right? And I think the objective here was that we would have a community that was somewhat consistent in all these things and I don't think it's really a stretch to say, you should have all of these things. I agree that maybe we don't go around beating people over the head with it but maybe share with the maintainers. Here's where you stand. You can decide whether you wanna fix these things or not but we adopt as a recommended practice that basically what's in that configuration file is what we'll be looking for. Right. And again, I mean, I've said that before, I believe that to me, I think a lot of the differences we have from one report to another today is more accidental just because we don't have in a recommended way. And I think people, when there is no recommended way they have to invent one and they invent their own way. And so just providing the tool will help convergence which is the primary goal here. Because- So one of the things why I think it should be socialized among the maintainers is not all the maintainers are tuned in to what the TSC is discussing. And basically we had a case where one of the maintainers was updating a lot of these and didn't realize that like, for example, code of conduct was one that was important should have changed. He said, well, it's in the weak heat. Why does it need to be in the code? So if we come with a sudden requirement that, hey, this is what you're doing without socializing with the maintainers, it might lead to rocky relationships with maintainers who are always tuned in with the TSC. So that's why I support socializing with the maintainers before adopting it. I don't have an objection to doing that either, by the way. And if nothing changed just the fact that the maintainers were consulted will make them feel more included. And following up on what Dan was talking about, there was a question that was raised by the Bezu team there, which just, is it okay to have a link from the file in the repo to say the wiki page? Would that be considered compliant? Or do they have to copy paste the text? Considering that these repos might be copied as zip files and that the wiki might change locations over time. I'm more in favor of having itself contained in the text in there, but that's a discussion that TSC can make in a second. We started having that discussion last week. I think my personal take is I don't have a problem if it's copied. However, it creates sort of immediate technical debt if we decide to modify the code of conduct or the security policy and so forth that we have to go through and change them all. Now, again, we could also automate that, right? Just like we did with the security file, automatically submit a pull request to everybody to update it with the change, but it's something that needs to get done if we do make a change. So that would be my only concern. And the repo venture would catch those changes too. Right. Yeah. So I'm fine as long as we're okay that we understand that there can be some other things that we aren't. Yeah. Rather than calling it technical debt, I want to vanish to look at it as it provides some, is it worth going through this effort to change it? How important is changing this policy rather than just, you know, up in Wiki where it gets changed too frivolously, putting a tiny bit of barrier to changing it makes such changes more measured and deliberate. Well, we graded it three years ago and we haven't changed it. So, yeah. The longest running debate. Who's going to play to make Chris low now? Just as playing devil's advocate here, I've worked in labs that were not connected to the internet and you would have to bring stuff in. So if there's a link to something that's out on the internet, I wouldn't be able to get to it. Do we care about that? Yeah. So this is, to get to the internet, how are we going to engage the community? So to support your point there, Mark. This is why I bring up this. This is the previous project I worked on. And as you can see, it hasn't been updated for six years, right? So this is exactly to your point and to Dano's, right? Because if it's not here, if it's not in this copy of a copy of a copy of this repo, it's gone. The Wiki and all the documentation that this refers to are gone from the internet. And maybe you can argue that that's fine because the project's dead, but at the same time, the code does live on. So I would be much more in favor of not linking to anything else online. Because also the files, when I download something, it builds rules in effect for that code, right? Until I update. But at the same time, if people don't update their copy, well, I mean, at the end of the day, it's like it can be a project's decision. There's a new version. It's nothing different than any other dependencies you have from one project to another. At some point, you have to decide, hey, we upgrade to the new version and it can be left to each project to make the decision when it's the right time. So I think there is more advantages to having a local copy with all the text in it than having a link that can be dangling because that unfortunately happens more often than we'd like. And that's the worst you can have is to have a file with just a link that points nowhere. All right, I'm good with that. All right, so it sounds like we are in favor of not having just links, but we want to at least have the content there. Of course, we could do the dirt we see thing, which is to say, to have a link at the top that says for the letters version of this, say, code of conduct, see this page. And then I'll copy anyway, but we don't have to get too fancy. I don't know that it's worth worrying too much about that. All right, but that does work if you've got a local. Yeah. Okay, anyone else, any comments? It sounds like I hear people are in favor of kind of not rushing into the decision, but it would be good that we agree that there is just the general direction we want to go, and then we can socialize it and maybe in a week or two, then we make a formal decision that this is it. Now we have adopted this as a policy. And for now, we don't have to make a formal decision. I just want to hear if anybody has concerns with the proposed approach. I have two questions. Question number one is, will the supply to the labs repose? I'm assuming yes, and question number two, Chris, is there a way, how do I run this on my repo? That was the part I couldn't figure out. If you want to run it on your, what I can do is I can put together a little readme, a little guide for how to use it. Okay, that would be helpful. Readme is pretty uninformative. I'm sure that they take clear requests. Just installing the tool is a pain in the ass, because you've got to make sure you have node up to current version, new version of Ruby, you have to download some dependencies, it's a pain. I'll put together a little guide for how to do it, but basically you can run it from a directory that has the config file in it and point it at your GitHub pretty straightforward, but I'll put together a little cheat sheet. Okay, that'd be great. And labs, yes, labs, no. You know, I think it would be a great idea. I don't know what others think. I would be in favor of that. Again, if it's not an enforced thing, but a sort of an advisory thing, I suppose. That's my thinking though, is that we don't have to enforce it, but we can say, hey, you might consider to do this, you know, so that we can kind of guide them in the right direction. Tracy has a lab steward difference. I mean, do the other lab stewards have any opinion on that? I mean, I'm fine with it. I think, you know, the intention is eventually, potentially the labs become projects, right? And if they're following through on kind of these best practices that we're trying to put in place, then it makes sense to me. Exactly, musician easier. Yeah. And as somebody with the labs repos, a couple of them, I'm perfectly happy to do my best to, I mean, it's not like these are owner's requests. So, No, that's a good point, Meeks. Thank you for bringing that up. I think, you know, there may be, I don't know if Dave is on, for instance, but you know, if we require a security file, for instance, on a lab, do we wanna encourage, you know, that people submit security defects for labs? I don't know. And I'm just against your implications. I agree, Meeks, it's a good idea. I mean, I think if I had a lab, I'd want others playing in that sandbox. That's why it's there. Yeah. And so having a contributions guide and the, The contributions guide, code of conduct, all of the other things are good. I think the only issue on the security side of things, that for the labs, it might be good that we have a standard labs disclaimer that basically says, this is prototype code at which you pay for. I mean, we've tried to write that all over all of our documentation, but having a standard place that that disclaimer is called, that would be a good thing. So maybe if we came up with a different security file, I suppose that might be, I don't know if I'm gonna go through all the trouble to report, because again, it's prototype code, basically, it's not intended to be used for production. Correct. I mean, for some labs, though, that are security focused, you still might want to have some of the security stuff. Well, yeah, see, again, I'm just... Being more rigorous is not a bad thing. Being forcing all every library pod to be that rigorous would be a very bad thing, though. Sure, yeah, I totally agree. I just think that some labs, that would be actually a really nice thing to have. And actually, thinking about this a little bit more, but maybe the rule of thumb is that if you're an active project, you should, with a capital, should be compliant. And if you're incubating, you may, right? And RC 2119 parlance, where it should is you have to have a damn good reason not to be compliant. For an active project. Because I mean, yeah, I think the expectation is a little bit more mature. It's sort of, it's part of what we're doing in the community, it's abiding by all the guidelines set by the TSE and so forth. That's one of the great, you know? So it should, but the capital should. Not necessarily a must, but there has to be a compelling reason not to. And then for labs, it's a may. Okay. So let's leave it at this for now. And there may be some adjustment that makes sense to make for the labs. But it seems like we, there's general agreement on the direction. Yeah. So let's go with this. And what I'll do is I'll go through, I'll update the actual decision log with the proposal. Yes. And you know, with what we just brought, you know what we just discussed here. And that way we can go off of that. Sounds good. Thank you, Chris. Yep. All right, let's move on. There's two more things that I want to discuss. This kind of one thing, maybe, although Dave is not here, but he marked, we have a couple of, I mean, we went through a whole list of issues related to the TSE election process. And there were a couple that were left bending and Dave has marked them as blocking. And I asked him, what do you mean by blocking? What is this blocking? And he said, well, it's blocking the staff from implementing, you know, the part of the process we agree to, which is the staff will come up with the plan for running the election that will be, you know, put before the TSE beforehand so everybody knows what exactly the expectation is. And so he's basically saying that, and if Dave is on, I'm happy to let him talk, but I believe that I captured this anyway. Oh yeah, I see Dave now, sorry. And, you know, the problem is if he's saying that if we don't address those issues, then they have a gap in what they need to put the plan together. So Dave, you're on. I'm sorry I didn't see your name first, but is there more to say on that or did I capture the crux of the matter? Aaron? Dave, are you on mute? I see his bike going, but I don't think he's coming through. Breaking up badly, I think. No, he's not coming through. Well, I think you captured the crux of it. What we, speaking for myself, I want the TSC to make these decisions so that we can have a much smoother TSC election. And the sooner it's done, the sooner we can start, the sooner the decisions are made, the sooner we can start implementing them. So it is really blocking us, the community architect staff from getting stuff going. And that's why we're asking for this. Yeah, there's a bunch of decisions that have to be made. And there's a bunch of also some things that have to go a little bit more farther forward. And I need to give clear direction to LFIT because there's a lot of this stuff that's actually being nailed out right now that they're about to start doing software development on. So the sooner we can give them a very clear agenda in regards to how this would, we would like for this to be run, the sooner development can start working on it because we're doing things like trying to figure out the LFID situation versus the GitHub ID situation, identifying the different maintainers who can vote. All of that is really important qualifications that we need to give to an entity that's outside of ourselves as well. Okay, so thank you. And so I would like to go to the TSC members now and ask them to feedback because, I mean, the reason we haven't really made any effort to address those lately is two-fold from what I understand. So there are two. The first one is this TSC election voter selection. I believe there was a bit of fatigue, quite frankly. And it really was kind of fed up. And I saw that one of the comments I already got was, oh, let's not talk about this anymore. And so it's clear that there isn't much interest in discussing this type of issue anymore. At the same time, I do understand and challenge that the staff is facing, and I don't want to ignore that. But there was this notion of the lecture voter selection, which is entirely up to us. And the other one is observer. And if you go to the observer, you'll see that the last was that we basically said, well, it raises some privacy issue, and we should really get guidance from the governing board on this. And VP and Sarah are saying, I think that's Bolochs. And there's no issue, we just have to make a decision. So I just wanted to, without getting into the gory details of each issue, I just wanted more to get a sense of how the members of the TSE feel about those issues. Do we have an agreement that we should spend a bit more energy back onto those issues? What about this privacy issue with regard to the observers? Is that an issue or do we want to go to the governing board, which I don't think we have done? So Arno, I mean, I guess I'm trying to figure out why the last four years have been bad. In doing these elections, what has changed since the last election or the last four elections that make us think that we need to change what we're doing? Secondly, this is written into the governing into our charter, right? So if any changes were to happen, it feels like the place that we may end up having to go anyways, the governing board. Right, I'm kind of with Tracy on this. I don't, and I said this the last time. I don't understand why we're reopening this can of worms, right? I mean, we have a pretty good process for deciding who is eligible to vote. The staff has been, you know, they have tooling that can determine this. Now, are they able to chase everybody down? No, but okay, but the biggest problem is not finding people who are eligible. It's getting people who are eligible to vote. So I don't understand why we think we're not, you know, picking up people because we also have an exception process that says, if you're not on this list and you think you deserve to be on the list, contact the staff. So we have a vehicle to get on there and we have a vehicle to collect who's contributing. And frankly, you know, if you're a working group and you're a task force and you're producing something, what do you think GitHub? This isn't hard. So I don't understand why we're opening it. Hold on, hold on, hold on. This argument has been going on for a while. The charter says anyone who contributes technical artifacts to the code base. The code base has been narrowly, you know, sort of targeted to GitHub only. Technical artifact, including documentation it says. And you have set up a wiki, you have set up all kinds of other Google Docs and everything else. And that's why you involved the working group chairs to get the names. So I don't think that in every election cycle, we come to the same point, which is how do we find out who are the contributors? Of technical artifacts. So I think you should broaden your base. And I agree with Chris that the participation rate is a big problem and it is, you know, always a problem in many, many elections, including, you know, national elections. And they have ways in which you can address this. And I've already suggested some of them, which was to send out an email saying, you know, this percentage has voted, we would like the participation to be more, you know, something like that, you know, over the course of the conduct of the election. So that, you know, these are all standard methods. I agree that, you know, raising the participation rate is important for people to get, you know, represented. I mean, for the TSE to be a true representation of the community, if it is confined to small numbers of people, then, you know, you're going to get some skew in the elected body. And that's what's happening. I, it's been a concern. And that has been, you know, broadly touted. So for us, as a community, it behooves us to address these problems, not just say, oh, if people are not on the list, let them, you know, let them object. That never works, you know. Whenever you have a choice architecture that says somebody has to do something in order to get on board, then it doesn't, you know, it's another friction that is added to the mix. All right, thank you, Vipin. I mean, we, as you said, we've been through this quite a few times. And so far, I don't hear anything really new, unfortunately. But so one thing that I did hear, which makes me, you know, think a bit is, in fact, what Tracy is saying, we have a status quo that has worked for the last several years. And so if we make no decisions on any of those two issues, for that matter, things just get carried forward the way they have been done so far. And so I would actually claim based on that statement, which I think is accurate, is that these are not actually blocking. The staff, you know, should just continue what has been done until we make a decision on those things. If we don't make decisions, this means the status quo doesn't change. Now, we might want to still capture the status quo in response to those. And I would claim that we have a process as Chris alluded to. There's tools that the staff uses to build the list with the exception process and all that. We could capture all of that and just document this so that everybody can see that in response to the issue on the voter selection. And then for the second one, the default is there's no observer until somebody comes up with a proposal that really feels excited about to support there's just no observer. And that would be an easy way to solve those two issues for now and, you know, move forward. But I would claim this is just capturing the status quo. We are basically out of time. So unfortunately, there's not much time but I wanted to get a reaction to this. Am I missing something here? No, I think you got a reaction. I got a reaction. Where? There's been a lot of reaction to this, right? So I haven't even jumped in yet. The status quo is not good. And I understand inside your fields and I respect that, but. I guess, okay. So I'm somebody who's sat on both sides of this, right? I've ran the TSC election for two years. I'm now on the TSC status quo is not good. That means that the process that I created is not good. So I'm taking a bit of offense at this point, but I think that if I were still on the community architect team and I were having a problem running the scripts and doing the steps that need to be done, I would take the necessary steps to fix that as any developer would, right? If the process that you have doesn't work well, you go and you fix it. I don't think that we as the TSC need to weigh in on somebody fixing those scripts. They're part of a lab. Anybody can go in and fix them. So anyway, I don't want to get into a lot of detail here because it's somewhat frustrating for me to be listening to this conversation for the 10th time. So take it for what you will. All right, thank you, Tracy. So unfortunately, we're running out of time. So that's it for today, but I would move to capture the status quo in these issues for now and make that the default resolution and I challenge anyone who feels like this needs to be modified to make concrete proposals and how to modify them. And at least we would have a solid starting point. So that is the course of action that I suggest we take and I will move towards that. So with that being said, I want to respect everybody's time. You did make me wrong again. I'm making this call shorter, but it's all right. Thank you all for participating today and I'll see you again next week.