EIPIP Meeting 61

Transcript

welcome everyone to eipip meeting 61. i have added agenda in chat the first item listed here is removing eapv as a required check and adding eipw as a required check sam we have managed to move it to ethereum repository and currently both are working or was it action needed here yeah so so right now ep is is the required check and is running and i i'm just proposing that we remove that and switch to ew as a required check anybody object sounded good to me

all right okay and gavin does not have a microphone in the chat he mentioned i'm in favor of that okay as next steps uh who is supposed to do what it is just to be honest okay thank you so that is done moving on to the biggest section of this uh meeting today there are some github issues and pull requests that i have collected and added here for discussion some of them were suggested as a comment to this agenda and some i found it in the repository and i have tried to order them based on their number the first one is uh five two six five it is to include superseded status

and uh superseded by any thoughts uh the the superseded discussion is interesting um because right now we have withdrawal reason and i think that that can cover it um pretty well but uh i'm open to other people's opinions too if i remember correctly uh sometimes ago it was decided that superseded should not be there anymore but is it just to change over it it's just a change in the preamble section okay fine i got it okay there is an update that eipv

is removed and eipw has been added as the required check thank you matt for that any other thought from any yeah please go ahead is the apw ready for being a required check um i think it is but that's kind of why i brought it up on the media instead of just changing it so if anybody has any objections we don't have to do it yet it's it's pretty strict um which i generally like i'm a big fan of it overall um i'm just a little concerned that we may end up having to

override it frequently compared to the eapv um i don't i don't have a good answer for this because either we have a very strict so it's super useful but we have to override it more often or we loosen it so it's not particular not as useful but it means we don't have to override as frequently um i can downgrade some of the particularly strict checks to warnings um that way they still show up but they don't block the merge if we like if we want something like that uh yeah that that may help um another option and i don't know this may be non-trivial and if so feel free to tell me to go pound sand

but it would be cool if we editors could like somehow comment on a particular check and say this is okay or i accept or go away bot just for this one thing yeah i can look into that overall though i'm quite happy with it like it does check a lot of things that i was previously manually checking now i just tell people go follow the bot come back when you're done i kind of on the topic of the bot commenting so much i kind of almost wish the bot would comment after the the person has managed to clear all of the things rather than it's like every single person has errors

like 100 of time and so it's useful to have the bot tell the person hey you've got errors go look but for me personally i would like it to receive notification when the boss says hey this person finally fixed all the errors it's time for you to go look at their pr at the moment i basically just every single time i see someone comment um if i don't see the bot reply to that then i go check but oftentimes it's just i'm faster than the bot and so they still have a bunch of errors um i don't know how other people feel i know gavin prefers less bot comments yeah i think it'd be

i like i want to figure out a way to signal on an eip generally when an editor is required so that might be like putting a label on it when all of the checks are passing or something like that so i'll add an issue for figuring that out too there is a comment by gavin here how about apw get overwritten by multiple editorial level approval and the other one is how about only running eip path when all other checks have passed okay so are we um sam's

comment here is yes that could work so are we going to make it mandatory right now and with the condition that it will only be running when all other checks have passed like deciding the level of precedence if i understand matt's comments it's already marked as required all right um is there any precedence like even if it is marked as required will it go will it go in residence like uh there would be bot number one going first part two going next and then we can decide then this vip part will go oh i see um no currently they all run simultaneously in parallel um and

really we only we have so we have the auto merge bot that basically just checks and comments on who needs to approve a thing and then we have the ipv which does everything else the eip bot does do a handful of other things but it doesn't actually come up say much very often so i think having them in parallel i think is probably the best bet oh eap bot is the one that requests editors i think having them in parallel is appropriate here it makes it so it gets uh people get the information they need

as fast as possible right uh so uh just for declaring clarity of the decision here related to this particular issue uh are we okay to have it enabled although it has already been enabled uh by mac and whatever issues will come up uh sam may be able to help them fix it and we can revisit this uh in the next making oh wait maybe maybe i misunderstood what matt said i'm looking it doesn't appear the apv is required right now apw still is did you set it somewhere different than i'm looking at i set it in branch protection yeah branch protection rule

oh sorry i saw an ew validator and i just ignored the w not bad yeah i mean it looks like a v it's just a it's just eep v v alligator that's what i saw okay so yeah um for people documenting notes eipw has now been added as a mandatory check and if there is any issue if there is any very strict rule uh sam may be helping them make them go easy so we do not stuck and bart does not stop things and we can revisit this in the next meeting moving on as we were discussing uh

2.1 that was proposal to include superseded status by superseded by is there anyone in this group presently i think that it is it is something that can be considered and that has to be changed in eip1 i believe right i mean is there any significant use of making this change is there any way to put this question as i mentioned in the issue i'm not a fan of it personally anyone from the editors group strongly in favor of this proposal

i don't see uh the proposal in this meeting yeah it's not here in this meeting so i i can let it be there and maybe we can expect some more feedback and comment from other eip editors if they have their in any strong feeling either in favor or and against so we'll keep this issue open this is the relates to um sorry super so this oh sorry okay yeah yeah no relates to will will be the next one yeah so i was just talking about superseded by superseded by so yeah uh there is a request to change

in the name of one of the headers in preamble section the issue number is five two six five moving on to the next uh sub item that is issue number 5274 it is the proposal um for eip preamble include relates to as an optional field this is by again by the same user i don't see him on the call but yeah any strong favor or any discussion needed my personal i don't i don't feel super strongly on this one my personal general preferences is that in my experience

people who reference eips gratuitously um generally would have a better eip like the quality would be better if they just didn't reference so many iaps and the act of requiring that they add them to the required field forces people to really think about the eips they want to depend on and it causes them to drastically limit and constrain the set of vips they depend on it makes their eip overall better um that being said like there's probably other ways to solve that problem we could just you know editors can just spend more time coaching people and um trying to work through them and say do you really need this one you really need this one you really need this one

um it's a little bit more effort than just saying hey you can include as many as you want but beware you have a hard dependency on all of them so your call um yeah like i said i'd like to solve that problem this is the currently the way it's being solved it's a poor solution but it's really easy to implement and i always like those i'm a fan of adding more context than less context um like i i don't see a problem with referring to other eips that aren't mandatory even if they're just interested or interesting reading um so i think you and i have different opinions there but i also don't think we

need a relates to field because like we have marked down we can just link to things if we're related to them so yeah and for what it's worth i was editing one of my eips today and i added a link to eip165 and i was like oh but now i have to add it to the require section dammit i removed it but i will admit the text was slightly worse because of it um like yeah if you want in 65 would have been like a perfect example like i was saying you know i was suggesting in my eop that authors should also uh implement some kind of introspection or um interface detection mechanism

such as the ip165 and so i do recognize the value in any sort of links it's not lost on me the ietf for rfcs insists on a proper reference section with proper citations at the end not just mysterious numbers and a header so you can actually see what something refers to and especially if an external link has problems you have a proper citation so you can find other copies even even in the library i don't think either in any libraries

no but they can refer to documents that if they're not online are available in in professional journals and in university libraries yeah if we were like referring to some so just because we have get and we have like markdown rich links i think internal eip references are always like fully qualified it's it's very difficult to have a more accurate reference section than you know the file name and the git commit hash but if we did allow external references i'm fully on board with like fully qualified references and just like you're describing even even internally it provides it provides a title and authors um to to

put things in context it's just a professional way to do things is to have readable references the header is a convenience for the bots i feel like we could so in the if this was something that is in heavy demand i feel like we could achieve it in the rendered version of the page by making it so the eip internal links turn into something that has like a little additional info on hover or something oh yeah yeah the same format as is used um in the published version it says please cite this as use our own proper citation format it also it makes it easy to distinguish

non-normative links two sections um there's a good idea yeah they get a little off topic i believe for the question at hand which is the relates to field i say that because we have a very long list and i believe this i think it's a good idea all right like you think that we should have the requires field and a release i think someone's mike is live all right excuse me yes i do and why do you think that we should have the relates to field rather than just like it's just it's just going to be a

list of eip numbers why not just have links in the document itself which is what sam was suggesting because the specification section should have nothing but normative references but to mount um a reasonable motivation and rationale can can have you referring to non-normative references that are part of your argument but not part of your specification i see so would you would you be okay with allowing um allowing non-reque links to non-required eips in the non-normative sections just free form so like i can just say my motivation

blah blah c eip123 yeah often your motivation is that this is an alternative um if you can't talk about what you're an alternative to your floundering making statements of fact with nothing to back them up right um i mean i think i can probably be convinced um by sam's suggestion um that we just and what greg described you know we just for the non-normative text you can link to any other eip i would like to retain the requirement that the status be

further along than your eip or um immutable in some way um just because we even for the non-normative sections i really don't want people linking eips that are going to change drastically and then therefore change the non-normative content and in theory we could have a bot check all that for us so um is uh is there um action needed like i see this is in the issue form i think the action would be to just change editor behavior and

maybe change eip1 i don't know if the ip1 says anything about it right now okay i would like to we before we make it official can we continue the dialogue in the issue maybe for one more week and then if no one else voices concerns or if and after we all think about this particular solution then we can agree that it's done no problem with that that sounds good to me because i see uh the opinion are divided here like some of them are in favor and some of them are in again so let's continue discussing in that issue and if we make

a concrete decision on that in the issue itself it's fair enough if not then i can bring it back in the next meeting and see where we are okay and i i still do feel worried that while in the ideal scenario where all the editors are good editors um this solution would be fine i'm concerned because i see a lot of vips where people just link to you know a dozen different things and it makes the standard incredibly hard to follow and read and understand because as gavin said people like to write history books in their motivation section and the motivation section should be you know a succinct pithy description of why this is a useful thing not here's the history of the

world and how we got here and how we're gonna fix it that's why you put one link to the uh most important textbook tell the reader go study this post go study this textbook and you will be qualified to understand this document i kid you not there's rfcs that have a single non-normative reference that is a link to a text i believe all right okay so yeah let's let's keep it uh the issue we continue discussing let's uh have

more feedback collected from eip editors and if the issue is not resolved we'll bring it up in the next meeting i hope the proposer also joins the next meeting because i don't um find him on the call moving on to the next uh number that is 5294 it is how should we pick eip number this looks like particularly interesting because there is a proposal can we come back to this one we've got a very long list and i think this one's going to take the rest of the meeting oh okay okay number five okay if there is if there is any preference i can probably go on there do we want to go on any particular number

five so no skip three and five for now and let's come back to them i think those are gonna be very long conversations okay so number one for everything else yeah i mean the list is very long today 11 sub items let's see how much we can cover so i suggested number four is about fixed spdx license identifier i have added the link here it is just skipping that one i think that's his name three and five you said i thought i said three and five you said escape four yeah skip three four and five so we're skipping four entirely and we're doing three and five at the end

okay let's move on to number six i hope that is fine okay i'm gonna share the link here oh skip a few sits too oh don't worry about it it's just a it's a rhyme children's nurse here okay number six is about um no i think i i mistakenly have added the wrong number the number is 5272 it is about add rfc information uh to ethereum yeah i'm so the

the tldr my position at the moment is that i don't have any problem with linking to rfcs um my problem is the door that it has potential to open because we actually do get quite a few people who want to link to their new standard repository it's got like free standards in it and they call it a sandwich repository i mean every standard report repository has to start small and so i get it but like some of these repositories i doubt will survive the year like they do not have the longevity that rfcs have for example and so my concern is that if we open the door to okay these standard repositories are allowed these are not um we're opening the door to people to argue that oh my standard repository should be allowed as well and we do get

people suggesting this like they're like well you reference rfc 2119 so that's a standard repository thing which reference mine as well and so if we had like a strong mechanism like a good shelling fence for saying you know preventing this from happening then i would feel a little better about rfcs in which case i wouldn't care whether we linked them or included them or whatever the one reason i do like the current suggestion of including the rfc is wholesale is because this allows anyone to include any standard from any other place as long as they're willing to copy it over wholesale into the repository and they're allowed to um whereas if we link to it now we have to get in the fight over you know what

external resources are people allowed to link to and what aren't right now the it's very simple none is the answer and um we can give that answer out very quickly very easily and we can stick to it we don't have to fight with people whereas if we start saying some then things get much harder gavin you have oh sorry he's not having microphones require that any standards that we link to must be around for three years and matt suggested 30. um i'd think i'd be okay with 30. like if you've got a standard repository and

still around for 30 years i mean that that's like what rfcs maybe a couple other from the i uh the ietf and not much else and so it does give us a pretty nice um thing and sam's question what is a shelling fence a shelling fence is a um yeah line in the sand it's it's more specifically it's a thing that you can reasonably believe that once you cross some blurry line when you get to this thing it's very clear that you have a new line that you will not cross and so it's it's basically if you imagine slippery slope a shelling fence is some fence that everybody can agree on where everybody is everybody involved in this process that it will be very clear when you cross that later

so um is there a general consensus of uh letting it have for like um let's go ahead with this proposal at rfc information and keep it there for a few years so i think the disagreement right now is there's three options one continue their current policy which is do not allow any external links whatsoever um two allow external links to some subset of things and then if we go with two we have to define what that subset of things are option three is we allow people to import external standards into the repository as assets and then we don't care where they come from as long as they are imported into the repository so that way we can be sure do we not

has anybody actually done it me [Laughter] okay so sam has allowed himself to do it so yes i guess we do collectively um yeah that i mean this is why this is coming up because people are wanting something here and sam's is one such person i guess i'm on board with allowing rfcs and for the other standard standards just importing them because i think the amount of standards people want to import are extremely low really i find like i feel like it's once every couple of weeks i get someone that

will spend like an hour arguing with me over why their standard is acceptable to include in the ip link too outside the chain agnostic standards maybe um maybe that's uh some bias making me think it happens more freely i feel like that one does come up somewhat frequently [Music] but beyond that i haven't personally seen many so regarding uh greg's suggestion of just common law or precedent-based law my two problems with that are one um and we'll discuss this more later but

the whole credible neutrality thing it's really hard to like when you have just say editors decide um if the editors are all totally honest and on the same page and agreement and they align with the ethos of the broader community then that works great the problem is is there's no way to guarantee that is the case at any point in time and from a credible neutrality standpoint it's hard to maintain that over time because eventually you get you know some some other will join and they're an honest person they want to help and they're being helpful but they just don't agree on what is acceptable and um when that happens now we have like a change in the ethos and that change may go in the direction of the community as a whole or it may go against the

direction of the community and so now if it goes in the direction against the community now you have lost some credible neutrality with with the community because of that and well and just this is something that whereas if you have hard and fast rules that are just written down and they're just applied uniformly to everybody then it's much harder to go down that route of no okay why is this allowed but not that allowed um and the second reason i'm not a huge fan of it is just because we historically have been very short in editors and i will admit lately there's been a lot more active editors and so maybe this is not as big of an issue as it used to be but we have also gone through times of lots of editors and then they all disappear and so uh hopefully you'll

forgive me if i assume that some subset of the people in this room right now will be gone by the end of the year and i will be back to the only active editor and once again having to do all the work myself and in that scenario i do not want to be getting engaging in debates and discussions with every single author that wants their thing so currently this is in the form of pull request there is a request to make some changes over there is it fair to understand like uh um this much will take place if we have like all adidas approval or maybe in favor of three or four

so if we can get all the editors to agree then yes it will it'll happen as soon as we all all enter to agree um at the moment i don't think we have full agreement across the board everybody has kind of a slightly different version of what they want and so we're trying to hammer that out and resolve it so so my understanding is that right now we can put whatever we want in the assets directory as long as it's allowed to be redistributed is that correct i mean my personal policy which i don't think is written down is everything must be cc0 licensed which basically forbids external standards um i know that it's not everybody follows the same policy i'm more of it and

is one of the many things that we don't all agree on as editors there is this question in the chat all right gavin suggesting merge as a change later my general preferences is when there's disagreement amongst editors to prefer to go with the status quo or previous rules rather than change them just as a kind of default rule and i know that prefers conservatism versus liberalism but

of the opinion that's valuable in cases of disagreement okay yeah this is an interesting comment i if something is murdered it's very likely to stick around so let's uh let's keep it open and we'll collect some more feedback from other eip editors and if we see we can have an unanimous decision that would be the best case scenario if not then we can try to maybe uh make some changes in the pull request and come to a general agreement anything else anyone would like to add

before we move on all right moving on to the next item listed here this is this particularly is very interested because we have been uh planning to discuss this for past few meetings now that we have it in form of pull request i believe it will be easier to maybe discuss and come on a decision it is about how do we write erc and eip especially for documentation purposes we did make one change on eip1 that wherever it was written as erc for

documentation we did write it as eip uh but this pull request is to suggest that it should be written as erc any thoughts people would like to share so i guess the only thing i'd like to mention here is that it is harder to enforce that ercs are written as erc and eips are written as eip uh like in in epw i'm not opposed to doing it but that is just a point against it do we not currently do does the ipw not currently have code to follow the link and parse the text at the other side yeah it does it's it's just more complicated than the regex that it has now yeah sure but it means not like a if you already have the

code for following links and parsing the metadata then it's not as big of a jump as if you didn't have that already correct yeah okay but i can appreciate that is still notably more work than a ragex i'm ambivalent i'll go with whatever direction everybody else wants i think one important feature change that we discussed uh earlier as well like if this has to be done um we might want to like uh change the header that is generated for every eip because currently it is written as eip no erc no code no networking and no interface it is just eip followed by the

number and so i think that at least for this initial change if i understand correctly it would just be changing the links relative links people put in their eips it would not be changing anything else and that being said if we did this change i can definitely see wanting to do a follow-up change that also maybe edited the rendered page and um what not and then i do not think we should change the file names though because that would be a huge headache yeah definitely no changing the file names and i think we should keep eip

colon as eip colon in the preamble i may be wrong here but for some reason it feels to me if we are not changing the header and we are making this change in documentation we are inviting confusion in terms of eips and ercs again like earlier we agreed that the ercs are standard track proposals they are standard attack eips and that's why or like all other standard track eips it is also documented at least documented as the eip and people are free to call whatever they want to call it they want to call

it that erc20 it's fine but it is documented as the ap 20. i think that's fair um i can see the argument that if we're going to do this we should do it all at once meaning i still don't think we should rename the files and i don't think we should change the the number at the top um but i can appreciate simultaneously updating the rendered page to render them differently matt it's using v proponent and you have microphone i think that we've been referring to

ercs for a long time and i don't think that we should unilaterally decide now that everybody needs to start calling them eips so i believe haven't we always required them to be eip dash blah in in the text i've always required erc's to be erc but i don't think it was codified in eip1 as you see your belief is there's some some volume of ercs have relative links that are to erc yada yada they say erc dash number and then they link to eip number.md

i i keep missing the first half of what you're saying i think your mic's cutting in too late maybe the zoom is plugging um there are a lot of erc links in the erc the different eip and erc category that start erc dash number and then link to eip dash number dot md i see so the link itself is to ap but the text the alt text is erc in a bunch of vrcs i guess policy has generally been strongly prefer erc dash number but i

wouldn't die on the hill of someone's calling an eip dash number generally speaking i feel like this would be an easy uh convincing point for people who are calling i mean i know the community is very big very strong and they have their own mind to decide and call whatever they want to call but when an author is documenting a proposal and he or she is trying to refer to an erc category proposal he is writing erc-20 and directing it towards eip 20 dot md he knows that it is called as

eip20 so it may be way easier to convince that you see it is the ip20 let's call it eip20 and let's start educating people ercs are standard track eips category eerc but that's again my argument my thought uh is there any suggestion how we can collect more feedback and how can we come up with a solution that we can start educating people i propose the last man standing gladatory and gladiator match between puja sam and matt and gavin who all seem to care will you host it

i'll host sounds like tim wants to join the ring one thing that we can do is like we can start sharing this pull request and ask more people to come and have feedback how they would like to see it it's it's about community so maybe it's beyond editors only and we can probably invite more community though i don't know how much is the reach but does that sound like a reasonable solution for now i mean i'm okay with uh punting this until later i'm always hesitant with inviting the community because it's a very amorphous set of people and it can very easily lead to brigading

like you know someone that's got a lot of twitter followers tweets hey everybody go comment on this and all of a sudden you have 100 people agreeing with that person um but none of them posing you know new arguments they're all just inheriting what their thought leader has told them to parrot it looks like an attentional debate it has been there for a very long time we move on and potentially skip some of these other ones we have time for those two big ones okay we can move on any particular number that we want to pick today next

for because i know we have only does uh i think several of these are yours gavin um remove old eap 20 file disallowed smart in eap title description um centralized discussions 2 and last call edition with changes in standard so i think for we can skip number 10 the person who wrote that i don't believe is here and so we would just be agreeing with ourselves um number eight i i think that's what gavin is suggesting here remove gold

oh plus one on removing the old eip20 file i'm fine with it anyone want to keep the poorly named eip20 file that's just currently redirect it's been there for like four years now okay let's let's get rid of it that one's easy um yeah is anyone passionate about talking about the word smart in titles descriptions today if not i propose we skip it until next week i propose we close it yeah i'm i i don't see it enough to think it's a concern like we looked

through quickly on the apprenticeship meeting uh where smart was in titles and it was almost always paired with smart contract except for one and yet that one was just a bad title so i i'm okay with allowing it but we should just be more careful and forcing people to have descriptive titles okay i'm fine with that um for the record though i do think that if you're saying smart contract you should just say contract i think that it's redundant say smart contract when yes there are at least three eips that also have legal contracts in them so okay we can talk about some other time but i'm fine with uh not standardizing on that at least not

making it official there can be some exception for that and we discussed it briefly as i mentioned that in the eip apprenticeship meeting um we can i mean it can be in discretion of eip editors right it's it is like not good at all probably it can be recommended there yeah it's fine like i'll probably still tell people please don't use smart but i'm fine with this not being a rule that we actively enforce and if other editors want to allow smart in the title um make smart contract i'm fine with that oh god that was fighting words man

um okay so i propose we move on to number i'd say number five uh number three and five are more or less the same conversation but i think five is uh one that we need to resolve sooner rather than later whereas three is one we can delay if we need to all right i'm gonna share the link here and wait available um on agenda so i know there has been discussion going on on the discord i'm surprised it hasn't spilled over on twitter yet or maybe it has and i just don't follow the right people

so for those listening in um i will try to describe the situation um as fairly as i can feel free after i'm done to correct me in all the ways that my biases are showing um the i think the crux of the issue to skip all of the what led to this i think the crux of the issue from my perspective is that there's a disagreement on whether editors should be weather editors should be giving special privileges to repeat contributors and well-known members of the ethereum development community or if we should be treating

the rando stranger who shows up off the street and submits an eip exactly the same as long-time core devs like metallic um basically everything that we discussed has led me to inclusion i think that's the core disagreement um i'm in the camp of i think we treat everybody equally um if italic shows up i'm probably gonna treat him more strictly or when he shows up i treat him more strictly than i treat other editors um specifically because i want to make it clear that no one gets special treatment i don't care how important you are within if you're in community you get treated exactly the same as the rando with a brand new github account that shows up as long as you're not a spammer um

i believe and i'll let matt jump in here in a second um but i believe matt holds the position that we should be kind of rewarding and favoring and um giving nicer treatment or better treatment to the uh long-time contributors you know like and this is called before like i've conflicted with peter on a number of occasions on this because peter hates the iep process and he hates it when i tell him to do you know the busy work that every eip author has to do and i keep telling him no you have to do this busy work and eventually hand it off to tim and that worked worked great because tim just did the busy work and we got it through pretty quickly um but this isn't the first time this conflict has come up where long time contributors want you know preferential treatment or special

treatment or you know to um for things to go a little smoother for them than it has been everybody else they're not have to they don't have to follow the rules like everybody else does and i'm pretty strongly against that and to finish the reason i'm against that is because i do think the eip process is part of ethereum's governance process and i think it's very very important that ethereum's governance process remains as credibly neutral as possible and one way to remain credibly neutral is to make it very very obvious that there is no favoritism there is no old boys club there's no insider deals there's no because everybody is treated exactly the same we can be confident that there's nothing underhanded going on there's no one trading favors behind

the scenes because everybody follows the exact same set of rules um that's what the bot is for the bottom sign is the number and it doesn't matter how we feel about it sure so like there are that's the second the second thing that's uh issue number three on our agenda here is how can we resolve this very specific problem of eip number assignment but i think the broader problem is that the editors currently don't all agree on whether we should be giving preferential treatment to the core devs and long-time contributors or should we treat everybody the same and i think even if we solve the

numbering problem we're still going to have this problem crop up somewhere else and i think we should resolve that we can't resolve everything with a policy up front if we have a discussion later we have a discussion later well i mean so this is the discussion later like that's what i'm saying in the past when in the past when we run into these walls of credible neutrality we've simply let the bot do it so we we simply get out of the argument it's just the way it's done um right i think i think mika's point though is like people have like abused you use kind of the strong term the bot right and not that like and then the question is like does that matter if

like okay the bot is saying you get the next issue number well if i open a thousand issues to get the next round you know thousand number like what do you do in that case um and i think the person sorry was that greg you block them right should we block alex like right and so yeah that's the thing that's my case i don't want to talk about what already happened it's gone it's done we have a way to assign numbers we have to actually address it or it's gonna this will happen again if we do nothing we've already addressed it we've gone

over and over and over it's addressed no we still have the efd is still open alex still has the number thank you if if anybody does this again they will face the wrath of mikka that that's really enough okay we have said so i said that the last time and now is the time for the wrath and okay alex because he's facing the wrath i don't think so but i think god can't just keep kicking the can down the road every time it happens yes we can i mean okay so yes we can keep kicking the can down the road i don't think we should keep kicking the can down the road it's the lightweight cam

steel towed boots so i would like to know do you believe that i represented your our disagreement well matt like do you feel like that accurately represents kind of where our our misalignment is uh i guess i i didn't i don't really see it as preferential treatment because to me it their contributions more weighed into like my editorial judgment of whether or not they were spamming the repo everything else was followed according to eip1 and it's not like they were breaking any kind of rules and

i was allowing them to break rules there's no rule against sniping an eip number and you know if somebody else came in with that number maybe it would have been more likely that they created that spam but i just feel like given you know my experience working with them in the past that's not something they would do and so i felt that you know they have followed all the the standard procedures and so i don't think it's the same as like peter wanting to just move something to final which i like agree it i i think that everybody should follow the same process i just think the authors of 5000 did follow the correct process so i think what you described there i think is i think what you described aligns with

my feeling situation because my feeling is is that if your uh familiarity with a particular author comes into play or decision making then it by definition is not a credibly neutral process any longer like if you're saying well you know i know alex i know him personally i we're friends you know i work with them i have a history but that's not the same thing it's you can know them as a contributor to ethereum right like i'm not friends with alex like i mean we've met a few times but like i know who he is because i know he's the guy who works on all these evm eips and like he does really good work and i'm not an editor but if i was i would be like willing it's not even to like

accommodate him because it's like i think i agree with matt that like he generally followed the process but it's like i don't know i would be willing to like not make the process explicitly worse for them because they just do good work and this is not like yeah it's not because i like alex particularly or don't like him it's just like he's like a valuable contributor and right and so i agree that he is a valuable contributor my concern is is that for an outside observer what they see is a different set of rules being applied to different people if you already have like 10 eips since like 2016 which i think right

i think it's reasonable to be honest sure and so that's why i think we have the ethos of misalignment like you and matt i think that's reasonable and i i don't want to claim that i believe that mine my view on the credibility here is necessarily right i think that the disagreement is that you guys think that is an acceptable behavior and i think that is unacceptable behavior and we need to come up with a cohesive vision on you know what is acceptable behavior for me i get it or should we be looking at the contribution history and you know there's eap authors who have submitted 10 eips in the past and i really would rather not give them any personal stream i think their ips are terrible um it's now it comes down to like am i preferring is it just if you have n eips

then you get treated better but like any any rough consensus system is going to end up like that it's like the same thing as all core depths you know like another way to like frame this would be like why do we let you mika speak on awkward right like people could just say like oh you know he's not part of a client team he doesn't like he shouldn't be here and we don't have like a soft rule for that you know it's like generally you make good contributions and people kind of recognize that and like you know you get like preferential treatment relative to i don't know some random person on the discord who shows up um and like i i don't know that we could draw a line there and i think if we drew a line it would just be bad because it

becomes like i don't know you just can't like manage this as like a pure bureaucracy because like people's idiosyncrasies kind of end up in different places and if they're good contributors you need to accommodate that some extent and some people want a nice eip number so i i don't know especially for something like for something like that where it's like you know like very soft abuse of the bot you could say i that's kind of why i see it as a non-issue i guess except if if if alex had like spammed a thousand issues you know something

and then alex immediately sniped the problem is is we cannot the only reason we don't believe alex found the issues is because we trust alex and i really don't like the idea of saying i trust that guy even though all the symptoms look like he did something very bad that would have should have we should have gotten him banned even though it looks like that i trust him whereas that other guy who did the exact same thing i don't trust him because you know i don't have a history of them that's where i get very uncomfortable but we trust people to be eip editors right it's like it's kind of the same thing like i trust that you're not gonna come and like mess up the entire process tomorrow right sure so i have the ability to mess up the process but my hope would be that if

i did mess up the process i would be kicked out and everything would be reverted and so in this case you know someone came in and messed with the process potentially and so the you know should we allow that should we let it stand and this is where i don't think we should so i mean what are you afraid of happening because in my perspective like the eap numbering is not very high on the list of important things related to ethereum i agree i agree with that um when i brought this issue up initially um

the the number was not actually the big deal um the the bigger issue was that i saw that sam told an author to renumber their eip and then they refused to renumber the eip and they merged it i didn't actually notice that alex was a co-author at the time and when i initially saw the issue and then you merged it i assumed initially that you just didn't notice sam's comment and you merged it without realizing the author didn't respect sam's comment or respond to it or anything like that so i was like hey this is just a mistake you know this author is maybe maybe they missed the comment from sam or they forgot about it or something but then the more i dug the more i was like oh wait those author definitely saw the comment from sam because i sat there for for three months and then i dug some

more it turns out that you know the author reached out to you privately and now so now things are not happening in public which is what has happened every other time that this has occurred it's brought up in public and so like this the issue that triggered this all was the eap number sniping but by itself that was not that big of a deal and i probably wouldn't have even i would have pushed a little bit to renumber it um after the fact but if that was the only issue someone got away with this night people have gotten away with snipes before we know of several um i probably would have let it slide my bigger far bigger issue is how the situation was handled and who was involved with it again the private discussions um it feels like it is not how we have historically handled

any of this we have we had an off an editor who specifically told the author to change the number and there's no public discussion after that it just you know changed um like these are the things that are the issues because to an outside observer and this is to answer your question my problem here is to and out to the observer it looks like you have a couple of eip editors you have an eap editor who's an author and the ip editor who um you know followed a normal procedure of renumbering snipes and then another aip editor who just merged it blindly like without respecting that first uh editor's comments and at best you know it looks it's sketchy looking and so from a credible neutrality point of view not not arguing

that anyone's non-neutral here just from appearing neutral to the public this does not appear like a neutral process this appears very much like our traditional governance institutions where back room deals happen and people engage outside of the public view make decisions and then just apply them without any public discussion or public discourse or anything like that and so that is kind of the bigger issue that and again this ethos misalignment where i think that i guess there's really two issues here there's ethos misalignment where some of us think that we should be giving preferential treatment like tim and matt to long-time editors or long-time authors and contributors and there's a separate issue of this you know that the whole thing occurred behind closed doors we don't

know what to the average external person we don't know what happened what was in that conversation who was in that conversation where the conversation occurred you know what what was exchange was it just a a request and an okay or was it like some deal was made and this is stuff that no one can know because it wasn't done in the public and so these are the issues that the numbering really doesn't matter i do think we should solve it to kind of avoid this class of problems because we've been getting more and more uh sniping attempts lately but those that the numbering is really not the issue in my opinion and that's not what i'm worried about i think a lot of the conflict arises from the fact that i treated the situation pretty

nonchalantly because it was about something i felt was extremely unimportant like the number of an eip and so i you know wasn't thinking as seriously about like what are the implications of doing this or this or that and i do agree that you know to me like the biggest mistake was just not saying hey yeah i see sam renumbered it but i think it's okay to keep it like this if i would have posted that on the issue then i don't really think that there would have been an issue you know really a problem because i feel as an editor i have the agency to override another editor and maybe in the past we've been like a little bit more explicit about um you know how or when but we have on

many times in the past you know overwritten other decisions and typically it's like followed by i'm not going to stop you or like i'm not going to prove this myself so somebody else can approve it that's happened like many times in the past and it just happens that sam and i have you know worked together in the past and we talked somewhat frequently and i happened to ask him hey is this gonna be something that you're you want to stop me over and he said that it wasn't he didn't want to fight about it and if i would have posted that on the issue which would have been the right thing to do then i don't really think there's a problem with the situation so i i personally agree with that then so i think if you would have posted on the issue and sam would have posted the

response from the issue um then i think it would have been less of a problem though uh most likely if you would have posted on the issue i would have replied and say i'm definitely not okay with this and then we would have had to have a discussion and you know engaged and have longer this longer debate that we need to have about numbering um i i still feel though that so that would that would resolve the half of the issue which is the the decision was made in private so so that is one problem i don't think we should as editors should ever be making decisions in private like everything should be done in the public to maintain our credible neutrality and you're right what you described would have addressed that half of it i still don't think it addresses the issue of it's alex so it's okay like i don't

think that should ever be an answer to anything that comes up in the ips repo that it's so and so so therefore it's okay like or it's so and so so therefore we can trust them like i don't think that's how we should be doing business for any big issues or small issues like they should be did this person follow the rules would i apply this rule evenly even handily to everybody and i think this is where you know tim and matt disagree with me on should we be treating everybody equally or should we be giving preferential treatment to long-term contributors and so i still think even if even if what you described happened we'd still need to resolve that problem because i do think that's going to come up again and again i mean i personally don't think i've

renumbered any eaps so i'm not really the biggest fan of the renumbering it to me makes it feel like the editors have to go on some sort of investigative journey to determine was their spam before like who did the spam and it's i don't know just not really a side quest that i want to engage in if it's like extremely egregious like 25 50 100 spam pull requester issues beforehand then maybe we can start talking about that or if it starts becoming a problem where we're seeing you know again like hundreds of issues then maybe but i just don't think this is that big of a problem if there's a few

spam issues beforehand obviously we want to discourage that but i think it's like more the you know i think it's more telling that our system is kind of broken for figuring out the numbering if you know we're dosing ourselves over four or five issues of spam before a number so yeah i agree that we should address the numbering issue um there's a this is so if we very briefly switch over to uh general item number three um there are several options that i think would uh completely mitigate this entirely so numbers are essentially randomly assigned and editors don't have any control over them anymore and then if you happen to get 5000 you got lucky

um but like i said i i still would like to resolve the issue of um whether editors should be treating core devs different from i mean how is this going to manifest like what other ways can we treat core developers differently because i think that the eip number is like a small area of a very small amount of editorial ability as an eip editor i don't really know what else is out there so um some examples have happened in the past and some of these i think you and i agree on some i suspect we don't um there's that peter you know has repeatedly requested that he doesn't have to follow the the process um so but there's no editorial wanting something different and then us if if we

don't agree on this broadly then some editor may decide you know it's peter it's okay he doesn't need to go through the draft to review to the last call to finally he can just skip the final um the there's one that's much more subtle that i again this one i suspect we disagree on i have noticed that when a core dev submits an eip it gets reviewed with like within two days and not by me like someone else actually beats me it's like the one time i get beaten to reviews on eips is when a courtois submits and this is a subtle one it's nothing that you know you can say hey you're obviously doing something bad here but it's noticeable i think to repeat eip authors who get frustrated when they see you know every time vitalik submits

something or his name's on something um it gets reviewed like within 24 hours and it gets merged like almost right away and and not just because they're they're i mean he does do a pretty good job writing the ips but that's not always it like there are other people who write very good at peace um and they take a long time to get reviewed just because we don't have the staff it's just another small example of us giving preferential treatment to a inside group versus an outside group um i just don't think that these degrees of freedom affect ethereum in any you know material way though so they like i said it's all about the credible neutrality like i think that it's very important and perhaps this is the real core disagreement between us perhaps is whether credible neutrality

for the ap process actually matters um i believe it matters and we should be as credibly neutral as possible like it should be as plain as day like if someone goes and really digs they should be able to find absolutely nothing that suggests that we're giving better treatment to one particular group or some other particular group and if someone digs a day they'll find a number of cases you know where we are potentially giving better treatment to one group or some other group and i i believe that it should be impossible to find such examples of things and so like my process just coming from as an example i go through the eips in the order that they show up i ignore who the authors are i treat everybody exactly the same and that includes sometimes telling peter to go away because and he has followed the same process everybody

else it sometimes means that i leave you know vitalik's pr to much later than because i'm backlogged other people's stuff um but these are things that give us credible neutrality um that i think is very important i think we should probably wrap up soon we're 10 minutes over i don't know if we're going to come to a conclusion here but we can talk about it um so on the the very immediate issue though um maybe we can resolve this one we do need to decide what to do about eip-5000 um i would like to at least renumber it to

something else there's a pr out that does that i believe we have a few editors that have agreed to it um i think if if you're willing to move forward with that we can at least close out that issue and move move on if you are pretty strong that we should not read number eight 5000 then we definitely should continue discussing that specific issue which may require resolving this bigger issue i mean you have the ability to override me but i don't think that we need to do anything about this i mean sure we we have three three editors but my general preference is i don't think we should like if we don't have unanimous or at least no one arguing against it

then we should wait quite a while and so the question is is do we continue discussing and over the next month or so and eventually maybe renumber maybe not eip 5000 at the end of the month um or would you rather just us renumber it now and you agree that you know you're i i don't say you agree but like i don't see an option where it's we don't renumber it ever i think the options are we decide we continue discussing and then we decide definitely not you know after months of further discussion or we decided today to renumber it if you're willing to budge i'm not willing to budge on this at the moment maybe with further discussion i will but at the

moment i'm not and so if you're also not then i think that we should leave this in limbo until we can make progress let's let's leave it in limbo i saw your mic light up but no sound i don't know why can you hear me i can but i keep getting like the first half of your statements cut off i think you're like how about if i turn off the automatically adjust microphone oh you got louder something changed can you hear me now yes i heard you say can you hear me okay i think we should keep it in limbo okay

so we can keep in limbo continue discussing them um probably the on the pr is probably the best place i think well yeah we can probably take it for a few more days weeks whatever is needed to get this decided and people are free to leave their comments on the request number that is added here in the agenda i believe one of the important questions that we were discussing earlier was like this quarting issue or so for squatting i if i have to like put it in the work for the note writers which generally agree that um if we find some not so useful issues or requests created before grabbing a good number then we

can particularly refer to them as a squatting however this is not exactly that issue but it is about the authority or the governance process that can be particularly considered as one time issue and could be discussed in the pull request here um i think the the summary is we have lots of problems um the one we didn't talk about was the yeah numbering unfortunately i suspect that was actually one of the easier topics despite it getting a lot of discussion right maybe we can have it on like top of our agenda uh for the next meeting we could not uh touch

we were on item number two only and then more so we'll try to uh collect and put it on priority so we get to address most important things that we can may be able to get a resolution faster yeah there may be value i don't know i'm not sure how to proceed on these topics um in order to come closer to agreement i think there's just like a fundament fundamental ethos difference between the parties involved and those are very very hard to come to rapid agreement on one option would be to you know schedule this meeting to be weekly until we resolve it um kind of as punishment to us recurring punishment until we fix our

problems um we have to suffer through more frequent meetings um but i'm not sure that would actually help like i think that when you have ethos disagreements like this it just requires a lot of dialogue and that dialogue needs to be spaced out enough that people have time to go home cool down think restructure their world model etc and that is not a fast process like that can take weeks months years depending on the topic and so i i don't know if we're gonna get this resolved anytime soon um i do think we need to keep talking about it um yeah i don't have any quick and easy paths to resolution here

all right definitely more discussions are required here on this topic and many other similar problems we will try to bring it up and see where we go i think we have like we have reached to a better place where we were about two years ago in january 2020 when eipip meeting started so i hope that this is going to help in future as well for the weekly do do you have a proposal that we propose to have it next week i can check it on the discard channel to get more feedback from people yeah yeah see if you can get feedback from other people if they're willing to continue engaging on a more frequent

basis um like all the parties involved i think are passionate about it but i think also i suspect most of the people would rather not discuss it because an uncomfortable topic anytime you have political or ethos disagreements like this it's not fun to discuss them and oftentimes it's not um you don't make progress either like it's you don't get anywhere and so on the one hand you know scheduling more meetings would give us more opportunity to discuss but that opportunity may just be wasted if no one actually wants to engage and so and i don't i don't know so it's probably worth at least talking to the other people involved and seeing if they want to engage in a voice call more frequently until we get this resolved or

if they think that would not uh that would not help i'm really quick to answer jay's question um so i think the eip bot uh still exists it still has a purpose it is still being used and at the moment basically we have a long list of things we want bots to do for the repository whether they go into eipw or the eap bot um doesn't really matter to me at least and so it's really just you know who gets to it first if someone has the ipw great someone adds it to the ap bot great we just want things to get improved and fixed and better and so i don't think the ip bot's dead it still has a large number of things that eftw doesn't do and i don't believe

there's any intention to have efw do many of those things and so uh so no bot's not dead and if you or someone else is interested in adding features to it i'm totally fine it's probably good to coordinate with the people working on epw just to make sure you're not both working the same thing at the same time but yeah i think we continue it already thank you just briefly that's fine but if we don't manage to get the test the code test for the eip body we will never progress i mean i have tried everything sorry for my ignorance because i need to

to really con confirm and conclude from my side that is no way that i can set a test environment for for the code in the board so and we can do a lot of progress because i have a code for for these pull requests that are already there and five more issues but i know the eipw which already i tweaked the i read the call and it's good but yeah there are things that the is not gonna do and we never do i agree with you but there is no way to i mean there is no way to test it well at least i can i can do the code and i can do the debug and i can try and basically discuss with you but as i kind of i cannot get the i'm sorry for the frustration but i'm

really appreciative yeah feel free to uh let's talk in the one of the eip editing channels um and let me know in there um what you're running into you definitely should be able to test it i know elita was able to test it and it should just be a matter of working in the ethereum repo and attaching the bot to it but i can maybe try to help you a little bit more on getting through whatever roblox run into let's do that in one of the editing channels uh thank you uh jay for sharing a concern and micah for a resolution i think it would be a good idea in general to uh put any question comment concern in the ap editors channel i'm sure

someone on the channel if they find an issue and they are aware how to uh resolve it they would be there to help out with so thank you on that and uh for the next meeting i am currently considering that i will be definitely making a making an outreach to ap editors and see if they are interested in having next week uh meeting but because most of them are already gone probably we can have the next meeting two weeks from now but we can definitely share this word in the channel to collect feedback and if they are interested going forward we can have weekly cadence for sometimes at least till we get some resolution well thank you everyone for staying a bit longer um

i know we could not touch on most of the things but we hope to get a get on it in the next meeting have a good rest of your day all of you bye bye