EIPIP Meeting 44

Transcript

all right welcome to eipip meeting 44 um i have shared the agenda in chat so the first item that we have added here is um add labels to pr's uh this was brought up by greg uh not there and greg coleman but the one with chain save you mentioned it in the eip editing discord channel um i was also interested in sorting these crs and once requested to get that triaging permission but it was brought to our attention that triaging permission is not possible with the present ethereum github

for so many reasons um so it was dropped but i really like the idea of lifeline of having it done by the bot i was hoping for get some thoughts on that i don't see anything on the call but if anyone else has any thoughts like is it going to be really i am i'm a fan of the bot doing everything uh of course it takes engineering to do it so we have to decide whether it's worth it or not um it wouldn't be so for purely status change should be relatively easy like yeah so the problem is is like analyzing a diff is non-trivial like it's possible but it's a bit of

work to analyze a diff and identify like what changed within a pr um so from an engineering standpoint i think it's going to be a good amount of work and relative to the benefits it's not obvious that it would be worth it at least not at the top of the list like there are other things i think it'll be more beneficial to have the bot too um for new eap that one could be done automatically i think pretty easy relatively easy the the other two though i think are gonna require a bit of work yeah i was thinking that new would be

easier relatively okay okay i will go ahead and add that as a feature request for the eip bot and obviously we'll try to prioritize other tasks that are already listed there and let's hope to like keep it in the list maybe sooner or later yeah i'm a big fan of just having a backlog of all the things that we would like to see the bot to and then whether we get to them or not is a separate conversation that sounds good all right

going on the next one is a general consensus for closing the discussion to issues so i have referred to three links here so i'm a little lost here maybe i missed uh some important piece of information i thought the group came to an agreement that we will try to enforce a fellowship of ethereum magician as the only discussion took place and the part was even updated accordingly to provide a message whenever any issue a new issue is created mentioning that this is i mean if you are creating this issue for discussion please close it and open it at fam

but recently i came across a new issue and that is mark two as discussion two so i was wondering if by any chance anyone has any information that something may have changed so the if i remember correctly the conclusion we came to was that we would strongly recommend ethereum magicians but we wouldn't strictly enforce it so you tell people you should really use ethereum magicians unless you have a very good reason not to whatever that might be we didn't really specify but the idea was is that if issues are still acceptable but frowned upon given that there are some people who feel very strongly that they want to create an issue discussion not an ethereum magician's discussion and so

they do and separately we also have discussions from a long time ago so before we made that change there's lots of discussion issues for that and so even if we do strictly enforce that we still have to decide what to do about discussion issues going for the old stuff uh well i agree yeah that was like um a strong recommendation and definitely it wasn't enforced though the idea was slowly we can move people unless they have like very strong reason of bringing it back to the issues section uh for older issues i don't know when we started running the bar to make it stale the idea was to

close the issues which which are not in active discussion however if that proposal is on the github repository the discussion tool link is available there even if the issue is closed and that will always accept the issues so that is something and if people want to keep it open forever it would definitely will get lost because nobody scrolls back like 10 or 12 pages and to find that particular issue to comment on that but with the help of link added to the proposal it is way easier that we can do so i think the idea was to uh stop getting more uh discussion to issues created so we can use that particular channel for

um the useful issues that people would like to generally discuss i mean again this is not up to me because i'm neither the author nor the eip editor but i was just trying to give it get clear picture to the community so they would know what to do and like where to go so if we are recommending from even with the help of bart that you should be going and opening and discussion to link at fem and at the same time we are allowing people to ha have this opened here i don't think we will be at a place where where we can actually share the information in the right way so it will be again the same thing where we started unfortunately alex isn't here he's the

primary proponent of keeping discussion issues open um matt do you want to try to steal man his argument against me i guess not um so you see yeah so can you hear me i can't know couldn't before talking um i don't really know what his argument is to steal man but my argument would be why i'm connected they're free right

sorry my audio is like switching between my phone you keep cutting out matt i think you said your audio switching between your phone and i'm gonna guess your cat oh my god just keeps trying to steal auto can you hear me now yeah yeah we can hear you know okay well i mean i don't i don't really see the argument to do anything and so i guess the argument is

it's acceptable right now i would be in favor of saying you can no longer use issues but ones that exist i don't see a reason to change that close them i think the idea is is we want to have the github issues list be an actually useful list rather than a list like fairly quickly become useful if we just stop allowing people to create new issues that are discussion areas well that was the idea yeah that was the idea when we started using bot uh go ahead matt i think you're a little

lagged so i think we talked to each other if you go first and we have lost matt to his cat again does he have a cat wow i'm just like really having trouble this morning um while matt fixes his mic i think i think the primary argument for me uh you know i'm pretty sure you're like 30 seconds behind but go ahead and try quickly

no you cut out just before you made it so we don't necessarily have to clean all the issues for the issues to become useful we just have to stop letting irrelevant issues come into place of course there's still going to be like a few dozen issues scattered in the history that are always going to be difficult to find but i think that that this is like a much more reasonable path to having usable issues than clearing all of the issues that exist i think that's like a really large task and we're gonna upset people when we close their issues um so my counter argument is twofold one there is value in having the issues list

to be actually actionable things because when you you know look at github and you see there are 41 open pull requests that is much more actionable than 500 open play requests like we used to have similarly with issues if you see 450 issues no one's going to read through those whereas if you have 50 issues some new apprentice may be like you know what i'm going to go through the issues and see what something i can handle worst name i can do like they're actually you know actionable items the second one is that i would tentatively argue that no one in their right mind finds a discussion link for an eip by going to the issues list and looking for the iep they always start with the idea and get linked to it

and so closer open is irrelevant and so there's no downside to closed and there's a very minor upside which is the issues listed well the downside should close is that it looks like the discussion has been closed and that may mean that you do not comment that you're never that's the probably my only concern for having them closed otherwise you i think you're right nobody goes through the issue of us to find the issue i say so your concern is just the kind of psychological effect of closed versus open and healthy i think it just signals that this discussion is complete now well i think the uh old issue i define

this to be a mildly compelling argument so there's a mildly against closing the old issues for what it's worth it's not something i'm going to lose sleep over so i suppose we are actually talking about two things here one uh closing the old issues and the second one allowing people to open the new issues so um if we talk about uh allowing people to open new

discussion is there a general agreement that we can try to request author let's say if assuming that he does not have very strong reason to go ahead with issues and not go to the fem to start the discussion tooling i'm i'm specially referring to an issue number 4431 that i think has been started just 10 days ago and it's fairly new and there's not much of a discussion and i don't know why but did not provide the message saying that you should go ahead and start discussing at fem though it was designed that way i just don't think we made it an

absolute requirement unless we have and i misremember we didn't it's just the it was so in i think erp one we might have updated it at some places not all the classes because i remember adding it somewhere that it is highly recommended uh but when i was checking it today i found that there are other mentions and there they have this permission to open it at issues so i was wondering if we can unify that eip1 and do it if all the editors are on board if not then we have to leave it the way it

i is whether or not we close the issues we should stop letting people create new ones for discussion threads we're never going to have that useful of uh issues list if that's the case yeah i i generally have an agreement the one downside is just that you know telling people hey go create an account at this other place just so you can do something does it have github sign in it doesn't github sign in and does it ask you for a bunch of ridiculous permissions to do so like a lot of faces do

i don't recall it asking for anything other than potentially your email but also it may not even ask for email uh one thing that i want to mention here is generally people who are creating issues or generally they are trying to add a new proposal they are already there on fam like i mean it's rare i mean definitely i haven't seen in my experience that someone is not there on fem and they are trying to do something here on github so i don't know if they're not maybe it's a good filter i'm not sure if we can come to a

conclusion on this right now because i know a strong argument is coming from exec and he isn't in the call so maybe i will try to write something open a pr to change it and discuss it with him on the pr that makes sense all right i'll go ahead and do that i will i mean if if it is fine by this group then uh to make it like highly recommended i will create a pull request to make all the possible changes in eip1 where we are suggesting where to open the discussion to link you might also want to update the template all right yes i can do that too okay

okay now let's move on to the next one um so the next one is eip editors apprenticeship meeting uh so the meeting went well of course we had a decent attendance of new contributors so thanks to timbeko for generating the momentum and help us getting people reach us on the discord channel and many thanks to matt garnett for answering questions from their group there were a lot of questions just uh in short the in the meeting yesterday we had a quick introduction of possible contributors for their background um i presented a 10 minute overview of eip type category and the present process

matt took the stream of uh questions and worked this with reviewing a pull request which is now merged as an eip in draft status um i hope most of the questions that we could have expected were answered in that meeting and the recording is also available now on calories youtube for anyone interested uh to follow what what actually happened in the meeting so uh we have shared all these information and if someone is still having question or they would want to reach us please reach us on ech discard eip editor's channel to share your questions

we have eip editors on the discord so we hope that your questions will be answered and we can plan the next meeting in two weeks matt if you would like to add anything did i miss out on anything uh two weeks hold on um could potentially i don't think i will be available in two weeks actually okay i think that tuesday i have something going on all day but we can figure out shout out yeah we can do it async i see some comment here on the chat uh

we'll get back to that uh let's finish up the agenda either first because those are really low in number uh so we are almost on the last item listed on the agenda for today it's a eip's uh insight the monthly eip status reporting um i have updated the inside for november up till 15 november so far we have three new drafts one eip is withdrawn and two have been moved to stagnant and three eips have been reserved from the statement status the good news is 864 and 65 are finally in the last call

uh with the review period ending on november 19th there are a couple of non-normative changes to funnel eips so eip 2681 and eip 2124 and there are a few other improvements to one so that's all about eip's insight and the link is available in the agenda nice there is one more thing yes funny i just said nice

i know thank you i i i thought someone is saying something and i just uh spoke over there is one thing that i wanted to bring here before i actually make a pull request for that in eip1 the bibliography section if we can check it out it looks like something is wrong with the formatting because i don't see any text over there when i was looking into the raw draft it is available is it an error or it is supposed to be that the which one i'm checking the bibliography section it's down looks like it's just missing

actually i found the data is already there it shows that it's not good let's see um i think it's because um markdown is recognizing this is just a link lists and it is using it to back the links when i was looking into the md file it looked like to me the way the it should be formatted is not correct so so the markdown renderer sees that list of links and it's saying hey these are just link references and then elsewhere in the document where that link shows up it

will replace like if you do square bracket devp square bracket somewhere else in the document it will replace that in rendering with that link but it doesn't display that below so you can just get rid of the the header and put that i'm not personally a fan of this style of markdown but some people like it like i prefer just inlining links it's like if you search so if you search the document the raw version of document for devp you'll find in two places one up in the eip types section and just says square back at the p2p

square bracket that's it and then you also find it down in the bibliography if you look at the rendered version and you go to that the types eip type section and you hover over the devp link you'll notice that it links to github.com ethereum slash wiki wiki p2p wire protocol and so what's happening is those links down there at the bottom are backfilling to any place that just uses the square bracket notation like it's a it's a feature of markdown that's doing this online and so they're not supposed to render on the page at all like it's not supposed to be a part of the document that renders

visibly so we have two options one we could just stop doing the bibliography style of links that's my personal preference so that means where you see square bracket the pdb squared bracket elsewhere in the document you change that to square bracket dev p2p square bracket open parentheses and then the link if you do that instead instead of just um the p2p instead of that do the first one so the second one and then you can get rid of the the section entirely but someone just need to go through and update all the links throughout the the other option is just delete the bibliography heading the subheading

so it doesn't look weird when it's rendered and you just leave the kind of link list and maybe put it at the very end of the document after the copyright i don't know like i said my preference is to just not use that style of markdown links i find it confusing but i'm not that passionate any thoughts like that i don't mind all right i'll be right back my headphone batteries die and i have to replace it all right so if i understand correct

so if i understand correct this section is required uh because we have been using this style uh for providing links at certain places in the document and um we cannot simply replace remove this section unless we have these things listed somewhere down [Music] so we can we can delete the section it just someone just needs to go through and do the work to do so so right now throughout throughout the document there's a mix of linking styles in some places we link with title

some places we use that format and some places we just oops we just use i wish there's that feature in here let's use that for it so the the square brackets followed by the parentheses that one is an inline link and so that works just like you'd expect the title will be what you see when it's rendered and the link inside parentheses is what happens when you click on it for the other format where it's just square bracket title square bracket and there's no parentheses afterwards that one refers to a link that is somewhere else on the page yeah so it's somewhere else on the page so the markdown renderer will then go through the page and look for somewhere that has something in the format of title colon

i'll look for that somewhere else in the page and then when it renders it will fill in the link so if we want to delete that section someone needs to go through and convert all the links that are just square bracket links without the parentheses to the ones that have the square bracket and parentheses does that make sense yeah it does yeah i mean i mean i'm just trying to think over here is like it definitely is helping i mean when when it was written for the first time it might have been very helpful because they don't have to repeat adding link everywhere and if someone has to go do that that should not be a problem because that is going to be just one time task to be done and people can start following that as a

practice for anything new to be added here um i'm just wondering like that should not be something heavily debated so before doing that maybe i can create an issue uh or maybe a pull request and then see what is the general opinion there because this seems like a big change because uh people who have written it initially might have considered that uh like not mentioning it again and again maybe for so many reasons um just removing it yeah so that's the that's the theory behind it in this case i believe every single one of those links is used only once so it didn't actually work out that way okay i'm doing a quick check and so far i've found i have found no duplicates in

my quick spot check like they're all linked exactly once without the link and then exactly ones down the biography section like none of them are reused and so that the argument you made is the reason people say this is a better way but in practice it doesn't appear to actually be benefiting us at all in fact some of them are in the bibliography and don't exist anywhere else like the even in the document yeah so like um the pull request link is in the bibliography but it doesn't exist anywhere in the page anymore and so this is the problem with those sorts of links is it's very easy when you edit the document to just like delete a line and then you don't realize that there was a bibliography link that

needs to be deleted as well which is why i prefer the inline all right i can take up on this task maybe i'll give some time and look into what all links need to be updated whatever is referred in the document and if these are not like so many places then definitely we can go ahead and do that okay that's on that i see on that comment britain you have mentioned about some ideas do you want to speak for it or i'll not let me open there yeah so it's just something that didn't get that much attention back in the r d

discord i was wondering if anyone read that and had some thoughts there but we can discuss it another time or maybe not um just the general vibe is just safe yeah for very complex things specs versus aips but i don't know so the i we definitely have talked about it um and thought about it a lot the currently sam and others sam edel is working on a executable spec for ethereum uh this means so the idea is basically a version of ethereum written explicitly for being readable not for being performant or usable and so it likely or in fact we know it will not be able to run in the real world it's written in python it is

unoptimized you will not be able to sync mainnet off if you would like to run it but it is um will pass all the tests and it is a functional client and again the goal here is it's written to be incredibly readable and the idea is is in the future hopefully near future we'll see how fast they can get that done instead of having the yellow paper which is both unreadable and not executable we will have the executable spec which people can read and execute and so other when we do changes we can just make a pr essentially or a diff against that executable spec and say this is the change and the reason is valuable is things like eip 1559 for

example um we basically had to kind of redefine a bunch of stuff in the specification section of that so that way the change made sense like in order to explain the change you had to for we had to first explain the existing system and this is very tedious and uh annoying and it leads to bugs and whatnot so that's the idea is actually in the future when that lands the question then becomes do we still use eips or do we not use eips and there are definitely several different camps of people in this discussion there's tim's in the camp if you would like to keep the eip process and have the eips maybe link out to the uh a diff against the executable spec in the specification section

um sam i believe wants to keep the certain sections of the ap such as security considerations backward compatibility rationale motivation in a isolated document but in the specs repo so maybe in the form of like still a markdown document of some kind and they would sit and sit next to the change itself in some way i mean there's people like me who are on the far extreme of i would prefer to just say keep all that information because i consider it to be transient information keep that information in the pr that is goes along with the spec change but don't retain it somewhere permanent and so there's definitely lots of

discussion on this lots of differing viewpoints and opinions i think at the moment i think we're always kind of waiting for the executable spec to be finished before we commit to anything because we want to wait and see how that turns out and wait to see you know what structure is like and maybe try a few different things before going too hard on one solution um so yeah so does that answer your question of or would you like to discuss it more i'm open for it yeah yeah that's awesome is that sam wilson uh yeah sam wilson is the one i think that matt might know better i think sam is leading that charge yeah he is

recently sam wilson um came on and he provided the latest on the execution respects that that he is working on for documenting in python as well as he proposed his new idea of eip process that he thinks could be useful uh but that's in thought phase right now probably will keep on iterating and think what would be the better way or better approach uh to continue the eip process once this pack is like fully uh functional and uh people are out of the merge thing and start thinking in this direction

i hope do you have a link to that people need episode by chance yeah i will send it to you i was gonna go watch it and then i think i got distracted with a bunch of other stuff and never did no problem uh i will share that with you uh i'll do me you and um i want to bring one last thing um oh okay if we are done with this topic of britain uh did that answer your questions yeah that was awesome okay thank you so i just wanted to discuss one more thing uh before uh we can leave for today it's just for formatting i have seen that in eip1 we try to refer status in

different ways sometimes it is in running letter sometimes it is in capital letter so i was trying to think like is it any value making it a standard that whenever we are referring to a status it should be all caps and whenever it is where you are referring it to a word it can be in running say for example review review is a review that we do for proposal but review is also a status so when we are trying to refer it as a status and we start using it in all caps would help people to differentiate between whatever we are talking about i mean it's just my general thought what do you guys think i find myself sometimes doing that um

just out of habit i think for the habit um i think for the same reason that you just described i do it uh it's kind of subconscious and when i catch myself doing it i correct and remove the all caps but if everybody agrees to do all caps i'm okay with it i don't really like all caps personally you don't or you do i don't uh would you prefer all right all lowercase um i guess i haven't thought about this very deeply but like it doesn't feel like the status needs to have all cops on it what about if we prepend it with an

underscore does that make you feel better if you put zero x in front of it yeah this is xerox final we can implement it sold uh i i don't really care that much but i'm not i don't really like all capital words when it's not really unnecessary so i think that i think the differentiation between an official status and just discussing like the general concept of some themes in review or something in draft is valuable i do wonder though is it sufficient to just maybe capitalize the first letter

for the status that follows normal english language conventions where if it's a you consider it like a proper noun sort of yeah i would be more on board with that title all right because in the eip1 at the moment i see that it is a mix of both like some places when uh we are writing it explaining the statuses it is kind of all caps and somewhere it is running so i would also be down with symposium backticks and using lowercase so are you recommending that

wherever we find it on all caps which it can be updated to lowercase or lowercase or just the first letter as capital i'm just super closing an alternative i think of those three my personal favorite favorite i think is uppercase first letter everywhere that we're referring to the actual state if someone has a strong argument otherwise i'm open to it though and not a hill i want to die on at all sounds good i want to really it's not even really a hill i want to fight on no it just came to my attention because sometimes in my general presentation i

talk about statuses and i myself write it in both ways sometimes running and sometimes in all caps so i was thinking to bring it to a standardization that i can i can follow it for myself and that's why i wanted to bring it up to you guys okay well if no one has strong opinions and everybody's okay with just capital first letter won't go with that it's in the middle of all lowercase and all caps so it's a compromise right okay that can be the third pull request

because i see some some places it is all caps so i can make a full request to a pay attack in eip one two if a stage were multi letters multi words would it be the first letter of each word so last yeah so last call is a good example of that one last call is two words and the l and the c are both capitals sweethearts all right sorry you were saying something micah i said you're right it is definitely inconsistent in this document we use

just about every form no problem i'll try to update it with whatever we agreed here i hope that it's not something that people will oppose doing it [Music] okay uh let's move on to the last item that's the action item from the last meeting uh 43.1 is rename review period end to last call and to be added in eip template i saw a recent merge which suggests that it is something different than last call and i don't want to like uh debate on that if it is fine by everyone

so um i think i i saw the um per request where we have actually updated this particular field but it's not as last call and it's it's something different it's last called a review period last call or something oh yeah yeah the um we renamed deadline or uh not deadline whatever it was called yeah deadline yeah i think so it is review period end maybe last call and or last call deadline something i don't know i mean i it's again not a hill that i would like to die on but i just want to say that it

has been updated not accordingly what was discussed something different but there is an update that might reflect that it's about the last call period not the tv period i'm trying to maybe misunderstand something do you have the link to the pr they're referring to yes i think um i'm trying to pull it out it should be here in mind you're talking about alex's pr right where he updated the template any ip1 to use last call deadline yes and the number is 4438 request 4438 oh this is in

in the midst of his race to four four four four with matt oh sorry i think uh yeah yeah i think matt updated it how is it rename review period end to last call deadline yeah that's fine yeah i think and basically it was no one in our last video remember correctly no one cared what it was called and we all agreed that the name could be better and um so i'm totally fine with the person who made the pr gets to this side and i think i even told someone that in discord right right yeah yeah i was just trying to make it a point that it has been updated now it's no more review period

ending is reflecting the last call not exactly the same wording but uh the field is updated now and it should be better i'm making more clarity yep all right the next one is what it takes to be on the list of active editors oh it's just the listing of it um 43.3 to agree on who gets mentioned in ea i think uh michael you already have a merged actor pull request there right yeah i think so 43.90 and the next one is eip registries oh we are still looking for it so if anyone is hearing this call we are

looking for a champion who can jump in the idea shared by nick johnson and eib's issue section um and if you are willing to put on time please reach ap editors or the cat holders anywhere on their discord channels ethernet or mdc the last one here is puja to open an issue with eatpod repo a little check the bad merge i think the part has merged the eip 2070 that we were having issues with and yeah i think that's all from the action items from the last meeting we have about five minutes left anyone

wants to bring up anything that's that's enough time for me to chastise matt on the vip number farming 1444 yes it's actually pronounced four fours but yeah i'm very conflicted because on the one hand i have a huge opponent to people in positions of power of using the rules and i feel like those in power should be held to a far higher standard and punished far more severely than regular plebs who uh i break the rules on the other hand i don't have the energy to actually give you a whipping so

i created useful pr's on the race the 444 were any club could have done that if some plug that sniped me i would have accepted and i would have waited till five five five five it just means that a lot more work would have been done in the meantime note to self next time i set up an alert like a page page me in the middle of the night wake me up if i see matt doing a lot of work matt is way too productive today something's fishy what's the next nice looking number coming up that's right 5k

what was that in puja 5k actually this might just be a real quick topic but i've noticed at least for two ercs or proposed ercs i think one was diamond standard and i can't remember the other they had subtypes and like an abc version is there an official idea for the subtypes like alphabet versus murals um so eip numbers are just numbers so it's just going to be a number from like one to ten thousand or whatever um now people can put whatever they want in the title we generally leave that

entirely up to the author um i discourage people from yeah so i mean there is only erc-1155 there may also be erc you know seven two three four which may depend on one one five five or maybe derived from one one five five but that is not erc-1155 it is erc7324 um i would if i saw someone uh referring to their eip as another eip number than what it is i would probably step in and correct them and

if you see someone doing that in the efus repo um pointed out to me because that is definitely not acceptable in my opinion like the numbering system exists for a reason and it's people should not be trying to basically use the like when i see when i see what you just typed there my gut is that someone's basically trying to use the marketing poll of 1155 in order to pump their own thing and i'm very much not a fan of that the numbering system should not be a marketing scheme like its numbers are meant to be monotonically increasing and strictly for organizational purposes the title is what you should go by so like if you want a cool title give your eip a cool title like as much as i hate the

diamond standard naming system that's a cool title and it's meaningful and so people can call it the diamond standard um so yeah so so the the short answer is you should not be naming an eip that is not eip1155 as eip155 not something um nor should you name it erc1155.something okay yeah no i didn't get that clear across very clearly uh i think it was more that i feel like i've at least found on two proposed ercs that there were subtypes within the document in some senses in like a stronger version then like it might lay out three different versions within the same arcs i can find the

uh examples if as you're saying if you i'm not sure you guys found them before yeah i mean i can imagine people doing that have you seen the matt you look at your shoes a lot more than i do these days i haven't seen no i'm also doing this i also learned you don't actually read the ercs when you edit them so i read them once the first time i added them um i have to think on how i feel about that like i feel like if you're gonna have two standards you should just have two standards in the pa for core eips specifically i strongly advocate to every single author that if you can break an eip up into multiple eips you should they go through

smoother they're easier to implement people can choose whether they implement all or nothing or one or the other from a communication standpoint it's way easier from a coordination standpoint it's way easier like people should be writing very small eips that do the least amount possible is similar to the general concept in software engineering where if you're going to submit a change request they should be as small as possible and you submit multiple small change requests that are each individually useful and individually tested and everything rather than one monolithic one because it just makes the process a lot easier so i feel very similar for eips that really they if you've got multiple standards within an eip that's a very strong signal to me that you really have multiple eips and

you should just create multiple aps um so yeah i guess i guess my answer is i don't have a strong opinion on the sub naming because i don't think people should be doing that getting into position in the first place where they need the sub name but i probably wouldn't force that on anyone i think this is something that has to be given by the eip editor so otto should not try to grab a number for himself or herself right in the first place and when we are doing it with the help of a pull request or issue number i don't think uh this kind of number system should exist in the first place yeah in this case what they're saying is

someone wrote an eip so let's say eip1234 and then within eip1234 it has two different standards defined and they're saying like how do you refer to the two different standards like do you do eip1234.a and b or do eip1234.1 and dot two or something else and my argument is you just have the ip one two three four and eip one two three five i would really support your argument here uh because as you mentioned that you already have been advocating it for the core eips and that turned out to be really good it is helpful in implementation finders find it easier to implement so i'm hoping that it would be helpful and

even on the application side if any developer wants to pick up only one part of the eip and there are two separate eips proposing different solutions hey apparently tim is still on american time he is right on time it does that we started an hour early well right on time only if you're living in a previous point in history can you understand i'm so ashamed

to be fair i don't know if the calendar event was updated until this morning right yeah it wasn't like and uh there is this um there is this calendar that is created by ethereum pm so that might also need some updating because that's also showing the older one and the one that i run i updated it this morning so might be sincere apologies yeah so what time should this be is this 1500 an hour ago yeah but this is right on the calendar or oh it should be an hour earlier we're starting an hour late history we already had the meeting and we just finished oh so we're saying oh sorry okay so i've just

agreed we've agreed that it's not entirely your fault it seems that the calendars are yeah not all up to date so i guess is there anything really urgent that like you really needed me for yeah okay uh sorry about that i'm gonna change the time zone on the protocol meeting invites to be utc which i think we can do now so that means that it actually stays kind of fixed right right if possible i would also like to share the zoom link there do you think it would be a good idea to share the zoom link over there in that invite well it's not it's already there that's how i joined okay okay that's fine now

can i ask a question quick question if i guess i'm curious like how the people feel about the new crop is probably too strong of a word but the couple people who like have joined into the eip editor channels did anyone like make a contribution yet or um is it just too early to tell i haven't seen any contributions at least on the part of the eips that i watch um but it's very early so hard to say if that's just people are still trying to figure out where they fit okay i also haven't seen a lot of contribution but i have had a couple of people dm me so feels like they're

trying to figure out the situation they'll do some contributing at some point cool by the way is this meeting every two or four weeks because the the protocol invite is every four weeks but yeah okay so i'll change that as well okay so that means that the next one would be uh basically the first december 1st uh 15 utc oh well thank you everyone for joining us today and um hope to see you in next two weeks and thank you tim for already updating the universal calendar that we are recommending people to join and follow so thanks everyone see you in two weeks thank you

see ya everyone thanks cheers