EIPIP Meeting 35

Transcript

welcome to eipip meeting 35 i am going to share agenda in the chat so the first item on the agenda is erc process and standardization oh my god okay so uh there has been some discussion around this erc process i think i have tried to add a couple of links one is the process that i'm proposing that can be um done to improve uh the current process and help push most of the ercs which are still in draft status to let them go in in like whatever is the appropriate status for that proposal

and there is an another proposal of a magician uh it's a rework of erc process that that should be something different from eips uh yeah i'm happy to go through my proposal yeah if that helps so it just suggests that like whatever erc are in like uh stuck stage uh draft or maybe in any other state for over a a long period of time maybe over three months we should reach out to them i'm happy to engage catholics get that work done if that is the way we would want to go ahead with reach out to them identify what is the current center whether they want to push

it or not and unless a proposal is in the final status that should not be considered as erc standard is my uh like you know proposal but uh according to the other proposal is like uh erc's do not need a state of finalization um that is request for comment and it does not have to follow the standard process i'm not sure where we can bring this topic up so i thought of bringing it to eipip meeting because of two reasons one we have a lot of editors here another is the process improvement meetings so i'm opening the floor for anyone to share their thoughts i think light client did a good job of

um responding in the thread that you linked in the um uh agenda about uh a net wanting to change some pieces of the erc process and it highlighted some misconceptions people have with the erc process so i think education above all is going to be helpful here um if people want to come in and you know suggest changes to the process that's perfectly that's great i i think it over like a big overhaul like annette seem to be indicating is probably a bit too much i think something that might give a good win it's just to not

assign numbers to erc's until they reach like a draft status like force there to be a pre-status for erc's something like the idea stage it feels like as soon as they get a number they just you know run off and start telling everybody about their erc another concern that i have is like even if that is not in the pull request if it is in somebody else's github repository they are still calling it as an erc so that was my biggest concern like if

they want it to be an ethereum standard it has to be in ethereum github repository at least agreed i think yeah if if we and this actually mirrors how um how the ietf handles rfcs they have some pre-rfc process where it doesn't receive an rfc number and that lets people work on it some before it reaches the stage where it's considered a draft rfc or i forget if they have a different name for it but there's actually a stage like official stages that have to happen before you are assigned a number and i think just forcing that is going

to significantly cut out the number of junk ercs that we have to deal with right so if i understand correct there would be like two uh important point that we have to consider at this point of time like maybe one for uh upcoming eips like how to deal with them uh with their uh sorry erc how to deal with their erc number and like for the existing proposals which are already there pushing them and the suggestion for the upcoming proposal so here is to not add the

number any other thoughts or comment on this may not be related but um for things that require some kind of bridge or some kind of something to achieve uh i don't know if everyone's ready to do this yet but there's always we've got the core dev thing that peop core devs can rank each other deter who is and is not a core dev if that got fully further developed then we could develop an algorithm on canonizer where if you had x number of core devs signed on then you could and there's various techniques we could do like that to

so that is something would have to be signed on by a certain number of people or a certain number of um core devs and stuff like that in any way just an idea for possible future things for whenever something has to cross a bridge in my opinion that would be a good way to do achieve those kinds of things so that no one can just say well i'm an erc already but it shows how much support an erc may have in a quantitative way for which you can set a bar where you can say something isn't an erc until it meets that bar just fyi right with the erc the the challenge is it's not core proposal so it cannot go

to like all code of meetings and all so it's difficult to get the set of people here on one call i mean at least on this eipip call to you know make a call like how they would want to see i think that thread is good that net has started and we can continue discussing the future process uh like that but uh i hope the calendars are still good to go ahead and uh look into the older proposals does anyone has any strong feeling or should we wait for some time sorry what would you be looking through

the older proposals at so so far like um uh just one like i think just 20 of ercs that has been proposed are in final status and over 100 ercs are either in draft or in last call or somewhere else they are obviously being used and treated as standard in many places but they are not standard according to the standards so i was hoping to push them to get a like you know besties status i see yeah i mean that sounds like a good idea

to me yeah i think that would also help us clean a lot of eips.ethereum.org list because i'm not sure if we really have over 100 ercs active and usable some of them might have been superseded or may not have been moved for a very very long time though the requests are closed so we can reach out to them one related task i just reminded so we have created a an issue on eip ip github uh that was discussed on on the last meeting that we are also looking for

someone to work on a bot to identify these proposals not only for erc but for all all different types of eips so we can you know identify this and mark them as closed or withdrawn if they are no more in you so anyone who is listening to the meeting and interested in work the issue number is 73 please respond to the issue if you are interested in working on that um also just to kind of jump in here um like if no one else is able

to do it or wants to or whatever like i'm happy to um hop on hop on that um yeah or like even just if someone starts working on it in his questions feel free to reach out um i'm sure i can help with this is its implementation yeah right so alita has already worked on some of the bart related work uh for eip github repository so if you have any question feel free to reach her all right any more question comment on this

okay moving on to the next item is updating eip1 uh so i have created this pull request with the very very small changes i think that it has been approved uh but i still see here as not much so i try to look into it my concern here is like it requires approval of two of the um authors mentioned in the proposal eip1 i am not sure hudson one is you another one is martin but i'm not sure either of those emails are active anymore or how this can be solved if it is not you you can ignore the bot for eip1

it's because it's technically an eip as far as the bot is concerned it does its normal path but our process free ip1 is just making sure that the editors agree personally i like to wait until we like historically my policy has been um create a pr for eip1 wait for other editors to speak up if no one speaks up after like a month then i just merge it it'd be nice if we could get more interaction from more editors but that doesn't always happen so i just wait a month and if no one says no then i go forward um that being said with this one i mean it's basically just corrections and edits

i don't have a problem just merging it as it is if since no one's responded negatively all right uh yeah i i responded to the bots thing like that requires approval and i was trying to dig into that you want me to um add an exclusion free ip1 i can do that it wouldn't hurt the eap1 doesn't get touched very frequently so it's not a huge deal but if it's like a simple thing it's like a one line change sure all right though we do we have auto merge on now like if we disable the bot for that it's

just gonna instant merge i think it actually um requires that the bot be well i'm not saying disable it by the way i'm just saying fail it every time more or less or just fail without um yeah i mean the error would just be like eip1 is not supported at the moment um well i wouldn't i wouldn't do that i would just not auto merge the one changes the price i just request that editors only merge surprisingly more common authors who would expect um to not do that so at the current moment he's being able to just fail the the bot so yeah i think i just

don't want to have failures as the like like common state i'd rather things be passing because then if we have to force merge like i don't even have access to force merge if the bot fails for instance but also it's i would rather have passing ci show on the master branch yeah so the problem is that um github auto merge is just when ci goes green auto merge so either you fail ci or it merges automatically and so we don't want people just be able to submit pr to ip1 and just have it auto merge because there's no checks against it at the same time we

don't want it to be blocked by um this is where they like it requires engine notable engineering to work around this like it's not as simple as just let it go green and have auto merges we have to do one of the other like either we don't have any auto versions whatsoever can we not instead using the authors just have a list of the eip editors and ask ping them the same way that the mod is pinging authors and then on approval check to see if an author approved a vip editor approved it that is on the to-do list um that that feature just in general so specifically for

when we transition between draft and review rather than just having the author approve the pr it would take an author plus an editor to approve the pr and that would let it go through a state transition so from like draft to review review to last call last call to final we could have something in theory similar free ip1 where we require editors to approve that's that is definitely much more within the realm of possibility just requires some changes to the bot um so that's a smaller much smaller engineering task caveat are we okay with eip1 changes after a single editor approves yeah i was going to say that's kind of unfortunate that

we can't let it sit there for a while and just have other editors approve as they have the time to review maybe we could you uh yeah if you created in wait what do you mean interactive i sorry not draft ap a draft pull request if you flag the pull request as a draft it won't auto merge yeah this is and then just be clear like i can add those like the things you're talking about like client i think they're possible to add to the bot um the question is whether or not we want to like i mean it's a one-line change just just to fail a bot if it's eip1 but then to add like you know the different

criteria and stuff um i mean it's getting easier because i'm cleaning up the logic but like i don't know it's slightly more complicated and probably just generally not worth it i mean i just don't want the this the default for eip1 changes to be failing like i it's fine if it fails until it is approved and merged but i don't want the default for the ci to be failing on master like in the ideal world ci on master would never fail we would only merge on success i mean that's fine i'm going to go ahead and

investigate because i don't know um essentially like the way that auto merge works is you're given like a list of required checks that need to pass and once they pass it merges and i don't know if that considers like if a check was skipped right and then in that case it wouldn't be failing but it still would not emerge so i'm going to look into that um but more importantly that sounds good i'll address that problem thanks i think in my opinion the ideal solution given constraints of the tooling available is to have um four state transitions uh prs it requires author plus editor review

and so there will be maybe two checks or one check that does both whatever and once that happens and it can it'll auto merge and then for eip1 i like the idea of like two of three or two event editors um approve so once you get to editor's approval on the ip1 change then it will merge automatically that way we get what's likely once which is we always have green like cis there's ways to get ci to pass without having to bypass it which we're doing right now and at the same time it makes it so eip1 doesn't auto merge um just as soon as the first person approves it like you have to get a couple of approvals at least yeah that's better but i yeah it's just not ideal because then you have

people like alex barry saucy who comes in and you know you've maybe approved it i haven't got around to it peruvian he reads it and he says oh this worked this is good and he approved and then emerges and then he's just sitting his computer like why the hell did it just that that's weird and so he's not sure what just happened and then i don't probably review it because i looked and i see oh that was merged it's probably it's fine so i think i think the other thing we can do that's low-hanging fruit is just to have a general kind of policy amongst editors that when you're making changes to eip1 uh do it as a draft pr until you have some lots of eyes on it okay yeah they seem okay i don't know if there's actually a way to do this properly with github actions

i know you can do it with bores and some of the other auto hub managers with with enough engineering we could i'm sure we could make pretty much anything happen um obviously now it doesn't look like it can actually be done i don't know if you can actually be done with github actions because they probably use github action through the api so the github action would be then called github api which would then call back into github and then merge complete nightmare but like it's yeah and then in some cases when the rest api isn't good enough then we can start using graphql but whatever the point is that like um is that that sounds great and i will

look into adding those exceptions which just to actually clarify are we in agreement or are you on an agreement that the uh the ip1 change should require two editor approvals um and then that's it given that we only have two editors that actually pay attention i feel like any higher than that and we're just asking to never merge anything and lower than that and it's just basically the first person to see it merges it so two feels pragmatic

okay i'll add that sounds good thank you um so another small uh point i wanted to bring up here was related to eip one uh if we go to eip one there is this uh section of code eips i'm gonna share the link in the chat for people to write a reference so there is this section of core eips uh the first uh statement of it suggests that for corey ip given that decline implementation to be considered final eip process now that we have separated eip process and the network upgrade process my understanding is here we should have the network upgrade process because the eip process that is

pointed here below is basically the eip statuses these same seem like a big changes for me to do it right away in the pull request so i wanted to bring it up in the meeting first before i can create full request for that so uh um like is it something okay like you know um we need to change here it should be network upgrade process because this we are talking about kodi ips so i would on the one i'm of two minds on this on one hand i would like to rip out the whole sect that whole query ap section and just record these like all their eips and follow kind of one consistent process um on the other hand i recognize that a lot

of people don't understand the the whole ethereum change control process in general and sometimes they end up starting out on eip1 and this kind of circles back to the whole our documentation on the ethereum change control process is distributed across a number of different places and i think getting that consolidated will help with this and will allow us to have this document focused just on the eip's repository stuff and not have to worry about describing you know what is the theme what does it mean to get a change into ethereum things focus on what does it mean to define a standard it will be with this document

as to what we should do right now whatever yeah at this point i i also uh figured like while i was going through this document again and again i figured that at many places instead of writing just eips we could have just proposes and that will cover all it's not only for core it's not only for this particular type if we address them as proposals or improvement proposals that would have helped a lot but for this particular section uh i think here uh because this was like you know uh before they uh before we had two separate processes my understanding is for under bracket

it should be network upgrade and when we are talking about uh the below that that is labeled as eip process should be actually the eip um um statuses like right obviously it is the process i don't know please somebody help here i think that you're talking about in the eip workflow section the subsection corey aps right right yeah i really think we can just delete the whole thing i'm reading it right now and all of this is basically outdated i don't think any of this actually is correct or applies anymore okay if there's information that we want to retain it should be moved over to

um eth1 specs repo right so we already have added that in readme file of each one or spec repo we can okay what's that yeah i'd say just delete it i don't think we need a pointer just delete all of it like most of this is wrong i guess from like years ago and this doesn't actually reflect the process we actually follow all right and about this diagram i remember i mentioned it in some of the channels um about this stagnant that it should it is a state and it should not be considered as status but later on while looking into ercs i felt like it should be a status for those proposals which are stuck

somewhere yeah fine with that i think we i think we talked about having it be a status but it wouldn't take effect for like a year or something when you originally talked about it like he said something like if an eip sits for six months or 12 months or something i don't know what the exact amount was then we'll just move it to stagnant just to indicate that no one's doing anything all right i just wanted to correct like i mentioned it somewhere so i think you were right there so yeah just wanted to bring it out again all right so we will revisit this evp one once one more time and try to figure out how it can be improved because i have seen that people have

started using it lately because we have been talking in different forums that the best place for you to start learning the eip process or the standardization process is to go read eit one so unless they make that like up to date it would be difficult for asking people to follow the right process okay any more comment or question on this topic fine moving on the number three item is new eip editors onboarding funding and related processes uh so in the last meeting we discussed about having a couple of more resources as like interns or maybe

apprentice for eid editing and um for that i just have created a small document that is a handbook for reference for new people like we have seen people visiting us on discord and other channels asking how to support so this is just listing what is the right set of places to visit or the documents to refer and a few frequently asked questions um i i'm not sure if like if there is any actual work that has started and people have started working on it anyone has any info on that i can confidently say that i have not

done anything yeah samesies i think you set up the channel and discord since last time and there was a little bit of movement from who was it um spore but uh are they here today i don't see any of the them today here on the call actually yeah so we might have to table this one till we get them back in here is or trent are you still interested in doing some eip editing or is that that phase passed in your life i am definitely interested in learning from you guys sure i i i can't contribute at the same level

for sure but uh i'd be curious to at least try to engage a bit more i think you may be overestimating the level at which we contribute cool then uh sign me up yeah so let's add trent to the chat pooja yeah i'll do that i'll do that and trent i know you are very much familiar with the process and everything else but in case if you have any question you can refer to that document but yes that is a good way to start um i'm not sure tim if you have any further question on that like you wanted to discuss something sorry i didn't have a time to look at all

all right no problem um okay as far as onboarding is related i think uh the general process here would be like people start looking into pull requests and issues and start adding comments and as we see more comments getting in eventually it will be easier for them to put them into full time not full time obviously like the eap editor as we have a few people here okay any more question on that we can continue discussion on discussing

this in the uh channel that we have created recently moving on to the next item may it's uh the progress on eip github repo action part yeah so i was curious to understand like i have been uh my understanding have been like it is almost done and it's about uh to be finished so just wanted to make sure if we are done with the primary task of like renaming the bot the script has been transferred to ethereum github repository and the part is working as functional and can we mark this task as complete yeah and complete i'm not sure about uh it's only me or someone else also sees

the bot with the same name i heard that you mentioned that you are a human more again but but it is still oh do you mean like um like the actual like repo bot yeah we just decided not to rename it because i mean the eip bot is like pretty self-explanatory in terms of its purpose um i suppose it can be renamed i'm not i think the i don't know what the impetus was behind renaming it to begin with um i think maybe that was more more so in reference to like moving it from you know my private repo to the ethereum repo um and or transferring ownership which we have done

so i mean i'm not holding my breath that it's going to be renamed um nor do i think it's necessary yeah that's what i see here so i'm wondering like if it is renamed why is it not showing to me no it it's so it's currently named eth dashbot now um okay so i think i think that task is done then it used to be named more yeah yeah apparently i'm a bob but like um yeah so i created the new bot to then take over my role um so i think the reason like you might

see or i think the reason why there might be some confusion pooches because i did it last night um and so there's it really hasn't like updated yet so it's good to say that the new bot name is eat dashboard correct yeah then we'll start using that one instead of eip bot good to know okay then uh i know that you have created a issue could you please mark it i don't know i i saw some last comments that were a month old if you could just uh answer to that and close that issue would be great we'll mark that task as completed i think i closed the issue um yeah sounds good

thank you so very much okay um i see the next item on the agenda is also uh i guess for you to speak on i see or comment that you would like to update us on json rpc api spec in each one repo the world that you have been and your team is doing okay yeah so the the json rpc is admittedly taking longer than i'd like um it is turning out to be kind of like get the github actions a significantly more um complicated procedure than you would you might expect um

but we are kind of like i mean it's a plan there's a vision for it and i just recently onboarded um jared who is on the call right now um to basically help with like producing things because i don't work full-time i work like i don't know like 12 to 16 hours a week on all this um and so it's hard to make a lot of progress but uh jared gonna be working full time with me i'm gonna be kind of project managing him um kind of training him today and tomorrow to sort of really hopefully ramp up production in terms of getting these edge cases made and everything um i don't know if

anybody was aware of this promise but i did promise to have um the eip1474 kind of converted to open rpcs to open our pc such that we no longer had to rely on the ethereum classic um open rpc which that is not done that is being delayed because um because it's more important that i onboard jared um and kind of get that production rolling so in addition to that like um i'm going to be like every week i'm going to be kind of or every eip ip mess um meeting i'm

going to be covering the end points that i'm going to be educating or we're going to be edge casing um and then like essentially it'll be a time where if for whatever reason um i don't know tim maybe you know one 1559 has a high importance right now um or there's some endpoint you know with high priority then people can let me know and i can prioritize those above others drop some things that we're working on um whatever just to try to keep some um visibility into what's being done so yeah i think the most important thing right now still is like the the cco spec i was talking about that

with lifetime this morning so um yeah that seems reasonable um yeah i think all the 1559 stuff is either done or you know like uh it's not blocked like there's no like uh 1559 changes that are that are needed we might decide to do more in the future but i think people will submit prs for those um so yeah i don't think there's anything left for for you to handle there i posted in the chat but i ended up rewriting the spec under cco yesterday so i recommend basing work off that oh you did wait did you just do all my

work for me what no it's it's pretty basic sketch i just was basically copying the information from the eth wiki so there's still probably some bugs and stuff okay um like clients stop doing my work for me but yeah um sounds good thanks i'm gonna use that for sure do we want to break the jason rpc stuff to a new repo was anything decided on that this is the first i'm hearing about that

oh yeah so um uh basically i think life science and i were talking about that but it seems like uh the eth one specs repo and the json basically contains two things right there's json rpc and there's the consensus specs it seems like those two things are very like they're very tightly coupled right now and there's not a ton of reason to have that um e2 basically has two separate repos they have e2 specs they need two api um and i feel like it might be a good idea to uh do a similar thing just because um yeah if especially if we move to a spot where like we do have like an executable spec for each one

um there's not a lot of like there's just gonna be such different things like the executable spec and the json rpc spec um yeah so that was kind of the the idea there um let me see if i can find like the uh i had a github issue for it um that's had commented on it yeah i suspect people might have just missed it um i think i posted it in the jason rpc channel um i posted in the chat here yeah so um

i oh yeah and i guess another thing too i feel i'm a terrible maintainer for the jason rpc stuff like i just have very little uh i guess hands-on experience with it i think i'm okay to maintain like the specs repo but um yeah it would be good to also separate those concerns like right now you know it's not the end of the world i'm i'm happy doing it but um i think yeah having two different repos um and yeah i i don't know how urgent that is like i i'm not sure i it's not something i would do before london hits my net for sure because we've been pointing everybody towards a single repo but if it's something everyone kind of

agrees to then maybe right after london is a is a reasonable time to split this um i mean this makes sense to me i i would say that like i i guess just to sort of like reiterate and be clear um we want to split it because of the fact that like the edge casing and the sort of like space specification or kind of do two different things no so i would remove even the json rpc spectrum that's repo basically like it just feels to me like the consensus spec so like the actual core eips and the hard forks are very different from the json rpc specs and that's what i would want to split

so like everything json rpc related would go into the separate repo and everything consensus spec related would stay would stay in the ethon specs repo um so if you look in the issue i shared you know e2 has exactly that um and one thing this would allow us also like aside from just like a better separation of concerns it would allow us to version the json rpc spec much easier so uh mica and that client both had proposals where like we could have a master branch which is you know like the stable spec but then we could create like a dev branch and uh you know have changes go first into the dev branch and maybe every month or so you know depending on the frequency of changes uh we review them and then we merge dev and the master

um so you know in this case like for example for london it could have been really nice to have like a specific dev branch that has all the 1559 stuff especially as we're still iterating on it um and then you know maybe once london actually goes live the main net uh then you merge that into back in the master or something and obviously that's something that's like gets really awkward to do if we also want to do the same thing with the consensus specs right like i think we want to move to a spot where if we have full consensus specs for each one um then we can do uh yeah then we then we can uh we can do just uh you know the similar thing where we have a branch for hard forks and stuff

like that um all right yeah that sounds good to me um whatever you think is best to keep things clean yeah and like like you're saying what would you pr into so you know i've ridden like most of the json rpc spec under cco like the absolute bare bones with the methods and the types but there's still a lot of like descriptions that aren't filled out or anything and so i can put pr that into the eth1 repo because the problem is that any work that we're doing on top of the respect that exists right now goes under apache 2 license and so the sooner we transition to cco all the work

becomes cco that's built on top of it so i can either pr into the eth1 repo or we can just start a new repo this eth 1.0 api's repo and put some deprecated notices in the uh in this eth1 specs repo that point to it that's my preference but i think yeah i would slightly prefer waiting until after london just because everybody's we've been pointing and we have like a bunch of london documentation that kind of points there so it's not the end of the world even if it's marked as deprecated but it feels like just having one spot might reduce confusion for like the next month or so um can we just like mark it as deprecated internally and not make that

and not socialize that publicly until london yeah we can do that or we can also do a sub module within it and then it looks the same to everyone else but it's the information is coming from another repo so it doesn't really change anything it just as if london will like remove it from the spec repo i'm fine with that does anyone have it thoughts objections about to say that to lifeline that why not why don't you make a beer but yeah now it is clear why why we are editing so i'm in favor of that and i guess so the only thing you would need for me then

from me then is to actually create the repo because yes yeah you can create the repo okay okay um so i can't but i can pick the devops people so it should be done today or tomorrow and then if you can add me as admin so i can maintain the ci stuff on it yeah cool and then yeah we'll we'll figure out whether we want to just like build it out separately and then after london kind of announced this is the thing or if we want to do the sub module i'll check and see how it looks either way okay um what do people feel about like names should we ask in all core devs what

people think that could delay this decision by two weeks okay oh i meant on the chat not on no yeah that could delay the decision okay um yeah okay anyone has a strong hit yeah so going for each one apis no no eth1 we should be terminating the name eth1 and these two we should die in fire but i would do that change when we did

the energy the longer we wait to change these names the more they're going to get seeded in the harder it's going to be like changing names is really hard to do especially with like a large community like ethereum community but we have issues already right yeah we should rename that like right away like we should be renaming things today like i keep like once a week i ping uh danny and say hey can we please rename the channels and ethereum discord because it's hurting us the longer we don't do this he's like yeah we should do that and then like later again i think the time to do that is after london and all terror my opinion on that like it's just like a lot of because what we point people to all these places if you start changing the

names there's already a bunch of like dead links in my old 1559 stuff so i yeah i'm i'm sorry we need to remain a bit but yeah i would wait until after that so with with github repositories when you rename them as long as you don't create another repository the old name it will um 302 redirects so so you don't have to worry about links dying if you rename the repository to like the thing is we want i think we probably want to rename everything right like the worst i think the the worst like spot is if half of it is execution and half of it is east one right like i would do like a full rename of the discord of the repos and i don't know if this other stuff but like um you know it's kind of i agree i agree that that is the worst spot is

to have half and half my concern is because there's different people in charge of each of those places and human coordination is hard everybody is waiting for someone else to like do it all at once and no one actually is in a position to do it all at once because yeah i think danny and me can get 95 to 99 okay have it done so what do i have to do to convince danny and you to sit in a room and just rename a bunch of stuff for a day uh like i i think to convince me is like wait until london is shipped that's my biggest concern yeah um of this i'll agree to lay off until london ship but you have to recognize that as soon as london ships i'm going to be on your

ass like daily yeah i i can that's the trade you're making here yeah i can live with that so we call it one apis for now it'll live under that name for like six weeks um and then it will have a a renaming that's fine for me what are we running into that question yeah yeah i mean that's that's micah's job right like um yeah yeah i i would be fine with execution api you know if we if we rename everything execution like i'm fine we just you know swap eth1 for execution everywhere basically that's that's generally okay for me um that's my preference and that seems to be

the direction that's getting the most traction of all the options yeah um but okay so i'll ask to create e1 apis today um pay me after london micah and i i promise i will uh make this a priority and i'll also pay you um ping uh danny and and try to get a priority on his list too um um cool okay so yeah i'll i'll paint the devops team to open it today i don't think i can create a new repo in the ethereum org um no i just checked i cannot one more thing on similar note um maybe micah you can help me understand i

i saw some messages related to some admin issues that you were not able to solve when you were looking for some help is that being resolved or you still need some help on that uh no i still need to deal with that so uh i don't know who the admins of the ap are but there's someone who is spamming it and normally i report them to github and get to advance them unfortunately this person decide realized that hey if i just pay github five dollars they will let me spam infinitely and will never ban me can they ethereum admin from ethereum yeah so an ethereum admin can bad them from the ethereum org so they can stop spamming us at least i'll still continue spamming the rest of github but at least they'll stop having us

okay yeah just get me their handle and i can get that result too okay all right so i'm just wondering like is it possible to get some kind of access to uh at least editors like micah and lifeline for them like you know to be handling these issues i don't know about the policies but just yeah i i i guess the the short answer is it depends the long answer is if there's a specific ask that's easier like so you know like making my client an admin for the and we just lost i find but making making him oh he had to hop making him an admin for json rpc like you know that was a pretty specific

request and i think we're able to do it uh i managed to get some guy admin for the yellow paper too who's done a bunch of pr's to it so like i think in general like if there's a specific reason and a specific history of contributing to the thing you know with high quality it's it's it's fine um but there's no there's no process unfortunately it's you know i said that to the devops people and i write the github ticket with you know good enough description of why i think it makes sense and if uh if people are are content with that it tends to get approved so in this case i don't actually need admin access i just need to know who the right people to talk to are when this

happens uh this happened like once before as well yeah it's just difficult to get so yeah i'm happy to act as a router in those cases uh jamie pitts is probably the best person from the ef if you want to go direct but he uh he does get a lot of like random inbounds so he you know if he doesn't answer um yeah it's kind of my job to answer to random inbound so uh whereas his job is to actually do devops stuff so yeah i see i'm sorry yeah no no it's not like i mean no no but but yeah i think you know pick me or you know jamie if you want to go directly but i i can make sure that jamie sees it eventually and yeah okay sounds good

all right uh so we are almost at the last agenda item about canonical source for eips um if you may have any update on that yeah i've been uh haven't had time to even look at this especially since i've been out offline on vacation over the last week at lake powell so sorry about that worries um we have almost had the time but i can quickly go through the last meeting notes i'm sorry the link is missing here i am sharing here in the chat all right so according to this um there were a couple of action items

two for me creating the discord channel for new eip editors and have the conversation of onboarding and whatever they need to do or direction they help help they need can be discussed over there the channel is created now it is on ech discord um puja to create an issue for eip bot to get updated okay so we have this issue created anyone who is willing to get more engaged and help out with the kind of development of this new bot this new script is identified the proposals which needs to go into the right status the issue is available on eip ap github repository a litter to work with mica to close eib

development issue and the stars seem to be close now so we are all good that's all from the uh i just listed on the agenda today anyone has to bring up anything yeah i just wanted to mention i brought this up maybe a month ago to jamie um but it looks like it's come up again in the characters about people going into getter and nobody is really there so um i'm gonna try and get uh get those deprecated if we can and just direct people into the ethereum r d discord instead um but it's cool it looks like somebody is already

finding where they're linked in documentation right does anybody have any thoughts on this right so someone pointed it out but he specifically pointed out for wherever the cat heard his getter was mentioned uh so we are trying to fix it like put discord channel over there gotcha yeah just just generally i think it's probably a larger problem outside of uh cat cather's documentation right so yeah um and seems like jamie is the person to contact for this but i'll um i'll try to reach out to him all right so yeah

we will continue discussing in different channels that we have mentioned today about the eip process and the json rpc api process and other stuff uh thank you all for joining today see you all in thank you everyone have a good one thanks