EIPIP Meeting 42

Transcript

welcome to eipip meeting 42 and i have shared the agenda in the chat the first item listed here is post merge will core cover execution and consensus or do we plan to categorize eips based on what they touch so eip process after the merge is something that people are interested to learn about i have picked up this agenda item from the eip editing channel though i find some responses there later on but not sure if there is any general agreement we discuss and come to a workable solution to most of the challenges related to eips statuses and the process so i wonder what people of this group

imagine the eip process after the merge to be so we lost light client i was curious for his thoughts but i can share mine and what i've been trying to advocate for yeah please um so i i think eips are really good because they provide kind of an english description of the changes uh especially i'm just focusing on quarry ips right now um and and i think there's a lot of value in like when there's a change to be able to like bundle it with an eip number so say you know eip 1559 is this change transaction fee market um eip uh 2929 is

this change the gas cost prices and and so on um and i think that's like a really valuable property like for example now if you look at the altair upgrade um there isn't uh there isn't eips for each of the changes and it's kind of hard to like explain what all the changes do um so that being said eips are also not a great place to actually have the technical specifications for the changes for a bunch of reasons and like clients has has gone on to this before but it's just it's hard because like you don't have all the entire specifications so you have to provide a lot of context and whatnot um

and the the cool team has been working on an executable specification for for the execution layer um so my i guess a long way of saying what i would like us to do is to keep core eips as a way to describe the changes that's at a high level both on the execution and consensus layer um but then not necessarily use them to to have the actual technical implementation inside um so that this way you could say an upgrade of the execution layer or the consensus layer has eips x y and z and the eips all have a link to a pr in the in the respective spec and that pr is basically what um

the actual technical changes um so that's what i would like to see i don't think it's been fully like decided yet i don't think it will be fully decided before the merge actually happens but right after the merge i suspect is when we start working on the actual beacon chain fork is when um uh we'll probably look at that that's interesting yeah i mean i generally agree to what you are saying i just have one concern or maybe a question there when we are talking about keeping it in a separate full request will that be a part of like a main ethereum repository or would that be a part of the individual's repository

so it would be a pr i guess from the individual's fork onto the main ethereum repository and then when it gets merged i guess when it gets accepted into a hard fork or something like the pr would always be on the main repository um right it's just opened by someone else and i guess if it gets accepted into a hard fork then the pr gets merged into the the main branch all right maybe i am missing something here uh but uh if i understand for a proposal to be merged maybe even as a draft it has to have no external links so the first first time then proposal is being

proposed as a pull request to eip repository it will be individuals but it gets accepted and then uh for further changes there will be a link within the eip for the technical specification yes yeah so i guess we'd have to have links for that yes all right i got yeah so i'm not a fan of that strategy as i'm sure no one's surprised at i prefer the strategy that i think um sam is planning on which is that the execution specs repo once it's ready will have um the human readable content in it

and so the entire process can be done in the specs repo and already we have that i think in the consensus specs repo they already have the human readable version as well no they don't embed where do they have that i thought they pull it up so they have the annotated specs yeah like they have which is notation they're human readable right yeah but those are they're bad they're good if you're reading the spec and you're trying to understand what it does they're bad if you're trying to reason about like the why you know like when we have discussions about including eips i think those are a pretty bad format because they don't walk you through like what's the

rationale what um you know what what basically benefits does this bring what are like the trade-offs and i think eips are great for that like a really good self-contained document is that content that needs to survive a long period of time i think so i and why is that why is that like someone in five years when they're looking at the specs why do they care i think the value is like it also helps like time it was proposed right right yeah it helps like encapsulate the changes in like a really valuable way like i don't know i found like i've struggled

to like explain alternative people more than i struggle to explain say like berlin um because it's not quite as easy to like say hey there were these three changes brought in and like at a high level here's what many of them do so i i don't know it does feel like it maybe it's just for not technical people like me uh but it does feel like more legitimate i agree the information is useful what mike and what i'm contesting here is that how often are you explaining to people what was in homestead like you don't you talk to people about like what's in berlin because berlin just happened or what's in the merge or altair because it's very recent but no

one cares what happened in homestead other than like the people who are implementing it and need to have a client that can travel through homestead and everyone else is completely oblivious and doesn't care like regular humans like not engineers don't need that history long term um so and the reason i think it matters how permanent the information needs to be is because i think for certain types of content we don't need like a really rigid long-term like standardization process like we just need a place for information to be and that place can be somewhere that's more transient where transit in here might mean a year or something but it doesn't need to be like 10 years

right i guess the other thing is and i'm not sure how much this is like valued here but i think eips are really well understood by the community and they're like easy to point to and for people to like hatch onto um whereas like even now that we've moved say the hard fork specs to like the specs repo i still get i had literally vitalik asking me for the the meta eip for london right then being like well where's the eip so i think i think there's like a really high cost when we move away from these systems like people just you know are used to them and it's not to say that like we shouldn't do it but yeah i i don't know i'm i'm a bit

cautious of moving it from away from vips all together but it's not a hill i i i might agree try to die on it i i won't fully die i'll lose an army this is the hill i'm willing to lose an arm maybe a foot on yeah yeah so i agree with you that change is hard and people will resist it no matter what it is like pretty much anything you change people resist you change the color of the facebook logo and people throw a fit like it's doesn't matter what it is or how significant it is or how significant it is and so i agree that if we do a change people will push back on it and we should consider that to some extent um

i wish that people would stop using eips i think this is this is one of the things that i dream maybe one day we can get to a place where people that aren't implementing specifications don't use eips for anything like no one who's using a web browser goes and looks at the w3c specs like they are incredibly technical and they are impossible for anyone to read regular people go look at like and even regular developers go look at canius.com or whatever like they go to other places to get that high level information they don't go to the specification like rfc see the same thing people who go to rfcs are people who are trying to implement

an rfc compliant thing and that is it no one else looks rfcs and i and i think this is where i end up uh in conflict with a lot of people on the ap eips is because i want the ips to be that i want them to be a technical specification designed for a very select group of people um not that we want to exclude anybody but just like the target audience is a very small set of people the people that are implementing things on ethereum directly and they need this strict specification to look at and then we have all that other stuff like that regular people go and look at somewhere else and um i think i'm kind of alone on this i think everybody else would just rather the eips repo just be this monolithic thing where as the source of all

information for ethereum um i think my problem with that is a i don't really like monolithic things i like things that are very targeted but separately we just don't have the manpower to manage a repository that grows outside of the scope that it currently has if we had more manpower then i think i would push back less hard um because as we extend the the audience the target audience it gets harder and harder to maintain things and you get more and more people trying to get involved and contribute and it just it becomes really hard whereas if you keep it very constrained say look this is a targeted at these you know 30 people and

that's who we're going for you know we're not targeting everybody else then like the management of it is much smaller because there's less people throwing things in at it there's less people reading it less people um debating you know what should we do for different things so i don't know maybe if we can somehow figure out a way to get more like people involved in the process at a low level we could expand the target audience and not suffer as much i so i guess i kind of agree i i 100 agree with like the fact that limited by number of people limits the amount of things we can do if that's really the main constraint

i think that's a solvable problem um and i'm conscious that we've tried to solve this problem before with like mixed uh success but we've also tried harder things on ethereum um i i'm also pretty sympathetic to your point of like no one cares after and and whatnot um i think i would be kind of fully on board with your vision it's like if we have a better process defined for the how do we actually talk about stuff and decide on stuff when we're doing it um right and that's you know yeah i think personally i i really like just as an engineer who uses github all the time

like most of my days on github or it used to be at least i really like prs and i like using pr's as the place where people discuss things and talk about things i find them because the code is right there it's like close to go by and once the pr is merged it kind of just goes away and you can still reference it like if you want to refer back to discussions or whatever you can but i do like that personally i don't know if it's a perfect fit here because i think pr start to fall apart when you get a large number of people involved in the discussion process unless you have like someone shepherding like the the first post and making sure that it's always up to date with the latest conversation but i think no matter what we need a shepherd for every change

and so the question just is where is the shepherd maintaining the current documentation for the change itself so not the specification but where they documented those things like the rationale the motivation and as people are contributing to the discussion you know they add things like when i was doing 2718 people would if i saw a question come up like more than once i would just add it to the rationale and so you need somebody there doing that step like making sure that this contains the latest information for 1559 i felt you did a great job with that with your hackmd article like it had a huge num all the links to all the relevant materials that you know people could easily find everything i really liked that personally i don't know why everybody seems to hate that

process but i thought it was great right it's like i agree with you i think in theory um and then i i just like think of all the practical steps and like hiccups to getting there and it seems like a harder yeah i'm currently debating i think with nick on this on the eips repo where we have the eps repo and it has a process creating a new process for a thing is hard so it's much easier to just shoehorn your thing into an existing process so

it's like oh there's a process right there that's related to ethereum i'll just jam my thing in there and just kind of squeeze it until it fits and i totally recognize why people do that because setting up a new change control process thing is a ton of work and lots of you know figuring out the details it's it's complicated uh i just i worry so much that if everybody jammed once because what i've noticed is once someone jams their thing into the ap process then they come back like like they force it to fit in there and it kind of fits like you can jam it in it maybe fits and then like a month one or two people do that and a couple months passed and then those people are like hey we should make the apd process work better for these

things right and by making it work better for these things it works less well for the thing it was originally designed for which is corey corey abs and so each new thing that gets shoehorned in is bringing in people that want to change the process to fit their thing better which means it doesn't fit the thing it was personally designed for as well and so i think that's my worry of the whole shoehorning and i i'm constantly arguing people on the aps repo about this like three or four times a week at least about someone you know wanting to change the process um because it doesn't fit their thing and i don't have a good solution other than hey go build your own process which isn't a good solution it sucks

well i don't think that we are going to get a solution right away today in this call for everything but um yeah but i think uh in improving the process we we have we have covered a long distance and educating people like how do we work and now that with some new changes coming in maybe if we try to define the process early on would be helpful for other people while i agree to both micah and tim suggestion about seeing eip repository in a different way but i think or that's that's workable for core eips and there are a ton of people who are there uh using erc's as well so if ercs are there processes are

there standards are there it will be cluttered we just have to try to clean it up and uh with the help of some of the bots that that have been designed recently uh to you know help us with the process i think we are in a process of cleanup and if i look at the stats today out of about 400 proposals that exist in eip repositories 200 are in stagnant so we we did some part of it and we are trying to clean up step by step and come up with clear and concise list of proposals those are good and irrelevant and as per the like people looking into the history

may not everyone uh be interested looking into the history but some students especially like i interact with a lot of college students and i have seen when they are trying to learn something they try to dig inside say for example account abstraction the latest proposal that vitalik proposed so when one of my students he was looking into that proposal he tried to look into all earlier proposals that were written for a counter abstraction they may not have been in like the final status but it did help so i think keeping history for these is useful is helpful for new people getting on board and yes we might want to improve the process do some cleanup and give it a

good look yeah and i think realistically this is gonna be a high focus after the merger like at least once the merge is like done code wise um yeah i and i think it's gonna be hard to get input from like actual engineers and folks from like danny until the merge is is is a bit farther along um yeah even like personally it's yeah i know this is important that we need to do it but it's like obviously less

important than the merge and so it just like falls to the bottom of my priority list every week um relative to just whatever thing related to the merges so i think once we're like in a spot where the code is mostly stable and we're kind of going to main nets then then people will have much more mental bandwidth to deal with this and we'll also be forced to deal with it because basically um we're going to need to start planning the withdrawals for afterwards uh i think uh sooner i mean um i understand your priority list here like getting into merge specs in place but i think the sooner we start discussing on the process better it would be for us because as for now we have just one

proposal that kind of describe the changes what we are expecting how we are going to switch from proof of work to proof of stake that is very good but in case we are trying to have some more features or something to be added if we keep getting them as like you know um proposals as eips and we have a place particular place for that that would be good for people to follow because they would not feel the friction like something has changed it would be same but if it start thinking about right at the point when merge is there i think it would be a little late for that i agree it's not optimal but i just think it's not realistic to expect a ton of

feedback before it emerges much farther along so that's just and i think folks like probably like me and danny can start looking at it um but yeah it it yeah it just feels like there's there's little appetite from like actual engineers to discuss this and maybe i don't know once we get to a spot where like the cordless calls are pretty empty again because like you know we're done with the merge and people are just saying that they fixed it as bugs that's maybe like a good a good signal that we should start bringing it up yeah i agree i mean yeah as i said that it's not going to be like decided today only but i just wanted to start discussion so we hope to get it discussed at some

point i think one thing that could be valuable um and uh is maybe getting like sam to present the executable spec on an alcor devs once uh he feels it's like in a reasonable spot so that i i suspect like most people on all core devs don't even know that's been worked on um yeah could be yeah i was thinking about that yeah yeah maybe like a if we can like peep it absolutely but if we can also do like a five ten minutes on all corners i think yeah it just catches different audiences but like absolutely we should have even and maybe like a sort of teaser on all core devs or something uh where he can just kind of give a high level overview

and then invite people to come there um yeah yeah um i'll try to show you something real soon on that yeah yeah that's a good one all right uh i think we are close to like uh half of the meeting so let's just move on uh unless someone has some last thought to go on with on this topic uh only comment for me just to close it out is if you guys do want to try to devise a new system um i'd be happy to be involved in whatever that process is so feel free to invite me to things if you think that would be valuable all right

so moving on to the next item listed here is remove updated from eip1 uh likeline has just started this issue and i saw some comment from mica but i'm not sure if uh like there is any reference to any pull request the link is added to the agenda so this updated is uh is there in eip1 but it's not being used it is about the last updated i think it is redundant because uh github will give us the last date of updating that proposal so it is not something that an eip author should keep on adding every time he is updating his

proposal sorry can you put a link to the agenda in zoom since i was late i missed it that way i can find these things you're referring to okay okay i'm just i just shared the link of the issue and i'm also sharing the link of the agenda here so the idea here is like yeah so for that one we just need um we have two pr's out we need to merge one of them both both pr's remember let's just turn let's just turn alex's pr and two ready for review without

alexa green i'll do it sorry alex you were overruled all right i did it it shouldn't auto emerge now maybe like it look at oh no it changes something other than an eip file okay we will be coming to that admin issue as well like that is there in my agenda list today but before that i also want to go through this one so uh do we consider that uh number two remove updated from eip one uh like salt yeah i think we just literally need to

click the merge button on this which i'm about to do okay cool so uh next one is uh some of the changes that i was wondering how to deal with and that's why i have listed them here with this eip bot like as i mentioned earlier 200 proposals have been moved to stagnant so far in the month of uh september and october so i'm looking for some of the guideline to understand and may be able to educate people on that the status changes from stagnant the present eip one suggests that it has to go back to e uh draft uh do we want to always go back to draft or is it okay if we can uh update it to review or is it okay to

go back to the last status say for example one proposal was in last call but it was last call for over six months the ip author did not do anything and now it has been moved to stagnant what do people think about when this proposal has to be pulled out should it go back to draft review or it can go to last call um so if someone has i think i'd rather people go to review first so i don't have a good reason for that to think about it i just want to make sure that people are getting the appropriate eyes and they're just skipping ahead to the end in hopes that no one will actually look at their

thing right and with the last call here is like i mean i was thinking that if a proposal was in last call now has it been moved to stanley it can be allowed to go back to last call but that would be the day one again 14 days so it will get the enough review period of time so i guess i guess realistically if someone wants to go straight from nothing to last call i don't actually have an argument against that like if you're so confident in your thing that you think that you don't need anyone else to look at it before it's done um i guess you could just go

straight to last call like like i can't think of a good reason to force people to iterate through the steps like the more i think about it so i guess yeah i don't i don't have any good argument for making forcing people to go through the steps yeah that sounds fair to me as well we might want to like add some text to eap when describing these changes um yeah like do you have any thoughts or do you think it is fair to go back to the original status um i don't really mind that much i would prefer slightly to go to draft to review but if they really want to go to last

call that's also okay yeah because make sure yeah i agree i agree i mean we want like people should should be around for the proposal to move it and we don't want the process to be a hurdle for them to like move their proposals all right i will make a note of that the next one is i think we discussed it yesterday in the eip uh editors apprenticeship meeting it's like when an author is making a pull request to change the status um would it require editor's permission or

should the bot design it like it should be auto merge like our our thought would like likeline suggested that it should be auto merged because author is there is it like if the if it's created by the author so actually i i saw that there is this one example um i think uh the proposal was um uh one five two three so it said that the barter left a message that it is auto merging but it never merged so i guess there is some bug you might want to look into it later

all right we'll do i suppose uh like land has also created an issue in the eip part repository so you might get some reference on that okay uh the next one is if moving the proposal is impossible for any reason say for example uh eap3403 partial removal of refunds we know that there is another proposal that went into one of the earlier upgrades and this is never going to go through now this has been moved to stagnant so we would want this proposal to be out of repository not stay in the stagnant forever so the next course of action could be to move it to withdrawal and withdrawn i don't know if the author would be around to do the thing

so i was wondering about what could be the other way so we make a cleanup here without uh um author's involvement if if if someone creates a pull request and arthur approves it it's fair enough if not can eip editor do it sorry i was trying to merge that what's the short version of what you just said so for a proposal which no longer we know that is no longer to go in the system what do we do with that if they are standing in stagnant status what do you mean no longer to go in the system

uh so there are a couple of proposals say for example eip2070 which was mata e prepared for i guess berlin or london uh i know that it's not gonna go ahead so it's better to be withdrawn that is that we know the author maybe we can reach but there are few more proposals um there was one for partial removal of refunds eip3403 we know that there is some other proposal that went into the final upgrade so this would never pull through and we don't want to leave in stagnant forever is it fair that someone creates a pull request why don't we why don't we want to leave it stagnant forever i thought that was the whole point of stagnant is a place we can dump

things that are abandoned or the author no longer seems to care about because there is a better proposal that actually went into it and it was proposed by the same author yeah i'm like i still think there's value in so i'm not a fan of doing anything with other people's eips and so we the two options we have currently it's our current process is either allow it to fall on stagnant just due to no one touching it for six months or two months or whatever it is or ask the offer author to withdrawn like we don't have a process for any other terminal states besides those two and i treat them like mentally is fairly

similar are you saying that you want a to delete the eip or just move it some new oh no i was wondering i was wondering like the proposal that has a hope that it can be pulled back should stay in withdrawn as long as author wants to but there are certain proposals which personally i feel is no hope for them to ever get added to the final repository because uh that was an intermittent proposal and something better was proposed during the same cycle and the better one went into the upgrade so we know that the older version is never gonna go through

so the two questions i or one question will comment um what would you like to see them with these like do you want them deleted from the repository or do you want a new status uh maybe withdrawn because that is the only terminal status we have got here it just that this time with john is not by the author it has to be with the permission of eip editors i'm just proposing this so my concern is is that deciding what is which eips are never never possible and which are not is challenging at best like for example this uh this proposal

3403 partial removal of refunds like maybe the authors feel that there's still a chance for that just with a little bit of tweaks or whatever um similarly like when before eip1559 went out we had several counter proposals that people created and well one five five yeah well one five five nine one could argue kind of it won some the the authors of those may feel like you know they want to try this again in six months or a year or whatever maybe they're waiting for 1559 to fail so they can bring their thing back in and so i'm very hesitant as an editor to get into the business of deciding whose eips are no longer relevant and who's aren't

like i would rather the author make that decision and if the author makes that decision they can move it withdrawn and within with alex's change they'll be with withdrawal reason and they can say uh we decided to go with eipx xx instead this is no longer relevant um that being said like i'm perfectly fine with stagnant being terminal like if it we can just update the ip1 or the picture or whatever to just say you know stagnant stagnant can be terminal like it's okay if things stay stagnant forever because there will be a lot of stuff this isn't stagnant forever i hear you yeah there was this another proposal that was also in my mind like 2593 which was escalator free market change for eat 1.0 now that 1559 is

there so uh i was considering that it may not go through but uh hearing your thoughts it is possible and yeah an author may decide at this at some point that he would want to bring it back okay so i see one more plus one on stagnant forever uh so maybe we would like to make these changes on eip one i will keep it open for at least one or two more meetings uh these changes that we are discussing today uh for eip1 and then after a few rounds of discussion maybe we will

update the eip1 does that sound reasonable yeah i'm also okay with just if you want to create a pr against um eip1 we can have discussion there asynchronously if you prefer that yeah that that may speed up the process make sense all right and the last one here on the list was um about the moving the proposal if there is a necessity but eip author or champion isn't actively involved i know micah you suggested someone uh getting involved from the eip editor apprenticeship program to look into that

and we kind of discussed that uh yesterday uh in the eap operating apprenticeship program but uh the concern here is we might want to have authors approval to be added them as a champion or co-author for the proposal and if we are not yet not getting the author's response at all what is the solution so uh ideally we get the the current author to like if they're not interested in doing the champion championing themselves like the the busy work of fixing things and getting through the review process making changes etc then ideally we get the author to sign off on somebody helping them out and so

for example you know if if there's some we will will william i don't know what he goes by uh if he wants to help out that would be a great place to help and he helps someone who is interested in getting involved in corey aps to learn the process and everything but they can do it with someone else's idea so they have someone with an idea they want to push through but they don't want to do all the bureaucratic stuff of vip editing they can get help from someone who wants to learn the process um so that's the ideal scenario which i think we all agree on if the author is completely unresponsive but we do want to get it pushed through the fallback option is to have find someone who wants to champion it and go through the editorial process to just basically make a clone of it

make a new a new eip that says the same thing but with a different set of authors and push that one through and if that one gets pushed through then eventually the other one will go staggered so um the second option uh question uh the eip would not be the same number correct actual champion presumably and so we'll actually make it final and then once it's final then the original one will eventually fade away into stagnant or withdrawn got it okay let us give some more thought we did discuss and yesterday we had couple of more people joining in the meeting so we

are trying to come up with a small group of volunteers who might want to help us in this process um maybe we we discuss with the eap author try some more time give some more time to it and if not then maybe that is the ultimate option i suppose yeah um maybe try reaching out to the author on multiple channels like just like email or discord or github just to see maybe they're simply not getting the messages i don't know yeah makes sense well thank you um

okay that's like most of the sections the next one is eip insight so this is just a monthly report that i have started recently talking about how we are doing on eip site uh up till october 15 there are two new proposals one is account abstraction 4337 the other one is difficulty bomb delay to uh summer june that is eap 4345 one proposal moved from draft to review that is an erc 1581 and about 115 proposals have been moved to um stagnant status we see some efforts are being made to pull out some of the proposals that is

good and encouraging that at least people are trying to move their proposal to a decent status we are happy with the progress that uh that we are making with the help of bart and the team eap editors elita and everyone who are heavily engaged in helping out with this so thank you everyone the next item that we have listed here is the future of the eip merge part so we know that there was another bot run by nick johnson and uh that was not working for a while or we thought that it's a good idea to create our create a different bot and that's why we have eip bot i was wondering like is it

safe to turn it down or do we want to have it um running i think about the old one you don't is this the one with the travis um ci that we'll get right now yeah i don't think next run for a while uh but he's still running it i mean he has still kept it on and he wants to check whether it's safe to turn it down if it is not being used at all and if it is being used it's fine i think that this is a different one we have two eip validators and realizing one isn't travis it's in ruby um and i don't know if you want to like

trans transfer the logic from here over to the other one um or something but regardless um chance to answer next question yes you can turn it off we do not use it anymore i believe it's been disconnected from github all right that makes sense um to elita's question um yes long term it'd be nice if we consolidated the bots into one consistent location and ideally one consistent language but i think that's probably not a high priority it's not for me okay sounds good

all right so this is good like i can inform him to turn it down uh the next one uh listed here is admin access to eip repo and a report to eip editor so recently we have made some uh i can't say changes it's just that we are trying to uh represent it correctly like most active eip editors and uh we have a new section called emeritus editors to list all the editors thank you tim for that suggestion that really helped i didn't want it to remove the name because it's it's good to have history there and uh i talked to different eip editors which are still as listed as active but they would want to be like removed from

there um with that list i think i will be sending one more pull request to update the list we have received from some of the eap editors that they do no longer want to be a part of active editing uh but i was wondering like the eip github repository there are very few people who have like admin access uh i suppose micah you already have the admin access unsure about exec and uh yep just just me and the um like it's just me jamie pitts and nick johnson yeah yeah so i'm wondering like

not most of the people are heavily engaged but lifeline is so can we consider getting access to the people who are working right now right um like i know there are only two three people exec like client micah i see all these comments i know uh greg also expressed interest to get the right access to the current repo do people think about like any thoughts in favor not favor otherwise so for like klein i'm fine with him in access i think jamie is probably the one you didn't talk to though [Music] similarly okay he contributes fairly

regularly not as regularly not as regularly as matt but regular enough that i consider him an editor um with greg i'm more on the fence and the reason is because pretty much the only time he interacts with the ips repo is when he's working on his own eyepiece like he doesn't really do any editing of other people's stuff and i'm kind of hesitant to and incentivize people to kind of get eip access just so they can merge their own eips and bypass the process yeah um that's my weak feelings i i if he wants to get returned to being involved i'm okay with that and similar with nick johnson like

nick johnson was an active editor in the past but isn't anymore again the only time he interacts with the repos with his own stuff um that being said uh nick has historically shown a little more restraint and he usually will defer to the other editors and won't automar like won't merge his own prs for example right um so this is my kind of surface thoughts on the subject right for nico he said that he would be like he would be interested in getting into active editing but his time constraint does not permit him so he would like to be a part of non-active editors for now but uh

greg showed his interest and he said that i would be like like interested in getting back into editing but for access right now i think uh let's go ahead with lifeline and see with like um in a period of time if we get more attention more work done by more people then we can start involving more one yeah just um talk to jamie pitts i believe this is the right person all right okay so that's all about it cool we are almost done with the agenda items we have just the next meeting sorry the last meeting

uh decision or action items okay okay the one thing the part will uh show a notice to new issues to make a discussion thread on ethereum magician i think the bot has started working on that direction but there is one thing that we wanted to do in issues eip issues which i think still need work on activating the part to clean up the issue section maybe alita whenever you get chance to look into that you might want to consider it can you repeat that

so we have one bar for pull request section of the eip github right that helps with the stagnant proposals and trying to clean it up close them marking them as a stale or stagnant similarly we would like to have a one for the issues section because we have over 400 issues and i mean i'm assuming more than 50 are non active discussion things so if we can have similar part activated and we start closing the issues we will have room for active discussing issues like real issues that people would like to discuss about all right okay yeah uh that one is i can definitely do um i will add that to the list

yeah so i think that's all from the last meeting and yeah that concludes all the items listed here anyone has anything else to bring up today yeah i'm just uh are there any other i'm gonna be doing a bug bash with with the bots this weekend um and just try to basically get through every single bug um so get your bugs in like if you know of any bugs that aren't reported yet please report them on the eip repo so i can have you bought repo so i can just grind through them this weekend awesome okay uh later just for your information like like there is this one resource he has reached out to me and he might be

interested into looking into uh the erb spot site oh like it as in working on it yeah not no not completely but you you mentioned earlier right so you might be looking for someone so he is interested i'll i'll try to get more conversation and if he fits with you you're happy to refer to you yeah okay and i think that's all we have listed on the agenda today thank you everyone for joining and yeah hope to see you in two weeks thanks virgin everyone well thank you bye