ACTION 56.1: Splitting Out EIP repo into EIPs & ERCs will be put on hold.
ACTION 56.2 No changes will be made to the repository
Pooja: Welcome to eipip meeting 56. I have shared agenda in chat the first item listed here is core eips in an executable spec world the proposal and discussion link is added to the agenda item so as we know that this item has been under discussion for a while I have added it as the first item so we get enough time for discussion however greg in a comment below has requested to postpone the final decision on this his comment is added on the agenda itself so as for the rough consensus from the last meeting they were supposed to collect the feedback from the alco dev meeting but as anticipated the all coder meeting agenda was jam-packed and I intend thought that it would be better to first finish up with the merge thing and maybe we can bring it up to the next code meeting or maybe if tim can collect the thoughts asynchronously I don't know I don't see him on the call today so I don't know if he has already collected feedback from the client but definitely we can have an update in the next meeting so I wonder if anyone had anyone has to add anything on this item or anything in response to greg's comment about fully understanding the issue
Micah: Not specifically about greg's comment but we did get a little bit of discussion in the all core devs discord like text channel and it seems like people are pretty mixed about it but yeah it wasn't like a super in depth or like we didn't talk to everybody yet so we'll probably have to bring it up in the next meeting
Pooja: Sounds good so for people listening to this call if you are interested in following this discussion there is a fem link added to the agenda and you may also follow earlier meeting notes available on ea repository but i'll keep it on the next meeting so if we get anything from codex we'll probably like to share that
#2. Splitting out EIP repo into EIPs & ERCs.
Pooja: Movingon to item number two splitting out eip repo into eips and ercs just to get some context here the number of standard track erc proposal and standard track core proposals submitted every month are generally equal in number but the merge as final for core and ercs the ratio is not same one main reason could be the lack of eip editors who are interested in reviewing erc kind of proposals on the other hand eap editors reviewing core proposals sometimes find it hard like finding out the relevant pull request to review from the pool of mixed proposals submitted in the github repository so this topic was an active discussion about a year ago and people may find the link below to follow earlier discussion and this has been brought back into active discussion with core eips for executable specs thanks to tim's tweet a few weeks ago people reached out to provide suggestions and even help as tim mentioned in the discard and also one contributor showed up yesterday in the internship meeting to maybe help with the process so inviting kilian I see him on the call today to share his thoughts
Killian: Hi all i'm killian we've been working on a product using github and a lot of bots and scripts therefore we wanted to propose our help there to split eips and ercs it would be not too hard to do that at the moment if I assessed the problem right so in my assumption we would read out the eips and erc's split them based then in the script based on some [Music] if statements and then post them again in the respective folders or repos depending on what the aim is here so generally we're here to help if you want to get that process going feel free to reach out if you have any questions also feel free to ask yeah that's it for my side
Jose: Well I just was wondering is the precisely is the vodka and the ap but can actually classify the which is eip and what do you say erc that's not the problem I think that the problem is to define is it's gonna be another repo for for what I was reading into the discussions the previous discussion if there is going to be another report for the ercs because the the the the classif the classification is straightforward after that if you if the editors and and senior contributors this side is going to be another repo for the erc so therefore it could be defined a new set or a new group of editors for the ercs and therefore the the process as I understood could flow I think that the classification is it's not pretty much the issue I think that the what I was reading there and on even I go back with your notes that the the that you sent the conversation that you sent and I went back to the leggy lee guy he he actually proposed like two years ago so it's just a matter of defining it it's going to be one additional repo for the ercs I mean that that's how I see it I don't know if this is just a proper way I mean but that that's that's a discussion point
Micah: that's it I think that's generally generally correct we're the hard part right now is deciding whether we're going to do it and as mentioned previously the big reason why we're hesitant making a decision is because we have the executables back potentially coming up and it doesn't make a whole lot of sense to pull out the ercs you know potentially months before we rearrange a bunch of other things as well it feels we should do it both at the same time or maybe plano extrudable specs will just solve this problem entirely
Tim: yeah I think alex has convinced me of that like I didn't know that the eip bot already could like segment much more granularly and just like tag specific people for ercs that's probably a good enough like crutch for like basically you know having a subset of people who are assigned the ercs and and we may choose to make that subset zero basically if we if we want like if nobody wants to be an erc editor then you can still have a world where like we only have vip editors and and just no one gets paid when there's a new erc which is obviously not great but that also happens if we split the repo and yeah I think figuring out something that's long term that works long term with the executable specs across both like the consensus and execution layer is like pretty important just because we're starting to see the like technical depth creep up there where there's like these weird pr's in the consensus specs repo that are basically eips and then there's stuff like an eip4844 folder showing up in the consensus specs as well so it just feels like we probably want to solve that problem and worst case just use the bots to deal with the erc thing
Pooja: so the one major problem that seems to be pertinent here is like we definitely need more people who will be able to review the erc category proposal so if we get the number of reviewers increased number of rivers probably it will help I mean splitting the repo may not be helpful getting erc category proposals on board
Tim: yeah I think that's right and I think mika the other thing you you mentioned in that chat with alex was like you currently watch the entire repo because you want to make sure no notification slips through the cracks and so another like valuable thing we can do is just have somebody who's maybe not an editor who just like monitors the notifications in the repo and then if something hasn't been like updated in like three days or like a week then they ping either mika or editors or i'm not sure who but it's like I think if if there is someone who's like willing to just do the triaging so that editors don't have to do that then it gives a bit more time back to editors as well which is which is really good
Pooja: I see a comment in the agenda here by lightclient maybe for having people who can maybe own the working group like land if you would like to speak about it she
Lightclient: so this is a little unrelated to splitting out the rc repo and just on that topic before we close it I sort of feel like what is most likely to happen is that the execution specs takes over for core proposals and then the erc eip repo sort of becomes the erc repo I think it's going to be pretty hard to actually migrate the erc repo somewhere else because we have you know lots of issues there lots of links that are linking to that repository it seems a lot easier to try and no eaps I don't know I mean it's not like a perfect solution I just don't know a better way it seems like like the people the easiest thing the easiest part of this equation to change is the core part because that those are the people that we are in cl most close communication with and it's the easiest to say this it has changed and I think the erc portion is a lot harder to change because you have this long tail of people who like don't follow what's happening and I think we are really successful with renaming things to el and ceo because we were able to just do it at this like small core group of like sub 100 people yeah I zero I don't know we need to figure out exactly what this will look like it just feels to me that the easiest thing is going to be to use the execution specs as some sort of eap type of repository
Tim: but how do you do something like 484 which is like the yeah I think and and how do you like send the community because I think the really neat thing about eips is like you can send the community to one page and like it's like a good thing so yeah
Micah: no it's not a good thing stop doing that as i've argued before I think that eaps should be specifications and specification should be self-contained which means the consensus spec has its specification the executable stack has a specification and they are isolated from each other okay fully I fully agree with you that we need a place to put useful documents that we can link people to and we can discuss and we can talk about on core dev calls blah blah blah that is a useful thing I think that we should not sacrifice the the standardization process to achieve that goal we should create a new process or a new thing that fulfills that need which is very different in my opinion from the need of specification and standardization in centralization you really want isolation and modular modularity you do not want them to grow to monolithic things you want to keep them separate just from like an engineering standpoint that is a very good thing to do and if
Tim: I get that that's why when you use that well but then when somebody comes out once and they're like I have eip4844 and they show the specs then the first question people ask is like what is this thing is there like a meta thing I wouldn't care if we literally use meta eips for that because they're like not used anymore like if we if we want to use meta eips as a like weird rapper around like right but it's basically saying meta eips become corey ips
Micah: right so I agree with you that it would be very valuable to have a place for the thing you described my only argument here is I do not think that we should take over the the standardization process with that process I think we need a new process and you've convinced me that we do need this new process like the thing you're describing I agree we need I just I really don't want to throw away like turn the standardization process into that because then we lose the standardization process as like a a clean pristine modular thing and we now have it it's kind of this ever-growing thing that is hard to define and it covers lots of lots of ground we have lots of people involved I think it's really valuable to keep those standardization process isolated and tiny
Tim: well that means nobody uses eips anymore except for ercs right no so you've still we still have this specification process for core chain for executable spec changes and that goes through the executable spectrum exactly
Lightclient: how do you refer to things like 4844 is I think what he's saying yeah and we're driving and like yeah things that cover both layers sure so so this
Micah: I am not opposed to having this this new system that i'm that that would satisfy tim's needs would maybe like maybe that's required before you approach core devs you have to have you know that that meta thing that you're describing like an from a navy standpoint like I am totally okay with the specification process not retaining the name eips like that part doesn't bother me I just think the specification process is isolated from the that kind of meta thing that you're describing
Tim: so what do you think goes in the specification process then because like my view is like emotional but the specifications for what
Micah: like for the executable client and for the consensus clients right
Tim: but those yeah so those we agree we move them out for consensus yes yes yes so like the python code the python code of 4844 say gets half of it in the cl spec half of it in the el spec i'm i'm very happy with that and ideally you give them the same name in the same folders because like then people can kind of navigate that well sure that's but then when I maybe I want
Micah: I disagree with keeping them in sync again I really do think specifications should be isolated and you should not need to worry about having your specifications seeing another specification because things get really complicated then like tcp is as an example is very isolated like lots of things build on it and integrate with it and use it and it's all over the internet but the specification for it is isolated from everything else
Tim: but that's yeah and this is why I want to keep eips because then you get the number so it's like I keeping eips as like just the english description and the number and then you add two links to that one to the cl one to the el like this is why it's my dream it's like because you keep the number it's still called 484 people then go to consensus specs and they look for 484 and they find it and they don't need to deal there's only one place you need to deal with numbering it's like once you get your eip number then you like you know change your folder name and the specs repo and that's it and it's it's super easy but then you can still have the community go to eeps.ethereum.org Eip-4844 it says hey this is going to add chart blob transactions it's going to scale ethereum there's a bunch of security considerations and here's the implementation here's the specification in the cl and the yell so that there's no like code in the eip
Micah: so I think there's two remaining places we disagree one I like as mentioned I don't think we should have try to maintain consistent naming across them I think that in the execution actual spec it should be isolated which means like when a there's a spec change proposal to it that would have whatever its numbering system is it would get that numbering system just like rfcs have their memory system ietf has this memory system and the two are isolated from each other the second thing that I would like is I do think that things like so for let's take four four four which touches with yellow and seal the security considerations section so like there will be an overarching security considerations set of things that affects both the seal and the eo there will also be things that are very specific to the el and I think those security considerations should live in executable specs repo and similarly any security considerations related to the consensus layer change should live in the consensus layer repo again trying to make sure that you know when there's a change to the executable spec everything that you need to know about that is in that repo by itself now if you want bigger contacts and you want the bigger picture then I agree we should we can use the aps I don't even mind if we take the name i'm not okay so yeah the name so I guess of course a set of things that needs to be in the repo with with the code in order for it to you know be useful like it's literally just a code change then there's I think we run into problems
Tim: okay and I think I think I think we're making progress here I think it's almost like looking at like the the template for eips and being like what do you have in the execution execution specs and what you have in the like eip security consideration motivation I weakly disagree but like again not enough to and and the reason why is like I think they are you you can't isolate them we could we would never say something like 4844 is all good on the el but then there's these things on the cl but like let's not think about them so like it's just weird
Micah: I think there's different types of considerations so like a dos vector is almost certainly going to be against just one of the layers and so that surface type security configuration would go in the relevant spec and so it could be the reason it should go there is because if someone's working off of the spec they need to be aware while they're writing their code for this thing hey you know specific to the code you write you need to make sure you deal with this okay yeah that's right
Tim: yeah that's where I disagree I guess because with dos like I think my experience is like with most security considerations you don't really deal with them as you're writing the code but you're dealing with them as you're like iterating on the specification so it's like and maybe i'm wrong there yes I would refer to like an actual kind of
Micah: yeah but there are so many eips have what you described exactly as you described were there the security considerations that like when we were designing this we thought about these things and we designed around them and this is why it's okay and those I would be okay with those type of things going in that the meta place similarly if we have security considerations that do affect like talk about the interaction between the two clients
Tim: okay I can see that yeah but but I can see something like weird like imagine this what's uniswap's eip like the transient storage one and there's some weird security considerations about like the inter frame calls or whatever like i'm totally fine with that just being in the executable spec like oh and now like client disagrees with all of this
Lightclient: does it not seem like the reason that we have this is just a fact of where we came from like if we were to start today I don't think there's any world where we would have separation between consensus and the execution layer like we have this because we're moving towards oh yeah we want modularization I think it's yeah
Micah: in order for us to scale development then
Lightclient: like what are we gonna have like a mempool spec like here's the spec for like how to propagate things
Micah: that would be my hope yes like I would like to pull out the mempool out of the clients and put it into a third service like just from a development standpoint if we want to keep velocity going up for ethereum we need to have separation of things like you can actually see this already so with executables like execution layer everybody knows that like martin is the person that you need to sell on everything right like martin is is the guy that will tell you your stuff is broken and wrong yeah that's the alpha like like martin is the guy who will tell you your stuff is wrong and it will break because of reasons that go way back we don't I martin no longer has to worry about consensus stuff danny does and so now we have two people doing the job that usually used to be just martin doing and because danny knows everything about the whole history of consensus layer and martin doesn't that's okay and vice versa is true as well and so this allows us to scale development of ethereum because we can now work on things in isolation that don't need to touch each other
Lightclient: I just don't see why that has to be at the spec level like you can still have this like imagine there's this world where all of these changes go through some eip repository that has both python specs for el and cl I don't see why you can't just have martin reviewing el danny reviewing cl and then when you have these changes that go across both then you can actually have it all in one place rather than trying to build these systems to create meta specs around like many changes
Micah: I think the answer to that is because humans suck and if we put everything into one repo then I think we're going to end up with lots of bleeding between the two whereas if we keep them in separate repos and fully isolated from each other it basically protects us from our future selves who will do bad things so by having the specs in two separate repos it forces us to draw very clear boundaries between the two pieces of software and it doesn't allow us to blur the line and and kind of blend the two and I think that that separation being very clear and a hard line forces you to think about things a certain way and that's the same reason why like in just as it's a kind of analogous example in my personal projects when i'm building a library I put it in a separate repo and I work on it because it forces me to have a very clear api layer it makes it forces me to interact with it as a third-party thing and that changes the way I think about the project as a whole if if I was not a human and I could do everything much better then I wouldn't need to do that but it is a very useful tool for keeping the i'm claiming i'm human still at least it provides a very useful tool for segregating these these two things mentally that humans have a tendency to not do naturally like the natural inclination is if you have two things they're sitting right next to each other you kind of blend them together especially if you're constantly working on them at similar points in time and you're integrating them together it's really easy to just blend those and so having these very clear lines protects us from future us because future us are going to do dumb things if we allow it
Tim: yeah and one thing i'll add is I may be a bit more pessimistic than you matt like I don't think we'll ever see a spec for the mempool just because people in practice have such a hard time letting go of the thing they control so like I it's almost like a nice accident of history that we've ended up with these two separate specs and now we get to manage them in parallel and like I think it's really hard to unbundle things everyone like I mean my wish list is like we unbundle the evm from like all the rest of like the clients that'll be so amazing yeah you know alex would thrive forever and like the evm would be would be great and like and that's just never gonna happen because I think it's like a human problem it's like or maybe it'll happen once all the current coordinates have like retired and the people who come have like less of an attachment to this stuff but it's yeah I don't I don't have a strong opinion that it should all be the same repo or not but I think in practice having different people own different parts of it is really valuable and and like i'm i'm not optimistic that we can actually improve that like that we can
Lightclient: i'm all about different people owning different pieces i'm just trying to think like how are we going to discuss changes in the future that go across like multiple layers and i'm just like not sure that like in my mind it's just a lot it would be a lot better if there was this perfect world where we had one repository that you could see the diff across both layers and you know those people can see immediately like what's happening rather than having a situation where now we have to have like you know meta specs built on top of like two different changes and you know always like keeping that up to date rather than just having it always up to date i'm okay with that long term
Tim: I don't think it's realistic for like v1 of the executable specs but I don't care about merging the repos themselves like at some point I mean I don't really have the super strong opinion on this no but I see your point I think it is you know there is some there are some humans who are able to do cl and yell work very few but like I think yeah sure it's probably good if proto can like just pull up the entire 484 thing in front of him and like do that yeah so i'm yeah you've connected me so
Micah: tim and I disagree on this but I am of the opinion that over time there will be relatively few changes that touch cl and yell at the same time historically we have had almost zero changes that have touched the consensus the proof of work consensus layer and the execution layer now prove state consensus does is significantly different and it does have withdrawals and deposits so there it is likely to have more changes to touch both but I think once we're done with this like initial thrust of merge plus post merge work I suspect we're not going to see that much in terms of changes to touch both I think most pages will touch execution
Tim: we still have all this stuff around history we still have all this stuff around like proposal builder separation we have you know you can argue you can argue that if we do 4844 we're done with charting on the el side but all I still struggle to believe that
Micah: so I think proposer builder can actually be designed one layer at a time I don't think I mean I haven't been following it closely so maybe i'm wrong on this but my gut tells me that we can we don't need to do both layers simultaneously whereas with some things we do like withdrawals for example we have to do both simultaneously we can't do them like one and then launch it wait like we and so anything that we can split I think we should split and if we accept that then I think we're down to very few that are left okay
Lightclient: how do people feel about the scorched earth approach to removing ercs from the eip repository
Micah: like I said my my feeling generally is let's wait until executable specs repo is up and we have solved that problem and then see where we're at
Lightclient: I just think that there's like no world where we don't want to continue using eips to describe like core changes across multiple layers and if that's the case there's like no way to not move ercs out of the eap repository
Micah: so I think it depends on where tim and I land in this epic seven month long battle over what to do with specifications versus description of large change sets if we end up like in the end that I want then that whole meta thing is just like someone can write a hackmd I don't care like it's it doesn't need I don't think it needs to be as official if we end up with tim once then I think you're right we will need you know someplace to put these official formal documents that get reviewed and audited
Lihtclient: so then what what will we call a change to the el in your world how do I refer to a change just to the el so change the l would be a change to executable specs following the system sam has designed which is basically you get a branch for the the change and I want to like I want to present my push zero op code how like what's the reference
Micah: so I think he has I think his number system is based off of the pr number but he'd be a better person to answer that
Lightclient: it's based on like in the execution specs yeah or we could go with like what's the prefix is it like yellow dash 22 or 75 like what's the
Micah: for the sake of discussion let's see we can just say that again I don't know what sam has planned but we can just say it's yeah el 2075 or whatever and that would refer to a very specific set of changes to the execution layer specification that go along with you know your push 0 no more core eips in my hypothetical future I suspect we may end up with something that's a blend between tim's and mine so i'm using the extremes just for for discussion here but yes and in my ideal future there would be no more core eips there would be execution layer spec changes and there would be concentration of changes
Lightclient: I just feel like there's not a way that we can get around getting rid of using eips to refer to core changes because it's like such a core historical part of referring to ethereum changes and I think it's like more likely that we have an eips that refer to execution layer and consensus layer and there's like a system for like making sure that those don't overlap because we already have the precedent of having application layer standards be referred to as ercs so there's not the conflict
Micah: so I think that the strongest argument that you've made is that humans suck and they don't like change and I mean it's certainly possible that we will not be able to convince all those humans to to change to a new system that does not unfold vips in which case you're right we'd have to keep your eyepiece i'm still holding out hope but I acknowledge that my hope is probably misplaced
Micah: that seems like a good place to cap this conversation until two weeks from now we re discovered for 30 more minutes
Pooja: maybe if one of you can like summarize it for the note taker from where to take it from in the next conversation all right at least we can
**Micah:**hey tim and I made a little bit of progress there I wouldn't say there's no progress
Pooja: so can we say for like coming back to agenda item number two splitting out eip repo and into like eips and erc we are putting it on hold right
Micah: I mean that's my recommendation sounds like matt wants to not put it on hold now with this let's get rid of the ep's reboot entirely just delete it let's completely delete it and then just figure out what we want to do after that
Pooja: so matt what would be your what would be your strongest argument for having this repo split in the present scenario I mean I think that having the er in a separate place is just something that would be nice for application developers to just have their own world where they can hopefully build a nice governance mechanism around application standards rather than being you know I feel like right now it's hard to give a lot of application developers power over the eep's repository because it's a very core piece of like infrastructure for ethereum governance and if they have their own world then they can sort of like we can just be like you know you can do whatever you want over here and then we keep the eeps repository because like we can't just give like an application dev like admin access in each repository just be like build a mechanism that you would like to see for governing application standards
Tim: so I the thing i've struggled with erc people is like generally they just want to push their specific change through and then move on with their lives like I haven't met somebody who's like passionate about erc's in the abstract
Pooja: yeah I agree I have seen this in most of the cases and coming back to lightline's point I was wondering this is a very strong argument but I would have been more more convinced if this is coming up from an erc developer I understand like erc people they come they push their standard and once it is done and implemented into a few projects they are gone they never demanded for any kind of governance or maybe their involvement deep involvement
Micah: I think the I think there have been a couple of people that have shown up and said they are interested but then they disappeared so I think the reason usually they disappear is they realize that it's a time-consuming thing and they don't have the time for it I don't so I do think there are people that want this what we're describing I don't know if there are people who want it and have the time to do it if we could somehow fund it then we might be able to find someone who wants it and is willing to work if they're like funded separately I think that if if what you guys say is true and there are literally no no application developers who actually care about a standardization process then maybe we just don't need a standardization process for application level stuff
Lightclient: there's a handful of things that are pretty useful to standardize on the application level and I feel like there needs to be a place I don't know like how to deal with that in that world like there needs to be some interface for tokens
Micah: sure I mean the the anarchist way to deal with this is everybody's build their tokens and they kind of can consolidate on a standard similar and how and usually it means following the most popular thing and so metamask the most popular thing for wallets there's no place place to do wallet standards right now and so everybody just copies metamasks api and so metamask gets to find whatever api they want and at some point in the future when someone is more popular in metamask then they get to define the api and that's the government the anarchist governance system for standardization and I mean the reason I mention this is just that like the world will not end if we end up in that universe perhaps it's not great but it's like things won't totally break
Lightclient: do you think that somebody from consensus would want to play a like similar role that you do tim you you
Tim: you think you need that much involvement for ercs?
Lightclient: I just think that there needs to be somebody out there driving like right now I feel like there are people who want to standardize things and they want to like work on improving application standards and like their own niche but there's no person who like does the role that you do like you do a lot of other things other than just like drive certain things but just having that person who's like always connecting always you know checking out making sure stuff is progressing that's like a super powerful thing that we just don't have at the erc level
Tim: right and it's not just about like the erc eips themselves it's more like basically running all wallet devs as well and that type of stuff
Lightclient: right like I don't know I think there's we're starting to see some of these things emerge like the wallet devs are wanting to like I don't know we're basically coercing them into like communicating amongst each other and then I think nft people would really like to have some more work on figuring out what in a teacher look like in the future but I don't know there doesn't really seem like you know a higher level of that to like push those groups forward it's just like eh
Tim: on ethereum as well because this is the other thing is like the nft people they want and the walnuts they care about like all the chains no you're right okay I will think about that yep
Lightclient: so anyways that's probably enough to talk about that I did want to just say one other thing on that working group topic if anybody has a recommendation for who can help sort of lead a standard on urls related to ethereum and maybe blockchains in general because there's about three eeps in flight right now regarding this
Micah: hasn't this already been done like three times I mean
Lightclient: maybe that's the case I think like when there's like started one like 8 23 maybe two three years ago and then it's stagnant now never finalized it just feels like there's some overlap of these proposals but also the proposal of doing different things and this should probably just be like one larger proposal about here is like all the things that you might need to do in a blockchain context and how you can encode that in a url that feels like that's an infinitely better situation to end up in than this world where we have like three or four half fake heaps about this topic and for the most part I don't really get too worried about ea erc's because you know they need to do whatever they want but I feel like the this url standard is something that's like actually could be pretty important depending on how it plays out so if anybody has a recommendation on who can help drive that process
Pooja: yeah maybe we can share this information out and check if anyone from community is willing to take a lead on this you are a standard for change I may be reaching out to the nft group I know one group is active there maybe if someone from that group working on a different application layer standard
Lightclient: yeah I was wondering maybe if like league would be interested or pedro from wall connect those people I feel like have done or maybe somebody from the chain agnostic improvement proposals group like maybe these url things are something that fit better in the context of caips okay okay i'll try to reach out to legend pedro at least to share this information if there is any interest
Poja: oh yeah a good suggestion I can check with greg as well cool I know we had good discussion today but in the interest of time I think we should move forward we have still more items to check on but before we move what would be the like general consensus on this particular item is it fair to say that we are letting it rest as it and no more progress because I know kilian is here to maybe help out if there is any interest in splitting the repo
Micah: so I think we are definitely not at a point we're ready to start working on the technical side of like actually splitting the repo we're still deep in discussion of whether we should split the repo and we're supposed to etc and it sounds like killians was looking to help out on the technical side so I don't think we're there yet
Killian: all right thank you for the information yeah I was aiming to help on technical level if you come to a conclusion you can find me on the cut hurdles discord and feel free to reach out i'll be there to help
Pooja: excellent thank you well thank you let's move on to the next item though I don't see sam on the call next item is related to him getting some permission sam wilson has been active actively engaged in eip editing and yesterday in the internship meeting he mentioned about having some permission to maybe override what I know this permission is limited right now but I was wondering if there are any thoughts on getting more people involved into it or what's the current
Micah: my general feeling from a security standpoint is you generally the security best practice is to limit who has access to things and so currently my preference is to keep the number of people with override power low and so if we are going to add sam I would like to remove someone else that could be me i'm fine with that I just don't think we should just add every editor to we don't have to have admin rights let me pull up who's admin right now I think it's me and you and elita Pooja: I think we can yeah remove later because she hasn't been active recently will that help
Micah: yeah that's fine like I think keeping it down to three is reasonable i'd be okay with that at some point we'll probably have to remove one of the three of us if we get a full-time bot author who needs to make edits but we can do cross that bridge when we get there and I volunteer to be removed not if I volunteer first too late bibs
Pooja: all right i'm assuming like having sam added is it something that can be done by either of you in case it is not possible then let me know then in that case i'll be reaching out to the devops team to get it done okay cool
#4. EIP bots related discussion, updates, agreement on merging PRs & closing Issues.
Pooja: item number four is eip's bot related discussion updates agreement on merging prs and closing so we are trying to bring out the pull requests which are already existing matt I know the the eipv repository you know most of the quotes were added by you so if you can maybe look into the pull request added over there it seems like they are there for for some time and let the proposer know if that can be moved further or if there is anything that can be improved to push it forward similarly for eip bot I don't know jose is on the call yeah if you have anything to begin with and then probably we can look into pull requests which are open
Jose: hi well basically yeah there are five issues that has been already coded into the pull request but mikka and all and all the guys are aware of that I mean there has been a very active discussion and there are already eight more issues that we I would say I will take the risk we basically agreed so i'm gonna start to to code those during this week so we can we can keep moving forward but yeah is it's getting there
Pooja: awesome I think we are getting quite a few discussion in the eap bot issue issues and pull requests but eipv is not getting that kind of attention I know mika has showed his limited interest on that because of his like maybe technical expertise with rust so lightline if you get a chance maybe look into the pull request if that helps just say you have hands free you want to say something or is it from the last time
Jose: well if if everybody agrees I can take a look in the eip repo just to just to see what what is there and to see what if we can from this side start to contribute I either
Pooja: I think in the last meeting we had mario on the call who I suppose will be helping out with the eipv so let's have one on one like if you can maybe take care of the ap part issues or and let mario be looking into eipv I just wanted to bring it up to this discussion because I see that there are already a couple of pull requests which may need attention does that sound reasonable jose i
Jose: yeah that's fine I just was wondering to I mean I can I can read whenever I want but that yeah that that's okay I will let's see how how mario's keep keep moving forward good agree
Pooja: I mean if we can get extra help I have absolutely no problem I just don't want that any any repository to be stuck at one place and I know you are doing a good job here and with eip path so yeah thank you thank you got it okay clear clear enough thank you yeah that's on it if there is no further updates on that
Pooja: maybe we can move on to item number five the number five is merge aetidium cathedrals into ethereum organization this was proposed by panda pip one and we discussed in the last meeting and our suggestion was if we can get more information from him on why does he want to do that I have added the link here which suggests that he has added some of his comments saying like why he thinks if this can be added to the repository I don't know if there is any comment from the group the main point that he has mentioned here is like it will increase the discoverability
Micah: my general feeling is I like the cat herders having autonomy and not being governed by and constrained by ethereum foundation rules and administration and whatnot and so i'm weakly against integration I don't feel super strongly I just I generally feel like there should be a very strong reason to merge two distinct organizations and I just don't see the strong reason here I see some weak reasons like the reasons you mentioned I think they're not reasonable not unreasonable but I don't think they're strong enough to warrant taking away that autonomy
Pooja: I think that we got another reason for maybe a not not very strongly favor in that of it's like it's a comment from tim saying that's a pain to add new repose under ethereum repository yeah I think I would agree to the point that ethereum cat herders has its own autonomy they are working in association with community to maybe help out in whatever way possible so unless we have like very strong needs and to put it under the head of ethereum foundation or ethereum repository sounds fair anyone who is strongly in support of the proposal that cat header should be merged into ethereum yeah daniel see your hand raised
Daniel: yeah I don't have an opinion about this specific point but one of the things that I felt as I was trying and i'm still trying to understand the ecosystem is you know cat herders vip editors ethereum magicians it's just it's a lot of names a lot of different platforms I don't know if merging into ethereum organization would solve any of those issues but this discussion and I think the reasons behind this the comment relate to kind of the lack of clarity there or at least the perceived lack of clarity
Pooja: yeah I see a very good suggestion from tim about having a page on ethereum.org explain how all these things work I know there is a community page on ethereum.org that points to what ethereum cathode is but maybe having more information on how all of these are connected and how the process actually works here may be helpful
Daniel: yeah I agree that that would be a a great step cool maybe we can look into having a page added over there or maybe update the existing page to provide more information on that
Pooja: all right moving on to the next item here that is eip's insight i've updated the report till this morning as per the report in may we have got 10 new proposals three of core one networking and six ercs as draft a new draft we have five potential proposals to be merged three eips of erc category are promoted to review and four eips are moved to stagnant due to inactivity over six months one proposal eip 1967 has completed its last call and now is in final this is the only final eip in this month the detailed report is added in the eips inside the link is available on the agenda check out for its new charts and let me know if people would like to have more in-depth analysis and more comparison with respect to different charts if there are suggestions you can either leave a comment or reach me on ethereum catalyst discord i'll try to add those
#7. EIP editor apprenticeship meeting
Pooja: next item is eap editors apprenticeship meeting so this meeting happens every two weeks one was completed yesterday I have added link to agenda and the video is already out people who are interested in learning about eip editing process are invited to participate in this meeting and share their questions with eap editors so they be able to become a reviewer in long term and maybe become an eap editor if they want to pursue that line for contributing ethereums as from the perspective of a reviewer so please join us on on tuesday two weeks from now and be a part of that apprenticeship meeting the
#8. Review action items from the previous meeting
Pooja: last item for today's is a review action item from previous meeting so i'm just gonna pull out I don't know my computer is working a little bit slower today okay so the first one is collect feedback from codef so making diff in python we did mention that we are going to bring this item in the next meeting and due to pam's agenda we could not talk to the acd team async communication is going on and discussion is on if our individual channel action item number two is collect more info on panda peeps comment we did discuss about it item number three jose will create pull requests in eap box github and he shared some of the pull requests that he created since the last meeting so that's all for the items listed here anything anyone would like to bring up for today or maybe for the next meetings discussion well in that case we hit the time and thank you everyone for joining us today I hope to see continued discussion on different channels
Micah Zoltu
Killian
Pooja Ranjan
Jen elle
Daniel Tedesco
Jose
Lightclient
Tim beiko