EIPIP Meeting #124

Transcript

Heat. [music] >> [music] >> Water thing.

Jesus. >> Heat. Heat. Oh,

heat, heat. Heat. Heat. [music] Heat. Heat.

>> All right, welcome to EIP IP meeting number 1 to 4. This is issue number 1934 on Ethereum/PM GitHub repository. On agenda we have uh e call for inputs, editors discussion and uh some discussions from the previous meeting along with uh the EIPS insight for the month. We are joined by various editors. So without further ado, let's uh get started with call for input. I know I usually call Sam to maybe talk about call for input. Sam, if you would

not mind like taking care of this, happy to jump in. >> Yeah, thank you. >> Yeah. So, first one up is the links to Unicode technical standards. There are two pull requests that need to be approved. Um, it's in a comment on the call for input. Uh, please take a look when you get the chance. Um, adding associate EIP editors. Oh, I guess this one finished. Um, yeah. So, it looks like I'll be closing this in favor. Uh, we'll be adding a new tier of editors. Um, next up we have removing the online serial from the citation. Um, this one closes on March 7th. So, please

leave your comments if you care. Uh, next up we have a status tag in citation. Maybe I can provide some >> background right over here. So this PR was created in order to fix a bug which is here um uh which which was detected in the last meeting saying that we are not having the citation as per the status. it is only showing the draft um in the in the uh proposal but um uh it was suggested that we should fix this and I kind of made this PR to fix uh uh the issue. Now uh the PR shows status

as per it but based on the previous meeting suggestion I removed it for living and final EIP and kept it for review and any other status it is uh it was reviewed by Kachendra Singh in the last meeting and he had a different idea like um it he suggests that we should be having this citation for all other status except for uh uh living and final. So people should know that the proposal is not ready. So this call for input is requesting editors to share their thought like what is the consensus like where should we head this PR to?

Should it be only for living and final or should it be for everything else but living and final? Yeah, I I don't see any uh comments yet. So editors might uh take a look and provide their input on that. >> Yes. Just just to ask like this is on the uh EIP's website then right to to to add these uh this the status to the >> That's correct. Yes. So um this is like on eip.ethereum.org.

So if we look at Eddie proposal earlier it was showing draft for all of them. I think it should be showing it right now as well. EAPS.ethereum.org. If we go, it should be showing draft for all of them. Uh yes. Uh so if we can see it is showing draft uh even if this proposal EIP1 is in final status. So that was a bug that was detected earlier and uh this PR is an effort to fix this bug bug. And um the question here is under what status we want this to be dis displayed. Should it be for living or final or should it be for everything but

I hope I answered your question. Okay, cool. Yeah, kindly take a look and based on the decision we should be in a position to like either merge this one or fix the PR to show whatever is decided here. Going on to the last call for input. It is about anformational EIP. While merging is not depending dependent on the decision. This is about the general decision. Uh because this PR is to be merged the proposal into draft category. But the question that was asked by editor in one of the office hour was should this PR head to final or to living a status. This is anformational EIP. Um yeah I think I have received uh

one or two responses here. It would be nice to have more editors response right over here like what what do we think in general like the status for such peers such EIP should be? >> Do we do we anticipate changing them in the future? I think the living between living and final status the difference is the expectation of whether that EIP's content will be legitimately updated over time.

Are we seeing that uh in this particular EIP? >> Apparently yes uh because this is um upgrade nomenclature proposal. So it suggests that like how historical ATM upgrades were named. But I understand that in the past >> makes sense. >> But I understand in the past editors had this preference of not having um uh living uh proposal uh because it would be a good idea to have the propos proposal reached to um a status and kept as a standard. So that's the confusion here.

>> I'm I I don't have a preference for this particular one. I think it has some standing to be living. It has it also can just be a historical information. So I'll defer to other VIP editors. I think the default will be final, right? >> Mhm. >> If no one has a strong preference, the default will be final. So yeah, what do other editors think? >> I'm in favor of going to final whenever possible. Um I think we can make exceptions for our own internal documents because we have a process for for editing them. But for external documents I I don't think we should give them living status.

I hear when you say internal you mean governance documents and >> yeah stuff where we are the authors like EIP editors are the authors >> and it governs the EIP process like uh the handbook and the EIP1. >> Yep. >> Sounds good. I I think that's a good line to to think. >> I would appreciate adding uh uh comments so we know that this proposal is heading towards final. Uh that's what I have added as an context because we see this uh proposal 6953 which kind of uh documents the historical upgrade

activation trigger point and it has reached to the status of final. So it should be fine. I just wanted to have clarity so we know where we are headed. >> I I think I'm inspired by uh Sam's comments. One, in addition to whether there's an expectation of the EIP being updated in the future, uh our editing model, our authoring model require uh authors to be involved either of approved or most likely to write them themsel. So if an EIP is living supposedly some living organizations who pledge and commit to f further maintain

them will have to be there in place to kind of further uh update them and then these group organization should be the author. So I think that that is what Sam's comment about internal uh basically um has in inspired me to think. So I think this one now seem to have a stronger in um reason to be final actually. >> Yeah, I think that makes sense. >> Yeah, that makes sense. Yep.

Cool. Uh so yeah, please take a look and uh add your input so that can be closed as needed. And for the overdue Sam, you can perhaps add the decision and close it. Moving ahead, the next one is overwhelming GitHub mentioned the problem and possible solution. I have just picked up this morning picked it up this morning. Um I wonder what editors think about the problem. I understand with like close to 600 PRs including both EIP and ERC repositories editors are getting pinged to every PR do we

>> just to just to just to add on like because I I just raised it on on Discord um because like uh you get emails and that's not like the the way I usually check like my my GitHub activities but uh now that I'm well the Ebot mentions like all the EIP editors so I get like a mention all the time. So also on Bobo I got the ping and uh this is starting to get well very overwhelming because I'm also realizing that I'm now starting to miss mentions on uh auto repositories uh like okay can you review this or can you comment on this and that that's that that's not very nice because these are like um I I would say

that that this is somewhat like more urgent that these needs immediate attention Um, so yeah, and I also saw that that that Sam well has as maybe a way to fix this, but yeah, wondering how the other editors um tackle this this well the problem of the overwhelming mentions of the apps. Okay. Oh, I can I can maybe just ignore.

Oh, right. I'm not sure why I did a check this earlier. >> Yeah, that makes it >> I I I basically give up using email notice as a as a notification. I have my filter that I will go to and uh if that helps I can share my my filter URL um of what I would uh like to uh review like what I what's my pending box for the for the EIPs to be review and there are a bunch of other tools too um email is not like very helpful in this cases because of the way how like

how the notification was generated. there per rep repository, right? And then you have that anyway. Um, yeah, no, configure your email in uh filter or use uh like advanced tools and I think it's more proper like you won't have that problem if you're an author, but uh you will have this problem when when you are an an editor and editor is probably the only one that's being spammed uh uh being spammed across all the EIP and VRC's. >> Yeah. So a follow-up question um like would there be because like if someone would mention uh me on an EIP or or an ERC then I would like a notification uh

but not the um notification because that that's that that's that's a actual [clears throat] problem or the the cause I would say that if bot mentions uh the EIP editors uh for well in most cases and I would like to I think disable those notifications. And I'm not sure if you want to change the bot because I think it is also like helpful because you won't get a ping always because like if an EIP editor needs to look at it, it would also be nice to to filter on on on these these um these mentions, but so specifically to not get a mention um when Ebot mentions you, but to be able to search

these kind of mentions so that you know, okay, I need as an editor to take a look at at this if that makes sense. >> Sam, what do you think? >> Um, I mean, personally, like I would just remove the ats from the editor not the uh editor usernames in the bot. I think like I think we all know that we all need to look at EI or at these poll requests um because then we regular notifications would become useful again.

Um, I don't think it's at all useful to add editors on every pull request. >> I have a thought on this. Uh, like I was also thinking uh how to maybe handle this problem. I was wondering like uh if the bot do not instantly add editors when a PR comes into a repo, it should when the PR is actually ready for editors review. For example, there are so many peers which only requires like first requires uh one of the author's approval and then editors notification to get adm. So if that can be adjusted in this way that editors do not get ping if a PR has to ping uh authors first. So

yeah that could be one way but again the solution that Sam is suggesting would be way more better because then in that case editors won't get any ping. The one downside that I see at this point is like if editors are not being pinged on that maybe uh the author wouldn't know whom to ping in if he wants someone's attention like yeah that's one thing >> yeah what we what we maybe can do there because I think when I just think about like 2 minutes more that maybe indeed the uh bot so like we move the mentions from there uh but uh as as you mentioned puja um that uh it's it's very nice that

that uh the EIP offers also know what to um uh approach um what we can do then do is just put it like uh into the back takes um maybe that that's also what Sam already meant uh such that it is clear who you should approach but it will not uh create like this notification or this this actual mention Yeah, maybe when we are considering fixing the bot, we can perhaps uh update the message. Instead of doing an at to the editor, a bot can just send a generic message uh in the as a comment saying that uh if you need help, you can

reach out to these editors. But that is like back. So editors do not get pinged, but authors should know whom to ping if required. Yeah, that'd be easy enough. >> Cool. So, we are uh looking for some edits in bot here and perhaps this would help resolve the problem for editors. And thank you so much for bearing the pain for so long. I understand there's a lot of notification going on. Every time the bot is triggered, you are getting a notification.

All right. Uh let's move ahead. The next one is PRs for elders review and consensus. Um um I forgot why I added it specifically. Okay. So it seems like um okay my question here was like this is three text for EIP 7904 but it did not ping the author of 7904. It only pinged all the editors. So that was my very first question and again that is pinged for editors. So if this is something that editors would want to maybe take a look at it today.

>> They're only editing an asset file, right? >> Ah yeah. >> Yeah. So there's a bug already open in the bot for this. Um we just haven't had the chance to look at it. >> Mhm. Okay. So in in this case we are just waiting for um asset and I believe there are some typos are also being addressed here. Uh so in this case do we not need author's permission at all? We >> we should um yeah >> okay okay then in that case I I I think that u uh the bot should also ping author which it failed to do here.

>> Maybe an there's a there's a bug in the architecture. Well, not a bug, but there's poor architecture in the bot where it can't figure out what EIP this belongs to. >> That's why it just pings all the editors. >> Got it. Okay. Got it. Okay. Cool. Just wanted to surface this uh issue again. Uh the next one is uh Okay. So, next one is again pinged to uh editors only. And I noticed that one editor says that this is fine. But obviously we'll be waiting for other editors to maybe take a look at it. So whenever you get a chance maybe take a look and do the needful for this particular PR.

There are a bunch of typos that I have added which ideally should require consensus from editors. But there is this one which uh suggests that um the author does not want this to be mared like he says that editors please close it. I request editors to please close this PR. So maybe this can be easily closed uh because he seems to be one of the author of this proposal and otherwise depending upon editor's um um like uh taking a look at rest of the PRs these can be handled either closed or merged. So these are like low hanging we can close all of them >> or merge or merge. Yeah, whatever works.

Thank you Sam. Um moving on to the next item it is like updates on >> so so one one question um so um is there like because we have like a a merge command for the ebot so that's like reviewing uh I think you have to also approve the review but and say something like looks good to me um but is there also a way to to instruct the bot to close a PR >> there is not um generally speaking There's a this the stale bot that'll eventually come along and close it. Um but that's about it.

>> Okay, I see. >> Yeah, I wanted to have this conversation. In fact, I had a little bit of it with the DAI team of Ethereum Foundation last week in Denver. Um I have a proposal like we should come up with different agents that can help editors. I could think of three or four agents. One could be the reviewer agent which actually reviews these kind of PRs and be able to close it on its own by by having a policy in place. So if we have a policy saying that if there is anything which is typo and that is a legitimate typo and we would want that to be merged, we don't need to necessarily wait for anybody's

permission. The the this agent can do that. So that would definitely reduce the dependency or if we would still want that editor should have a look. At least this uh agent can flag it. We don't have to wait for another editor to flag it with the limitation of postmerge permission. We can have this agent flag it and whenever right editor is taking a look at those list of uh PRs they can merge it. So there are a few ideas I would love to share but it seems like there are other priorities. So just taking a step back right here but wanted to share it would be a good idea to have different bots added to the EIP

repository might be helpful. >> Yeah for for the bots uh I I think you like you you mentioned agent so I'm going to assume that these are like AI bots. uh I don't think I will be comfortable with like giving these uh AI bots or uh agents the rights to actually close uh PRs or like in general like like rights on the EIP repository. >> Yeah, I would give like I I would love an AI agent that can take care of the lowhanging review fruit, but anything that closes a PR or merges a PR should still be a human's job.

>> Yeah. Right. And that's why the other proposal was like you know even if we don't want to get it close at least it should create a label and just keep on labeling it all by itself. We don't have to have human intervention to leave uh like add the label. It can be done by agent. Well we hope we have some help on that side having some um um agents added to help review these proposals. okay moving on to the next one. Uh updates on topics from earlier meetings.

I don't know if we have any update on this side as we understand that there are only a few number of editors having the force merge permission and that kinds of increase the open number. wondering if there is any um thoughts on having more editors and or if it is still a work in progress. We we should be fine. I think that um because like one of the EIPs which should just Yeah. So these typo PRs like uh oh yeah the 7873 one like that the alpha already requests like closing um I think it

would be great if we can also um add to the bot that it can handle this um I'm not really sure how to do this like because it should not scan for certain text. I think um maybe like the cleanest way to do it will be to let an offer make a review uh signal like request changes and then uh scatter forward like close this EIP or something like that if that makes sense. >> Yeah. Yeah. I can think of multiple um multiple areas where bot can be helpful with limited permission. And we do not want to replace editors with bots, but we would want that these bots be um helpful to editors and they make their

life easier. Yeah. >> Yeah. Yeah. Yeah. Because like uh so the bot now handles that if an offer of an EIP so it's like an external contribution to an EIP. So that's contribution from someone who is not an offer. Um and if an offer then reviews and approves it then it will get merged which is fine. Uh but it should also have like a way for office to close it I think. >> Like it's Yeah. Yeah. >> Yeah. >> All right. Uh moving to the next one. Um it is coming from an older EIP office

hour. I I suppose the request there was to have a collection of EIP documentation formats for test cases and reference implementation. Recently we have added this contributing empty that talks about the normal contributors norms and editors like dos and everybody's dos so people can take a look but we still do not have a placeholder for uh documentation of this uh test references test cases and reference implementation. Do we see a best place to keep it somewhere? Do we think we can add it on EIP template or contributing MD or have a separate file altogether that new authors may be able to refer to?

>> Sorry, I missed what content are we deciding to put in a file? Uh so in one of the earlier meetings where new contributors are joining the um EIP documentation they are wondering if we they can get some references of implementation like how they should write it down the test cases and things on on documentation EAP document. Yes, >> I feel like that belongs in contributing. I think that makes sense. >> Okay. Okay. Then we can create a section for these and I create from that try to come up with some templates that can be used as like guidelines or best practices that people should use for

adding their reference implementation in test cases. >> Okay. Um so the next one is uh >> I uh I like to be involved in that. Uh I'm actually pushing for um more sharing more reference implementation especially from non-authors. So yeah if there is any link or discussion thread I should be on love to be on there. >> Can you Yeah. Can you ping me on discord?

>> Yes sure that would be great. Thank you so much. I'll >> thank you. >> All right. Uh so the next one is action items from last meeting. I'm just taking a quick look if there is anything pending. Most likely we have finished up on all of those. So if there is anything pending, we can get back or maybe added it into the next uh meeting agenda. Okay. And uh observation from incoming PRs, we already have discussed that.

Yes, I'm looking for more um editors to please sign up for um office hour. I guess we don't have it for March 10, March 3rd and 10th. Uh so if any editor is available, please add yourself uh to this document. We would love to have more signups on this. Next is EIP insight. Let me quickly check if the team member is around. Yes, I see Danush on the call. Danush, would you want to maybe uh talk about the comments that you have added? Yes, please take it from here.

>> Yes. Hey everyone, I'm Dhanush from the EIP Insight team and uh we wanted to quickly walk you through a few updates from our side and get your feedback. So, I would like to share my screen just a minute. Um and yeah, so yeah the first thing go so the very first thing is uh so uh the new board that we are proposing so this uh so yeah this particular board section uh this uh instead uh so this instead of relying uh on the t uh the labels uh distrib distributes the uh open PRs into

few content filters which is a process type. So it has these filters which uh distributes the open PRs which needs editor review according to typo new EIP status change website uh and tooling tooling basically has all the uh all the ad folders or bumps or uh or CI/CD pipeline changes uh so yeah and the EIP1 consists of all the changes which uh is done in the EIP1 particularly and there's one more uh filter which is content edit which basically uh align distributes the uh uh it is a filter which uh distributes uh

EIP uh sorry the PR into changes which is done in the EIP content of the proposal. So yeah, we have this new board section and it has a few other filters like create uh which if the PR is waiting for more than 30 days or if it's between 14 to 30 days or it's a new relatively new PR. So I would want your uh like uh comments or maybe review or your feedbacks on this particular board section.

The uh priority filters is that uh based on like when the PR was created or when the last reviewable event happened. >> Uh it's basically uh in respond to last reviewable action. For example, if it's review or commented or something like that. So yeah, that's one action. Any other feedback? So >> looks great so far. I I'll take a look at it when I um >> go through and start reviewing.

>> Yeah. Yeah, definitely. So, yeah. Uh so, next item we have is uh basically we made this new contributor analysis pages which basically uh shows everything every activity that a contributor has done be it an editor be it a reviewer or be it a normal contributor. So basically we have this timeline uh timeline filters which is 30 days last month last year and we custom range too. So I'll basically put it on 30 days for now. So it has repository breakdown how many commits, how many PRs, how many reviews and how many comments have been done in each repository and we have this recent activities uh which shows what last

comment last comment the last review and we have the distribution AC across all the repository and the most uh thing is the ranking uh which we have here. So it's based on the total score. Total score is uh basically what we have done is uh we have scored everything the whole activity comments be it comments be it commits be it reviews and everything. So yeah we can change the distribution across the total activities or maybe pull requests the most pull request and the most reviews also. So yeah, we have this thing here. And another uh thing is we have this uh whole contributor space.

So we can basically search a contributor for some sound here and we can go through the profile and we have this activity timeline thing which shows uh the whole timeline whatever is in this. So yeah uh this updated every 6 to 7 hours I believe. So yeah uh that was just oh everything about this page. So yeah any review any feedbacks >> I want to say thank you. This is great contributions uh to all the uh to all the teammates um who created this board

and a contributor analysis. This is wonderful. >> Yep. Thank you so much. Thank you so much. >> Yeah, >> I guess one um maybe point that uh I believe the team would be looking for a decision is like as of now we do have two links. One for EIP boards which was there in place and one is boards new. So if uh editors feel comfortable then they can perhaps uh switch boards new as the main board and we can replace the old one with the existing one. And this is good. This is something new addition.

Thank you for sharing. Uh so yeah. Uh next I would like to show the inside for February month. Uh so we have 10 draft EIPs, one in ERC and we have uh three ERC's on review status. Uh three on last call and uh yeah, pretty much that. Yeah. And uh there are three EIPs under EIP uh three EIP in final status and two uh two ERC on the final status and three got into stagnant uh three EIP got into stagnant and one and one ERC on the

withdrawn and the leaderboard shows like this the top top editor is G1 tech and yeah that is pretty much it for this month's inside. Thank you for having me. >> I have one question if you don't mind. >> Uh in Denmark, I met so many people and there was this one question that was asked by uh uh by by someone and I would be curious to have the answer like in every upgrade we have a bunch of EIP getting into the upgrade like as core proposal. Is there a way to find the number of uh um authors who are outside the client development team and they and

their proposal are getting into the upgrade. Why this is required? We want to understand like how good process is understood outside the client team like they know how network upgrade happens so they can work with the process but are there contributors who are not the part of client team yet they are contributing and we would love to reach out to them to understand if they understand the process as well. Yeah, we we can pretty much have it. Uh yeah, I mean yeah, we will surely look into it.

>> Cool. Yeah, I'm happy to maybe um help you around like identifying who the authors are not part of client team because I don't think it is being captured by the normal MD file right now. Um but we if we can come up with some ideas, some processes around that that would be super helpful. It helps to understand we are decentralized. [laughter] >> Yeah, definitely. So we'll look into this. >> Cool. Cool. Thank you so much. >> Yeah, maybe maybe to to mention like um we also have um Charles Cooper for instance. Charles Cooper is a developer for Viper. So that's technically not a

client developer but very close to the process. Um I think that's maybe the um there maybe like two things like we should have like an entry point for people who will want to contribute uh um and I think like EIP1 is already a great start but it might look a little bit um well very daunting because it is like a very big document and the other thing is that it is also maybe a bit scary to get into this process because uh have these calls and then there are all these client developers and that that might be very also what scary to join. Uh that's also like maybe the the more human part of it

and that's maybe also something we should should figure out if this is actually an issue and if that's the case um how we could address this. >> Yeah. Right. Yeah. So there is currently like there um two different things that goes in parallel when an EIP is being documented, drafted and uh considered for upgrade. One is EIP status and another one is EIP stages. And I see that this line is blurred. There's a kind of gradient that uh that is there when it is only being discussed among the client teams. But it would be a good idea to have a fine line. So any external contributor should also be able

to understand that. All right. Uh I think uh that is pretty much it for today's uh um agenda. I wonder if anyone has anything else to add, share, discuss or maybe propose for the next uh meeting consideration. All right, it seems like we are pretty contented with where we are right now. I would really appreciate editors taking a look at all open call for input so we be

in a position to close them on time. And please also uh take a look at the um schedule for next office hour. If you find yourself available, please add yourself. Thank you all for joining us here today. See you in the next cough. Have a great rest of the day everyone. >> What's up? [music]

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

>> Heat [music] up here. Thank

>> you. [music] Heat. [music] >> Heat. Heat. [music]