EIPIP Meeting 9

Transcript

hello hope the stream can hear me okay looks like it's going well hi everyone this is eipip meeting number nine um it looks like what we got today is the first agenda item separation of eip process from the hard fork process we made a lot of a lot of progress on this last time so we can start to go over this again i think james you had worked on editing the model the the image after last call right or what was i thinking of access doing that uh yeah i did okay do you want to go over that

um once the edits happened and just review kind of what we based on what we did last time what edits were made yes i will just share my screen i thought i had access still on this document but i'm not seeing it so i'll need to re-edit it to have his on there but i can do that while we're talking i just updated my zoom so i'm hoping that this works again great i see it sweet so i i the one i worked on was this top

one and i went in and added all of the all of the arrows for all the state transitions so the back and forth so you can go from idea to draft and then inactive i left in an inactive and withdrawn just so we could talk about it i don't know whether we should still have two or not but just so that's clear the and then i need to move this a little bit so i can see it it's behind my my thing so you can go back you can go forward to inactive or back to draft or from inactive to withdrawn and but then after it's withdrawn you can't

go backwards without making like a new one what's the thought for that and then you can go from draft to review and you can go from review to forward um and that that this could go back and forth quite a bit like between review and last call or however it needs um oh i guess i need to also put an arrow here being this one is the the one that i think the between review and active that the the way active should work is that you do a change to active and then

it goes into review and then after a certain amount then it goes back to uh after that the pr is reviewed and edits and stuff go through that it goes back to active status so people know to go when to look at eip one for example um and it's probably good to do let's just do quick definitions for everyone to be up to speed what we're talking about so ideas pretty obvious draft is you become a draft when your formatting is correct and you have all of the requirements for an eip

inside of the ip itself that's pretty low like the quality stings and a lot of should it be implemented or not or not at all at this stage it's just editors making sure that the formatting is correct and at this stage it's viewable by by people in the in the eip repository and an author or the champion works on it until they get to a spot where they want to have greater review from the community and this is so then he has the he or she has the ability to change its status to review or request for it to be reviewed and then that is a request for the

community and for other eip authors saying that this is at a point where i want other people to um chime in on this eip and get feedback for more it's in a more stable state or it's at least articulated well for people to come in and listen to it which after that point then there's a process of last call meaning that i've i'm this is my the final proposal for this vip and then it goes through a two-week process of of final comments and if there isn't any then it goes to final and what final means in this case

is that the specifications complete and the author is happy with its with how it is defined it doesn't mean that it's going into anything or that it isn't going into anything it is a fine the standardization is in a it's the state of the art it's the final state and that any changes after that point should be done by making another eip which supersedes the final eip and so then that's how an eip can be superseded the big so the last call that is that this line it seems we were pretty um agreed on or had consensus about that

this is a great way to handle this flow if anyone has wants to go more into that where we're welcome to or if if you have any other someone has a contrary thought to that or thinks that we should have some clarification on some of this definitely uh speak up my only comment um is that in between some of the arrows we need to make sure we put or maybe by the statuses put like meta only on active um so that people know that active is not an eip status for just anything same thing with um superseded superseded is never

with never to be used with a meta eip because those can only be active or review oh that's a good point putting like a sub tag of meta in here i would be like in like italics would be really good yep and then um yeah that's all i had uh again what is active and inactive i just didn't get the idea i didn't describe really described it yet so that would be how that fits so active is a special status it's a weird name um but it's related primarily to things like meta vip registries like the efi document what eips are on efi that shouldn't ever be finalized that's a that's a rolling document it's a

living document that's continually updated and so we shouldn't we should expect that it is something that is updated semi-regularly or when necessary depending on what the registry is and eip1 is another example of kind of this special kind of eip where the idea is that it's never finished it is a it's designed to be editable and to have changes made to it so having it be in this having it go through last call and final doesn't make sense because we're not going to make another eip1 we're going to continually edit eip1 so uh maybe the better name for it would be rolling

then like rolling release of uh of the you know of linux distributions like the whole idea that the release is never finished it's continuously updated so it's uh yeah i think rather than renaming that one i almost want to rename inactive and the reason is because inactive and active are not related at all in fact they're on totally different eip tracks but people may conflate them for the fact that they are generally mean opposites of each other so making an active like a name like stagnant seems a little bit more straightforward

in my opinion but um artem can you elaborate on why you would want to rename active well because for me active uh when i first looked at this diagram today i thought that active is um means deployed on the ethereum and i guess this is the first thing that many people would assume that it's this eap is active it's live on the network in the oh i guess yeah because it's different from accepted right like because in the past we had accepted prior to being on the network and then final meant it was live on the network

um so do you i guess do you feel uh artem do you feel this like accepted has the same connotation and if not is there a reason to not change it to that uh oh i guess that for at least for the newcomer uh both all accepted and final and uh in this case active they are all confusing yeah i can agree with that that's been my experience and trying to describe the eip process usually involves re just specifically re-talking about those words in specificular specific in specifics so active uh so there's just uh

you know at the glance there's just not enough distinction between active and final like uh yeah like you said it's it's like accepted very very much like accepted i'm just googling synonyms for that and i'm not finding anything for active that's good i found some stuff for inactive like um we could call it rolling i i like rolling i think because this is a technical this is a technical uh specifications like repository so rolling could be a good one i'm not like opposed to it yet or anything

rolling instead of active uh yes yes the i thought of the i think the best descriptive term would be living document that doesn't fit in a status living works too i suppose just the word living and actually it's actually good yeah living and then what is what do people think of an act of changing the stagnant or i guess we could keep it inactive if we're changing active stagnant uh works better um living i don't anyways living seems a

bit weird to me but that's it's kind of a small it does seem weird but it's also a weird status well i don't know i feel like accepted actually actually defines it pretty well right like where the i guess final is basically that though yeah i don't know uh but um except accept it sounds like it's it's like uh accepted into what first thoughts for ethereum improvement proposals oh it's accepted into ethereum which is yeah yeah and domain name which implies a lot of stuff and it's can and can be confusing and what does and i guess what are the

cases sorry where it goes the active or living or whatever but it doesn't go to final uh the vip one meta eips they don't go to final uh i'd previously suggested a registry since it's kind of meant for largest race i don't i i think that is i'm not totally convinced that we're only going to have registries yet and it's actually eip1 is a meta eip and that's not a registry so eip1 wouldn't have a place to live so the chat has some stuff um

uh elita said uh i like stagnant and then when i heard of active it's a as if it's running on main net and final as if it's in final draft that's a good point and and then this version oh sorry keep going oh the only other comment was active to vital uh changing the word active to vital was uh puja's idea um i it would give wrong connotation to it i mean vital yeah seems like you can't take it out of the network or like you'll break the network or something you misspelled vital yeah i'm oh you guys can see what i'm doing

um i did there is there's a vitali it's like the l is the latin word for what for a living let's ju let's just call it living document and it it would instantly convey the meaning to or to users and wouldn't confuse anyone i'm with i'm from i mean yeah i mean you you will still have to exp if you call it something else you will still have to explain that oh this means it is a living document why is it something like a reference right like it's like a reference implementation when it gets final it means it kind of can't change anymore but i don't know like reference or

something that just kind of highlights what it is rather than like the maybe necessarily the state i'm sure this is a good idea i don't think that's a good idea to deviate from the fact that these are all statuses and then yeah one of them just being a descriptor would all right more of a descriptor than a status yeah yeah i'm good with living document i don't think like many syllables is a problem since i mean i don't think it'll be used much and then elita said final to staged maybe uh i'm not not necessarily staged i mean uh that's i guess that's the next topic

or another topic but uh or well the eips in general are just building blocks for the for ethereum ecosystem and if we make any eap final if we accept it into this toolbox it doesn't mean that it is staged for say inclusion into the theory main net so that's like that applies to things like click or to brockpow but whatever that's that's another topic yeah and i think final like the definition is literally the spec will not change anymore unless we're typos and i think i i feel pretty strongly we should keep it as such because it's also it's also something that's really

distinct from the deployment right because we can say this eep is final so for example the prog power heap is final the spec is done but that's independent of the stage at which it is with regard to like a main net deployment um interesting okay and then finally yeah i think so your main point tim was to separate the the so these statuses should separate the hard fork process from the the eip process of what statuses they are is that kind of what you were saying yeah i think it should be clear that like these are eip statuses and not hard forks whereas like say eligible for inclusion

sounds way more you know hard fork process right and then i think if you wanted to be coherent you could say something like included you know once it gets scheduled for a fork and deployed once it's live on mainnet or you know something like that got it okay um and then inactive to stagnant would would that be something that anyone disagrees on because i heard three people say that was better than inactive the the intention for inactive as if if a certain amount of time has passed and the eib has been inactive or not or or i guess stagnant is another

word you could use then it's put into this stage which means and it was automatic it was by the system automatically put into this stage because of inactivity so it seemed pretty um descriptive but i'm not i'm more tied to the function than the than what it's called about this status like when we put it inactive and after a certain point of time if i mean if somebody would want they may activate it again so i find stagnant more appropriate like that inactive defines it as it's going to be inactive like forever maybe and also at inactive implies that there

is an active state and there isn't okay i'll concede today okay alita oh elite is it okay if i keep just relaying your chat messages because you're welcome to also jump on mike yeah that's fine sorry i just don't want to interject okay no problem so final to final locked just final doesn't clearly convey its immutability oh that's an interesting point i would if we were talking about main net stuff i would be i would be more tended to agree with that i think leaving it a standard as being final is

is uh articulated well enough or is clear enough on its own there's one more active somewhere okay do we have other comments on any of this i think we've done a really good job figuring out um where things should go i just saw like a major arrow change was that because we changed the length of a of a word yes that's because i've i'm trying to switch out inactive for stagnant ah okay and it and

it automatically formats so it then had both okay here we go um yeah i think the last thing to talk about is do we have is stagnant and withdrawn necessary or do we just have one i think all right i'll go ahead i actually think um it's good to have two because stagnant implies soft inactivity and then withdrawn like assumes finality so it might be good to add finality to the inactive statuses

yeah withdrawn is withdrawn is purposefully with like taking withdrawn is purposefully making the eip permanently inactive whereas stagnant is an activity due to defaults in time past so we don't want to we wouldn't want stagnant or withdrawn to be the only one because then the person wouldn't know if it's permanent and the person wouldn't know if it just lapsed over time or not which is important to make a distinction of if you want to resurrect it and become a new champion of it first for instance because that happens a lot with the ips or new champions come in um can't withdrawn eips get new

champions that's that's my one question and another question uh do we want to only have withdrawn but not rejected so what if we declined to move the eap from the review to last call and to final the the first one if an eip is if like if i withdrew an eip and someone wants to do to be a champion of it i think they should make a different eib yeah i think i think like also just politically it makes a huge difference to just say you know this is the new proposal for x and this is what we've done in the

past as well like when we fixed like eip 1283 the other eip kind of combined both the original one and the fix into one so i think it's it's simpler to like say this is a new iop which replaces this previous one rather than were kind of retaking this odip yeah and here i wrote in from stagnant you can go back to draft so if someone just dropped it you can pick it back up start it back again but if someone purposefully stopped and withdrew then re then to have to continue that eip you would make a new eip and have it start as draft

with a different number so we're not addressing the fact that you can explicitly reject any ip within these statuses the well rejecting an eip really doesn't come up unless we're talking about maintenance is it yeah i think the standard you could write whatever you want for a standard there's really no reason to reject a standard unless it's like malformed and but even then it would just it would just most likely go to stagnant after a while and then disappear yeah but i think in the in the hard fork process you should have a rejected so it kind of goes from uh

from eligible for inclusion to like included or rejected and then the mainnet right yeah and as last week i had a very long conversation with with uh bryant and he i think i've been convinced that it's better to have kept track keeping track of what's on maintenance be part of the hard fork process and kept out of this entirely so even though it's kept out of this if i'm just a person reading the eip repository and i'm like okay eip 972 i want to see if that's ever been included in a hard fork well i need to go through

every meta or will that be in the header or every hard fork meta i should say how will i be able to quickly ascertain that a core eip has made it into a fork or not i know there's a separate process but i don't want to have to dig through a separate process necessarily if it's not very well defined what eips went into where [Music] i think there's two ways to solve to solve that i'm not sure which one fits and that's a big open question one is would be at the status level of having a status that says that this is live on mainnet like it's been implemented so that people know this is something that's part of ethereum which kind of

and then the other one would be to have a document or registry that tracks these are all the eips on mainnet and and have that be a registry iap that's tied to the hartford process that would be at least my suggestion i don't know like we should go over pros and cons of both or alternate suggestions yeah and i think the use case is maybe a little bit like weird like i feel like people will either care about what's in the hard fork and then they can you know find a hard fork or they'll care about a specific eip but i think the use case would say say i don't know you wanted to see his eip xyz included in a hard fork you

just go to the place where the hard fork process is defined you know command f or whatever the eip number is and you should be able to find it there but i think i i think having your stylist to say it's included kind of goes against the whole the whole purpose of separating the eip process from the hard fork process yeah so i'm i'm a little bit confused i assume that this diagram that we are discussing currently this process is only about uh inclusion into the into our eap toolbox so to speak not uh deployment on the on any network so that's how i see it as well and i think yeah

figuring out what that means and then what do we do yeah what do we do about how keeping track of what's actually yeah we i think we all agree on that um it's just that that was one of the two ways to do it that james said but yeah i like the registry idea better um that also makes it so that people can look up everything because i see the eip repository is a little bit more than just something that lists out specifications it's kind of something that also is used by people to replace the yellow paper at times to look up the latest network stack of like ether 65 or whatever i forgot what they're called so like the networking layer but also like how to how to implement eips based on

the rules of the eip so even though we're not we don't want to facilitate the eip process directly saying what's in the what's in the what is in mainnet having a registry is a good in between so so so your but that registry would be another eap i i assume and uh it would follow the same path as uh that we have been discussing for the past half an hour it would follow i'll go ahead it would be a living document um so it would be like eip1 and the

heart and the eligible inclusion eap it'd be similar to this and yes be tagged as living yeah i like that idea a lot uh does anyone else have comments on this um the graph the things we've been talking about stuff like that because we can move on to the other agenda items if not it sounds like we're slowing down on this and came to a few really good decisions i have a question about am i immune okay you can hear me um what what about ones that are like recovery of funds like is it eip 999 which was um rejected but um

i wonder if someone had a powerful i'm just hypothesizing here had a powerful consensus building tool and they could start building consensus and if they could definitively show that say greater than 90 of everyone 90 of ether 90 percent of the core devs and everyone was on board with on with moving that from withdrawn back to active or something like that and and then getting something approved simply because they could definitively prove that everyone was on board with that is is that something that we don't want to consider in here or not not to change withdrawn to anything they would just in that case if it's already been withdrawn by the author

they would need to create an entirely new one in that situation and that scenario you're laying out okay okay cool thanks and the the part about getting consensus from the network to implement is all on the hard fork implementation layer not on the standardization layer like you don't need you don't need um consensus to define the standard for your vip you can just make it and then have it be the best that you can think of and then and then all of the other stuff happens in the parallel process yeah i think i understood that thanks okay anything else and then otherwise i'll move on to the next thing

um i have a very peculiar question so uh if we don't uh have the the eib process tied to the deployment on the main net so will eips go through any scrutiny by the core developers yes um the reason they would go through when you say they would go through scrutiny or not clarify that would be helpful yeah like do you mean the decision what do we define the decision-making process and the standardization process we're talking now yeah so basically what would be the the bar

for uh moving the eap into into last call and into final that would be this is this is an open-ended question but uh but yeah i expect that the this bar would be lower for core eips specifically it would be the first step would be eligible for inclusion and that would be someone has made an idea created a draft and then said my draft is at the point where i want to consider doing things like um implementation test implementations that are really rough uh stuff like that and then from there if the if the devs core devs say yes

this meets the standards for efi this is something that could definitely go in then it would go from there to like further implementations and then into that that would be almost the review phase at that point depending on how the core devs want to do it and that's like a whole nother that's kind of outside the scope of what we're talking about today but it is a really good question i think because yes this needs to be this needs to be decided along with the statuses so that the statuses don't impede that process the i think your point artem that it's easier to go from review to last call to final is

is definitely the case and i i think that's fine um that's part of the difficult part previously was the paul was the political part slash cordev um including in mainnet parts so having that not be a requirement to get to final means it's easier to get to the final stage for if someone wants their vip to get into mainnet then there's just all of the whole other process that uh hudson was talking about of getting it through efi getting it through all of these things uh they're like you wouldn't be able to get into mainnet without going through this plus doing that extra like effort and here actually the review i think

means that they'll get better scrutiny earlier earlier because something we've had previously is an eip goes for quite a long time in development and the authors are working on it and then at the tail end then everyone looks at it um or at least they're like the scrutiny is really delved in at when we finally just when i finally put a hey we're thinking about doing this when so here with review it's a little bit of combination of this is this will help focus conversation on eips from the core devs and the community as they are ready to be talked about and then even though like i think greg's eip is actually a good example of this

sorry if this is a little bit of a tangent but his his eip is for doing the subroutines like this the the stat what he has proposed is a is a well thought out like you could say it's a standard and you we could make it be a final one there are some additional concerns that that the core devs have related to it um like should we have more restrictions or not when it's when it comes to deploying to mainnet so in in greg's case it would be easier for it to get to final which is nice for him because he has this he has a thing that he's trying to get done and implemented and worked and then other people who want to

add on and build on it can do that but he does it means he doesn't have to go back and forth forever trying to make make what works for the core devs or the rest of them he can get to a finished product and then um additional things that need to be done like so it's being implemented into the f-net that's coming up and at that stage we we could say like at some point hey this is this is good but there's some extra things that need to be done before goes into mainnet and we could either um now i'm rambling a little bit but i hope that has a bit more more pieces that are helpful that answer any of your concerns um one thing i wanted to add was that i

think having the eaps be fast tracked being able to be free of strike to final which is kind of considered a feature because if you have an eip in final and it's and it's rejected by the hard-fought coordination process then they can make a version of 1.1 quickly to try to address any concerns brought up do are they able to do that because once it's in final there's not a way to go back to draft or review yeah yeah so when i say 1.1 i mean a new eip that's the same name that's just version 1.1 with a new eip number ah got it okay um yeah i'll let artem answer anything else

before i go to my next thing because that was his questions were initially this um yeah i mean that's um yeah that's uh that's a bit concerning that uh you can have a like a final ap that will go on a test net and then suddenly an intestine you discover issues and then you have to do another eip to replace it so it feels like a lot of boilerplate boilerplate but yeah maybe it should be like i don't know like i i shared something in the in the chat but like almost like our last call for core eips should include the test net period so it's like you have i don't know you have like last call

all the way up to it's deployed on main net and then it becomes final um yeah but uh somewhere some eips are never to be meant to to be deployed on on the main net yeah sure sure like like for example or corey ips right like oh so you're saying but yeah click is a core vip um i mean i don't know for those maybe we just still move them to final you have the standard two weeks last call yeah you can make i mean i could make something called the icebreaker format and it like completely redefines how you do account abstraction or i'm just throwing words around

and it could go to last call and then final as long as there is as long as there is like the core devs say yes that can go to final but that doesn't mean it's included in a hard fork ever so click for instance is a good example of that the networking protocols are a good example of that because sometimes like i think in the case of was it 64 65 or some 64 and 65 like some clients actually skipped one of the networking protocols to go to the latest one um that might have been open ethereum actually i forgot um no no we introduced it 64 in 3.0 and we are currently implementing get 65.

okay so and there was another client that just skipped it so that doesn't mean that either a networking protocol or a core eip uh either one of those could go into a hard fork but it can still be final and i think we're going to have to drive that point home because that's going to be confusing especially since final up until now or including now means that it went into a hard fork so we're redefining the term um yeah just just uh small notes um the networking eip is a networking protocol uh is it's a bit orthogonal to to the hard forks because it does not affect the chain state only how the clients talk to each other

so it doesn't it doesn't require a hard fork deployment and it doesn't affect the chain state so it yeah it doesn't require a separate inclusion process that is a good point and that's why um if on eip1 right now networking is actually a separate uh category within a within the standard tracks of eip um so yeah i think are you going to eip1 right now james yeah i just need to get to this part of the screen where i can get to it so yeah there's eip types so there's a standard track eip and networking is

separate from core and it's exactly what you said artem it's because it's separate it's consensus critical as core and networking is not critical um and then tim you have to leave in a minute but tim posted a picture uh in chat that kind of described a little bit of the efi process um so i think yeah the short answer there is i think like the the efi should basically operate ideally like in between the eip stages right and it's anyways like so you have like an eip that's first a draft and then it can be made like efi and then when it goes into review then

it can be after that it can be included and when it goes into last call then i don't know we can put it on testnet and when it's final it means it's deployed but i think it would be good that there's still like a link between you know when does like the hard fork process which stages of the eip process does the hard fork process like hook into um because that makes it rather i'm sorry i'd rather call it not included but but uh staged because uh it's sure sure yeah i mean it's just because we use eligible for inclusion so i used to but like whatever that i don't have a strong opinion on the on the name uh but just mostly like how the two processes kind of interact with each other and yeah that i have to jump though so

yeah thanks everybody bye tim thanks tim okay um [Music] okay this was all really good any final stuff before we move on to the next item okay so the next item is an eip number registry process that's a lot better than what we have now does anyone have thoughts on a better process um and also i guess we should go over what we currently have um right now i believe it's my pr number right yep there's a little piece of eip1 that is not very well toxic but does not uh our we don't really even follow well

but it says that after an eip is implemented then and after an eip is mur as a put as a pr then an eip editor gives it a number and the number usually references the pr number what actually happens is you do a pr you go backwards you figure out what number it is then you put the ip number in and then that's the only way to get it through the edit of the edit bot because you have to make sure you have the formatting correct okay is there a better way that people can think of i actually am okay with the pr number thing because it's an unlimited number set and i i can't think of an alternative

um yeah i mean i have the same basic opinion that uh it's it's pretty awkward and it ties us to the platform basically to github pull requests but then there is just no better way so so i assume um that just just confirmed are we talking about the labeling or the numbering yes the numbering so like if i make a draft eip and then i make a pull request for that draft eip that pr number and github is what is going to define my eip number within that draft okay so the reason that i thought

changing it in the um or one of the reasons i brought it up was because at least with the z cash model they use different numbers to signify different states of the process um and different like you know purposes of the actual of the actual draft so if we had say a you know you could have the same labeling scheme so that way it's that we have right now so that way it's unique but then you have like a dash um zero whatever that signifies whether or not it's you know in the stagnant phase or if it's currently or if it applies to the networking or something

[Music] that's an interesting idea i think um i love how zcash does it from at least from my review of the numbering however they only what they do if i remember correctly is for things like if it is a consensus critical change for instance its numbers 100 through 199 if it's a networking change it's 200 to 299 and the problem with that is we have so many that we can't define a pre a preset range like they can because they have many fewer eip or they have many fewer zips than we do eips but i don't think you were you weren't saying that we should do it

exactly like that but maybe include dashes that indicate some other fact about that eip like us like a what category it's in and stuff like that right yeah exactly um and i think you can take just like an extension as it were uh just a classification which which is um which would be variable as like throughout the process and presumably that would help maintain history of the process as well so you could say for example have uh the 0 through 90 be if it's whatever and then each and then each change that's accepted or reviewed

increments that extension by one something like that it might add like an unnecessary level of complexity especially since we already have statuses defining where it is as i recall the statuses were in the header of the eip which might which in my opinion is um difficult to comprehend um or read but i suppose i haven't championed an eip the oh go ahead james um i'm i'm a little hesitant for that and i think it has to do with

one we have way better defined statuses like this is very not this is pretty comprehensible i'm looking at all the draft dips and how they're organized things like uh having the number b the link is very easy to handle um i don't know if we add any i guess it's i don't see what we get specifically out of having more using the number system to better specify the statuses when we are when we have the statuses yeah i agree with that i see it both ways but i don't really know where i fall so i have i don't think i've thought about that enough to really um

i want to think about that more so the primary reason why um why i believe it would be a or why it would be beneficial is if we have a lot of vips it's easy to say query the eips to sort only certain you know categories or certain state vips so you're saying having an extension to the eip number would make it that people have hard time understanding would make it easier than just having a simple status field with well-defined values that is what i'm saying i guess i'm having trouble seeing that

if the if we had it if we had the numbers have more information beyond the status that might add something as far as from like a querying status a querying ability by filtering the way that these are organized filtering by their status actually isn't really that difficult like i wouldn't need to have a if i was to write a a system to get all of the drafty ips for networking i wouldn't need any other information to do that pretty easily like writing a script to do that because this is uh really strict on what the inputs are

so if i think we would need to think of more things to that the numbers would signify that are helpful to have but don't deserve their own status then i think that would make more sense that's at least where my mind's going currently i don't want to say anything super definitive yeah um go ahead with regards to the number uh being tied to the pr and issue number um axic in the previous meeting brought up the using a smart contract to to choose the number um i'm not sure if if that's too complex if or if we should continue using pr

numbers for the erp number i don't see what problem that solves immediately that is a lot more complexity the the so reasons i think the um vip number process sucks or is really unhelpful is the inflation of because it's tied into the github issues we get weird things where well one people come in do 10 issues so that they get a good number and that just floods the eip repository with random issues for no reason other than someone wanted to five instead of three or they wait until 1770 like leap and we we've seen that a bunch of times

happen already in the eip repo which at which is adding more things onto eip editors and creating it harder making it harder to manage the repository for me i've wanted to go in and make a lot of little changes to um like updates to eips like if i was going to change the status it would be nice if i did up like a lot of changes but i am hesitant to do a hundred prs because i've immediately bumped the number because i wanted to have a couple things changed on a lot of ones so they could be decided individually so then i start packaging things together which has its own like weird um incentive like a weird consent not incentivization

but like i think you get what i'm saying like it's it's ten it's it's pulling my thought process into a weird place because of trying to work within them the uh i think itself the it's confusing like having huge gaps in numbers is is confusing i think to people who it's like well why why do we have vip 2000 and then eip 2150 that's like that's like more of a just general reason but not like a super hard reason i would say not to do it not to do it how i've um so i i would say it's a big deal that we

figure out a way to do this that isn't tied to the using github issues because it would free up github issues to be used for a lot of other things you mean pr's right not issues well the yeah yeah because pr is turning to issues so you're actually using the issue number because prs go by the sequential including issues ah that's right okay personally uh i would just turn off github issues for the eap repo and uh put the pull request submission behind some kind of a bot so you could so people would have an interface to submit an eip

and the bot would just submit it as a pull request and maybe give that author the rights to the created pull request yeah that'd be really cool i've thought about some stuff like that a little bit before yeah getting the bot to be better but stuff like that would be amazing i thought of a proposal for doing that for choosing numbers or having numbers and having an eip registry of eip numbers and then when i write an eip i go in and i request this number i like i get i get the next number and

then the editors are the ones that say yep okay because they are the ones who hit the merge button when an eip is formatted enough for them to merge it then they can assign it a number and then just have it be in a list that goes sequentially interesting so part of the process for an author like it's a weird flow for for me as an author to write an eip send it submit the p like put a placeholder tag for the number because i don't know what it's going to be then when i hit by my i have to submit my pr first before i

know what the number is and so then i go back in after words and make all the edits and then do another i uh like edit that pr afterwards to be able to get the number it would be a lot easier for me as a and from an editor perspective to sit down write an eip go to the eip registry say oh this is the next one write in that number hit merge and then the draft and then that's just ready to go so you you get you apply as for a number through a pr to the registry for eip numbers yeah i don't have an opinion yet on that

so why don't we currently just use a um like a system where say we have 10 numbers and then for each you know each time you request a number you just increment by one is that not a reliable method well the the problem is tracking that the increment by one because they're without having a way to track the current number and what's the next next number then there isn't really a way to increment so are you saying basically to use a hub or almost like a proxy to manage that so repository

yeah so we would have a a list here of eip numbers and the eip and then the date it was assigned if we wanted to and so then that would be the registry of eip numbers and you would part of the process of submitting an eip is registering for a number okay who'd be responsible for the registry of numbers the editors i guess yep hmm i'll think about this more and um we have one minute left if there's any final comments on this talking point yeah it's uh just feels like uh github

is i don't i don't know if github is like the best solution for for eip management in general but uh yeah that's not like i have an alternative right now yeah i i agree it's it's it has its ups and downs for sure okay yeah yeah we need we need like a front end like you were talking about to make it more streamlined okay um i think we should wrap up then we have a little less than a minute left if not if even that uh so let's let's get to the other

topics next time by moving them up the list um it looks like oh the other two topics uh weren't super there oh the eipip survey though we have a new document on that if edson do you want to run through that real quick um yeah so this is probably gonna be published on friday um it's in the telegram i can post it in the chat it just summarizes the results in the form of questions um so um say we're almost done the set creating the the eip process statuses separate from the

hard fork process um we could start formalizing the hard work process and then after we finish that we go through the last questions in part one and then we can just choose which questions to go for us topics for these discussions that make sense yeah but uh i think so yeah um go through the article if you haven't already it'll be public on friday and i think that's it for me thanks i thought this was a really good meeting i'm really excited about the progress we've made

and the next meeting is going to be june 17th i believe yeah june 17th so everyone have a great day or evening bye bye thank you thank you you