EIPIP Meeting #130

Transcript

[music] What's up? [music] >> [music]

>> Thank you. >> Heat. Heat.

Heat. Heat. [music]

Heat. Heat. >> What's up? [music]

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

>> Heat. [music] All right. Thank you so much. Welcome to

EIP IP meeting number 130. Today, September 16 and the agenda is added on Ethereum/PM issue 2190. I'm also sharing the link in chat for people to refer to. Well, on agenda, we have call for inputs as usual, editors discussion item. There are some topics and updates coming up from the previous meetings. EIP insight. I see some note provided by the dev team. They have some uh progress to share with us and community feedback update. Uh maybe we can get started with the first agenda item. Um that is call for input. Uh Sam, would you want to maybe um

share your screen if you want to? Otherwise, I'm happy to share >> for call for input. Uh yeah, let me just find my window here. Where is it? All right, let's go take a look at some calls for input. Uh yeah, so Unicode technical standards is still here. Have these been merged yet? Let's see. >> So the one merged, another one is still pending.

>> Yeah. What is this? This is waiting on. So we have an approval. I guess we're just waiting on another approval that yeah, I guess um and we have to resolve some conflict. So, yeah, I can take take care of that. Um I still needs another approval, I guess. Um I don't know why why didn't that work. That's strange. Um anyways, there's enough approval so I can force merge this. Um I'll just fix the the things and yeah, then we can close that one. Uh now we have on uh add associated EIP editors.

Um >> so here I would like to mention one point. I noticed recently that uh Gajjender has not added any of his input and this decision is based on unanimous. >> Yeah. So it it is past the deadline. So we can just remove all of the editors who haven't replied. Um I think that's how our our thing works. Um >> Yeah. So, does is this ready to be merged? I would assume so. >> It's in the draft status.

>> Yeah. So, as long as this is good to merge, then we can merge it. Um, yeah. Uh, closing affirmed. Yeah. Okay. So, and then this should just merge. Cool. And then we have this one here, which is strict rules for changing authors. All right. Uh where' we leave it off on this one? So I am opposed. We have one in favor. Um yeah, I guess do we want to talk a little bit about this one? Um

yeah >> I think both editors who have added their response appear on the call. So [laughter] >> yeah okay >> we would be waiting for some other responses to be added here. >> Um >> maybe a friendly ping to editors to maybe >> get it. I guess that's the best we can probably do for now. Um, EMIP editors.

Okay. And then uh the last one here which is uh EIP coordinator. Yep. Okay. Uh, so I think I need to still go through and read this one. Yeah. So I haven't looked at this one yet. I will do that after this call. Um, yeah. So that's it for the uh call for inputs. >> Awesome. So >> yeah, maybe maybe just because on on the uh so this EIP coordinator so there's this this deadline of September 26. in 10 days. I actually hope that Matt could uh come on this get on the scope because he is opposed to it. I wanted to discuss this with uh with with flight plan in uh

well over this uh this voice chat sadly is not here because I think there's like a lot of nuance with this proposal uh because I think there's also like a lot of confusion about this thing. So just like generally like in my own words like the EIP coordinator it's like a rule within the EIP ecosystem. It sits alongside the roles of the EIP editors, the EIP associates, editors and one could see like the EIP coordinator as a recognition of a person or like an organization uh who knows about the process because currently if people who know about the process and they would raise like specific points on uh PPRs or ERCPRs then it's a very healthy response for people to u

well be a bit like afraid of of these responses because yeah it's it's maybe just a random person like why does this person or this organization like tell me what I can or cannot do. So this is like about like a recognition of this uh this role. I think it is like very important uh to have this role because I would see it also like as the social role um and I'm not saying that I'm not a social person but I do not have the bandwidth to to to do like the social part of these EIPs and that's also why I want to introduce this role. But yeah, I mean the details are all into the the EIP IP. Uh I was hoping that we could get uh well like the the rough contents today, but I I feel that we cannot do that that

today. Yeah. So the difference between the EIP coordinator and the EIP associate editor

is the coordinator is the social side. >> Yes, I will. >> Okay, I think that makes sense. Yeah. >> And another big difference here is like coordinator may not be allocate numbers which associate editor can do. Cool. Yeah, I I think this is a great idea. I will um Yeah, I think I'm in favor of this. All right, with that we are over with

call for input and the next discussion item is again related to call for input. I was wondering should we move call for input to uh Ethereum EIP's issues section rather than keeping into uh Ecat herders uh GitHub repository would that make sense because I I assume that visibility of Ethereum/ EIP's GitHub is more than what we get it over there. So if we have any new call for input people may have more visibility. Um, I I would just be afraid of it like fracturing further between EIPs and ERC's. Um, I don't really feel strongly about it, but yeah,

>> I just wouldn't want like I want all the calls for input to be in the same repo. I don't want the ERC ones and the ERC that would just get confusing. Um, but as long as they're all in the same place, I don't mind where they are. >> All right, that makes sense. But uh in that case would it help if we have a equivalent issue created on EIP and ERC repository so people may have visibility of like where to find even if >> oh like you you duplicate them. >> Yes. >> Um I think that's even worse because then the comments might get lost in one versus the other and um >> point.

>> Yeah. I don't know. Yeah. Yeah. I I think they should if they if they don't go where they are now, the EIP's repository is a good place for them. >> Yes. Yeah. Um yeah, we are seeing some concern with eatcat herders GitHub in future because uh um the project is is not at a very good stable status right now. So we don't know if that is going to be there depending upon how much legal issues are there. we we need to figure it out like can we have it publicly open though Ethereum CAD was just a working group not um registered entity.

So if everything works well I have no concern but if there are any concern I was looking for having a good placeholder right in advance. >> Okay. Yeah. >> All right. So we are also joined by Gajenda Singh. Uh thank you Gajender for joining us here today. Uh there were couple of uh call for input where we were hoping to have some uh input. Um I don't know if you would want to go on that just now uh or maybe we can do it later. Sam you are still sharing your screen.

>> Oh oops. >> Hi. Hi everyone. >> Y >> all right maybe I can share my screen from here on. Um we did discuss about uh two call for inputs. Gajender if you have a time um have some time maybe take a look at it. The number is 409 and 413. For 413 you already have added your input. So thank you so much for that. But 409 still request uh input. Um please take a look at it. Yeah. Well, thank you. All right.

Let me share my screen so we can Oh, yes, please. Go. >> Yes. So about the uh because Oh, wait. No, sorry. I was going to say that now all the editors have added their uh opinion or like their votes on 413, but that's actually not the case because Victor has not done it. So, sorry, this dismissed this comment. Yeah, >> I'm not sure. Is there any question like it seems like there is a decision and we can move forward with it.

>> Okay. So, so what what's then the decision here? >> Um because Okay. I I would let Sam speak for it but my understanding is because most of the people said yes and uh it is approved it. I think we can go ahead and merge the PR, right? >> Uh yeah, for the one that's past the deadline. Yes, we can just Oh, sorry. Is this the rough consensus one or is this the >> rough consensus one? 413. >> So, we have to wait for everybody to give a comment. Uh, >> everybody did.

>> Yep. Then then we can close it. Perfect. >> So, I think I see one in favor. Yam Gajender has already added. Uh, for the next one, I think there is one light client. he is not in favor and he raised some concerns uh which I tried to explain it right over here but uh obviously we did not have follow-up comment if he changed his mind or not then we already have received from Zen Zen panel v um not very clear and neither in positive uh negative but uh I have tried to respond to all the question it just

seems very appreciative of it and he also mentioned that he would love to hear what your thoughts Sam here is. So yeah um I think you were the last person to add your comment here. >> Yeah, I mean I don't mind just creating the title. I think it doesn't really hurt anything and if it encourages more people to participate uh I think that's a good thing. So yeah. Uh so would you want to maybe conclude it as like the decision or should we wait for another 10 days for decision to be documented?

>> Yeah, so I think because we have myself in favor Johan in favor and um Matt against. Um I'd want to wait for Victor I think to come in with a comment. Um yeah but we are past the deadline. Um >> no we are not past the deadline we are >> and semi also in favor. >> Oh okay. Yeah. So we have so at most we have two two against and one and three in favor. So >> no we don't have two against. We have >> at most two against.

>> Yeah at most. Yes. >> Yeah. So I think we can uh I think Yeah. So there and Okay, perfect.

That is good. So, we will wait for Victor to come back with his final decision on this uh after your comment. I think he we wanted to hear from you too. Uh that's good. It's covered. Cool. With that uh we can move on to the next item. I think there is this u so for move call for input. Is there any strong like opposition to it like uh if we do not have a better placeholder can we do it here for both EIPs and ERC's related issues?

I I I think maybe the main question is because it's about uh that these issues and these uh inputs currently live into if caters I think that the actual question is should it still live into if caters uh because of the um uncertainty of the well I would say the f future I think of if caters uh so then the question is not really should it move to well it's of course a related question but should it move into EIPs? Um and the valid concern is indeed that we have then this would then focus the issues on EIPs which could be confusing because it is also related to ERC's

um because the the well the the governance process but also like the I would say the the the yeah the rule sets of the of both these uh of both EIPs and ESC's they are the same. uh but that will then raise the question like why should it be an ERIP and an ERC's and I'm I don't know like I also don't want to create like a specific repository purely for like inputs and and issues but that would make this thing like a little bit more neutral um but yeah just just sharing this these kind of thoughts maybe has some other thoughts on this.

Yeah, thanks Yom. Yeah, so my my thoughts are and my question really is that uh what is the need to move to EIP because I think EIPIP is the uh is where we do go one else. So what exactly are the reasons that we want to move to EIP repo and what are the benefits that we'll get out of that? >> Yeah. So I I shared that that uh I'm not 100% sure about like having this uh GitHub repo uh continue to be existing for because it is tied it is actually not tied to an entity but if the entity dissolves would we have to dissolve this or like I don't know archive it or

something like that. So if such situation comes and we need to archive it then should we consider moving it to um EIP GitHub repository? If not then we are fine. Yeah, I I this particular EIP IP existed before >> yes. So I don't think this is basically entity dependent and uh >> it would be better to have the governance group separate >> even if it I mean EC dissolves. So basically >> EIP's existence is not really one to one related with EC in my opinion.

>> I would agree to it. Well, fine. In that case, we don't have a immediate requirement to move it anywhere else. We we can continue doing it. I will just go back and check with the team and if everything works well, then it should be good. Moving on to the next item on agenda which is contributing.md. I think this is coming up from the previous meeting uh discussion. We wanted to have some additional contributor guidelines uh about u dos and don'ts and sorry it's not it's just rearranging but added instructions on EIP numbering and decision on active err merge policy. So

I believe it was decided that if there are active EIP there would not be force merged by any of the editors. So these things are now added uh in the contributing MD and it requires two reviewers sorry two editors approval to merge it. So if someone may kindly take time out to review this please take a look at it and just merge this one. So the next one is a stagnant bot related. I know it has been brought up in multiple um office hours. Um I don't know if uh Sam Sam if you would like to add you know review it and add your

comment because people depend on you for this tooling. >> Um I don't actually know how this tooling works. So I am not any more useful than anybody else on this one. Um, but the uh stagnant bot doesn't run on the ERC repository. Um, and we need to get it to run there because things aren't being marked as stagnant. Um, yeah, I I the I took a quick look at this one. Uh, this is the one by Cyber Centry, right? Yeah. So, I took a quick look at it. It seemed reasonable. Um, I have not taken a deeper look at it yet.

I wonder if there is a way like let's get this merged and let's have a watch over the process. I don't know if there is a way to find anything malacious in advance. We would not want to have it. Um otherwise I don't know what is the right approach to make this thing working. We don't have a dedicated team to take care of toolings yet. >> Yeah, I don't think we will considering they they fired everybody. So, you know, [clears throat] >> right?

>> Um, yeah, I guess um I can read this. Um, I would don't want to be the only person approving it, but I will at least give an a review on it after this call. >> Yeah, it requires at least two auditors approval. So yes, but I don't know if there is a way to maybe be able to communicate it uh to Ethereum repository maintainers that we need to have someone supporting EIP tooling that is very much needed in order to like keep the PRs in check. So many open PRs and the reasons could be easily solved. So if we can have someone

in it looking into these issues, it will be helpful. My next item on agenda is about the mention of EIP 7457 in possib EIP. Oops. Is this removed? Because I mean it's obviously 7547. Okay. Oh, it is there. Yep. Okay. So it seems like when they were um creating this document, it is still in the draft status. When they were creating this document, this EIP may have been in

draft status, but currently it is in stagnant status. So I don't see it's much helpful being mentioned in the draft and fossil is one of the important EIPs which are considered for upgrade. So, we might want this thing to be highlighted and removed. And I don't know if tooling can do that. Can our present tooling help with finding this check before moving into the next status? >> Uh, I think we turn that back on. Um, so when they make a PR, it should tell them to remove it.

>> Okay. Okay. In that case, >> it should. Yeah. >> I think in reviews when they'll do it for review, then it would definitely come up. Okay, that would be helpful. Yeah, we don't want to go stagnant proposal into any of the active proposals. Very well. Uh the next one here it is from yesterday's office hour. So while office hour is a very good place for editors to take a look at the proposals, the PRs which are there in EIP and ERC's GitHub repositories to like you know move into different statuses. It would be helpful to have a kind of checklist for author as well as for editors uh to maybe take a look into like what are the important notes for both of them. So

authors be prepared and editors may move it faster. So yam requested to have a kind of checklist for every status if we can create one to share with authors to take a look at it. Um the link is added in the agenda and I have tried to create a first pass where it talks about what is expected out of author when they are trying to maybe add an EIP and move it along first to second EIP. As we understand editors only look into editorial aspect of it and not the technical aspect of it. So I have uh like separated it like if there is any technical thing that is nice to have but not editor's responsibility. So this

checklist basically covers what authors should be looking into before coming before pushing their PR um and what editors may take a look at it while it is reviewing. So I would request editors here to maybe take a look at it and if they have any comments please add it and if it looks generally okay I am open to create a PR to contributing MD adding these suggestions right over there so people may be able to take a look at it. Yes, maybe just just to give some some um some context. Um so I I think we all have like a general sense of like what should be required when an EIP moves into draft, when it moves into review,

uh when it moves into like any uh any any any other status. Um but I think it would be nice to have like this kind of document and it should not be like an a big rule set and like like a super big checklist uh but more to have like some some some some general guidelines. Okay. What what should uh what's like the minimum well the minimum viable EIP? Um because for instance like I had some some so the EIP office hour yesterday I had some EIPs or some ERC's um which move states but like I think at least that that's my perception like when we move an EIP into draft then we basically give the office of this EIP or this ERC like a free pass to edit anything what they want. I mean that's that's okay but

that means that like the draft version can have like can be like have like a very high standard of quality uh or well some kind of quality what we what we agree on by these rules but then when we move it to review like the the PR uh likely only has like one change it moves the draft line to the review line but the thing is that if we do not check the EIP again like the quality might have degraded like by a lot and I think that that this what you should actually check uh because otherwise I feel that we should at least require some kind of of of of quality of EIP and ERC's. So this is also why I asked Puja yesterday to make like this this checklist. I have not checked it uh but just for the context like why I uh propose this.

So I have a suggestion over there. I think this is a great idea. So when a PR is being created, this checklist would be posted as per the current status in which the PR is PR is moving it to directly into the PR command. And if you do that basically then you can tick over there that okay I have checked this I have checked this I have checked this itself. So it would be very handy and useful directly when the PR is being created and if you can do that then nobody has to go to different places to go and verify the checklist they can just take it over there.

>> Yeah, very very good. A lot of us Yeah, very nice. Very nice. Yeah, let's >> Yeah, that's a pretty good suggestion. I just have one concern here. Like so for example if someone checks on some things and uh editor leaves a note on some review notes that should be fixed again I don't see how we can go back and uncheck that would that be like something that can be added on what >> but for this idea >> this checklist just should be editable by yes because you can >> I mean generally I don't know whether how you can do that because comments are

generally I don't know how you can control the comment editing because this is just like editing a comment on the PR. >> Mhm. >> But I think one would should be able to provide uh uh some sort of roles for that. >> Yeah. Yeah. Yeah, I mean this would definitely require some engineering but this is very good suggestion to maybe have it uh added just like the bot adds a comment that it requires one review or two review from editors, authors and things like that. If the bot could also add that checklist that will come handy for editors.

For that we need engineering team. I hope someone listens to this call and may be able to fund some engineers to maintain EIP repository. We definitely need one at least one. All right, moving ahead. Uh please take out time to look at it and we would love to make it precise so we can share it with engineer to have it incorporated. That would be nice. What I created was basically to add it on contributing.md. We can have it at both places. Nothing wrong in sharing at both places but yes we can come up with concise version of it.

Um moving ahead we have some action items from last meeting which we can look into quickly if there are something that that needs attention right away. Summary. Okay. I mean the next level would be to actually integrate an AI bot which basically builds that up by itself. >> Mhm. Yep. >> Okay.

Okay. So this is going to be taken care the uh uni code thing propos I don't know what is this yam do you have any context I don't know how AI has written that as your to-do propose and create pull request to update agents MD to include a note that AI llm I do I do not recall this thing if this is just by mistake or AI did something we can perhaps ignore and move on.

>> No, no, I think I I remember. So I think that most of these EIPs or EC's what are currently being written are assist with like language models which is fine. Uh the problem is that these like language models also allocate like a number for them. Uh and this conflicts with like our number policy. Uh so the idea was and yeah like this is also a reminder for myself. I think this was on my to-do list. I did not get to this but to explicitly instruct large language models to not allocate an EIP number like they should keep it blank or whatever so that we can assign them a number so we don't get like these conflicts well what we had in the past with EIP getting a number on the PR and then people think that that's actually

the EIP number of this being allocated to and then we get all this confusion what we simply don't don't want so yeah >> so is there any best place like is it just we are talking about creating an issue at EIP's repository or somewhere else we are talking about >> I think I should just open this PR because it's a very simple simple one so I I should just I should just do it yeah I will do it >> okay perfect all right and um take a look at the rest implementation of rendering system for EIP working group if you get a chance please take a look those are the action items from the previous meetings and rest all seems to to have covered I am still reaching out to EIP hub at

Defcon. I know people have shown a lot of interest. We have received over 160 uh attendees confirmation so far which is very good. We would love to have editors uh on EIP hub. Uh thank you GA that he has shared his interest and we would love to have you. Um and thank you Yoham. I know you also have a shared interest in that and would love to have you one day. If any other editor are joining Tvcon, please let me know and I would love to have all of them in the EIP help. That's what we can share with the community. I'm sure it is going to be helpful and I'm coming up with a more detailed agenda very soon. So uh finally

very excited that the announcement has gone out that we are selected we are one of the 14 hubs those are selected for Devcon this hub and I guess there were over 33 applications and yes uh we were one of those so so much looking forward to devcon this year to talk to developers and uh we have received quite a few inquiries about process they showed interest in participation hoping to address most of them there and maybe come up with a report later on. And uh the next item is to schedule um meetings. We don't have uh any more editors signed up here. So we would love

to have editors take a look into it and if they are available for future meetings, please add yourself and we can schedule next office hour accordingly. Next comes EIP insight. Uh I see Dhanush has joined the call. Uh Danush if you would like to maybe start with the EIPS inside data and then we can go over the comments. It seems that there are some improvements, some new addition that you would like to share. >> Yep. Sure. Uh I will share my screen.

Yep. So uh this month September 26 uh we have five EIPs that were in draft. uh and one ERC that was that moved to truck uh one in review four in uh one EIP in the review four ERC's in the review uh and there's one more EIP that moved to last call and another ERC that move to last call and there's a lot of activities and happening in the leaderboard side we see 27 uh 27 activities Yohim leading the leaderboard following up Zam and Light line. Uh uh yeah, that's uh it from the

September insight. So moving forward with the moving forward with the uh demo. Uh actually thanks for having us and thank you all for the work you put into the process uh week after week. uh a lot of what we built uh built at IIP inset is aimed at making that work easier and easier to follow. So uh we wanted to walk through three uh things that we have shipped recently and get your feedbacks on them. Uh starting off with uh EIP EIP IP. So uh yeah uh we have added all all the recent EIPIP meetings and with the with the summary uh the key

decisions and fully searchable transcript if you look into it. Uh so yeah we have the transcript here call summary with uh key decisions highlights and all the action items listed here. Uh yep. Uh and uh so instead of digging through all the call links and scattered nodes uh we can have uh like uh h we have everything right here. Uh even uh eip like all the recent cost. Uh so yeah u u any feedbacks like how it should be rendered and what other things can we include in this? Anyone?

I mean thank you for this. Uh I really noticed it just yesterday that from previous meeting we have not added it on fellowship of Ethereum magician because that was a manual effort that I was doing. So this is definitely going to help us like get all the action items and notes at one place. So thank you. >> Yep. Uh so moving on to the next thing we have. Uh so we have uh we had a separate board section previously but we moved everything including Pics to one particular page which is EIP editing office hours. So we have these graphs uh uh with everything activity by day recent changes status changes and pull

requests that was worked on uh in specific date range and everything. Uh we also have uh a single like we have all the calls listed here too. All the editing officer the key decisions the PRs that were merged in that particular call. Uh and the whole filter across it and this uh we and obviously the PR board and analytics especially in PR board we have this particular uh tab called on an ACD agenda. So any PR uh that is mentioned in an ACD agenda if it's waiting for an editor it would be listed here if you move the filter to editors u all the u all the PRs and

where it was mentioned exactly that will also be available here and even uh if anything is uh CI like CI related so like it's stopped because of the CI merging it so that will also be here since there is no APR which is paused because of the CI issues. Uh it's not mentioned here. So yeah, uh we have uh this particular tab here. Uh yeah, that's that's about it for the EIPing office. any feedbacks for this uh how like how we how you want this page to be or how intuitive like if any uh graphs or any metrics that you would want to

see any any yeah maybe uh because yeah we can see like this uh spike since what is it like 20 started 2025 in these open PRs um the thing is That's that's some of these PRs. The these are like I would say like typo PRs. >> So these are not not opened by office of these uh these EIPs or ERC's but they are simply not being noticed by uh EIP offers or ESC offers and I personally do not want to close these PRs like I think >> that

I do not have like the right to say that this should be closed or whatever. Uh but it's actually this maybe not entirely related to to EIP's insight but um what he could maybe uh try to at least filter out is um so we have like PRs open which are uh PRs open like the the the total count but this also gives impression that there might be like I don't know like 800 PRs waiting on editors and that's not the case uh because uh some of these PRs I do not know the number but some of these PRs are waiting on the offers of this EIP to uh either approve it or this is also interesting to close it. And I believe that EIP or ESC offers do not have the possibility to close an EIP or an ERC.

Uh I think this is something what we should actually add. Um of course that needs some engineering. Uh but if an uh EIP or ERC offer um comments on this PR like okay we don't want this change or or whatever that they say at Ebot close this PR uh with like if if they are nice they should also include like a comment why this this PR has to be closed. Um because I do not want to do that. I do not want to decide for EAP or ESA offers if a PR should be closed or not. uh what you could also think of is like uh that after let's say six months if there's no activity then we close uh close these PRs but I think for the EIP insights themsel it might be more fel to to see

if we can somewhat filter these PRs like okay what is waiting on uh EIP editor and what is not waiting on an EIP editor if that makes sense. Okay. So as far as I understand like uh PRs which are not open by the author but are uh like uh or also not waiting for uh the editor is something I got. So yeah I would definitely work on it like if I there's any workar around or filter that we can use to help help out. Uh thank you for the feedback by the way.

>> By the way I noticed that there is a chart I shared the link in the uh chat. It talks about like you know waiting on author, waiting on editor and awaited. So if there is a uh no if you can maybe take a look at the Yes. Scroll down please. >> Yeah. Yes. This this one the above >> above. Yeah. >> Yeah. Yeah. So if you take a look at it, it definitely reflects us like most of them are waiting on authors and not on the editors. Awaited are those who are like in the draft form. So it's not ready to be merged yet. So on editor we do have actually very less. So if there is a filter by which editor can only see these peers which are ready for editor

should be helpful here. And um yeah if we receive a comment directly from author by author here means one is PR author one is the EIP author. So it can be waiting on either of those. So yeah we really do not have a way to filter. I don't know if there is a way. Can we do it? I don't think there is any but uh I would want to look into it there's an >> okay yeah I mean if we can look into it that would also help you come I I think we are moving in the right direction with that right if we can filter it with the PR author and the EIP author it will be easier for people to distinguish okay cool >> I mean there's obviously no uh no no particular like we can have a filter to

check out that that if the PR is actually from the owner or is it from the PR uh PR author itself but uh we definitely don't have something that that would uh make sure that okay EIP author doesn't want this PR to go ahead >> uh that's the issue >> I guess we can have a work around it maybe maybe have like a particular comment that gets flagged by a bot or something that okay this PR author doesn't want this PR to go ahead uh and which can be flagged RB bot also which filters all the uh PRs. Uh yeah that would be great I guess if we have that particular command.

>> So that would take off the everything from the editor itself and bring it back to author. So yeah that's about it. >> Yeah. Awesome. >> Yeah. Moving ahead, we have another uh another new feature or uh uh a new page that we are working on right now uh which is account abstraction. So we have been building out uh account abstraction coverage too since it's one of the most more active areas across the process right now. uh it currently tracks uh two particular things which is EIP 7702 and 4 ERC 4337 with uh like uh real onchain usage and also the value that uh it's

giving we have for now we have these few graphs which have we have plotted uh with uh yep this is uh comparing the ERC 4337 and EIP 7702 like what's been used more and even the value that's it's uh getting used. Yep. Uh we have this too if any feedbacks any metrics that uh you would want to see which would help uh the even the working group calls. We are also having uh a tab where we are tracking all the meetings and decisions that was made in uh the meet uh working group calls like frame transaction breakouts and everything. Uh so yeah any

feedback on this like any metrics that we would want to see in this page and uh anything like yes um may maybe a comment like I I really like these kind of ideas but uh this feels uh at least my first impression is that this is a very specific um forinsight.com so I I'm Not really sure like my thought of EIP insight is about well the insight of EPS that can of course be taken like as a very broad insight but this yeah it always states it's under the label

features hubs and this raises then the question to me like what's what's like on features hub so this this to me implicitly promotes specific ideas uh on on this uh site uh which would make it like less neutral like it would push for for specific uh things. Um I think that I'm initially like not a fan of this. Like if this is on a different site then I'm fine. Like um for instance accountabins insights.com but for for me it looks like insights is maybe not the right place for for this.

So that's my initial thought for this. Yeah. Um uh I mean actually the plan whole plan was since it's an EIP and it's a law it's an EIP that has been talked about a lot recently so maybe covering a few uh you know for example lucid even lucid and even account abstraction EIP related to account abstraction uh would I mean would make sense to but yeah I get what you are saying um and yeah definitely look into it.

Yeah, I think because you basically are saying it is being talked about a lot, but I don't think that that that should be like a reason because that means that if something is not talked about a lot, then it is not present on on this site. Um so that that will be my main um yeah point to be against this like I I I would be perfectly fine to to have this like on a different site but to my in my perspective this makes this site less neutral and it would like promote popular EIPS or ESC's like popular EIPS in the sense that they are being talked about a lot um which I would advise against um I I think that like I do not know like what what's the purpose of uh

of EIP insight is supposed to be but I was I will treat this like as a little bit more neutral but yeah this of course your uh your your side so yeah >> yeah I mean fair fair enough like I mean the idea that I have about uh EIP like uh we as a platform uh want to show everything about related to EIP's protocol what's been happening in those particular fields. So like that's why we kind of thought okay this might be a right place to have this particular data. So yeah that's it. Thank you. Thank you for your feedbacks by the way. Thank you.

>> Yeah. I I mean I don't want to come across like super harsh because that's not my intention but >> No, it's it's all right. It's all right. >> Yeah. Yeah. Yeah. Yeah. I I I would adise to to to maybe move it like a link to like a that you explicitly move it to like a different site to to less promote it. But Yeah. Yeah, that would be my my initial thoughts. Yeah, thank you. >> Yep. So, thank you. Uh that's it from our side. Thank you. Thank you, Puja. >> Thank you, Danosh. All right. So, we are almost at the end of this call and um yeah, I I noticed we are also joined by Lightland. I don't see any further agenda item, but if there is anything in specific we want to revisit, we want to go back there. We

still have five minutes. Yeah, I I'm not sure because I I think like five minutes is not long enough to to talk about the the EAP coordinator CFI again because I also have to leave at well in in the five minutes. Um but yeah, maybe like you have maybe we can resolve something in like like three minutes. Maybe your confusion. I I don't know. Yeah. are not confusion but your thoughts.

>> Yeah. I mean if there are any question Matt please go ahead. Sorry. >> Yeah. I mean I was just wondering what you guys wanted to discuss with respect to the proposal. >> yeah I mean I posted my thoughts on the the issue. >> Yes. So um I think there might be some confusion about like what this role uh does. So it is like an more like a social role of of within EIP. Um and this is why we want to create this rule to give like people or like an organization like the recognition but uh because otherwise if people come to you uh an EP or an ESCPR

and they say what you can do or what you cannot do like if this seems to come from random people then uh it's very logical that that people will not uh well they think okay these are like random people or random organizations and not listen here and I think that this would like make this this process more efficiently more efficient in the sense that it would give like these people or uh well the more social role in this uh this process but yeah >> yeah I mean I think that people don't care about this and if someone gives you feedback on EIP it doesn't really matter if it's from an editor or from a coordinator

you build credit by presenting good arguments and the EIP process is supposed to be like laid out fairly clearly in EIP1 and so you can always refer to the document and point the person in the correct direction and they can for themselves see from the source of truth what needs to happen if they're EIP like this is basically how all EIP editors become EIP editors right they just begin contributing to the editing process and I think has worked in the past and I think that Puja has a lot of credibility with her experience and the time that she's put into helping edit and helping her EIPs. I don't think that

she posts on MEIP and someone says who is this person is this this person is an EIP editor. Like if this person is saying who is this that they don't know what EIP editors even are probably so they definitely want to know what an EIP coordinator is, right? Uh if I may u add something here I think adding a role might help for avoiding confusion at many places. A recent example was there in yesterday's office hour. There was a PR which was related to fixing stagnant bot and it was approved by one random user and the author was under impression that random user uh is part of EIP process and

that's why he has he or she has approved the PR. So if there is a place where we can let people know like how you can distinct between the random user and the people who are actually part of the process would be helpful for very u large part of community who may not be closely watching EIP process. So the >> and I can't help someone who can't just open a GitHub and look to see who this person is like if you can't open a GitHub and see if this is a bot or not. >> No, this EIP >> coordinator is not going to help. All right. And I noticed Yam's message that he may have to drop in few minutes.

Um, but yeah, if I mean I I have tried to respond to your comment in the CFI itself. If you have any further, you know, like point to oppose it other than like, you know, why it is not documented, we can perhaps discuss it even more. Um I know we are running out of time so I I don't think it's the best time to discuss it here I'm saying but definitely open if in the next meeting or if you want to take it async happy to respond to all of them. >> Sounds good.

>> Any final thoughts here? All right. There was another proposal. I know Sam has to drop off and he did uh drop and he's not in the call. He had some concerns that he wanted to discuss in the next meeting. Maybe we can add it in the next agenda item. We are looking through the process of like um having more edited onboard. So definitely this is something that we can talk in future meeting for today. Let's try to wrap it up right over here. Thank you everyone for joining us here on the call and we look forward to meet everyone in the next meeting. We don't have most of the editors on the call but if there is any pref preference other than the third week um we can definitely discuss the

date in in the discord channel to finalize the next meeting. All right. Thank you everyone for joining us here. See you around. >> All right. >> Heat. Heat. [music] >> What's up?

>> Heat.