EIPIP Meeting #131

Transcript

[music] >> All right.

Welcome to EIP IP meeting number 131. This is added to ethereum/pm repo on agenda. Uh we have call for input editors discussion item and topics from earlier meetings for sharing today. Let me share the link in the chat for people to follow. The issue number is 2231. Um I'm wondering Yuhong, do we want to go ahead and get it started with call for input or should we wait for Sam for a few more minutes and we can cover other items and get back to it?

>> Yeah, I mean we can't really decide anything without Sam as so uh I guess we uh yeah we can't do anything at this point. So I think we should move on um until Sam is here. >> Awesome. Um yeah, I think there was a a couple of items that was suggested by Sam in the meeting office hour yesterday so we can perhaps discuss about it and move forward. So the first item on editors discussion is contributing.md. The PR is uh essentially merged. One point that Sam raised yesterday uh in the meeting was um in the contribution guidelines, there is

a section don'ts. Okay, let me share my screen quickly so that will be easier for everyone to follow. Um so in the contributing.md, this PR is merged and this section talks about don'ts for EIP editors and reviewers who are reviewing any PR. Uh he specifically shows his concern with respect to this discretionary merge policy for typo or formatting. As per my recollection, it was mentioned in the call that sometimes active authors do not accept typo-related PRs, and they want to ignore those PRs.

But it is on editors if they want to merge it. So, from my recollection, the decision was that um it will be merged only if we figure out that the author is no more around to say yes or no about it, or they they say that, "Okay, we want to merge it." The reason behind this was there were so many typo-related PRs which are open for unlimited period of time. I want to check here if people in the room agree with this discretionary merge policy for typo or formatting fixes.

>> Let Let me quickly read this thing again because it is for active or non-final EIPs without author approval. Yeah, okay, so that's that's I think uh fine. Um yeah, I I think I also agree because I mean, if the if there's like a clear um if the intent of an EIP is clear, uh but there is a typo in the text or um it renders wrong on the on the side, then I think this uh this is fine. Um but this would of course only be done for this kind of style style uh PRs.

Um Typos I'm not entirely sure if I agree with that, but like clear formatting fixes that uh yeah, that that that sounds very clear to me. Like if it's if something renders incorrectly, um then we should approve these kind of things. Uh but yeah, that's maybe on on the point that I wanted to touch on later. Like, I think also with AI tooling, if you want to do this, then uh we should also check that PRs do not mess up formatting.

So, that we that if there are like draft EIPs, or uh if we have uh EIPs moving, especially those moving to final, uh then we should also have an AI, I think, or some tool some CI tool or some something else checking on the CI if the if it's rendered correctly. And if it's not, then the CI should uh fail. >> Right. Yes, we will get back on the bot. I think there was an action item. Uh we will get there. But, for this uh this I I gathered that the concern of merging typo is fine. Uh I mean, we don't need to make any more changes to this text

because this is only for active or non-final EIP. For final EIP, we most of the time understand that there is no water to provide further approval and that to say yes or no or whatever, and they keep open for unlimited period of time. So, editors can merge if they find it right. All right. Um so, with that we can move on to the next one. I guess this was also reviewed uh in yesterday's office hour meeting, and uh I suppose only testing part is pending.

yeah. Yeah, and uh yeah, whatever fixes Sam suggested, it looks like uh Cyber Centry has already implemented. I would leave it here only because I would love for Sam to take a look at look at it again before this PR can further be merged. So, um if if if it is reviewed, very well. If not, then I will bring it up in the next office hour. Next item uh on the editor's discussion was status update and checklist for authors.

We briefly discussed this checklist in the last meeting. What we would want to do here is uh if we would want to have this thing added to the contributing.md. So, this checklist basically talks about what an author EIP editor should take a look at at the PR before like sending the PR. Or when the PR is for changing different statuses. So, most of the things are already covered in contributing.md, but there are still few things which are not covered. So, what we are hoping to do is get this thing added to contributing.md.

That's item number one that we would want to finalize today. And the second as Gajender in the previous meeting suggested that we could all probably add it to the bot's comment. So, editor can take a look at it before uh approving that PR. So, in this uh bot's comment, we have added the smaller section of the checklist. I would request the editors to maybe take a look at it. For example, if there is a new PR um the editor will verify the valid PR number is allocated, if the EIP template has been followed, and discussion tool links or requests are all valid, and

ensure that proposal is valid for EIP repository. Sometimes uh people propose a proposal which are not for EIP, it is for ERC repository. So, just make sure that they are valid for the right repository. And and if an editor finds all these checks done, then after high-level overview of the proposal, they can perhaps uh approve it and get it to merge. And similarly, there are small checklists for review and last call. For example, we don't want to have to lose in review, so it's a gentle reminder to editors. Of course, they know their duties, but uh having these things added on bot would help them get there.

does this uh look okay? And I wonder what people think about these two of items here. >> Yeah, uh for for the uh so for the previous point, for the uh auto stagnant bot, um Sam, if if you could re-recheck that because Sam has don't call me, Sam. if you could recheck that PR and if you approve it, then I will also approve it uh so we can can get that thing merged, so we can uh also uh make uh EIPs like a stagnant because this should should really uh uh well, this should happen.

Um for this EIP status promotion guidelines, I will check this. This idea itself is uh is also very good. yeah, I already said that I wanted to bring up that like AI tooling, but I think that um what is it also let people do is we should make it very easy for people to point their AI agent to these kind of rules uh so that this AI can also directly check it. Um and if like these rules are like very clear that we can also program these, then we should also add them to the to the CI.

Um but especially the agent point, I I think this this this would be would be great because well, for instance, like something that what I keep uh finding in uh draft EIPs is that for instance, this RFC keywords uh so RFC what is it 2119 is not linked to this uh RFC. Um these kind of things should be added to like this doc and then an agent can either check it or uh or the bot. And maybe the bot already does this, but uh for all these rules. Cool. Yeah, then then let's say you buy we. Yeah, nice.

>> As Sam, uh in that case, please uh take a look at the uh document. Our links are added to agenda, and uh if there are any feedback, feel free to add them. Well, uh we have Sam on the call now. Sam, we were waiting for you to get to the call for input. Um and we are already done with editors' discussion now. Would you want me to maybe click on it, or if you would want to share your screen and go ahead with that? >> Oh, uh go for it. You can share you can click on it. I'll >> So, this is still open.

>> Yeah, so where did we leave off on that? Has that been Are we waiting on somebody to approve that, or merge it, or Yeah, I guess it's just merge this. So, why haven't you merged? >> Yes. Let's see. >> Yeah, it just has some conflicts to change here, so Yeah, okay. I I can resolve the conflicts. That that that isn't too bad. And then I can just just merge. So, this will merge, and let's go back to the next one.

Uh yeah, I guess there was an action items for editors to maybe take a look at it, and if they would like to add their input. Let's go through each of the messages here. One favor, one opposed. >> Yeah, so I don't think anything's changed on 409. Uh we're still waiting for other editors to chime in, cuz I think we're we're tied right now, right? We have >> Yeah. >> One in favor, one opposed.

Shh. >> Yeah, but the two states I think it is two opposed. So Sam is weakly opposed and lifetime is opposed. >> So at this point there is clearly no consensus, I would say. >> Okay, I feel like this has been open for long enough. Unless you object, I'm going to close it. >> Yeah, that's fine. Let's let's close it. We are done with these two. Let's go to the third one. Oh my god, contentious one.

>> [sighs and gasps] So it is there. Just to provide some background here, there was a decision but this one more editor changed the decision saying that they want to abstain I mean want to abstain. this issue was closed after the after the decision but yeah, let me try to bring it back to the conversation. Yeah.

Yeah. So this was reopened. Oh my goodness. Sam, I don't know if you >> Yeah, I'm just reading through it right now. Not going to lie, I have not been following my keeper of consensus. >> [laughter] >> Um I'm just reading >> this has this has more than usual So yeah. Yeah, I think this was reopened in in a confusion that maybe keeper did not consider one editor's involvement or the role in the decision-making process. So that was the main reason to open it but I guess it was clarified.

Yeah, considering Sam about this was a specific caveat around this. But >> Oh, that was resolved. So >> That was resolved. So yeah, we can >> Victor has been an editor for like 2 years now. So >> Yeah, yeah. Yeah, so I don't think that will change the decision which was there. But there are more responses that people can go ahead and yeah. >> Yeah, um I think my preference is still to we have associate editors.

I I Like the way it's written for the the pull request that we're planning on merging here, I think is um a lot more general than just assigning EIP numbers. So I don't know. If we If Matt's okay with reusing that, I think that's the least contentious approach. Um but you know, if if we did feel like that's not the best way to approach it, we can always do something different. I don't know. >> Yeah, I mean it is very clear that EIP coordinator and EIP associate editor do not have the same set of responsibilities. They are quite different.

And the proposal here already encapsulate what are the responsibilities and boundaries which does not conflict with any other rules in present. And going through all the comments here, it is very evident that people believe this is already happening and they are open to the idea, especially EIP authors. Whoever have shined in, they mentioned that they they really need this rule and we already have gone through back and forth. Like if this does not work, we can revisit after 6 months. If there is there are any downside of it, we can definitely go back and forth. So it does not seem like a bad idea right now. I understand that not all editors are on board. But again, we we work in this ecosystem. Not every

time we will get we will have 100% people on board. So, if there is no potential downside or like direct harm people are seeing, I think we can go ahead with the decision which was already taken before. >> Yeah, I don't I don't care if you want to do that. Um, let's do that. Um, >> So, we just need to merge this sorry, close this PR. Merge I think it is it was already merged because the decision was made in the previous meeting and it was already merged.

>> Yeah, so we can just go ahead and close this issue. after this issue there was another one that was created which obviously is open till November 4th, which is about the nomination. Here I am being nominated as the first EIP coordinator, but it doesn't mean that there has to be only one coordinator. There cannot be more coordinated. Those can get on boarded. Ecosystem is very big. We have multiple coordinators for all core dev call. We have execution coordinator. We have consensus coordinator. If people think that there are more people who can come and support, they are welcome and we can follow the process to go ahead with that.

So, for now on this call for input, I see that we have one two favor and one opposed and we are still waiting for two more editors to chime in. And call for input is open till 4th of November. So, I'm sure this will be open for for the next meeting or so. So, uh, going back to 413, Sam, can we like um, add or close the call for input just by restating that on that decision.

>> Uh Yeah, I suppose we can. I don't I I would really much rather get Matt on board with whatever we're doing here. but yes, I think we can >> Yeah, I think this is something that we can prove by doing it. Sometimes it take time to bring people in. >> Okay, so Matt says that number three seems good. So wants to add a few points here. Okay, so yeah, I can do that. So Okay, and then

Okay, there. Closed. So with that, we have gone through all four open call for inputs. I believe after this meeting there would be one, which is November 4th, and we hopefully be able to close all of them. Uh uh all the rest of the call for inputs. Going on to the notes and action item from previous meeting, I guess we have it here uh on action item.

Um I'm I'm sure this has already been done, and this is all about the stagnant bot that we discussed already. Uh 409, we are waiting on Gajendra's input. We can work on that. Yes, I think this was the agent.md or instruction to LLM that Yohan wanted to share. So, I'll pause here, Yohan, if you want to maybe talk a little bit more about if there is any progress or if there are ideas being generated. >> Yeah, it's actually interesting that I raised a similar point in the previous EIP IP. So, that's that's that's interesting.

I have not opened this PR. So, I should actually do that. Um but I wanted to go more into to detail um on how we how we want to use AI tooling. Um okay, let let let let me first ask because I think I will be much more opposed to this idea what I'm going to propose now than I'm now because now I'm in favor of of of this. Um so, I think that we should start using um most people are most people are writing ERCs and EIPs using AI. This itself is um yeah, I think I think this is this is is fine. Um but what would really help

in reviewing these EIPs is that they also help agents to find whatever rules we are enforcing here. and I would hope like to know like like Sam, what what what are your thoughts on um yeah, AI tooling um on um well, basically the the PR opener side. People who will who update or create a new EIPs and ERCs. >> People people are going to use them. We need to make it as easy as possible for them to do it correctly. >> Yeah, exactly. Okay, that's that's great.

I'm I'm I'm wondering because some of these rules we can add to uh EIP W. Uh but some of them them we can't, but the nice thing is with agents is that they can now infer specific things. So for instance, like if I make like an an a review and I think we should actually add these rules if they are not yet into uh contributing and the or or like this rule set. Um that's each time if you have an abbreviation which is like not a super uh uh well-known abbreviation, then uh it should be defined before use.

Uh and also that an I an AI checks that if something is defined um or pointed at that this is um already uh well, it it is like a forward reference like okay, we have this constant or like this thing which will be introduced there. Um or that it is already previously uh introduced. And this is of course something what agents can uh very nicely do. I would not say that they are 100% correct. Um but this should at least give like well, flag 95% of these kind of uh of well, I would say editor yeah, rules.

>> That sounds reasonable to me. >> Cool. Then uh I will go ahead and figure out like yeah, like we we should add this to some agents in the company. So, I will open a an PR for that. Yeah. On both of the EIP and the ERC side. >> Awesome. With that, we have one action item pending on EIPs inside team. I don't see anyone on the call here today, so maybe I can check with the individual A saying.

And um yes, we have to secure an engineering support for EIP tooling that we are looking for. Um I'm hoping to continue the conversation in the in the Devcon. I'm hoping to meet quite a few people. Maybe we'll try to get some engineers work in the direction, but yes, that is something that we are definitely considering. Um next on the agenda is schedule for office hour. I think we do not have anyone from October 27 beyond. I am unavailable for these two dates, but if any editor is available and would want to take the meeting, I can definitely help out with

agenda and everything done in an advance, so it can be um taken care of, but if not, then maybe we can resume right after the Devcon from November 10th onwards. So, please feel free to take out time for uh adding your name um to take this office hour. Okay, next thing if I can do. Okay, perfect. Um yes, it can be moved to Wednesday as well if editor is available. Quickly taking a look at the EIPs inside for the month.

We have 24 proposal in last call from um EIP side. That's because of Glamsedam EIP moving into testnet, so um that's good, but I still feel that this number is less than the total number of EIPs in Glamsedam. So, there is a high possibility of a few EIP which are not in last call and they are part of Glamsedam. Uh I know it is not responsibility of coordinator, but it is uh of an ecosystem contributor. Let's try to bring this up to the next uh ACD meeting.

Um maybe we can quickly take a look at uh EIPs.ethereum.org to see if the Glamsedam matter is No, it is uh still in the review. That means there uh not all EIPs have been moved to the last call. So, I think it is a good point that can be brought up in the all core dev meeting tomorrow. Um unfortunately, I'm traveling, so I may not be able to attend the call, but if anyone from this meeting is uh there, please uh yeah, try to bring it to the all core dev coordinator's attention.

So, we can have all the proposals moved to the last call. And that's pretty much uh on the monthly inside. And yes, that's Yes, please go ahead, Yacine. I I think I can stop sharing. We have covered all the agenda item. >> Yes. Uh so, one more thing I wanted to uh well, at least raise at this call. Um because uh it's very clear that we have like a lot of EIPs and ERCs open. Uh I'm also getting a lot of pings like, "Can you please review this?" Well, uh I can, um but the thing is and and I think this is where my main struggle currently is.

I'm obviously now using a uh AI agents to to help review uh EIPs or ERCs. Um but the thing is and this is what what what I think makes me uncomfortable is when I was not an editor in well how do you say it? Like an official editor. Um what I did is I just picked EIPs which I wanted to review. Uh where I had like this knowledge of. So these are mostly uh EOL EIPs. Um and I'm also getting a lot of people coming to me which say like okay, can't we just automate the entire process to use AI?

And I think that we can do this to some extent, but um that at all editor uh um um actions that we should still read the uh EIP ourselves. Because an agent might think that everything makes sense, but we can if we also have like our own knowledge also of the entire ecosystem which I believe AI can currently not have. I think that we should not automate like moving for instance like a new EIPs to draft or to review or whatever. Like we can use AI to help uh review these things. Uh but we should still read them ourselves.

But the problem is that this is what I found mostly um yeah, how do you say this? Uh what I found very hard is on the ERC side. Like I simply I the only thing that I can do there is I can review ERCs strictly for editorial rules. And I think I stated this on on the last office hour previous week. Like this kind of reviews is basically that you are reading another language. Well, okay, that's maybe an exaggeration, but that you are reading another language and you are simply just checking if like the grammar and like the spelling of this language is correct, but you simply do

not understand what you are reading or if it makes any sense at all. Um so, and this is also to some extent um uh um for the CL, because I'm absolutely not a CL expert. Like I I treat the entire CL as an as a black box basically. Uh so, I simply I I think that it is very nice if an EIP or an ERC, especially in the draft state, uh can already get like an initial review or like some pointers to authors. Um because if you also have like this this uh domain knowledge, it is very helpful for authors to also point to like, okay, uh did you check this and this and this, or well, this looks okay, but did you also think of this situation, et cetera, et cetera. I think

this is very efficient for the entire process of the ecosystem on both on the EIP and ERC side. Uh but yeah, the the thing is that I can only do that for EL EIPs. Uh and not for ERCs, and also not for CL yeah, I I I yeah, that's that's basically what what what the state is of the really a question. I think that the main point is what I wanted to make is that I still think that we should uh uh we can of course use AI to to review these uh these documents, but in the end we should still read these and uh um uh check if if it makes sense before

giving like a final decision, like, okay, we can move this we can merge this, or um uh move to final. >> That that sounds exactly like what I what I would want from an LLM. Like, I I basically just want it to comment on uh pull requests, giving the exact same kind of comments that I would give, um and just keep repeating that until it approves the pull request and then it shows up on an editor's desk. They read it and they're like, "Yep, that makes sense." And then they approve the PR. That's kind of the flow I'd like it to to have.

And yeah, um, also I'm also completely lost reviewing ERCs. I have like I review it to make sure it follows our rules and that's pretty much it. >> Yeah, okay. Yeah, I see. I see. Yeah. Yeah, I I guess what what we should try to do is, uh, well, we should also find some people on the CL side, Justin for instance, um, but also maybe on the ERC side. Um, Let's hope that we can we we can find some people cuz I really think that that would be very helpful for the entire ecosystem.

>> Uh, I just want to jump in and say that I'd be more than happy to review the CL-related EIPs from a technical perspective. Uh, on the CL side, I believe things are a bit more simple. Like the IP, in my opinion, should be a pretty much like an overview of what the IP is like is planning to do with security considerations and little things like that, whereas the nitty-gritty implementation details will live in the specs. So, I I think it'll be be a bit easier for the CL EIPs.

>> That is a great point brought up by Yihong. Yihong, thank you for that and thank you, Justin, for offering help. I I think we should have more editors on board, definitely on ERC side because we have very less editor for ERC, but on EIP also, we have over 500 open PRs. So, having more editors from both EL and CL side would be helpful. So, Justin, I think [clears throat] for one, Yes, [laughter] I was coming there. I'm coming to the point that Sam made. Yes, we would love to have you as an editor. So, uh just to begin with the EIP editing process, what what has been agreed upon so far is like we want to notice contri- continuous

contribution of a contributor before advancing them as an editor. Um but that's just a process point of view and 6 months is not too long. So, if you could please go ahead and add approval whatever PR you review or add your comments or whatever, everything will be pulled up and it will be easier for us to just like, you know, uh move it to the next step of being an editor. >> Yeah, that sounds fine. I can uh review things and leave approvals and uh etc.

>> Yeah. In that case, we will start up capturing your comments and anything that is related to review on the EIPs inside dashboard where we do it for all other editors and eventually we would be happy to like follow the process and have you on board. If you find more developers interested in becoming an editor, we are all open because we need more people on board. So, please share words with developers community as well. >> I think Jehan [clears throat] might also be interested. I mean, he works with me on the consensus layer specifications and he has a very keen attention to detail and uh >> Awesome. Then we will definitely reach

out to Jehan as well. All right. Uh with that, I have a few ERC Yes, please go ahead. >> Uh I was going to say I I guess one last point is I I will be officially stepping down as keeper of consensus. Um I I really haven't been able to keep up with uh my work on that. So, uh for the next EIP IP meeting, we should probably have a vote on who we want the next one to be. >> As much as it is sad for us that you are stepping down from keeper of consensus, but it's a good suggestion that we can perhaps add it to the next agenda item and we can make the discussion on that.

>> Yeah, just want to say Sam, thanks a lot for this for doing this. Yeah, thanks. Thanks a lot. >> It's been fun. Thanks for Thanks for letting me do it for so long. All right. And thank you Sam. I just noticed that the PR is merged 4569 and the call for input is closed and that the brought my attention to um issue 414. For generally when we close a call for input there is a PR or actionable item.

Uh if we look into 414 it says that add Pooja as EIP coordinator, but we do not have any PR. I wonder if there is any suggestion where it could be documented. >> That'd be an EIP one kind of thing I think. >> Uh yeah, I mean there is a section for all emeritus editor, present editor. We can definitely add EIP coordinator over there. So maybe after the deadline has passed and we have a decision we will open a PR to update EIP one. Um with that I think we have covered most of the agenda item. Just final announcement on Devcon 8.

So we are organizing a Devcon 8 community hub which is called as EIP hub. I can quickly share my screen for 2 more minutes so people can have a look at all the discussions and all the links that we are sharing here. So for EIP hub uh are organizing four days event for four different programming. Um we are going to have first day, day one as the process one, day two, protocol and EIP clients, um uh and other upgrade-related discussion will be there. Day three would be application and ERC standards, and day four would be enterprise and implementation of that.

We also have a alumni invite added. We are also organizing a workshop for um beginners, students, um because there are a lot of professors and students joining uh the Devcon event. So, we are having a uni day. We are talking about how people can get involved in the Ethereum ecosystem, and this particular workshop will be about um how to contribute into EIP. We already have received close to Oh, over 500 um participation interest. I'm very happy to share that uh this would be a great place to talk about EIPs. Yoav is joining in person. So, if you have

questions for editor, please bring it up. And yeah, we are happy to talk more about EIP, how we can get more participation. And of course, if there is uh someone in the ecosystem more interested in doing reviews for other EIPs and ERCs, we would love to on board people uh to help support the present And uh that's pretty much it for today. And if we can finalize the next meeting for EIP IP, are we fine with uh week three?

>> Oh, week three is uh Sorry, sorry. Uh I jumped in again. No, week three is fine. I was wondering if it is a Thanksgiving week. Okay, cool. Yes, we can do it. >> Sorry, sorry. But which day is this is this uh 18? >> 18. >> 18. Yeah, that's fine, I think. Let's see. Uh yeah. Yeah, that's fine. >> Okay. Then we can keep it for 18th November at 1600 UTC. Justin, you are more than welcome to do all the reviews async, but if you can take out uh time to just participate in uh this EIP IP meeting, that would be super helpful because this is a place where we expect all the editors to come in and

yes, uh let us know what do we do next from process point of view. >> Okay. Yeah, I'll try to join. >> Sure. All right, any final comment from anyone for today's meeting? Otherwise, we can wrap up a little early. Very cool. Thank you, Sam, for everything you have done here. We will definitely miss you, but I'm going to add it to the next agenda item to have the vote for the next keeper of consensus. We will work towards onboarding Justin. I will take a look at the uh proposal document of EIP 569, how we can move forward, but the simplest process we

already have discussed. Yo, come on, I'm looking forward to meet you in Devcon, and we will be looking forward to see more people, more participation in EIP process. Thank you, everyone, for joining us here today. See you on the next call. >> Thanks, everyone. >> [music] >> Oh.