EIPIP Meeting #123

Transcript

Loading developers...

[music] Heat. Heat. >> [music] >> Thank

you. >> Heat. Heat.

>> Heat. [music] Heat. Heat. >> progress.

EIPIP Meeting Introduction

Welcome to EIP IP meeting number 1 2 3. This is a very good meeting number and this is the first meeting for the year 2026. I'm sharing the link on chat right here. This is issue number uh 1886 on Ethereum PM GitHub repository. Let me quickly share my screen so we all can uh be on the same page. So on agenda we have a few items uh for discussion and review. Starting from call for input we do have a few items for editors discussion. There are some PRs which might need attention of editors as well as we will get updates from the topics

discussed in the earlier meetings. Uh so kicking off uh this meeting with the call for input. I would like to invite Sam to maybe um yeah talk about these call for inputs and see if we can close some of them today. >> Sure. So uh probably the most important one is uh number 400 force merge fusaka status changes. So um some of the authors haven't been replying. Um I just want to close out uh Fusaka. So uh please leave a comment on there. Um, if we get everybody's comments, we don't need to wait until the deadline. So, uh, yeah, leave a comment.

>> Sam, uh, there is an update on that. Um, I managed to get to all editors and this PR is now closed. So I think we can perhaps close this call for input. >> Yeah, I mean >> uh next up we have Matt's uh call for input for adding an associate editor role. Um that's people who can merge PRs but not h uh they aren't counted for calls for input. Um the deadline for that is February 10th.

Discussion on Associate Editor Role

Then if there's any discussion on that, we can talk about it. If not, >> um >> yeah, I I can see uh Yam on the call here today. I wonder Yam if you have any thoughts. I do not see your comment added here. So you can perhaps add it later or if you have anything you can share here as well. Yeah, I mean this uh this looks reasonable to me. Um I will read it after I will read this today and then also leave a comment on this today. But so far this looks good. So I will leave a comment this one. Yeah.

>> Awesome. Thank you. >> Um Sam, if I may uh um just share my thoughts over here. I really do appreciate the idea of having associate editor but I just want to have a clarity on this part like are we continuing two different role uh EIP reviewer and EIP associate editor if we are trying to merge them together we can perhaps let the tooling team know about it so that's my only not objection so far here but uh something that I would like to be um sorted off so from my understanding associate editor is the one who just uh helps EIP editor providing the EIP number.

However, EIP reviewers which we announced last year and Yaham was also one of the reviewers who turned out to be editor at the end of the day uh are the people who are actually reviewing these proposals. So my recommendation was that we should use the word EIP reviewer instead of associate editor. But I'm fine if people want to merge these two terms just want to have clarity so we can communicate it. I I think that the uh the ideas here that we want more people as yeah I said that people can add like these EIP numbers but that they do not uh

participate in the governance process that's the idea right >> uh no I allocation of EIP number is not a problem reviewing the EIP are the challenge that we are trying to address here because there are close to 400 open PRs. >> Yeah. Okay. So, yeah, I'm just reading the backgrounds again. Uh that's exactly what uh what I meant. So, uh they don't just don't uh just won't be eligible for formally voting on the governance matters, but they can edit the piece.

Yeah, I mean this this looks uh fine to me. Do we have like if we would u uh um accept this one, do we already have like some candidates for for this? >> Okay. Uh yeah. So um my understanding is as of now we do have one individual who actually acts as associate editor and he uh just allocates number but uh he isn't like a formal reviewer he definitely provides editorial feedback um but I'm not very sure about do we have the

candidate and will the process be any different from what we have got for reviewers. So, yeah, that's what I'm hoping to get some some clarity on. I mean I see the due date is February 10 and we can perhaps uh get more input from more editors on this one. But I would be happy to see this uh broadly discussed because it also includes one of the um EIP that would be changed with the help of this PR. So if we would want we can perhaps bring it to fellowship of Ethereum magician. I uh did share my

thoughts and concerns over here. Like I'm happy with the idea. It's just that I want the clarity on role of reviewer or the associate editor. I do not see Matt on the call. So I'm not sure if we would be in a position to address it today. Um yeah um I'm open to move forward unless uh anyone else has any final thought to add on this one. >> I mean we can we can call them EIP ballerinas. It doesn't matter really uh what we call them. It's just uh they get their names added in EIP editors. Miml and then they can approve pull requests I think is the the meat of this proposal.

>> Right. So in that case like while we have already um established a process of onboarding reviewer and the reviewer can eventually be an editor. Um again I I don't want to die on this hill but would love to um uh consider adding EIP reviewer because we already have a set of reviewers like if we look into this dashboard we already are tracking reviewers. Um uh I I just uh was hoping to um get this uh um idea that if we have to rename this one or are there new set of people who are joining as associate editor?

>> So is your intent that these people in that list be added as associate what whatever this title is called are those people going to be added to it? I >> I would love to hear the idea if there is a way of selection. I know this is going to be migration and people on this list are already making contribution. Most of them are client devs except as individual. Um I would not mind if editors agree to the idea that let's move these people um who are already doing the reviews as people who can actually merge because they are doing review they are already looking into PR they just don't have permission to merge them.

Yeah, I think that makes sense. >> Yeah, because I believe uh all of them are client dev except for this individual. Um but [clears throat] that's a call for editors. So my suggestion here was instead of using the term EIP associate editor which is already defined as individual who just allocates number and nothing more than that. I'm fine with the idea if the associate editor is also added as reviewer. So now he he would be in a position if he's interested he would be in a position to review and merge the PRs. But I I want the term to be consistent so it does not create confusion in the community.

All right, we don't have to make a decision today. Um just wanted to share the idea so people can think a little bit more about it and we can come up with the appropriate wording. But I am pro on uh the idea of adding more people adding uh providing more people the ability to merge the PRs. So uh moving on we have now okay I can perhaps talk about this one as well. So uh call for input best place. I did not receive much response here. It seems only Sam has responded and uh he is not in favor of moving it to the Ethereum PM repo. I agree with the idea and I'm fine keeping it in the uh eat cat herders repo. We do still

Discussion on PR Merging Permissions

have some some time left. If any other editor would like to uh want to add their thoughts which is different from whatever the sentiment is already, please feel free to do so. Otherwise, um we should be good to make a decision by the next meeting. All right, moving ahead. The last one over to you, Sam. [laughter] >> Yeah, this is just if somebody wants to make the pull requested changes, go go for it. Um otherwise, I'm just leaving it open so I don't forget to do it eventually.

>> Right. I know this has already passed the deadline but uh yeah u editors please uh take a look at it and if you have any response to this one perhaps you can add it so we can >> No, that one's that one's closed. Um >> it's already >> Yeah, it's it's closed. Um >> I'm just leaving it open until somebody actually makes the pull request to change it. >> Uh what is it? 100565. Okay. Okay.

So, do do we need to add this to EIP1? Yes, I'm I'm seeing that you already have a PR for this one. Um, >> yeah, it also needs to be added to EIPW. >> Okay. >> Okay. Awesome. Makes sense. All right. Uh, moving ahead. Uh, [snorts] next big thing is Faka EIP. As Sam mentioned, I have tried to uh kind of create a list of which all are pending right now. So we do have Fusaka Meta which hasn't been moved. Musaka Meta is dependent upon 7723. So I tried to pull out all the information. Uh 7723 have I believe three open PRs right now. The first one is uh

this one. This seems to be like a um farming kind of PR because they have just removed this space with dash. So um we can take a call and close it if needed. Um this is another PR which is open with respect to 7723. However, it seems like the individual was trying to add the definition of declined for inclusion and that is already added in the present EIP right now. So we perhaps don't need this PR to go. And the last one is again seems to be related to um again yeah it seems to be like kind of a spam u PR so not very sensible uh PR here.

No no no I think they have some sentence changes so it might need author's attention. Um yeah right. So um we have list. Okay. One last PR related to 7. Oh my goodness. Sorry. I think I made a mistake. The earlier one that I showed was for 7607. The first two here which seems to be like one redundant and one related to farming. But the 7723 PRs are 1 2 3 there. Um this one is okay. So I find this a meaningful one. I would definitely love for author to take a look at it. Uh it seems like um we have

uh uh mistakenly added statuses instead of stages stages. So as per my understanding this is for network inclusion stages and stat statuses are only draft review last call and final. So I have just made this PR to update the wording. It should not be stages uh statuses. It should be stages. So definitely this requires editors as well as author's attention here. So we are waiting for this to get closed.

Uh so uh if with these two we are left with 1 2 3 4 five PRs. Out of those five we already have received approval for two PRs. may require editors approval only to merges to final. So this is for 7910 and we received approval from the um author of the proposal. So it is only waiting on editor's approval. So either of the editor if you can approve it this can be merged. But this also means that we might have to close these two PR which is 7910 related. Here author has left specific comment that they uh that

he doesn't want these PRs to be merged. So we can actually close these two simultaneously. Similarly for this PR uh this is to move it to the final status for EIP 7935. We have already received approval from both the authors here. Just waiting on editor's approval and this can be merged. Uh with that done we would still be waiting on three additional EIPs. I have listed out the issues here. We are waiting on uh um author's response on that. Then only we will be in a position to move these proposals to final. I would like to take a pause here. If anyone has any thought, ideas, anything else to suggest like how we can proceed

even faster, please. Yeah. All right. uh in that case I would hope editors approve the other two PRs and we can get two more EIPs moved into the final status and we'll wait I will try to communicate with uh with the uh authors and try to um get them merged as well. All right, moving ahead. Uh, uh, last week, not last week, this week, we had EIP editing office hour and, um, from that office hour, there were a few suggestions that

EIP Editing Office Hour Suggestions

came out. Um, I have just added the AI notes here for reference, but I have also added these uh, specific point that Gajender whom I do not see on the call right now. Yeah, he is not on the call but he has left some uh ideas to be shared with Sam and other editors if this is possible. So while reviewing we identified that some of the authors um keep TBD instead of todo and um Gajender educated us that todo is a marker that is read by bot and that stops from moving forward in the status of review when it comes to in draft it will pass but not in review. So

the request here is like can we have uh TBD also added next to to-do. So this is a question specific for Sam. Yeah. >> So it it's not that to-do blocks going into draft, it's comments. So it doesn't matter what you put inside of an HTML comment, it'll block it. So um >> Yeah. >> Yeah. Yeah. No, the idea was like it is not readable. So what Gajenda did some of the author wrote TBD and Gajender suggested him to write todudo instead of TBD because the understanding is tudoo can be read by the bot not TBD >> neither of them are read by the bot is

what I'm saying >> okay perfect in that case cool uh so the next suggestion was to have a label of force merge or typo as we have discussed in the past that there are so many PRs that is being reviewed by him but he isn't able to merge it force merge it and we always bring it to you auto automat get it merge so he was requesting if there is a possibility of having the typo or force merge label he can perhaps add it and it will add notification instead of tagging you all the time I mean either way is fine but that's a suggestion >> um yeah we can definitely do that yeah >> okay

PR Labeling and Merge Process Discussion

uh moving ahead said uh there was a ping to editor which he thought that may not be that valuable. Uh I'm going to open the PR here. He already merged it. But what he was trying to say that uh the bot should not ping editors. It should be merged by the author himself if the PR is done by the original author. So that's some kind of bug. I just wanted to point it out. CI bug or something like that. >> Yeah. So, um, the review bot can't handle the case where only an asset is edited.

>> Um, that's been a limitation of the tool for for years now. >> Mhm. Okay. Okay. So, um, I'm wondering if we have any issues open for it that this is to be considered or is it not possible to do it for a set? [laughter] >> It's it's possible. It's just none of us are. Okay. like since Panda Pip left um we don't have anybody who maintains the bot. >> Okay. Okay. Nevertheless, Sam if you can create the PR maybe we can use it. Oh Mark is here. So I don't know Mark if you can perhaps take care of that. Uh so if Sam if you could open the uh issue uh we would share it with the community and

whoever have some expertise may Yeah. Awesome. Thank you [laughter] may look into that. Um so there was this another PR which had Lint issues. Okay. I already had a word with you Sam. So we noticed the Lint issue here but you mentioned that it would not be blocking the PR, right? >> All right. Yeah. >> Okay. Perfect. So we this can be avoided as well. Cool. Uh the next item is citation section removed from draft. Uh this is not from the meeting. this is uh something that uh is another topic for discussion that we would like to bring it in uh maybe for editor's attention. I don't know if this is a tooling error or

something that we should consider updating it. So when we look at this citation, this is not something filled by the author. It is done by the tools that we are using. But I noticed that this keeps this thing in draft. when I looked into other EIPs everywhere it is mentioned in draft irrespective of their status if it is final if it is living or whatever it is. So I was just wondering do we need to keep this draft thing or can we update the >> yeah so we can perhaps update it and um yeah if we can update the tool that that can be removed.

>> Yeah I'll open a bug about that. Okay, perfect. All right. Uh, moving ahead. Next, we have these four reviews. Um, I wouldn't want to go into each one of them one one by one. Maybe editors can take a look at their um convenience. Uh, but um, we just wanted to bring it to attention that most of them either would require um, force march or u, I think I see that one. Okay. or maybe uh Sam's attention. Okay, you already have CFI for this one, right? Yes. 395 says done. So maybe you can or anybody can take a look at it later. So just

listed some of the proposals which might require editor's attention or review. Here there was a bunch of more. Why I'm not able to find them? Did I miss it? Looks like that. Okay. Nevertheless, we will get back to it. Um, moving ahead, updates on topic from earlier meetings. So, yes. Uh, so the first one was grant more editors force merge permission. I don't know if we have any update or uh is the idea of adding more editors with merging permission will help with this.

Updates on Previous Meeting Topics and EIPIP Meeting Structure

That's on me and I just forgot. >> No worries then we can take it next next week. Um best place for call for input we already have discussed so we can skip that one. Uh network upgrade names. It seems um Sam you are working on something that might help the tooling without adding any field. Is the idea to fetch it directly from the meta or uh is there any alternate? Perfect. So we can perhaps mark this as closed. I don't know if we can close this in fellowship of Ethereum magician.

We'll keep it there. But at least we can understand that this issue is resolved. I wondered um is it um is there any uh timeline by when we can see um this thing activated or will it be activated with your new e? Um >> it'll be on the new one. Yeah. >> Awesome. We'll keep a note of that. Got it. So um this was the next thing. restructure and renaming it again came up from the last EIPIP meeting. It seems that there is not a strong support of the rebranding of EIPIP meeting as ACDG.

So um I believe the idea is we will continue having the EIPIP meeting and uh maybe we can take out the inferences or any action items that we would like to share it with the codev in the ACD meeting. I do not see much of editors response here. So if editors because I understand this the merge was basically to have editors say in the meeting because ACD meeting is mostly clinv and editors do not participate actively. So if you have any thoughts ideas on this one please add them here. Um as of now it looks like people do not have much interest in having ACDG. Um there could be a possibility of having a breakout

room meeting uh in future for anything related. The next one is again from EIP office hour. Earlier EIP office hour. Um okay. I think so that the suggestion from earlier EIP office hour was that we we should have a placeholder where we can have some kind of guideline for EIP documentation, formats, test cases and things like that that new authors are always asking questions for.

Excuse me. Excuse me. So for that I have created this contributor.md that we discussed in the meeting back in October 2025. So this contributors dot okay sorry there are two of them let me so in in 20 October 2025 it was discussed that we should have um okay I think I have mistakenly added both links to this one yeah this is the one so the idea was to have some kind of um file which does not

update EIP1 frequently but that can be referenced from EIP1. So if needed we can uh we can refer that to we file we can refer that to the community and um to make this contributor's guideline um Sam I have taken heavily um reference of of your text that you have added for author's guideline it was floating as a hackmd file so um I believe the contributor MD will give this a very good root place where authors can find it easily and um yeah this file currently contains

information about um how to do dos and don'ts for authors just simple rules um again related to assets that that sometimes create confusion and there is another section which is for nonauthors now there is idea of champions and other contributors community contributors which sometimes come up with PR so this just lists like what are dos and don'ts for them and we also have added a few guidelines for editors and reviewers who would be um looking into it. So uh with this uh this thing in mind I have opened a PR um uh with contributor.md and um that is uh PR number

this one PR number124 and u um I have also made an associate PR in order to refer this contribution guideline in EIP1 along with few other tiny updates. So, um I would request editors to maybe take a look at these PRs and if they have any suggestions, thoughts or approval, please go ahead with that. Um I I'll like to take a pause if anyone has to add anything. Okay, I'm I'm looking at the comments.

>> Cool. Thank you. >> I think we all like this. So, this this looks great. Yeah. No fix. >> All right. Yeah. So, kindly take a look at the uh text and uh yeah uh if there are any fixes uh maybe suggest that and we can approve and keep on updating. So with this we can maintain contributor.md but we would not have to update EIP1 as frequently. All right moving ahead analytics. Uh we already have discussed about typo fixes in the previous meeting. It seems like we are getting an increased number of type of fixes. How many? 93 out of close to 400. Hundreds are type

PR Review and Contributor Guidelines Discussion

of fixes we are getting. We should definitely make some hard rules around type of fixes. Um yeah, we need to deal with it. Next is a schedule for office hour. Um >> oh sorry one one one question like how are these type of fixes categorized like is it just like a oneline change or like what's a type of fix like how does the bot um >> yeah lab so um I mean for example okay for example we can take this one so this is also would be considered as like sorry let's get there.

Let me see if he's actually suggesting some something or is it a type of X? No, this is a suggestion. Um, my bad. Let me go back to another PR here. Okay. So, here in this commit as we can see this individual is suggesting just this one one space replaced by hyphen. So this would be kind of considered as type of fixing or some update. And these type of PRs are increasing every passing day. So [laughter] we have almost 100 open PRs like this.

>> Yeah. I'm Yeah. I like I I know this is um especially part like this adop farming. Um >> Yes. and the sentiment which we have about this like I'm I'm not really sure what I think about because I don't really like these kind of things. Um but on the other hand like spelling mistakes or or these kind of things they in the end they will improve the quality of the um so I'm not really sure what we should do here but on the other end to brief and maybe maybe a more broad question is like um if you if you would like fast these things that that's I think not something what we would want

because then we would get like an even larger influx of these things uh like these typo fixes. Um yeah, I'm not not not really sure what what to do here. How how because we we can't really block these kind of things because I mean they are in some way valid. Um yeah, okay, that's a good suggestion by Sam like uh we basically would need a llinter I think like a llinter and a spell checker for the EIPs that that would need to work. >> Yeah. [clears throat] So, back in the day, we had code spell and it did a fairly good job. Um, but it's not perfect. It only does known incorrect spellings. It doesn't verify that every

word is correctly spelled. So, didn't catch everything and there's a bug in their Docker container that Anyways, long story short, it caused problems. Um, the new version of EIPW does have a spell checker built into it. Um, it's just we haven't been able to deploy it yet. Yes, Victor. And then Carson, you are muted, Victoria, if you are talking. >> Yes.

Um I think there two aspect here. One is that the reason that we felt this these are not fulfilling is I agree with you and partly I think why I think these are not good is because these are like trivial fixes that doesn't have the level of expectation when someone is considered a contributor to this repos repository. So I think one way to do it is actually we run a one time fix of everything with let's say spelling and co and then AI just for anything that is trivial let's just if

they are act indeed trivial the other level of the problem is actually acknowledge uh which is like we started to see one or another ERC's or EIP but not necessarily to the level that they're considered a an author because they might not be the major proposer or the person who contributes significant part of it. Maybe they like fix a an error. Let's say if someone comes in and says this formula has an error. I think that's a valid contributions and should be included but not necessarily considered an author for

that. So I think it would be nice for us to as a EIP editor group to think about what is a meaningful way for authors to recognize contributions that's meaningful but not necessarily author level. So these are my two comments. Yeah, I think uh to comment on that, I think those are very good points. Um and maybe because you you were talking about offers maybe there are then two levels of offer ship here. Is that even the right English word? Well, um like we have the EIP offers. So these are like in the header of the ERP and we then we also have the um well the commit offers.

Addressing Typo Fixes and Contributor Recognition

Um and the question then is I think in the end like what would we consider like if it is a typo fix. Um I think that the consensus there will be that we do not want to grant these um EIP authorship and maybe also not authorship of the commit itself or is this maybe not the thing you are thinking? I I think using commit author as a concept has its merits. I would probably let author decide who they explicitly credits as contributors rather than fully depend on the commit uh history of

authoring. Sometimes bot does that. Um so one thing I have been thinking about is maybe we should have a new um metadata line in the in the header of ER ERC ERC or EIP says in addition to contri author there is a line of contributor and then author can add them manually either via GitHub handle or uh email address just like they have in in in the authorship uh list. But that's one way. We could also have an acknowledgement section, but that's less metadata based. My my personal feeling is that we should let author credit uh we should give authors options to credit

uh contributors. Carson. >> Oh, you are on mute, Carson, if you are speaking. >> Uh, no, I was just waiting to Yeah, I wasn't sure if you could point me out. Anyway, um, yeah, no, I like those ideas. Um, because I think it's important to incentivize like participation in the project, right? Like that's how a lot of people get started with open source projects is just making like doc fixes or spelling mistake fixes, things like that. But yeah, on the other hand, we don't want this to become like a distraction of a

million little, you know, fixes that they're farming for like reputation as formal authors. So I think the distinction between like big C contributor and little C contributor makes sense or you know having some kind of acknowledgement section like they should get something out of it cuz especially when we fix um like adding in um uh spellchecking back into it, right? Those kinds of things will disappear. So we still want little things fixed. Um, but if they're not contributing meaningfully to the definition of an EIP, then yeah, we don't want them to like get the kind of the type of credit that infers that they did something that they actually didn't, right? Um, so yeah, I

think like an acknowledgement section or something like that would be really good. Yeah, and that's that's I think like a very good idea. And then just to add on like this add adop performing stuff like these adop um well bots or whatever how you want to call them like will drop these adops they will just look at the commit history. So what we could do here is I think I really like this uh suggestion of adding contributors to the EIPs. Um but what we could do here if there are like spelling uh fixes or typo fixes or like we might have a suspicion of like addup farming. What we could do here is people could be added to the config

bridges field of the EIP but we will just uh we would take this commit out so they are not added to the git history but maybe this is like a good Yeah. Yeah. Exactly. Yeah. This >> I think that that's like a fair balance to strike. Oh, the other thing I was thinking was it since like you're talking about like the basically this being used for firing. So I am assuming that a lot of these fixes are coming from the same probably couple of people who have kind of automated this kind of thing. Um in the near term we could like just request that they combine any um like any of the the you know proposed changes into a single um pull request rather than having like multiples right

um if they're kind of doing it to like you know up their numbers or whatever. Not sure if that's an issue here though. Yeah, but likely if it is like a bot or like a team, what they will just do is they will create multiple GitHub accounts and then they will say no, it's they are like different people. So then we would not be able to combine those. Um but yeah, I I I like the general idea of that to combine these in one PR. >> Yes, sir. So, we should not give two shits about airdrops and airdrop farmers.

Discussion on Airdrop Farmers and Workflow Adjustments

It's it's outside our process. People will use whatever stupid ways they want to assign like tokens to people. We should not care about that at all. Um, we shouldn't change our workflows. We shouldn't make our ourselves do anything. Like, even if it's just changing the commit author, that's too much work to deal with airdrops. I don't care. Um, we used to get people to combine their uh spelling mistake things, but we changed it to do it separately because um if like 10 different p uh like proposals are all edited in the same poll request, you need to get 10

different author approvals to get that pull request merged and then it just sits around forever. So, it's kind of a trade-off. Um, if we're just going to be force merging them anyways, it doesn't really matter too much, but that is why they're split right now. Um, yeah, I think that's that's all I wanted to reply to there. And I would like to bring one other issue that generally increases the number are this kind of typo fixes like this is fixed grammatical. Typo means I'm using the word typo but that also covers some kind of grammatical or formatting issues. So for example here this is for EIP5. Now EIP5 has been finalized and the according to the

process it has to wait for author's approval and author uh may not respond because they may not find it that significant to come back and respond to these two changes here like we added s it was missing here and I don't know there was something else here so for these types of ps they will also increase the number I wonder if this can be just taken care by bot might be helpful to decrease our present Open PR numbers. All right. Um, we definitely need to

think a little bit more about it. Maybe we can give ourselves some time to think more and maybe write down some more concrete words in here. What can handle merging? Yeah, I mean of course not but um here's the thing like if more editors or reviewers may have this merging power or if this can be tagged just like u Kajjendra suggested we can have a label and use it then it will be easier for people who have permissions to merge it force merge it may be able to do it at one go I have tried to put together some text here in which like we are just trying to suggest these nonauthors and contributor

contribute.m MD guideline we can perhaps enhance this guideline even more like what kind of typo would be acceptable and what not would be acceptable and uh I I hope that this might help us in future when we start sharing this information with people then if they are making uh PR for type grammar or style correction they would know what what things can be added in here I mean that's just one possible way of helping us in long run. Okay. Um yeah, I I realized what I missed uh in uh in the agenda item. So I wanted to quickly uh check on this uh

Addressing PR Review and Approval Process

these kind of PRs. So um Gajjender could not review these PRs and um he requested Sam's review. So Sam, I wanted to list them. Maybe I can do it after the meeting. I will add it for for reference so it can be reviewed. So there are some some this kind of like you know dependency which is there on files and up on our website where two or more editors approvals are required. So we do have these kind of PS wondering how do we address this?

>> I mean we should just review them. Um I think it's just a lot of us don't have a jackal knowledge. So I don't know for this one in particular who's going to review it. >> All right. Yeah. Yeah. As we can see that there are a bunch of them with this kind of PR. So we are just trying to like segregate the types of PR. So we should be able to handle them um independently and hopefully we'll be able to decrease the number of open PR. Well uh that's pretty much on agenda. I would request editors to maybe take a look at the sheet and uh if you are available please um please um allocate

yourself the new uh date and time for office hour. It is very helpful for the community to know that in advance because when we have the agenda created in advance, they come back and add their PRs for review and they are always looking forward to have a word with editors so they know what they are doing wrong and they get their proposals reviewed. So please take out time add your comments and we can take it from there. Um and uh I think that's pretty much on it on January insight. Wow. We have made nine new EIPs, three new ERC's and yes we are we have moved five and we

are hoping to move more on final status. This is pretty good. I mean like wow we already have 44 EIP reviewed by Sam in January. Good. Thank you so much Sam and Victor and Gachendra and everyone else who are reviewing these peers. This definitely will help us get to a better place. Um that's pretty much for today's agenda. If anyone has anything to bring up, please feel free. We still have some time.

Catching Up and Future Proposals

Yeah, I wanted to just take a note that uh I have not been able to review much of uh these so far, but I'm really trying to also to uh catch up and to uh to get back to well the time when I was not an editor yet, but to get back to that place. Just wanted to let everyone know that. >> And yes, you are also slated for next office hours. So yeah, we are looking forward to have proposals reviewed by Yes. Yes. Next week it has to happen, >> right?

All right. [sighs and gasps] Uh, anything else for today? If not, then perhaps we can wrap up early. Uh, see you all in the next meeting on February 17th at 1600 UTC. Thank you everyone for joining us here today. >> Thank you.

Oh, heat, heat. [music] Heat up here.