EIPIP Meeting #121

Transcript

Loading developers...

[Music] What's up?

Thank you. Oh, heat, heat. Heat up here.

Heat. Heat. Heat.

Okay. Welcome to EIP IP meeting number 121.

EIPIP Meeting Introduction

This is issue number 1762 on Ethereum/PM repo. I'm going to quickly take a minute to share my screen so we all are on the same page. So on agenda we have a few items for editors discussion here today starting from call for input and uh some items that we would like to see a policy that may help our contributors, authors, editors, new editors and community to stay informed. We can perhaps take a look at some open PRs which might require attention of editors.

Um and yes we will have fe analytics as well as some input from P EIPs insight I believe. Yes I believe we the team wants to demo something and have some agenda items to discuss here today. So starting from the very first item which is call for input. Um in the last meeting we uh discussed about uh this particular call for input but I would love for you to Sam maybe take over from here and uh talk about it. >> Uh sure. Um we're really just waiting for um any kind of solid input from editors.

Um, I'll wait a little bit longer after this call, but it's been past the 30 days and I'm the only one who's given an answer. So, yeah. Um, yeah. And on the other one, uh, allow allow links to protocol buffers. Um, this is, uh, in favor. I'm just haven't gotten around to modifying uh, E1 yet. So, that's why this one's still open. >> All right. So we can maybe close this one in favor today and because that is past one month as um keeper of the consensus may you want to have a decision either here or you may add it on the call for input u issue. So yeah

that can be closed as well. So moving forward uh we have a few more items for discussion but is there anything else anyone would like to add? I know Mercy is on the call. Mercy if you would like to add anything from your end uh before the decision is made on that particular call for input. >> I don't have anything I want to add. >> No worries at all. Thank you so much for this uh issue and uh we hope to get a decision soon on this one.

Discussion on Linking Reference Implementations

Moving on um yeah on discord there was a discussion on uh linking a discussion to section for reference implementation. I am opening the discussion right here but I believe the point mentioned by editor Kender was that we generally allow fellowship of Ethereum magician because that's not considered as an outside link but adding that link as reference implementation may not work. I wonder Sam if you have any thoughts on that, any input that could help solve this.

>> Um like whether or not we want to allow links to Ethereum magicians in the body of the document. >> Yes. >> Um I mean that doesn't really work because you can edit your posts on Ethereum magicians and you can like obviously continue discussion. Uh, so it kind of goes against the whole proposals become immutable thing. Um, but that's just my stance on it. It's not like it's a hard rule or anything. We can certainly discuss changing it. >> That's a very fair point because we want to keep things which are immutable on body section of an EIP. So it definitely makes sense to keep uh FEM limited to a

preamble section only. But yes, I'm happy to bring it up in the next meeting or I don't know if it would make sense to create a call for input as well in order to close this open item sooner rather than later. yeah, if we need an official ruling on it, we can make a a call for input for it. My understanding is that would be helpful because if by any chance fellowship of Ethereum magician is allowed. Uh then um then people may add their links to reference implementation over there. Although it seems unlikely that it will be allowed because you already have explained it is uh not

going to be um immutable anymore. But yeah, it's worth a shot. So close this topic for forever now. >> Okay. All right. Um on agenda, I have added a few other items which I think an official decision might be very much helpful. So we should perhaps discuss it and try to document it because officially it is discussed on this EIPIP meeting but hasn't been documented anywhere. And that sometimes is the point of like confusion for people who are new to the ecosystem sometimes for new editors and so on so forth. So I'm I'm sure like we are seeing some

repetitive um corner edge cases that uh that comes across editing while reviewing these proposals. As someone um who has been closely reviewing it, closely looking at uh these PRs, incoming PRs, I have often found these uh edge cases. So I think it makes sense to make things more consistent going forwards forward. We can perhaps make a decision and input it either in EIP1 or in EIP 5069 wherever people find it appropriate.

So uh the first uh item here is accepting uh policy on accepting typo only PRs. So before I go ahead like why I'm discussing this I want to quickly uh show the volume of the typo PR that we are receiving these days. So um yeah select all. So this is like a number of open PRs in EIP repo that we see as on today it is 278 like definitely a huge number way past 100 way past 200 close to 300. So I I was trying to analyze this section and try to find out how many of them are like typo PR. You see about 100 are just typo PRs. And in these typo PRs we see different two or

three different kind of PRs. One is with respect to stagnant and withdrawn proposal and one is with respect to final proposal and the other one is like active proposal. I can understand the value add of active proposal because we are having this proposal in active consideration. So it makes sense to address anything that comes in before for final proposal. We sometimes discuss it in this EIPIP meeting. try to make a consensus among editors like whether or not to approve that typo and uh edit the file because we say that after moving into final we don't want to edit it and it has also been established in earlier meetings that stagnant and withdrawn um EIP PR on their end to just fix typo

Discussion on Handling Typos in Stagnant/Withdrawn EIPs

does not add value especially when we compare it with the respect to the time that an editor has to put in to review these proposals and the volume of these proposals getting in. So I'm wondering if we can um do one of these two things or maybe both of these things. Maybe have a check uh for bot to review these PR like incoming PR which is with a header typo PR and if it is a stagnant and withdrawn then just close the PR with a message suggesting that we do not uh accept type of PR for stagnant and withdrawn proposal unless there is an intention to uh reopen or uh revive this proposal and also it would be helpful to add a appropriate uh link to message

where the author may also know that there is a policy about this that they are not accepting it. Maybe we can have this documented in EIP 5069 as I mentioned earlier. What are your thoughts? so I think like I disagree a little bit on there's no value in updating stagnant and withdrawn proposals with typos. I think typos anywhere on the EIP's website kind of hurts our credibility. like it doesn't matter if you're reading like a a stagnant proposal or withdrawn proposal. The fact that they're incorrectly and poorly written reflects poorly on the EIP process. So, personally, I think we should still

merge them. Um, yeah, I think honestly this is just me not going through and cleaning up typo. Um, so I can certainly spend uh a few minutes today cleaning those up. Um, and getting a spell checker back working again would probably help a lot too. Um, and that is something uh that we should do at some point. Um, >> sure.

>> Yeah, I guess those are my thoughts on that. >> Sure. Sure. Thank you so much for sharing that. So I understand that um uh from different perspective the value of like uh in allowing these kind of PRs may be uh higher or or lower like there is a trade-off of course it's increasing the number and personally I think that having it clean is a good idea but just having these kind of PRs may increase editors workload so perhaps we can have some check but uh these PRs um is there a way that we can perhaps automate these kind of PRs and that brings me to the next uh point of discussion here policy on edits to final EIP. So we can apply the

Policy on Edits to Final EIPs and Documentation Suggestions

similar policy for stagnant and withdrawn as well because most likely the editor would not be around. However, author would not be around. However, editor can merge them because that has not reached to the final status yet. But for the type of PRs which are coming for final EIPs and say EIP editor allow that PR to be merged but it is sitting there forever because we are not getting attention from author and the policy is that without author's approval final PR cannot be updated. I remember back in the days um when we used to have this uh EIP apprentichip handbook, the we had this thing documented that if a pull request is approved by at least one EIP

editor and has been sitting for months with a trivial grammar or spelling or whatever typo thing is there at any point um any of the EIP editor may override editorial edits and merge that EIP. um EIP bot can also do that but this thing has not been in the practice and while collating all the PRs for review for office hour I have found many EIPs where the comment by editor is I am fine merging this but you have to get approval from author so again those kind of PRs are sitting there and increasing the volume definitely not giving us a good impression especially around having four editors and we have this kind of val volume of PRs even if editors pays

attention it will still still sit there. So can we have a consensus around like okay let's document this thing so any editor who sees it next time may be able to merge it directly like force merge or something. Yeah, I think that's probably a good policy to to have. Um, >> yeah. And what do you think about documentation of such thing where we can document? Definitely we can work on a wordings that should go in. Uh, do you think we can perhaps make use of this section like deciding section mentioned in EIP 5069 because this is a living proposal so we can perhaps edit it. Uh, so there is something making decisions right. So we can make a section called others or like uh uh edge cases and we

can list it there rather than listing it to EIP1. I'm not sure which is the best place to document this but it would be a good idea to have one. >> Yeah, maybe a contributing imm um because GitHub will display that in uh in pull requests. So we could document there what will actually merge and what we won't merge and and stuff like that. Um I mean or we can put it in in the EIP. I mean both work. >> Yeah. Contributing.md also sounds good. Uh um as long as it could be referred through any of the EIPs, you know, because it's good idea to site it directly to make it official.

>> Oh, like link to it from Yeah. Yeah. We could link to it from E1. I think that's a good idea. >> Yeah. uh then uh maybe uh we can think a little bit more about I think uh there is an agreement on this part so uh allowing editors to merge because this was like very simple thing and we can perhaps do that um we can come up with a PR to have this thing documented in contributing MD and maybe add it to EAB1 but for this part we can perhaps reiterate come up with good wordings and see what are the acceptable type of policies Um anyone on the call? I see um Pier Sky on the call. Mercy on the call. Anyone

else have any thoughts and opinion on these things they think can go and cannot go? Yeah. Anything you would like to share? If not, maybe we can come back again when we have a PR to make it more official. All right, let's move on. Um, yeah, the next uh agenda item is any other process change uh recommendation that is coming from community feedback if any. So, another option for people to chime in if they have anything because I I'm not sure if we received anything

formally on uh Discord or anywhere else. >> Uh I I haven't seen anything that I'm aware of. >> Very well. Then we can perhaps move forward and we should try to like uh share this this information more uh often with community that we are open to all kind of ideas and suggestions if you have any. By the way, I would like to take this opportunity to also announce that ECH is organizing um EIP summit at Dev Connect and that's going to be a half-day event. In that event, we are going to talk about the process uh proposals, the EIP proposals and uh how protocol teams are

interacting with that. So if you are around please join us on 21st of September starting at 9:00 a.m. and you could find it and find more information on dev connect calendar we are added there. Um sticking to the same point Sam I also noticed that uh uh in the week of tab connect we do have an EIP editing office hour scheduled. I wonder would it be a good idea to have live session directly on 21st instead of having it on um 18th.

EIP Editing Office Hour Discussion

I guess 18th is Tuesday. Yeah. Instead of having it on 18th, we have it on 21st and have you there as well live connected with us. >> Uh 21st of November, you said >> that's correct. >> Uh yeah, I can do that. >> Okay. Then we would work towards that. We would invite authors in person. they can ask questions from there and you would be around to respond to that. Perfect. >> Perfect. >> All right. Uh moving on. I believe Sam already mentioned that he could not find anything else. Uh uh okay. Yeah. Else to share here in this section. So let's move on to the PRs for address review and consensus. Okay. This

PR has been open for a while and I believe uh we have not received any support for this PR. Um Sam also does not think it is important and Gajenda thinks that there are alternate ways to get it done. My question here is like do you want to keep this uh open or do you do we want >> We can close it. >> Yeah, we can close it. Okay. >> I think if other people haven't commented on it yet. Um >> all right every PR closed either merge I'm very happy about it bit by bit helps all right so uh there are a bunch of uh force merge uh open PRs uh if we don't

want to go right now it's fine we can go ahead and get it done later but here is another example as I was mentioning uh here Gajendra mentions that looks fine to me but the end call belongs to EIP author And here the EIP author is Vitalic Gutarin. So I'm not sure he he will be coming to this PR to respond to uh this individual whether he wants to allow this um uh this things this uh >> yeah this is why we have the stale bot right it should be closing these every so often. Um >> yeah but like does after 6 months and I believe this was just a month ago >> a couple.

>> Yeah. I mean it's it's not going to get looked at. >> Yeah. But here's the thing like since this has been open for over two months any editor can close it if they find it okay right we don't have to wait for >> no no we can yeah that makes sense cool so let's add that as a policy so even gajjudan can go ahead and get it closed get it merged by himself without violating any editorial policies around that um I think we have a couple of more PRs to be addressed. I think this is about uh again. Okay. Oh, it simply requires one reviewer from editors and may you want to take a look either now or later.

>> 513. Yep, I can do that. >> Awesome. Let's move on to the next one which is C. Oh, you have closed it. Perfect. So, I guess it was from your end only. Cool. We do have a bunch of other typo related uh PRs. We may not be going into uh each one of them. Maybe um editors can take a look and leave their comment and based on that some you can either close them or uh we can perhaps merge it after keeping it open for a month or so. I guess this was another example of like you know when author is not around and uh and I think yeah so he again mentions it looks good to me but

you have to reach out to author. So we have definitely a lot more example of these kind of PRs which are unnecessarily uh taking up the numbers count here. All right. Uh moving on to the next section. Um this is PR analytics and editors update. Uh we already have heard from Sam and um uh we can maybe look on to the next one. There is a schedule which is now live for all editors to add their u uh like availability. So we can host this editing office hour every Tuesday at 1600 UTC. We do have a agenda updated.

I I believe we do have editors already signed up for next couple of weeks. We will request editors to maybe take a look and add their availability for upcoming uh weeks. Uh next is EIP insight and I would rather like to pass it on to EIP insight team to um showcase or um provide the input whatever they want to talk about here. Yeah. >> Yeah. Um just two minutes. Uh okay. Uh thank >> yeah. Am I audible by the way? Uh hello everyone. Thank thank you for letting uh >> thank you for letting me demo today.

I'll walk you through what the EIP inside team have been uh uh h have been developing for past few weeks. Uh so let me share my screen. We aren't able to see your screen yet.

>> Oh yeah, I just don't want Can you see my screen now? Is it visible? >> Uh, it's just black for me. >> Yeah, it's upcoming. It's black for me as well. >> Yep. Just Can I say it now? Is it Is it visible?

>> Yes, we can. >> Yep. Forget just Yeah. So, uh moving on to the first thing we have. So we have built this uh live count uh this full Faka started with uh the Faka network update countdown. This gives a live view of uh uh ma uh next Ethereum's next major upgrades which is expected uh sakup and it gives all the live countdown of the blocks and epochs for example is already done and hoodie which is upcoming

upgrade uh in the test net uh it'll give the epochs and the slots which are left to be done. So and since the mainet date has hasn't been announced. So uh yeah this is what uh our first tool is it's a simple but useful tool for anyone following the network closely and it ensures everyone is aligned on upgrade timelines. So this is what we have. Uh and uh the next one is EIP board. So uh next we're planning to expand the EIP boards page. The goal is to

provide richer proposal tracking uh status overviews for all EIPS contributor mapping to see who is actively participating. This will also make the governance progress more transparent. So I guess this is the most uh important tool which is used by all the editors. So I guess this is this will help the editors more if we expand the VIP boards. Uh sorry do uh does anyone have any comments to us? I have a quick question like what is that we are going to add here like it already provides the list although I see the list is a little shorter it's not >> we just expanding the uh list of open like uh all the EIPS which is provided

here I guess the list is very short because it only provides 26 for now uh and but we're planning to expand it so that we have more broader overview of all the IPS >> right and I I see a comment ment by uh Sam here in the chat and I think it it make a lot of sense. If we can perhaps add PR title as well like we do have PR number and date but there is no title. So unless we click it we don't know what this PR is all about. So if we can get that that would be nice addition. >> Yeah. Uh we'd love to have that also.

>> Okay. I'll we'll look into it. Okay. uh we uh another upcoming feature which we have planned is uh uh contributors analytics page. So here I mean uh we are we still working on it but uh here we'll visualize activity like commits uh PS and contribute contributions across all all the three repositories and how how many additions how many deletions uh something like that but uh we're open to any suggestions with which you all uh want to give us uh for for which like uh it will help the editors and all the the audience so to get a a nice view of contribute contrib.

Contributors Leaderboard Development

We are open to ideas for this feature. >> I mean I would love to see a leaderboard if we can have there. >> Yeah definitely we are working on that only. So we will have a contributors leaderboard uh for weekly, monthly, yearly and over overall. So yeah, that's what we're working on right now. And at last, we do have this uh just a minute. I'll just take a uh yeah uh just a minute.

Onchain Transaction Tracker Introduction

Uh so we have also built this transaction tracker uh uh I mean it's uh the work is lift but uh we also plan to uh also uh it will allow us to monitor and analyze onchain transactions and what type of transactions are there for example type zero type 1 type two type three type four uh it will show an extension view of all the blocks which for example uh the latest block was this and uh okay what What was the base fee trend? What is the priority fee? Ga, how much gas is used and how much gas is burned for last few transaction which has been done. So this uh we've been also working on this.

Yeah, that all we have for now. >> A quick question. I noticed in the last call there was some feedback from Sam. I think something was not working. Um has it been fixed? I think the whole website wasn't working for me. >> That I think I I'm aware of it. It it was down for a few minutes. Yeah. Um if you may have update on that that is it working. >> Uh not this whole website thing but I think there was some specific mention. I followed the video later.

>> Uh can um never mind. I will go back and re revisit the video and try to follow up on that input. >> Yeah, sure. Yeah. >> All right. Would you want to maybe uh quickly share the insight for this month or maybe EIP's insight for the month of October? We can perhaps cover that. >> Yeah, sure. Definitely. Yeah. Uh for just I think it is loading at my end. Maybe

it is a bandwidth issue. Yeah, I mean I guess probably open the test just ah okay. Uh I opened the test net. Yeah. Yep. We have the side proc one ERC six in the review.

Is my screen visible? >> It is. And I guess the error was right here. uh I guess last meeting when Sam was trying to showcase it, it was not visible for the latest month or some something was breaking there. We were not able to reach 202510 but now I can see it on the website so it's working. >> Mhm. >> Very well. Thank you so much for this one. >> And thanks for the updates as well. All right, we can perhaps move forward with the next agenda item which is community update. Uh we are joined by PSK Sky today and Pierre Sky is looking

forward to have some feedback uh from editors and he has some questions. PS I'm happy to pass it on to you if you would like to maybe share your screen and uh talk about this topic. Um yeah, thanks Puja. Um appreciate uh giving me a mic here. Um so some of the editors might see me around the GitHub lurking around and doing some pull requests and sometimes uh getting into the arguments whether something should be merged or not. Um which partly is because I'm interested in the protocol.

I'm doing protocol research and I'm really building those ARCs. But on some other part, I'm also just exploring how the process is working. And um we're working on something that uh probably similar to what EIP insights look like uh at first glance uh but with different approach. So we want to you know help EIP editors and Ethereum community to collaborate better uh but do that from the more like product perspective and uh uh invite more different ecosystems inside. Um so it's kind of like a big lift for me. So

we're a very small team and uh we've built a prototype which we are showing to you know um some stakeholders in Ethereum foundation and trying to understand where we can get a support. Uh part of that involves uh EIP editing uh which we think uh could be like uh one of the lean you know initial features. So basically we want to propose uh completely abstracting EIP editors which are like rather like not editors but authors from needing to know how to use GitHub at all. So we can build and we've already prototyped the app uh where uh we can basically go to our um I'll share my screen in a second

where we can go to our portal. Um so I'm just sharing the whole screen. If you see something impolite here, I hope you don't see anything wrong. Just don't just don't uh just close your eyes if you see something not relevant please. Um so this is our portal DIP.box talks which stands for decentralization improvement proposals or uh also the way I frame it alternatively is decentralized intellectual property which EIPs are and um basically we are building you know also we have some statistics some analytics now like it takes a bit of time to load

just because we are in development database and the project is pretty much underfunded so I just do this for my personal you know experience and perspective. So we have some statistics around you know what are the flow uh what are the metrics on the protocols uh you know something similar but you know I I guess like the difference what where we are going is that this is a multi-tenant environment so you can see that this is ethereum dip so that's a subdomain and you know we can invite multiple ecosystems potentially invite like you know polygon optimism or even like some dows with time to join same

great process of RFC's um and uh what we're basically doing here right now is um we're basically having a GitHub integration where uh you know you can you have a form validation so you don't need to pass like form validation I'm not sure what it's like I need I have to clean my tokens right just let's see if it will work out. this is a GitHub authentication happening. Um so while it happens here so basically yeah so there's like a form validation

build as a prototype uh which uh also allows you know to link the IPs say if I'm you know out of link any IP I can just refer here some specific ones um we can have uh you know more better like we're working on improving this uh markdown editor here as well you know you have like tables built in and more features and then eventually you can submit a PR. Um now this one particularly uh requires uh some PR title. Let's say demo IP and then I can submit PR. Uh there's

something else. Let's say this one needed some description as well. and uh yeah so like I'm sorry for like you know being very uh prototypish here. Uh so we're still form like form validation kind of got broken somewhere. Uh but uh it's not super functional right now. One of the reasons is that we need Ethereum to actually install our app if we wanted to have it in production. So this is just a demo. Um but what happens is basically you know

Ethereum Dependency for App Production

here we have our fork for AIP's repository. Boom. We created an you know pull request where we requested some changes. Uh and that didn't require an author to know how to fork GitHub. how to do forks doesn't require anything but having an account on GitHub and our road map is actually to hopefully re release the need to actually have the GitHub accounts at all. Um whether also have better ability to understand the author statistics metrics uh and build you know this like cohesive all-inclusive workspace uh environment.

So uh I'm just here you know taking notes. actually took some bunch of the notes uh during the call that uh you know um kind of um features requested. So I also was um a little bit concerned that we are not really like doing something same which I insights does. So, um, yeah, I'm just really excited and curious if I can have some feedback, some feature requests, you know, if we can work on this project, what would be the features that EIP editors would really support us doing? Thanks.

EIP Editing Process and Feedback Requests

Thank you so much for sharing this demo. uh Psy I think I loved a few sections uh in your demo. By the way, for people who may not have watched it this earlier, Pier Sky joined us on u ecosystem project demo and we have an hourong uh video recorded on the demo of DIP.box and many other features that uh the team is planning to bring up in future. So please uh check out the link I have shared here in the chat.

Uh so I love that uh in your EIP it was colorcoded the EIP which are there in required to section like proposals which are already in final status it says final and it is in green and the proposals which are in review status and it is being kept as in required section it is in yellow. That gives a very good uh clarity um to people to know that uh if they want to move their status beyond review, they might either want to reconsider having a review proposal in required section or might want to first push the other proposal um up to a higher status. So this can also be moved forward. This is something we should do

it in EIPs.the.org as well. Yeah. Uh that's a very cool idea. we are going to get it from you. And I think I loved the EIP um uh creating document or the PR creation document very similar to what uh we have noticed in um EIPS inside but I think the one that you demoed uh definitely would be helpful for people who aren't very familiar with EIP GitHub sorry the GitHub process in general but they want to contribute people who are not very technical but they just want to contribute with uh simple edits or simple um suggestions.

I believe Sam also has a bunch of uh suggestions or ideas. Yes, Sam, if you would like to maybe share it. Um yeah. >> Oh, sure. Um I just had a few small comments. Um yeah, I think uh I don't know. It's a great idea to make the EIP editing process more accessible. And um I think that's an admirable goal. I think it's going to be a little bit hard to get Ethereum to install um the app, but uh not impossible. So that's about it.

>> Yeah, thanks. Um really appreciate that. just for the context. So we are talking to Nixa from I think is it uh ESP group uh ecosystem support um basically for some possibilities when there are any grants openings uh happen for us to really focus on that project because right now we don't have really resource to work on it. Um and one of her uh strong feedbacks was that that would be possible only if we have really strong consensus around the IP editors that that would be a clear you know improvement over the current processes.

Um therefore you know I'm here uh really curious to get all of the feedback what we would need to you know propose uh there. So today I just noticed in my in in my notes basically there was like you know type of fixers spell auto checker policies on finalizing key IPs dark liked theme um you know autoc closing requests actually like here is one of the think I would be able sometime maybe later to show the wireframes we have but we actually think that uh all of this kind of like pull requests when they are created as well we can actually display them inside of the EIPs just as one of the tabs of you

know what happens in that EIP and also um we can actually send some kind of notifications to the authors or champions that you know you know you have some backlog of things to do there. Um then availability calendar for uh office hours and bookings. Um yeah, these are just like some features I noted here and uh if you have any more um you know I'm I'm out here uh listening or you can always reach me out uh at Telegram. I'll add my here as well.

I think the last time something like like this came up um the big feature request that I usually have is integrate uh EPW into the editor. Um it's Rust project. It can compile into JavaScript or into WOM rather. Um it would be nice to be able to get live feedback on on the p uh proposals. Um but that's kind of >> uh sorry can can you can you link me the software particular speaking about kind of like I didn't get the the point right now. I heard like rust.

>> It's our uh tool for linting EIPs. >> IP warrior, right? >> That's a good name for it. >> Validator warrior. But like there is one GitHub action automation which just made me nuts and actually that was uh that was something that made me think that you know maybe I should work on this kind of like workspace. And I think it it start with W. That's what I thought. >> Yeah. So, this can be compiled and run in the browser. So, it might be useful to have it provide live feedback to people who are writing. Um.

>> Oh, great. So, this is like a automated basically like form validation on steroids that we could integrate. >> Yep. >> Cool. Definitely not that there. Cool. Yeah, thank you for for demoing everything. I'm happy to see projects like that.

>> Yep. Thank you. >> Thank you all. Um yes, we would love to see more projects, more tooling coming around. That is definitely going to be a strong support system for all editors given that we have a huge volume of open PRs and limited editoring hours. Very well. Uh I think that also brings us to the end of the agenda. My next item is just to figure out when is the next meeting. Um I in my initial proposal it was like we keep it generally on the Tuesday um third Wednesday of the month but next month the third Wednesday is falling on dev

connect week. So would we consider it moving a week earlier or later maybe 12th or 26th? Any thoughts on that? and earlier would be better. I just realized 26th will be Thanksgiving week so I'm not sure. So yeah, >> I mean either is is fine with me. Um I'm Canadian so I just had my Thanksgiving. >> Yeah, you have it earlier or uh later. I mean like what is there >> earlier?

>> Earlier. Okay. Yeah. Yeah. Cool. So let's keep it on 12th. Um I'm I will make the agenda accordingly and and let editors know about it so they know the change of week and we can have more people on call. That's pretty much uh it for today's meeting. Do does anyone have anything else to bring up here today or suggest something for the next meeting? All right. In that case, we can have our 8 minutes back. Thank you everyone for joining us here today. See you in the next call on uh November 12th. Have a

Meeting Conclusion and Next Steps

great rest of the day. >> Thank you for your great work. water.

Heat up here. Heat [Applause] up here.