EIPIP Meeting 18

Transcript

welcome everyone this is eipip meeting 18 and i'm sharing agenda in chat so the uh first topic for today's discussion is eip standardization process uh pr to eip1 and network upgrade process so this pr is created by um james uh anyone has any update on that like i have also added some comments i see lifeline and micah also have added there so james would you like to take over and let us know more about it um it's there i don't know what the next

steps are i've responded to most of them i guess i haven't in the last couple days looked so there might be ones that i haven't responded to if there's comments or stuff you all have about it i'd be happy to discuss i think the next step is to merge okay so there is just one last comment i added to the pull request there in one of the i just have requested to remove the word accepted there i think in the comment section i'm not sure if that is appropriate or not but if it is like that after that

and another thing that i wanted to discuss was on the part of the living status so for living status i see some communication on the other should be one-sided or two-sided and the status so i was wondering like what would be the you know ideal situation to consider it because the ap one is going to be under review all the time but changing the status is it something that is visible and should be considered or the status should be living but we will be considering the changes what is general part of you my my thoughts for that was that for eip1 going back to draft

doesn't makes uh going back to review doesn't make sense because then we have eip1 no longer active looking which is kind of strange but i didn't feel too strongly about having the both arrows be possible uh because i don't think that because if eip1 can't go back to to um yeah if he wants to just stay and then we should find some way um i also start with the intention of why i had the barrels back and forth because i'd like for some way for people to subscribe to changes that are happening to leave

living eips so there are there are people that are going to want to know what's happening to eip1 and aren't going to care about what's happening to many other eips or just living in leaving eips in general so currently we have an rss feed for last call but it would be great to have an rss feed for all eips so whenever there's a change in state people can subscribe to that are state using the rss feed yes how many people are using the rso seed i do not know i think you can get that from the eip repo but you have to be

have permissions to see it i think the answer is like one or two yeah it just seems like a lot of work to improve the experience for one or two people who are using this i feel like there are better avenues to alert people with changes of eeps i'm not sure optimizing for rss is the best avenue for that well with an rss feed it'd be easy to put a bot for like a twitter bot or other things and it's fairly

actually easy to implement with github to have the rss feed be a thing we just haven't had someone do it so yeah maybe it's not an rss feed that's also fine the i do think we should have some way of people being able to subscribe or see that these changes are happening because um [Music] people are going to care about what's happening in eip1 and they shouldn't have to go and look at eip1 every week just to see if something's changed and look through all the different pr's and make sure like that we should make that fairly

easy and transparent that stuff is happening there um so whether it's whether it's rss feed or some other way that's that's fine when i had thought about the going back between review and um active it was if it changed state then the rss feed would show that but that's an optimization in just like relying on a weird weird part of the process like a nuance of whatever to achieve a goal rather than just have the goal and then achieve it the best way possible which that was brought up by um i think micah on the

on the pr so i i agree with that that it doesn't that there's probably better ways to do that and in the case for eip1 moving it into review would make it look like it's no longer active and so that would kind of be strange that there would be no appearance of no eip1 active at a time and so it should stay but as far as if there are living vips that want to go back and forth i haven't thought about it enough to really say that they should or shouldn't and so and then that's kind of where i got i didn't feel too strongly we needed

to to force that there is only one state change here uh given that we just don't know a lot about living eips and something that we can figure out as we go along down the road so considering if we have eip one only for now like as we have only one uh do we consider the change of a state or we just agree that it has to be living only and we will be doing the reviews because as you mentioned if we change the status people will have some kind of confusion yeah so for ev1 we shouldn't change the status to review but i don't know if that means we

shouldn't have an arrow because there so before we were going to have meta eips that had that were in a living state but a lot of those meta-eips the registry ones are kind of moving into the eth1 specifications repo so i don't know if there will be another living eip out of the meta eo ones that exist yeah i mean i i feel like i would rather see living eips be documented in another way like obviously ep 1 is special and it's unlikely we can change that but i think that generally when we run into a time where we want to continue updating

eep it would make more sense to do those updates out of band and maybe define how the process for updating and where those updates happen as an eep and that can be static the network upgrades is obviously a good example of that do we have any ideas of what else besides eip1 makes sense as living in the eips repo especially now that we've split out the network upgrade stuff i haven't really deep dove into it since we have done the splitting most things in the

into network upgrades my attention to feelings on the matter is until we have another a second example of a living eip we don't spend too much time worrying about what the process for eip1 is since it will only affect eip1 which only affects like the people in this channel right now as far as i can tell no users actually read that yeah look at that so i mean uh like i'm also in favor of having it for eip1 at this point of time because we cannot foresee what is coming up for any other future this thing a future living document but if it will then

maybe considering the status change would matter okay so talking about the process but uh the second part of uh the first item is the network upgrade process james has let's let's actually just have a decision on that is it is it okay just to leave it as arrow goes both ways and we we don't really take time to figure out the nuances until there's a reason to or do we have the arrow be one way and figure it out all i care about is i don't want to see

the status of eip1 go back to not active or living or whatever it is yeah as long as that's i don't care what the graphics looks like or anything since it's just eip1 and there's like six people that need to care about the status of eip1 and it's it's flow through the process so i'm not too worried about being super formal about it so i mean uh it's it's my personal opinion here because we are talking about standardization process and every time the arrow way points it it states that the the proposal in that category is going to change the status

so let's have the arrow one way but while documenting what living document is we can mention it clearly that it is a living document it will be under review all the time but this status is going to be living is it something that is considerable um this seems okay it's it's it's the it seems like we don't really need to necessarily limit it like the arrow in the document literally just is on the diagram why um so i can

i can change that and then if someone wants some way to do that later they'll just have to make any ip to make it so it's gonna be possible to go to review again sounds good anyone has any objection to this or before we move further just real quick earlier james you indicated that the reason you wanted the arrow to go their direction was so people get notified um you have an idea of who the people that might want to be notified on eip1 changes are besides you know the six of us that actually care there is for eip1 there is a lot um like for example the change that

accepted is no longer a status is pretty huge to the community and and as far as so in the in the day-to-day stuff there are people who are working on eips and though and that's kind of a small group of people and then there's us who work on the process of eips which is even a smaller group of people but as far as the definition for how standards work who are the eip editors what um how the eip repo works and those things there are a lot of people who care a lot about it they just don't know they don't look at it very much and changes to those things are quite big

it's sort of like changing the uh it'll be easier post this so perhaps it's less of a thing moving forward but previously it was basically the constitution of how to do ethereum stuff and yeah a lot a lot of people are are very thinking back to some of the they don't care about it until suddenly everybody does and changes to it can have pretty far-reaching effects like the like the a good example is the splitting the splitting of the network upgrade process

and the standardization process actually has pretty big far-reaching effects for uh the community and decision makers within them so people i think most more people would care about eip1 than any other efp in the ip repo so i suspect that all those people are not subscribed to the rss feed um do we know how to reach those people like is the best mechanism to just tweak or is like there's like what is what is the means of actually getting in touch with all these stakeholders if there was an rss feed if there was a twitter account that

tweeted the rss feed that would be the easiest way to get that information to the people who care about it because then they could just subscribe either so or through twitter given that this is one just yeah he won and the changes to it are pretty infrequent i wonder if we can just avoid the automation for now and just have someone here tweet major updates on some well-defined accounts like at eip yeah i think that is a good idea since this eip group is working on the process improvement part and looking into it so

one of the eipip group member can do that or maybe from the cat herders official account if people would want we can go ahead and do that because we do not have any official twitter for eipip so we can do that if that's uh okay with everyone here yeah like in eip updates that'd be a nice twitter account to have for people to follow yeah right so i mean like most of the eips would be under the process of either standardization or maybe for the network upgrade i'm not sure if any of the eap editor would like to volunteer to handle that twitter account separately

or is it something that anyone from the group is interested to do that because i'm not sure cat had this would be you know qualified to handle that eap's twitter or maybe you know they are not part of some of them of course they are but most of them not are not editors so not sure if how people are gonna perceive it i mean i can just start treating them for now until we figure out if there's a better way to do it yeah i mean i'm perfectly fine with that

because you being hardcore coordinator if you start tweeting about eips and especially eips which are related to network upgrade it's fine um any other thought on that excuse me would that be something that would make sense to have the cat herders own that and use the cat cat heard his email as the owner of that it would cat herders could certainly own it and then figure out we have either they or whoever they want to consult with to help figure out what should be tweeted i don't know if it should come from the cat herders account because people don't know that cat herders are eip updates

makes sense so it may make sense to have its own venue so people know what they're what they're subscribing for oh yeah pbot's available yeah you should just get that like client and then let's use it and then we can coordinate eips from it i'm doing tweets from it and with cat herders and like client perhaps you can help too right cool so we can take uh we can like note it down as an action item

uh for us today like we would be creating a twitter account for tweeting about eip status update and the categories the hardware coordinator and likeline matt all of them all of us will be working together to start tweeting about it yep moving on the next part was a network upgrade process process flow see the process that we have been discussing uh i have tried to document it in i another james uh try to you know work together and document it in a proposal but the confusion part was uh

should this proposal be a part of eip or not itself in itself like i had some comments there going by the current process i personally feel that it should be a part of meta e where we are mentioning the process for network upgrade process um but would like to hear other thoughts on it broken record micah thinks that the iep should only be technical standards i'm pretty sure you guys all know my feelings on that at this point so i won't go into details unless someone wants to hear me again right about that i i i mean if people are comfortable i'm going to put that as

a specific agenda item in the next meeting about uh should the meta and information eip not part of the ap at all because they are clearly defined they are process and that is process around the uh ethereum but that is not bringing any change to the network itself so i find that if people are looking for only technical specification we have a special category of that standard track eip so we can look into that and i was also looking into the numbers of informational and meta eep so far i think we have like very few under 10 for information as well as for meta for meta so far we have only the number of

upgrades are the number of metas because whatever is going into upgrade we are just listing all those proposal into one bucket and we name them them as meta up till now because for process we have eip1 now we are separating the process of standardization as well as for networks so i'm proposing to have another meta one there another meta er proposal for documenting the process i don't think it's a like you know creating a lot of confusion because for technical specification we have a clear category so from the from the context of metas have a clear category and technical specifications have their own

clear category there is like that those buckets exist within eips make sense what i'd like to avoid is if we have the process for network upgrade processes being within an eip then we once again have eip editors in the politics of what goes into the upgrade process i'm not so sure of that because uh if we look into the process it just tells okay fine the reason behind having it in a uh in an eip in the first place my argument was whenever we change the process we don't want to go back and change the eip1 every time

it's just changing one eip say for example yeah so i i would say we don't even need it in eip1 yeah that's exactly what i'm saying and we and we don't need it in the meta eip either we just have it in the network upgrade we have we have this information in the heath one specs yes of course so the point was uh like when we when we are trying to reach to the eat one spec repo and they the readme file there that is limited to this particular repository only but when we put something on the you know eip depot i mean like uh

eips.ethereum.org then it is accessible to everybody but i do not want you know to um have super strong opinion on it but uh yeah if it's yeah if we if the if the concern is that that so it doesn't we can make a file like in a hackmd file for the process like literally just take this meta eip and put it on the specs repo make sense but remove these stuff the eip specific formatting and information and just put it there and and make it so it it fits in the in its own file underneath network upgrade specification

um as far as formatting and fitting and everything if the concern is how do we make this visible because there isn't a website that shows the information then we should figure that out separately and not not use that it's convenient that eips are shown on eips.org so we could plug into that system by having the network upgrade system use it is a it's a it's a little bit of a using what we currently have to to do something that we should just do better anyway on its own

and and then we're not again tying the processes together even indirectly if someone goes to an eip and then reads about the network upgrade process they're you're they're they're once they're getting tied like the the worlds are once again coming together into one place because edits to the process become an edit to an eip which then becomes an edit uh in the eip repo which then becomes the domain of eip editors and then also the people that are there working on it and that's the this one that's pulling things together more than i think is appropriate and any information about network upgrades should exist on the network upgrades spec repo that's that's the the purpose is to

hold the information and and the the process the current process and the definition of the process in one place and have it be in its own world and if visibility of that is an issue we should then solve that so yeah any other thought you can make a website that is network upgrades like ethereum network upgrades and then put the information there if we have one such website i think

the bot thing that we are talking about would also make sense to have it there i'm in the twitter bot well the twitter bot should be for eips but having having a twitter bot for network upgrades also would be nice but really that's just me you were just a twitter bot very advanced pretty much i'm just a twitter bot at this point my rules have been defined i just execute them great okay so i'm gonna leave it just like that and if and if it has to be converted

into a hackmd file i'm okay to do that but again as as i mentioned my concern would be like what would what would be going into meta and informational but let's keep it for some other um discussion some other time yeah for the general conversation of meta of should we have meta and should we have informational is separate but i do think anything about network upgrades shouldn't be on the eip repo it should be in the network upgrade specification so one more thing uh before we move on from this uh the other day uh uh we were talking about different phases of network upgrade process so

would you like to you know reiterate on that or i mean i can share this screen if you want um is it something the group wants to go through right now there was one concern which i think should be brought into the consideration for eip additives it was about the eip status like the network upgrade process is divided into three phases and i was looking into eip statuses what i have seen historically is even if an eip is deployed on the main net the status does not change to

change from draft to any other sometimes it happens so i was looking to enforce that you know yeah i have strong feelings about this the people are very often create an eip and as a draft and then think they're done and they just walk away and then hundreds of other people think that oh this is an eip i should go and put this and they go implement it it's not just for corey ips this happens to ercs and basically all of them and which is why we have 3 000 drafts and you know 10 final eips or whatever it is yeah i don't know how to solve this but it would be great if we could at least

get the core developers to not implement or not put things on the main net until they're final especially with this new process like an eip should be final before it touches maintenance in my opinion like or rather maintenance should not be putting non-final standards onto maintenance i think it's a better way to put it right so that is what i wanted to specify here uh like when we are changing the i mean the category of efi sorry cfi like see if i applied cfi approved um ci devnet waiting room whenever we are changing the statuses uh changing the bucket for any of the proposal

we should also consider the status at that point uh meaning whenever a proposal is getting in the bucket of cfi applied they can be in draft status and when it changes from cfi applied to approved the status must be between review to final okay i'm i'm just quickly going to share this screen so share the screen so people can see and my um i i also agree with micah that an eip shouldn't be on main net without being final right that's that's what yeah like so i i totally agree with that what

i want what i the nuance to that i kind of want to address is who enforces it and how do we enforce it in a way that vip and the network upgrade process isn't getting tied again so the people deciding what yeah ideally um we can work with the core devs since that's a relatively small group of people and we can hopefully convince them that this is for the betterment of the ecosystem as a whole if they would stop putting drafts onto me that's i mean really all it takes is just someone sitting down saying you know submitting a pr that moves it to final or last call and final

like the champion just needs to do those extra steps i think for for most cases it's just a matter of no one is doing those steps so my hope would be that we can just simply talk to the core devs and convince them that hey it would really help everything if you guys would set a good example here and when you're ready to put something on the main net you know take those steps have whoever the champion is you know do the three things they need to do in order to get it onto mainnet yeah and then we can avoid anything too formal or like official just because we're working with a small group yeah that that would be nice and i would like the decision to be in the hands of the core devs or the people doing the network upgrade stuff

i wouldn't want the decision to be on eip editors to like uh enforce that or or even make it you're going to have to do something yeah as i said before i think the the direction of the arrow should be network upgrade points at eips eips effectively don't know the network upgrade process exists like from a from a programming standpoint it would be you know i have a pointer to from network upgrades to the ips repo the ips repo does not have a pointer back to network upgrades yep okay is my screen visible now

yep yep okay and i'm generally okay with uh what you have there again as an editor i i should i don't actually know this exists but as a user of ethereum i think those are fine yeah i mean as as we were mentioning right now like we would want to enforce this we would like this like people to adopt it and make sure that every our what we had said earlier is we don't want to enforce it from the eip side from the network upgrade size aside i understand but i think since we are defining everything okay you want it to be added as a

recommendation who is the network upgrade group is there a similar like network upgrade group like this one not really i think james hancock is pretty much just me james is the group yeah yeah right so james the editors would like it if you enforce the silver on your side yeah and that and that's what i mean i it should be the i like that it exists as a rule but i think the enforcement shouldn't exist on the eip editors or even defined in the eip side it should be in the the specifications for the repo for the repo

and up to the authors and the people like me to make sure that that it's enforced so i don't want to if it's tempting to make a official vip standard that only eips that are final go into mainnet and have that exist on the eip repo because that would be a sort of easy way to to enforce this but it would put the hands of the decision into the eip editor's hands and the eipip meeting people or in in general the eip stuff like the decision is no long is is on the other side of the fence and we want to make sure that that decision is

on the network upgrade side of the fence and it stays over there and so far because it's just me and then the core devs it's easy for just it's easy for me just to tell them hey the cip needs to be final before we're moving it into mainnet and they say okay cool in that case at least we agree to document it and we'll see in the process how it turns out to be like yeah it can it can be documented in the network upgrade stuff and then i really just want to be very very careful about stuff about

when we when we when we decide that something should be done we should also decide who is it that enforces the who is it that enforces those decisions and does it and does it fit with the paradigm that we're moving forward with a middleware here i mean it's it's again a suggestion like for network upgrade process most of the time cat headers are helping with some of the other activities reaching out to author for some or the other task so if it is appropriate and if it can be considered under the boundaries of cad herders we can certainly reach out to the authors requesting to change the status uh citing this document that this is the new process we are trying to

follow the process and according to this process uh you are supposed to do that neither we are enforcing we are just passing information for first few uh like upgrades and then maybe eventually people will be in a practice of doing it so that might help in long run okay so i'll be happy to reach out to the proposal and the eip authors which is considered for this particular upgrade and we'll let them know but before that we have to have it documented in apple i mean in in the network upgrade

repository or somewhere else wherever how can your repository it's fine one thing before we move on i wanted to clarify here the uh the proposals which gets into this process but they are not moving forward for example there was eip204 which is listed as ci devnet waiting room my fear and understanding is that may not go ahead how we are going to uh you know take out those kind of proposal out of this system should we have a bucket of rejected deploy rejected or withdrawn or what

give a link to what did you say 2046 yeah yeah okay so i was looking for that specific bucket because that was there in the earlier process when we had network upgrade and eip standardization together we had this bucket of rejected eips and that we took off from the standardization citing that it would be a part of network upgrade but we don't see it anywhere here but we certainly need that i mean um in the standardization process we have

i mean i don't know we certainly so at some point we probably need it today i don't think we need it i don't there even the eip you mentioned we had kind of talked we talked a bit about this last week that like the the philosophy i've had when designing the system is that sure there are there are many more things to be added or things that could be added but i don't i want to add them as they come up so we have a sense of emergence emergent properties that that are around the system we're kind of building a system that's never really existed before but there isn't really a playbook on how to upgrade a multi-thousand distributed network of computers with

lots of different parties and somehow there isn't like a project management book that is describes how well to do this so because we're working into new territory i want to avoid deciding in advance how things should be and then shaping them to that shape and instead as we move forward see the shapes that appear and have the process fit to it so the these cfi and the the devnets and all those things are examples of stuff that arose or organically as we were moving forward as the natural next step in this process um if in the beginning i sat down and wrote out a network upgrade process

it wouldn't be what this is today it would have been something else based on my imagination of how things should go based on who knows what because there isn't anything really to to uh big back off so the at some point there will be a a need to have a rejection bucket but i would not want to define what it is or how it gets there until we have an eip that needs to have it happen sounds brilliant okay and the and that and the eip you mentioned it got it is waiting it is technically quote unquote isn't necessary is

superseded by another one going into mainnet because if that goes in then we don't need to have that one but at this state the the eip that would supersede it also isn't in mainnet so it hasn't kicked the other one out of the process because technically at this point the other one could not that we could we could switch our decision and have it so the one that's waiting back at 20 89 i don't remember the numbers but the gas change the gas change cost for that eip we could change our mind and do that one instead and then the other one would be rejected or whatever it happens so so because there hasn't been a decision

that kicks it out i don't think we should build the process for kicking it out yet it's fine just to sit in the waiting room or as efi yeah i mean that's fine we will come with more buckets as you mentioned that for rejection for the proceeding we'll look into it and i'm fine with that before we move on uh there's thanks to light client we have secured a twitter for eip info twitter at eip info that we would be using for status change of eips cool okay

so the next uh item is discussion issues of final eip i think this was mentioned by micah about a particular eip which uh was i mean they have created an issue but after the eip went into final they closed it and yeah micah if you have uh yeah so we have we encourage people to use either github issues or ethereum magicians one for discussion two links on erps the question is just should those remain open and active forever with ethereum magicians doesn't really matter too much they kind of just disappear over time just how forums work with github issues though we have a ever growing list of

open issues that doesn't really hurt anything per se just means the search results become harder and harder to get useful results out of someone came along and said oh the cip is final so it makes sense to close the discussion link and that got me thinking historically we have not done that and so i reopened the issue just because that is not our general process but it did get me thinking is that a good process should we do that should we like does it make sense to continue discussion on an eip that's already been marked as final and the author is now long gone you can't change it uh if it's so it the the discussion two was an issue

and then it it being closed yeah it was a github issue and so the author came by and closed the github issue and again like i said i reopened it because we normally don't do that but it was a very reasonable thing to do and i'm wondering do we want to do that if can someone like that doesn't remove an issue it doesn't delete it it's still there just not open so someone could always go back and say hey we should talk about this again yeah it just basically removes it from the open list and it means when you search it's a little easier to find things because you can filter out closed yeah and it's pretty minor either way would the and the link still exists if they clicked on the discussion to link it

would take them to the discussion and it would so show they could read through it all and then see that it's closed but then still see it all yeah in my mind we should like uh we should encourage people to go ahead and do that with magician only because the example that you have cited i see that that is a recent proposal uh that was uh you know created but i think uh like if people have done it like if a pr is open for very long time the eap is in process for very long time understand the issue of having it a discussion two section in the issue but from here on we should try encourage people to get it in at magician and i think it's it totally makes sense that

we should close it we want to have least number of open issues so that it can be addressed and finally closed i agree with the original reason but i was going to say i i agree closing it makes sense like letting letting them close the issue and then as long as it's findable still by the link and the content isn't gone then it can be reopened if whatever happens okay and i i i feel less about i feel less strongly about enforcing it being on either one i think it should be up to authors but closing it makes sense i think i think the context for why um we still allow people to do github

issues is because these magicians does require a second account and we want to enable people to only need a github account to participate in the iep process and not have to go create accounts everywhere especially since you know these magicians i think requires an email address i don't know if github does or not but if you're trying to remain anonymous which we want to encourage it's easier the fewer accounts you have to go create at random places i believe that was the original intent with still allowing github issues i think with the pull request itself they are getting a place like in the eip report to discuss that uh uh proposal yeah we have a rule that says you you cannot use that yeah okay like it has to be

an eighth magician's or github issue yeah i i mean i also find if magician to be the best place because that is that was originally created to discuss all kind of proposals it's certainly the best place i don't feel like we should limit authors to only do that that saying that you saying that we can do eip i guess we're kind of getting out of tangent here uh as far as should should the issue be closed or not do can we get a like to close i'm good with that yeah so then we're okay with closing final eips and then does anyone else have thoughts on that so we can

make that a decision sounds like we have a decision yep yeah uh okay so that one we can record that uh it's a that final eips can close their issues if they mark the discussion too as a as an issue and then whether or not we allow um so then the next the next part of the conversation started into should we allow should we enforce only one or the other or not or the other so we can get back into that if we'd like

yeah sure so moving on the next item is eip number squatting so this was brought into attention by micah and we see a lot of alex alex has brought this to attention before too i would want to say i want to bring that up too i didn't i wasn't aware i just read micah's comments so like months months ago alex says has brought this up as well okay so what is general thought here like uh uh um michael if you would like to explain the situation and the point so the situation is the ip numbers

are people know how the editors choose numbers technically the editor choose whatever that number they want they sign it but people have figured out our secret formula which is to just use the pr number um and so when they want to have a particularly cool number like 3000 or 2000 or 1337 or 777 or whatever it is they have learned to do one of two things either just set up a bot or something and wait for an eip number to be next and then immediately go create an eip or worse they come in and just create a bunch of trash issues just to force the number up until it gets to the one they want and

then they squat on that one the i think in the past we have kind of tentatively tried to frown on this uh but we haven't actively done anything to stop it um this the question here is we have a situation where someone is doing exactly this they you know saw that 3000 was coming up and they waited until 2999 was used and then a few minutes later they created an eip which of course got them three thousand um but or at least they got their pr number was three thousand as editors we have the authority to just simply give them a different number if we want since the process is editor will assign you a number and so the question is

should we exercise that power and give them some other number or should we allow them to have successfully squatted my personal feelings is if we allow them to squat it encourages people to do the same thing in the future and it just kind of it's one of those things where the situation can escalate and i would rather nip it in the bud and just say hey if we even think you're trying to squat we're going to give you a different number that you don't like i think this is something that most of the editors can answer but if i have to go by my personal

opinion since we have not done that in past we could let it go for one time making it you know as a note and then highlighting this issue to be in future to be you know lesson learned kind of stuff and if something is there we are going to be more strict about it but that's my personal and i'm not edited i believe there was one situation in the past where we actually didn't allow the squatting uh in this particular situation for mercury it was a while ago someone was actually like creating a bunch of issues to bump the number up and then we closed their pr on them once they got the number they wanted we said no um that was a little more aggressive this this time around it's a little more passive and so i don't know if it won't

be as harsh now we do have i think we have at least one instance of precedence of shutting down squatting i don't know if that's enough to do it again but yeah if if so if someone just waits for a number and then has an eip and they write it so in this case did they just get the pr and then write the ip later yeah so they grabbed the number and it was tpd on every section they had had a title i think and that was it if i remember correctly i don't know if they might have updated it by now but at least i'll check but at the time they had a title and the front matter and that was it like they had they had no content yet

and they're like oh we have a plan i actually still there so yeah they have title author discussion two which is actually wrong it's the discussion two is currently the full request so i'll feedback that if we keep it open and then tpd for everything else yeah in that case i would say if if someone had an eap and they waited and then they like i guess the appropriate cases if someone wants a number and they write an eip and it has content and then they just wait and then they do it cool good on them but if you if they do this where it's literally just they have the least amount of work possible to keep the number then i would i would agree with just saying sorry you

don't get it well it's like it looks like they've got a project with some code and contracts and a reference implementation so it looks like they're progressing towards like writing it as a spec i mean my feeling is that the editor should come in and say hey we have complete control over the numbers and so you did this but that doesn't necessarily mean the future people are going to get this but i mean this is this is aragon this isn't like some random you know group that has some random eep i think like of all people to get the 3 000 these this is like

not the worst i don't know i don't really think it's that big of a problem if it becomes a problem then the editors can start assigning numbers but no one's upset about this if they if they if they made a bunch of if they made a bunch of issues which has happened a couple times and then to get to the right number then for sure i think that's a far enough that we say sorry you just bloated the eip number issues for no reason so you you're not going to get what you wanted in this case it's kind of less clear to me that they're if if they if they went a couple if they

went like a week and nothing had happened then it would be more feel like squatting versus just developing i don't know i'm not sure if they have bumped the number it just that like after the last 10 minutes after that this appear was open and they have also populated it with goats now yeah it looks like they like legitimately pulled it at 3 000 because the one before it um in this case that they they really did

just wait and i'm guessing they set up like a github bot to watch and then to just paint somebody one 299 showed up and then that then a human came along and just the new pr copy the template deleted the comments hit submit hence why it took 10 minutes um so i don't think they were doing the malicious bumping and so maybe it sounds like the general feeling is that if we believe if you are causing problems like generating garbage prs or issues then we will stop you if you on the other hand just wait and you you know fight with other people for that number and you win then will you have it does that sound great

i think that can be recorded as well like for future reference okay i don't know if we want to make this an official policy i would still like to retain the power to deny numbers in the future yeah i agree with that reason i also do but unofficial policy i'm okay with uh kind of operating procedure for us internally and it would be helpful for us to you know cite some example if we are talking to somebody it's a martyr uh it would be helpful for us to cite some example mentioning that this is something not acceptable if such

scenario comes in future but definitely this is under the purview of editors so um i'm not sure if that can be a policy just for reference point i was mentioning gotcha yeah i'm good with this really just wanted to bring it up talk about it i'm satisfied okay anyone has any more comment on it since we're already talking about it and hopefully so i don't want to bring this up again

do we have a feeling like if they never actually fill in that eip will there be a point in time where we say okay yeah this is not okay or we just let them have three thousand forever yes if they didn't looks like that and with if they didn't within a couple couple days start doing something with it then it's then it then it was a oh we just place hold it to come back to in like a in four weeks or something then that's also kind of an appropriate time to tell them sorry you don't get that number you're you you clearly waited six weeks two years that is currently the situation it's been about a week and the eip is still just empty so the question is sorry how long do we

wait before we take away this number from them if we want to do that or do we just say you know take it take your time you're going to come back in a year and get the a your c 3000 go for it i mean i think a year is like too long but it's i i think like three months like if they don't have any to publish in three months then that's you know that's a little bit ignorant three months is even too long it doesn't need to be an eep like it could be they all they need is a simple summary and like the abstract and the okay i mean they have done quite a bit of work like they've registered all these sites around this eep number and they've uh already come up with some implementation of their ep so i think

they just need to if that's the minimum we should let them know because i think they'll do it they have all this information they're like obviously continue to progress on it it's not a case where somebody decided they want e3 000 and they just like fall off the map i think that this is like definitely going to happen with like very little chance doesn't if they don't do it within that time frame anyway it is going to be stagnant by the part itself yeah but if if thinking about it just the general case if it's two to three weeks and nothing's happened with the vip then they didn't have content when they he when they made they when

they made the like the the the ideal case is someone sits down they write some stuff doesn't need to be everything but they at least have some of the basic things and then they hit submit an issue and then boom they hit they make a pr the pr gives them an issue and then that's their number so as the if they like i cert i can certainly they have the standard and all that stuff kind of already it seems like written out or or developed but in the case of that they made the number and then came back three weeks later to write those things that's it gets further and further from what we want

which is just people to make yeah make prs when they have something to pr so we should tell them hey put stuff in or are we going to give you a new number yeah and and the new numbers probably should be the the most recent issue number available kind of a thing sure we can do that we also have a bunch of numbers that are never used like when you get those spammers that come on and create issues in your repo then we immediately delete the issue those numbers could be reused if you want yeah like any numbers is easy we got

lots of extras so we are out of time here but i think we made good progress here i mean we have a few decisions on the topics um there is a triaging permission if you have anything uh quickly to go over that is it something that we need to carry in the next agenda or is it something that is done like client if you can let us know about it well let's so so someone's going to reach out to the aircon guys and tell them that if that they need to put in content so we can discourage squatting doing that right now

okay cool okay so i just wanted to quickly uh check if this the next item should be on the agenda for the next meeting here be charging permission or is it something that we can remove now i think we made good progress last meeting i don't well we don't i is like client in the list and have permissions to do it i don't think i am at the moment yes so we're not done yet okay so we could not even touch uh

comments on that and i know we are running out of time so i'm gonna move the uh the items which we could not test this meeting to its meeting thank you everyone for joining us today i hope you all guys have a good day night evening see you all in next two weeks on october 21 thank you everyone for joining thank you