EIPIP Meeting #127

Transcript

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

>> Thank you. >> Heat up here.

>> Heat up here. Heat. [music] Heat. Welcome to EIP editing. I'm sorry.

Welcome to EIP IP meeting 127. I'm still in the EIP editing office hour 100 meeting. But now today a new day. Today is June 3rd and this is EIP IP meeting 127. This happens generally on the third Wednesday but we have it uh a little earlier this month. On agenda we have call for input some important point for discussions uh for editors and uh yeah we will have an insight of uh EIP/ ERC stats.

So maybe we can start with call for input and a call for input generally is taken by Sam. So Sam, it's for you now. >> Sure. So uh there are three on the agenda. We have the allow links to Unicode technical standards. That one needs approvals on two PRs. They are linked in the call for input. Um then we can close it. Um then we have um the associate EIP editors which is also waiting on review on pull requests.

So um I guess that's on me. Uh and then I don't think we need uh this last one anymore. So, if you don't object, um I'll just close the one that allows links to um a WASP CTPA and CI since they do have a license that allows us to um republish them. >> Yeah, I have one uh point on the last one. Uh if it's resolved, that's that's very nice. But [music] uh the main theme there seems to be um for some kind of external inputs um of sorry for some

kind of external resources um and I don't know like we don't have to discuss that today but I think this this might [music] become like a a a well not recurring topic but a topic on like um for other especially ERC's um I don't So [music] do we want to discuss that now like how we should handle these these kind of things or we want to do this like when this actually is a problem >> just the like how we handle generally allowing external links or >> um I mean more like like these kind of resources so first of all like I don't know these ones because I'm not super

deep in ERC's but this O ow that seems to be somewhat established Um but the question is like like yeah what what what would be the process what would go through for these kind of things because in the end it will still be um that if one of these resources in the future goes down then we have a problem. So yeah. >> Yeah, definitely. Um, so I think uh like uh I'm assuming you've seen EIP 5757.

[music] Um >> yes. >> Yeah, this is um yeah, I'm not sure if we need any more process [music] than that. Do we? >> no. Okay. It was more like a general comment on like uh well approving like like these kind of external [music] resources. Uh I mean like the way that this is resolved now I think is fine but this might well become a subject in in the future also but I think we can skip skip maybe for now. Yeah. >> Okay. I'm I'm happy to talk about it if you want. But yeah.

>> Yep. Uh and uh I have shared link of a PR. I I believe we have already closed the call for input that was number 405 in the last meeting but the PR is not merged yet because it requires two editors approval. So I'll appreciate u um another approval on this PR in order to get this merge and uh yeah that is about uh adding a status tag in citation. All right with that we can move on to the next section which is called editors discussion section. Here we have 1 2 3 4 four points for discussion. Uh I I believe Yam has added first two point.

The number one is about authorship changes. So Yam if you would provide some overview of what this is and what we want to discuss today. >> Yes. Uh so this is actually because Greg just asked on Discord uh about this EIP. Um and what this what's happening there is I didn't check the contents [music] but the problem there is that um he wants to well to add himself. Well, we suspect himself, but it is it should [music] be himself um under a GitHub username and he cannot approve uh this PR himself. So, he needs an approval from uh either uh Holyman or Expedian uh on GitHub. Um, and I was wondering like

what is our current process uh regarding [music] approving these kind of PRs via email because Greg should in theory be able to um to to to to uh to accept this PR. But how do we like verify that uh gregit.org um has authorized this? Uh my approach is send an email to that email address and then get them to reply with their approval.

>> Okay, that's reasonable. Yeah, >> it's interesting that he's removing the other author's um usernames and emails. >> Yes. I mean like I think that was maybe my my second point like I think that is well I that might be a mistake but I don't think that we should uh allow that >> um like we shouldn't allow Greg to merge this PR or so specifically this authorship line um removing these GitHub handles would also remove the rights of these [music]

GitHub users to make any changes to this PR >> and I think that that this is not something that can be done. I don't know maybe the [music] bots already programmed it like this that this well I've made a message it seems that this is not the case [music] because it requires requires one more review from the office which is X speed or holy mail um which would then mean that one of these offers can approve um deleting [music] themselves to have the rights to um well to to edit this uh this EIP uh which I [music] don't think should happen um And I don't know, I did not check with with Greg, but I I think it

is [music] a mistake, but yeah, I don't think that should happen. And also like removing uh for instance this email, so this [music] from John Max Scala, that should also not um I believe this should never be allowed. But maybe we have found another policy for this. But I don't think that's that's something that we can do. [music] Maybe you can change your own email that that's fine. But not uh not that another [music] person or entity can remove this handle. >> I'm not sure. So, so far I think we um would just allow like any author has the right to approve any change and if an like let's say Greg does remove the

other names that would be an internal dispute between the authors and if one of the other ones wants you know to have merge privileges they could make a new EIP under a new number. Um but that's also really annoying. Um but on the flip side uh let's say an author you know hasn't been responsive for a really long time or their GitHub handle gets compromised uh or or there's a fear of their GitHub handle getting compromised then uh author should be able to remove um other authors. So I'm not like my my default here would be just let the author sort it out. They

can if they want to remove each other they can. Um, I could definitely see the argument the other way around. >> I mean, I'm also in a agreement kind of agreement with yam here like uh [music] allowing authors to update the author section is fine [music] but it is nice to have that we know what can be allowed and what not. For example, if GitHub handled is removed, then the author who was listed earlier will not get any notification right now. Right now, we know Greg Greg is messaging in in the Discord channel

and we are kind of considering the request. But just imagine if uh a bad party, a malicious party does that if we allow this kind of merge go unnoticed. So in my mind the good approach here could be we do not allow deletion of author we allow addition of author and for deletion of author there can be a proper uh process setup which explains why this particular author is being deleted because the author was added in the first place because [music] there was a contribution from that author uh to this uh particular

proposal. So let's not take away the right of uh editing, merging or whatever they had been provided the privileges there. And I also feel like um like if we want to update email address [music] that is fine but there has to be one or um either one handle or email address where these authors can be reached out to. Yes, maybe to also chime in on here like um I suspect that we don't have a policy for authorship changes uh but an offer themselves can either change their uh so this is like my opinion like they can

either change their own uh offership so Greg could for instance change his greg.org into Greg Kovven uh the GitHub username G Coven or he could delete himself but he should not be able or not he but but an office should not be able to delete uh other offers because this could indeed like we could for instance see like in in five years that one of the original offers of an EIP um let's assume this EIP is not finalized yet [music] um changes the uh just opens PR they remove all the other offers [music] um and then just merge it because they have the rights to to to merge this and then

they can claim but I uh I I created this EIP. [music] So if you get added as an offer this is uh approved by uh well one offer of EIP then one offer themselves should not be able [music] to to change this this list of authors. If there's a dispute then uh then uh people can indeed open a new [music] EIP and they just copy the entire thing and they create like a new office list. I mean that's [music] that's fine. Um but of course we have the other case and that's like so it's like a uh the danger that this GitHub handle is [music] compromised. I think this is not a um like a [music]

problem but well of course we would likely hear this from the office or we would see this on the EIP's [music] uh repository. But this should then be like an EIP editor's uh process and this should only happen in the case that there's like these kind [music] of security incidents that we remove the handle of this uh uh uh this offer with I don't know like with an explicit mention like okay this handle is compromised [music] we cannot use it anymore or maybe just in the EIP uh in the EF pot um put this on like a blacklist like okay this this uh username is compromised um but I think that's that's like a different Um, >> okay.

>> Story. Yeah. >> H. So, I think this is going to qualify as controversial. Um, so maybe we should write up a call for input talking about like the policy that we want to add for authorship changes. Um, and then uh we can get feedback from the other editors as well. >> yeah, that that that sounds good. Like I I think like in general what we should do is at least have a policy for authorship change because I believe we don't have one yet. Um >> correct. Yeah. Yeah. I think our our current policy is any author has ultimate privileges and can do whatever they want with a proposal.

>> Very [music] well. Uh I think call for input is good. Next step we should invite [music] other editors who are not present in this meeting to chime in and yeah help uh decide a policy around authorship. With that maybe we can move on to the next one that is EIP prioritization in the review process. Uh >> yes. Oh sorry. Yeah I >> no no I just wanted to invite you. >> Okay cool. Um yeah, so I added that as second or well not the second item but I just added that to the agenda. Let me see what I actually wrote because now I can't find the agenda. Well, I I know what I said. [music]

Um so I generally believe that uh the the fair process of uh reviewing EIP and ERC's is by the uh well the um the ERC or the EIP which is waiting the oh thanks um which is waiting the longest but uh this request from Greg is uh well that was added like 3 hours almost 3 hours ago because Greg wants to discuss this EIP uh tomorrow on ACD and [music] uh because uh well he wants to do an offership change or well it does not have the rights to [music] merge this uh

EIP um and uh so this is not specifically about this EIP [music] let's let's make that clear um but these situations uh I also realize that that this happens to me often like I get a request from like uh like person they want to discuss an EIP or an ERC well in most cases it's an EIP on ACB um and then they ask okay can you please [music] uh uh review do an editorial review of this EIP uh so we can discuss this [music] tomorrow at ACD well of course we also can stick to the original process like okay we do it by uh well by by the Q system um but I believe that

for the governance process itself it makes more sense to prioritize these uh these EIPs. Um the well [music] the yeah I just wanted to raise like like that point. Um Sam >> okay >> so if the the process isn't like my concern is obviously appearing like neutral. So if for example the uh um pull request is linked on uh the arcore dev's agenda that would be a fairly um objective way of prioritizing these things. So if it's on there um review it and um I think that's objective enough

for me. Okay, cool. That's that's a yeah okay that that's inde like one of the points yeah what I would would like to make for for prioritizing these uh the only point is but that's that might be like an well not an artificial problem but uh this could of course lead to a problem where people will just put items on the um the ACB agenda just to get it reviewed faster. I don't think that this will happen but well that can of course happen. Um, but [music] yeah, >> honestly I don't think that's bad. Like if it if they put it on the agenda and then they show up to ACD to talk about it, like I sure, yeah, it probably should be reviewed.

>> Okay. Okay, that's okay. That's cool. Um, but [music] okay, just to check because what do you mean here by uh put up on the agenda? Because is this then [music] a comment on the ACD like okay can we please discuss this EIP and this is or EIP or EC and this is then a link to the PR uh or is it actually in the agenda of the ACD [music] so in the in the well in the how do you call it like the issue uh the top post >> yeah I think that makes sense >> so it's it should be in the top post or should it as a comment okay yeah cool that makes sense that also means that um because I have to [music] well I not

really sure if that's the case but I think that the agenda of uh ACBs are updated like well very short before the ACD. >> I know. >> Um so so this this could be a a a a problem. Yeah. >> Yeah. I think as long as we're like aware and like um conscious of being like neutral, I think it won't be a problem. I think people would understand us prioritizing those reviews. Sorry, Puj, I didn't mean to cut you off.

>> No, no, that's perfectly all right. Yeah, I mean what I can do before preparing the agenda like right in the Tuesday morning if ACD is already prepared, ACD agenda is already prepared, I can go back and check what they have added in comments because yeah as Ya mentioned maybe uh updating of agenda is last minute thing. So we may not find everything in the agenda itself but we'll try to go through the comment section and try to pull up the PRs and add it as high priority PRs to be reviewed. Yeah, I I I think this makes sense. Um and then maybe as like the last comment on this is then that uh EIP office hour is on Tuesdays. Um of course that doesn't [music] mean that we only review

on on Tuesdays. Um but uh what I see in practice is that like one day before or like a few hours before then EPS or ESC's [music] get added as a comment to the to the ACD. But I think this is then my point what people should realize like okay if you want to put [music] this on ACD and you want this thing get uh get merged then you should just do this earlier to also give a style. I think that's that's fair. Very well. Um, yeah. So, I think this this would be under my action item. So, whenever I'm uh sharing the agenda for Tuesday's meeting, I will try to make

sure that we have included all the PRs coming up from ACD agendas and prioritize that and then we'll get into the regular reviews. Obviously uh the last um or the longest waiting PR is the priority but sometimes they are unattended and that's why we [music] try to take up PRs for which authors are already on the call. >> Yeah I I think that also makes sense for for the office hour. Um yeah maybe as final [music] points there what what do you want to say? Um yeah, now I forgot. Okay. Yeah, never mind.

>> Sorry if I interrupted and >> so whenever it is there, please let us know and we can get into that. >> Well, moving ahead, we have next is dispute resolution. So we were talking about authorship changes. This is in my mind kind of a dispute. We have also seen some examples in the previous meeting that there are different kind of disputes which are arising. So I am proposing here a working group like dispute resolution working group and for that kind of uh came up with a document that uh lists some of the primary questions. Um I'm going to share my screen for a moment so we all are on the same page.

So this is the document. The link is added to the agenda. So you can also uh take your time to read it later and it is open for every signin user. If you have any common thoughts processes on this process you can uh probably add. I I strongly feel that EIP editors is an important participant of this working group. Most of the EIP editing is done by editors. They suggest what to do, what not to do. They are the maintainer of EIP1. um obviously the maintainer of um 5757 which suggests like what can be included not included when it comes to link and things like that are currently being supported by EAP editors. So I I strongly believe that EIP editor should be part of this working group and what

this working group can do. I know the uh EIP5069 already list what editors do, what are their responsibility and what they don't do. This may be coming up something that they generally don't do it but they might [music] consider facilitating the process about a dispute resolution. So this document just talks about highle thing like [music] what is a EIP dispute resolution working group. Um yeah and some basic questions that we [music] should get answers um from editors itself in order to proceed in this direction. We talk about like what are the problems. First we need to list

it. Then we need to figure out what is the scope of dispute resolution. Obviously we are not a um a court. The group is not a court. So we may not be um sending decisions out but we are just trying to set process that may [music] help other contributors of the ecosystem to get to a solution uh for the problems that [music] that they are facing these days. So uh we would be talking and the working group would be talking about the ownership of of the problem like what dispute categories they would um own or try to discuss. Primarily I I feel like it is a good um starting point to consider two or three uh dispute

scenarios which are prominent so far and we can keep on updating as we go. So the moment we say that we can keep on updating it it becomes a question that where this uh dispute resolution process would be living right would that be a part of EIP1 would that be a part of contributing.mmd or should that be a part of u a meta e separately so we we need to find like uh where we are going to put it together uh and there has to be some deliverables of course if the working group is there we need to come up with some kind of deliverables like what what we are doing here what uh uh the solution are proposed and things like that. So this

document just talks about um [music] you know the uh proposal to have a working group. I I would pause here and like to hear what uh people think about it. So, I'm almost always on the side of uh minimizing uh the EIP process and um editor responsibilities. So, my vote would be for we don't resolve disputes, we don't do any of this, and um we let people fight it out. Um [music] and we just don't participate. um that's

probably not the most um pleasant um or or useful approach. Uh but that's the one I'm going to present forward here. but that's not to say we should do that. >> Yeah, I I think I agree with you. Um maybe taking the example of this authorship um what what what we just discussed like these are the kind of things what we should um because these kind of disputes are things what we can actually [music] now foresee that these might happen in the future. So what might happen is that [music] uh let's say that there is now

an offership dispute uh and then maybe at some point uh this dispute gets [music] resolved and this uh new offer or this disputed offer now gets added into the EIP or ESC and this person now has the rights to remove the other offers of this ERP and that also removes their rights to merge this EI or EC. >> Yep. >> I could foresee that this is [music] uh this is going to be uh or this could be a problem. Um and we can see this coming. So [music] we should actually prevent this. Then maybe the idea for this work group um would not be u disputes resolution working group but actually to see okay what part of the process [music] can be

um well what can be abused slash well that's in line with sense idea of the code of conduct document [music] like what parts of the EIP process should we document um and then yeah because EIP office would enforce this uh uh these these rules uh and if at some point we find that uh there's a hole in this uh in these rules then we have to change the rules. >> So like let's explore the authorship dispute with the other approach. So I if we do choose let's say um a dispute resolution process where we forcibly add

an author to the EIP what you say where the new author could just remove the other authors um is true that could totally happen. [music] Um so let's walk through what happens if we don't have a dispute resolution process. So um you have three authors on the EIP and then a fourth author wants to be added. Let's say um we change nothing. we do nothing and the authors decide not to add the fourth author. So now the fourth author can either give up or they can make a new EIP number and add um themselves plus just the names of the old authors.

So they don't have edit rights. So now you end up in a situation where you have two different EIPs um and they can't affect each other because they're not on each other's author lists. And so the the conflict has been resolved simply by forking the EIP. um and we don't need any complicated permission systems or anything like that. >> Uh I kind of uh slightly uh disagree with the process for the reason that it may be resolved on author's point of view but it is a problem for community.

Now the community has because both of them are added as a standard to Ethereum repository. Now community has two different EIP number which actually does the same thing. It's just that they have different authors. It doesn't make sense to people like which one should I pick. So that's another kind of problem that we are getting into by not solving the basic problem. So if we have some kind of process setup for for the same example that Sam picked up right here of authorship. If uh someone is saying that I have contributed enough that it should be considered as my authorship to this proposal. I believe providing certain guideline and giving a certain answer yes or no. I mean obviously editors will not say yes or no. The process will say

yes or no. They have to go through that. For example, we have call for input. So we get a solution at the end of call for input. Similarly, if we can create a process of these kind of problems which are coming up in the ecosystem, there would be a solution without uh any individual being the owner of of saying yes or no. So in this specific example there, if the two documents only differ in authorship, then it doesn't matter which one the community chooses. They're the same. [music] And as soon as they diverge technically, then they need separate EIP numbers anyways. So I don't really see that there's a problem there.

>> I'm sorry. I definitely missed some point. So some >> what we are saying is like there would be two document with same authorship and same number in the EIP repository. How is that possible? >> Uh no no it would be different EIP numbers. So like let's say you have EIP 501 and um there's a another author who wants to add themselves they don't. So they get EIP 502. [music] So now you have these two documents that only 50001 50002 that only differ in the author list. And your um issue with the forking the EIP uh was that it would create confusion in the community because now you have two EIPs that are [music] um materially the same but they have different numbers. Um and my my

counterargument to that is that they're the same document. It doesn't matter which number people use to refer to them. Um or they diverge technically in which case they need different EIP numbers anyways. So um I I I actually don't think it's a problem if um that happens. >> Let's say they do not diverge technically. So in this case if the content is same which one would be picked up for an upgrade? >> It doesn't matter if the content is the same. >> Um I am I'm thinking that it will be a problem because every client would ask which EIP should I implement? what number should I put it on the dashboard?

Like there is a there is a complete process. The entire community needs to know which EIPs are part of the um part of the um upgrade, right? So >> yeah, and it like my argument is it doesn't matter which one the community picks because they're material like they're technically the same. >> Yeah. To to to chime in here. So the for this specific example the community will then just pick uh or the governance process will then just pick uh what the EIP will will be. So if this uh for this offers ship example if this alpha would get included or not. Um so for this specific example I indeed agree with Sam

that there is not [music] a problem because the community uh will indeed decide what the canonical EIP or ERC is what uh is being put into the fork. Um which will then also resolve this dispute because if the community thinks okay this offer should need be on the offership list then they will follow this uh this number with that offer in it. uh but I can see uh and maybe maybe just to generalize this this this uh this proposal of the dis dispute uh dispute specification working group. So I uh so I just proposed okay we should

maybe have a working group to see okay what parts of the process can be abused but um I think what PAUA is is uh suggesting here is we should also have a maybe a working group in case that the current rules are being abused or not abused so there is a dispute um and and well we did not fix this problem in the in the in the process [music] So um yeah what what yeah this working group [music] will then figure out like what uh uh what to do with these disputes. I'm only thinking of >> uh well that's that's I think that's basically question one in the problem definition like um [music] what kind of

disputes would these then be is that is this somewhat correct? Yeah, that that is like uh going in the right direction. But I'm still stuck to the point that uh how is it possible to have two EIPs? I mean, if editors allow to have two same content EIP living on the EIPs.ethereum.org, then we are like opening a Pandora box. Anybody will come next day and it will pick up EIP559. I am the author. Add me in here. And I I think in the editor's roles and responsibility the very first responsibility while reviewing the

proposal is to make sure that it is not the same proposal that is already listed in the part of repo otherwise we will be having like any number of same uh same proposal with one new author in that proposal. If I could chime in just uh listening, um Sam made a a very good point I think about how the things could diverge but still make sense. But I think Pua uh you made a very strong foundational argument about not setting a precedent of duplicating these forks of what it could eventually lead to. I mean maybe there could be a way to um you know strongly limit it but I think it does create certain risks of um you know additional

cases happening that you know goes against that fundamental rule. So just my thought about that. Yeah, puja about this because you indeed have a point um here about that that we do not want [music] that uh this EIP repository becomes like a this would be indeed part of the yeah how you could abuse the system not sure I have to think about this a little Yeah, I mean we obviously discussed the

authorship uh dispute as one of the disputes. We we have received examples of couple of others. So uh I think uh the group should think in the direction of at least having a working group at least trying to put together some guidelines which which might help uh the community because at the end of the day EAP editors are the first um interaction of the community towards documenting the proposal or even when they are uh reading the standards like they believe that it has been vetted by editors. So yeah, whatever they are getting is absolute uh work of art right here.

Um just a little bit more in that direction because I have this document I I want to bring it up maybe we can discuss it in future meeting. So just for people to maybe uh get a chance to look into it. I don't know uh what uh the direction would be picked up but there are a few question which I would highly recommend editors to maybe [music] take a look at it and if they are convinced to have this working group in the place then we can think of like uh how to start a document Sam suggested code of conduct it can be one of those documents so we need to figure out where where the placeholders are so in the second document that I have added is like um uh dispute resolution guidelines so this document talk about first few like four

problems that we have picked up from the um ecosystem and uh kind of provided the solution to those problems. It does talk about the roles and responsibilities which are obviously limited from the category of contributor if they they are author if they are contributor if they are editor. So it talks about like how we can generally proceed towards solving the problem. Uh so yeah the second document is kind of a lightweight uh dispute resolution flow. Uh if people think that dispute resolution is not the right word. I think it should not be a problem. We can come up with the

appropriate word which kind of satisfies the community um concerns as well. But the idea is if there is a problem there has to be a solution. And this EIP IP meeting has been doing the same thing for years now since 2020. The first problem was the EIP improvement uh process. We worked on that. Now that there is a good process in place. We have a good repository of standards. There are chances that some kind of disputes will come up. Now it's the time to set up a process to solve these disputes. Yeah, that's what I wanted to share on this topic. I would really appreciate any feedback, comment,

thoughts on this. I'm open to discuss it on Discord as well as on this document >> Yeah, I will I will read it and I will do an uh uh yeah, I will I will leave some comments uh async on Discord. Yeah, thanks. really appreciate that. Moving ahead, uh we discussed a few things with the EIP developers who are here to help out with the EIP process. So I had opened an issue to fix ETHbot comment. I believe the issue is now closed because the P PR has been merged. Thank you Sam

for approving that. Uh the next one is EIP numbering related. It is still open. Um I wonder if there is any update on that. Um I don't see any PR link but uh if I remember correctly it was mentioned that the process was discussed uh within EF and there is a team working on it. [music] I wonder if there is any update. Sorry, which was this on? Um, >> it it's a EIP numbering issue number 14.

>> Oh, yes. Um, yeah. No, no, they're still still working on that as far as I'm aware. Um, yeah, I haven't I don't have any updates unfortunately. >> Okay, no worries. Um, maybe we can check with David uh next week and see if there are any progress. Moving ahead, we have EIP meeting um >> uh summary from the last meeting. I remember there were some presentation by RTO. RTO had a question. What's the next step? RTO if you want to take the floor now and yeah, maybe discuss about the next steps or anything that you want to get an answer from editors right here.

>> Okay. Yeah. Well, I wasn't really planning on it. I was just here to tune in. But um All right. So, since I have you Sam right here, um what do you think would be a good way to um collaborate to get this done on your time cuz you have a million things to do? I hear, you know, activities that you have to do here that I wasn't even aware about and stuff. Um is there a way that we may be able to uh coordinate on certain times so that we can, you know, get through this review process? So, you know, it's a 10, it's been a 10-year project. you know, is there a way we can work together to move smoothly?

>> I don't know. We could we could maybe set up a um weekly or bi-weekly like sync that'll at least encourage me to um do some work on this because um yeah, this does need to get in and I have been moving very slowly on it, but that's up to you. I don't know what your schedule is like. >> Oh, I'm flexible and I I've made a a priority to do this. I'd like to follow it through. So, um, if we're able to like correspond somewhere, I don't know if you prefer email or like, uh, create an issue that we, you know, chat in, like what what's best for you, cuz I know you're probably bombarded on GitHub.

>> Um, yeah, let's, um, go with email or Telegram, I guess. Either of those would be fine. Um, >> all right. >> Have we on Telegram yet? I'm not sure. >> Not on Telegram. I sent you an email before when uh this meeting was rescheduled >> if uh did you did you see it? Did you find it read at I don't want to say the full I guess it's it's on readvision.com give me spam mail everybody everybody listening to this come attack me. Yes I sent you an email from that but Telegram is also cool too. Um I would be Rita Rhymes. What are you on Telegram?

>> Uh I'm just checking that now. Uh Sam Wilson without the O. >> Cool. Okay. >> All right. See you. >> And then yeah, let's let's let's coordinate a meeting here or something every so often. Doesn't have to be long. Just like a 15-inute thing and we can figure out uh pull request updates and stuff. And um if anybody else wants to help review the stuff too, I'd appreciate it. >> Yeah, that I'm going to bring that up too. If anyone else wants to uh to join in, hey, come on. Working group. Let's get working. Come on. Let's go. Okay. Yeah. So that will regard to the the webdev front end now of the the page.

>> Yeah. This is the um the Rust rewrite of the whole rendering process. >> Oh, sweet. Okay. Feel free to count me in. >> Uh I appreciate it. Yeah. Thanks. >> If if you want to get started, um the a great place to look at what we're working on right now. You can review the past few uh meetings under you know this meeting thread. Um I have a few comments there that link to the issues. There are some very extensive PRs um that are coordinated inside of these issues. So you can see [music] um you know what we're currently going through the review process now to get uh acclimated to things. And it's across multiple repos too. So be aware it's it's everywhere.

It's a lot. Okay. >> Yeah, Brito, if you could link that comment to to look, that would be handy, I think. Then we can directly dive in. >> Should I I should link it in um on this issue today for this. >> Yeah. Or in the issue and also maybe in [music] the chat of this uh this this meeting. Yeah. >> Okay. Yeah. I'll I'll add it to the issue on GitHub. No problem. Very well. We hope uh it gets enough attention and we see it because the working group model shared there was

there was [music] right. Yes, I think this is the repo eips dot eips-working group. Yes. Um I was going through u eip.ethereum.org. I am going to share my screen one more time right here uh to share this. Maybe someone can take a look. It looks like something is broken right here. So if we go look into the draft section >> under the all uh I don't know why it is missing >> and this is not the case for any other >> um status.

>> I can I can guess what that is. >> Okay. Um >> yeah, I just wanted to bring attention maybe if this is something broken we can it can be fixed. >> Yeah. Okay. So that's >> I think it might be in parallel with draft. [music] Do we have the same setup? I'm not even sure. >> Uh yeah. So the Jackal is picking up someone's template as an EIP. um which is kind of annoying. Um I'll just make a poll request to change the [music] file extension and that should fix it.

>> Awesome. All right, with that uh the next item here on the agenda is EIP editing office hour. We concluded 100th office hour yesterday. It was great. Thank you so much Sam Olson for reviewing the proposals for 2 hours continuously. It was great and the good news for the community is that we got ERC 4337 merged as final. [music] ERC 4337 was documented back in 2021. It has gone through multiple versions of account abstraction and it is one of the most used account abstraction proposal. So having that um pass the finish line, I'm very happy and uh congratulation to the

to the group to everyone who worked behind the proposal. So that was one of the achievements and yesterday we get to like review kind of balanced like uh almost equal number of EIP proposals as well as ERC proposals. So all in all I find that this office hour was success. Uh there is also a live dashboard for people who missed may follow that and see how um that looks like. it it was an experiment by um by the team which I find it quite attractive and I'm I'm wondering if we can start using this kind of feature for all the office hours just to get a like sense of what we are doing how we are doing and

what all proposals are are being reviewed. I do agree with the idea that was discussed in the last meeting that we should try to have uh invitation to editors uh invitation to authors who have questions rather than the idea of getting their proposals merged. We are definitely um working in that direction and trying to share this information with the the community and try to get those authors on call. Uh but yeah, I think uh having EIP editing office hour in place, having the meeting on every Tuesday at 1600 UTC gives a sense to the community that they have a place to

visit to. So let's continue doing that and yeah, I look forward to have more office hours in future [clears throat] and uh be able to help the community. Next one is while we are talking about office hour, we should also update the schedule. Right now we have uh um editors booked for um until meeting one or two um like for the next two weeks but not beyond that. Editors kindly take a look at the sheet and please add yourself wherever possible so we can schedule the meeting accordingly.

I am unavailable for one of the weeks but uh that should not be a blocker. I'm definitely going to put up the agenda and the meeting would be in place if there is an editor to host that uh office hour. So yeah, kindly take a look and yeah that would be great. [sighs] Next one is uh EIPS insight for the month of June. Um yeah this is early June. Today is June 3rd only. So not much we can um expect right over here but as we can see that we have two final proposals moved uh in ERC uh one two to the last call one to

review and three here in in the draft like it was March yesterday. Yeah we can learn more about it from this uh insight page for the month of June. Probably we should also take a look at May. That will give us a good sense of how we did last month. Yeah, definitely it [music] is way more than what we are seeing for the month of June because we just have passed 3 days [music] in June. So that is all um on agenda. Yeah, that's pretty much [music] it.

If there is anything anyone would like to bring up, this is the time. I see [music] five comments. Uh, no problem. Yo, whatever is the best date for you even in future, please feel free to add it. Oh, Sam, thank you for already creating the PR. Okay, that is really fast. Yes. Uh Luke um contributor to 4337 I guess four commits. Okay.

>> No contri contributor to the um uh EIP pre-processor [music] theme ages ago. >> Okay. Cool. Cool. Yep. Thank you. S is G. Yes, he does. I agree 100%. Anyway, uh any anything else anyone would like to bring up today? And also what is the next uh um date for [music] next EIP meeting? Yes, Yam. >> Yes, I remembered what I wanted to say before on the [music] uh topic of the uh work. No, sorry, on the the disputes. Um [music] no, not on the sorry, not on the disputes on uh the order of reviews. um because I assumed

[music] that we have this well written down somewhere that we do this by audits first uh but actually I [music] don't see this anywhere so this is not in the uh the editor handbook but maybe it is implicit that that could also be be the case but yeah this just maybe just send the question to well other editors or well in this call Sam um is this implicit in EIP 5069 that uh the well the the the the reviews queue is [music] by August 1st.

Um or something this >> um so I don't think uh it's been codified anywhere. Um and like I don't want to force other editors to work the way that I do. Um what's important to me is that we're credibly neutral. I don't really care how you prioritize stuff as long as there's some relatively objective way of of doing it. Um, but if we want all this to be the the official way of doing it, we can absolutely add that too.

>> Okay. No, that that that's fine. Then I made an unconscious assumption that this is [music] the way how we should we view. But I think you are right. We should maybe not um uh well make this like a a very strict [music] rule. Yeah. Okay, that makes sense. Thanks. >> Yeah. And I have also shared the link which based on Sam's ideas. I think uh the first pass was Sam's uh code base uh UI has been created where you can where every editor can maybe uh take a look at u um the oldest first issue it is uh eabsite.com/board where you can like go and check for proposals which are waiting on editors

review. There are 400 plus open PRs but not all of them are dependent upon uh EIP editors. Most of them are on waiting on authors. So filtering that out if you look into this uh uh sheet here the table here you might be able to find which are waiting on editors and you can u an editor can maybe prioritize like what they want to process first and based on that. Yeah it is an easier way to um go find and go for review. So yeah, anyone listening maybe take a look at it.

All right. Uh that's pretty much it. The last question for today is when is the next meeting? Do we want to have another meeting in the month of June or should we have it in July? Because we generally have one meeting in a month and we already have done it in in the first week of June. And if after a month then should we keep the first week of yeah July as well. What's the general sentiment? >> My feeling [music] is that uh in well in basically in the last eight eight days uh we we we [music] discussed a lot. I

my feeling is that we should do this in one month. Um, I'm checking like I can do do uh the 1st of July or also the 8th of July. That's that's also >> uh the 1st of July is a holiday for us. So, >> the 8th would probably work. Yeah. >> Yeah, the work for me. >> Okay. Uh then in that case, we'll create the agenda and add it to the Ethereum/PM GitHub repository for 8th of July.

Please feel free to add any item you would like to bring up to the meeting. We are almost at time right now. Any final comments start? We have 2 3 minutes left. >> Yes. Um Sam, the the call for input. Um do you want to write this call for input or should I do it >> uh for the dispute resolution? >> Uh for the author dispute? Yeah. Um >> both actually. Yeah, I I'd prefer not to do it, but if you want me to, I will. >> Okay, then I will uh I will do this. I will not do that today, but I will I will do that. Yeah.

>> Okay, cool. Thank you. Very well. With that, I think we are good to wrap up for today. Thank you everyone for joining us here. I believe meeting the sync meeting helps us make decision faster. So, let's continue to have uh at least one meeting in a month and let's continue improving the process. Thank you everyone. See you around. >> Take care. >> water. [music]

Something Heat up here. [music]

up >> Heat. Heat.

>> Heat. Heat. [music] >> water

thing. Jesus. >> What's up?

Heat [music] [music] Heat.

>> Heat. >> What happened?

>> Super [music] Jesus. Oh, heat, heat.

>> Super. [music] Oh, [music] [music] here.

up [music] here. [music] >> Super

>> Heat up [music] >> thing.

>> Oh, heat. >> Heat up here.

Heat. Heat. [music] [music] Heat. Heat.

>> Heat. Heat. N. >> Heat. [music]

>> Heat [music]