EIPIP Meeting 95

Transcript

welcome to EIP IP meeting 95 this is issue number 297 on EIP GitHub repository in the past few days I have received multiple queries on EIP ERC report split and on how Robos the current feedback loop is between researcher and authors and also for those uh building applications and infrastructure um we can use some more clarity on evolving process this week etherum C ERS published a pep and video on EIP 5069 with the editor Sam Wilson where Sam has explained a high level proposal of working group which we will be

hearing more in this meeting and perhaps collect editors thought on this to decide what are the next steps on that and uh some of us here may also know that we are also looking for a rough consensus on how we would like to render ethereum standard we we need one website for all standards or we may need multiple websites one for each GitHub repository and yeah what is the best approach here I'm hoping to get a resolution on that as well we also have some issues and PR and also call for inputs added for today's agenda that's on High level what we can uh uh discuss here in today's meeting

hoping we get enough time to discuss all of them so I have been redirecting people to follow the EIP meeting to learn and uh contribute to decision making of the EIP process as we can see there are a few new participants on the call for them and for everyone following this call later I would like to begin uh this call today with a brief high level overview of where we are and perhaps uh share my vision also to see how we are taking it forward so um I have added the first item here as high level overview and that is a presentation so let me

quickly share my screen uh so uh this is like uh we are going to just talk about EIP ERC and rip uh standardization so what we had in the past is like one unified website e. ethereum.org we had one repo which is ethereum eips and we have set of editors called EIP editors although there was a split in uh having EIP and ERC editors we had unified tooling EIP W ebot and other Bots and data analytics with eips inside why we made this split because there were too many ercs with there were too many PRS getting on ethereum eips repo which was

not very convenient for people who have subscribed to that and also cevs wanted to have their say on EIP process especially which is directed towards the core eips and this would also lead to an opportunity for ERC Community to evolve so what we can expect here is like we have a unified website I know there is u a discussion on that as I mentioned earlier like would we have one or more but assuming for now that we have one website and uh we can have independent GitHub repos for like eips we can have ethereums for ercs we can have etherum SL ercs and similarly for RPS we might need EIP ERC and RP editors and of

course customized tooling and unified data analytics website for that so as most of us may know that uh at present our eips are basically divided into type and category the definition for all these are available on EIP 1 meta is basically for decision making and process information are for other informations that are provided and a standard track contains code networking interface and ERC all of those those were earlier registered to the ethum eips GitHub repository and when we look at a proposal when we look at it EIP that is basically divided into two parts one is called Preamble in which we have like some standard set of information provided which in most of the cases are

unique sometimes they are overlap but in most of the cases are unique and those are being helpful for uh tooling websites those are available this body structure is what actually defines the IPS and I hope that we can perhaps make changes on the body structure so this header the Preamble header is already defined on EIP 1 people can take a look at it and it sounds like this is like fair list of um uh headers which we can have on um every set of proposals and like on every GitHub irrespective of type and categories these are the set of statuses except idea because idea is not trackable under any rep repository we

have seven statuses my hope would be to have standard statuses except the statuses could be defined by the working group or who would want to move onto certain status depending upon their independent criteria and this is like the high level structure of how we move around eips eips go under draft review last call and final this is the standard uh moving statuses and then we have other defined an EIP one again so we recently saw the EIP ERC po split it happened in October about a month ago what changed there is like

earlier we had this eips GitHub repository but we kept the type and category same what I would like to see in future is like we make minimal changes and see where we land up so now we have two GitHub repositories one is eips and another one is ercs all under the github.com ethereum what we have here is like meta and informational U again that is there with eips repository and under standard track we have interface networking and core we have moved the ERC section out to the ERC repository however there are certain interface level um proposals which are also used by ERC so people

would like to discuss um that on the ERC repositories as well so we have kept this U category for erc's as well and we will have meta and informational of course needed for it so this is the present uh REO split status and uh with the status is because it is a clone like the ERC repository is a clone of eips repository and we have been doing well with the moving ahead with the same statuses that we decided earlier for eips there is no change as such no noted change as such now uh people may observe that we have an addition of RPS a new repository has been created so

what I am hoping to see here is like an addition of an additional category called RPS under the standard track this will not disturb our current uh framework and like you know whatever the earlier eips were there we do not have to make any changes for them again will have almost the similar uh status type but of course the rip developers may decide on when to move from one status to the another status so now our GitHub structure looks something like this we have GitHub SL ethereum and under that we will have we have three repositories eips ercs and RPS now we can have meta and informational common for all of them

except we have specific categories added for uh different repository and this is like for eips it is mostly for protocol client teams this is for application projects and this is for layer two projects um now when we have gith repository separated we understand what type and category proposals we get in it is important to have editors we do have editors for EIP and erc's but I am not aware of rip editors it would be really helpful uh for authors uh to get the list of RP editors maybe we can work on that and we will share the hcar and Carl mostly okay

then I will go ahead and update the editor sheet and have them added over there so we talked about working group working group is has been proposed in this EIP meeting for past few of um few times and it's it seems to be like really helpful so um I'm hoping the working group will be with respect to repository so we have three different repository eips ercs and RPS so we will have working group accordingly and as we can see that there are already meetings going on for core working group most of the things can be decided the proposals can be decided on all cev meeting however the governance will be something

that can be taken care on in the EIP IP meeting which we can talk later on as of now we do have all wallet Dev meeting um for wallet related proposals and we have all ERC Dev meeting for ERC related proposal and similarly we are aware of rooll call meetings that goes on for rollup uh developers so this can be the rip working group and um who would be like participating on these working group and what this working group will be uh doing more on that uh we will get to that but first take a look at the website for users who are looking eips from a distance they see the website like this all core

networking interface ERC meta and informational um I would hope that this would not change for users for looking from the distance and we will just add the rip here and if we take a look it would not matter much because the first uh thing that if we click on each of the tab what we see is this thing the number the title and the author and depending upon the status what may change is the inside of it the MD file may change for this particular section the Preamble we hope that it could be consistent and there should not be a problem with that but the table of content will be controlled by the working group so let's

go back to this uh the structure of the EIP again the Preble we can perhaps maintain to have it uh consistent all over the repository and this body structure could be decided by the working group so for example if people do not want to include test cases or reference implementation as a part of their EIP or they would like to add for example upgrade name uh for core eips they can make the modification in this body structure of the EIP and that can be updated into the template um file that we have for every eips so the Preamble will remain constant and working group will decide the content of it now let's take a look

at the governance side of it like EAP ERC and rip I'm hoping that all should be governed uh with with the help of like this group meeting at EIP IP level so for governance again it would be based on the uh GitHub repositories that we have and if people want like if this working group people want that they would perhaps have their separate subw working group um like for example for ERC they can have ERC nft group they can have ERC SBT soulbound token group and similarly for core they can have core e core CL if it is like decided by the working group that's totally optional and uh what working group will do I know Sam has a lot uh with the

charter and I hope that we will cover that right after this presentation to understand how he wants to look at the working group but on a high level as per my understanding what I have added here is like a working group will be consisting the GitHub repo editor the editor associate and reviewers that will be added with the help of Charter um that we will learn more about it and what they will do is like they can uh control the template of each of the um repository like what to include what not to include and they will also decide on the status criteria when to move from one status to another status they can do a micr level governance over there they can accept reject pull request if they want to include final proposal in or not

kind of thing and of course they have independent meeting they can perhaps discuss those proposals in the developers respective developers meetings to make decision on them U I have added an example over here like what can be the criteria so for General if we say that okay a draft when proposal is uh proposed bya PLL request for review when that is ready uh and for last called generally that is 14 days but it varies in case of core proposal so this is just one example so if we want to be more specific about it we can perhaps go for core in interface networking informational or depending upon whatever the um category of The Proposal is we can perhaps decide uh

this thing uh the status what will remain constant irrespective of GitHub repository I hope to see like unique proposal number allocation right now what we are doing is EIP number is being allocated both for EIP and ERC maintained by a Google sheet among the EIP editors they um they coordinate there and they add uh the numbers and that could be um Extended to rips as well if uh we would like to coordinate here I'm H I'm hoping to see it same over there then again we can just live with one. ethereum.org I know we have this thing added for agenda for the discussion if people don't agree fair

enough it's just a proposal and we can have almost a uniform tooling BS data analytics and everything else for micro level governance as I mentioned we can perhaps use EIP meeting and we can have like call for inputs discussion final EIP discussion and any coordination related to tooling is needed we can perhaps do that um uh so we already have covered like we would love to see Preamble common status common tooling common and everything else there are certain eips which are going to be uniform EIP 1 EIP 5757 EIP 5069 and am aware that people are willing to have erc1 and rip1 kind of

thing but I hoping that if we can have one of the um proposal as EIP 1 I will explain it later why we needed one and it would be really nice to have so for having just one um IP 1 what what needs to be appended if we take a look at the current EIP 1 this is how it looks like the table of content so this contains the information of uh how EIP should be written so these are the highlighted areas where I think it could be a part part where we can append it for example this is like a special requirement for core EIP there are two ways to go about it either we can move these uh special requirements or anything specific to any particular type

of per category in their respective read MD file or else we can make it a standard and have it added over here why I am hoping to have only one EIP one because if we have erc1 it would be mostly a duplicate of that so most of the contents will remain same but we will change very Minor Details so it would be really nice to see either everything added to EIP 1 back link to where whatever respective repository readme file is or add these specific things to the respective readme file so EIP format and template so here we can add like okay for if you are proposing an RP the template is available at rip uh M uh template. MD and we can back

link over there that's one way of it so here simply this is um limited to core only it can be either moved to the readme or if we have any specific for any other type and category we can perhaps add that bottom line is we do not need to like exactly copy paste too much we can perhaps move data depending upon the consensus we get here by the AP editors uh to make sure that we have only one EIP one I have added this as an example of like if we want to have a the uh EIP status decided based on the uh type and category there are very few changes either we can add these changes to um respective uh EAP respective readme file or update on

the EIP 1 itself I know this will not contain all of them so I have also added this thing here for people to leave comment and feedback that is reviewers uh sheet that we are maintaining for active EIP reviewer and uh uh ERC reviewers I'm going to add RP reviewers here as well for people to refer to but if people have thoughts we can perhaps add it over here so I I did mention that why we need to have only one EIP one so of as of now we see EIP 1 uh is also available on ERC GitHub repository so when we are looking at tooling it will be like duplicating the same thing okay EIP one is here from the um EIP GitHub

repository and it is again here from the um another GitHub uh GitHub repository which are there for erc's so for that purpose my uh hope is to have only one EIP 1 and yeah uh I just wanted to uh share this and maybe open to questions if there are any I know I see a lot of comments here um but yeah if anyone has anything to add share agree disagree yeah I think that's a a great summary of where we are right now that's awesome thanks for putting that together sure yeah that's that's wonderful I I really uh appreciate the effort of uh

putting it is much more more clearer um I I do have a few uh clarification question um that I like to maybe leave on the uh on the comments were asked on the spot um but uh what is the best way to um further the discussion on this I mean if there are questions that you think that more editors input would be required we can perhaps take it here we can spend another four five minutes to finish up this thing and then we'll jump into the uh working group concept otherwise I'm happy to respond uh both the slides as well as the the Google sheet that I have shared are on comment mode you can add it over there and we can respond it

there yeah yeah cool um I think one one of the first question I have is that uh um if we are going to have um ERC meta and and er EIP meta um and I'm assuming based on meta's policy with regarding um they will be imposed specifically within that repository um I'm a big fan of having a one unified uh website but uh also in that website do we plan to show or how do we differentiate it is a mattera for ERC or it is a meta for e and also uh EIP one uh in your proposal which I'm also in support of the being

one uh EIP one for all um how do you show an EIP matter uh that is applying to all these repositories um yeah that's true so as I was sharing this um uh rendering here it can be managed for example here we have categorized based on the type and category So Meta and informational are here as you can see because EIP 1 is added on both the repository as meta the number one is being duplicate here so say for example we decide on a process for ERC and we make a meta for that particular ERC that will be shown here as well um on

whatever it is it it does not matter um which depository you are saving if you are creating a meta for a process it will be it could be displayed I mean uh can they uh is that intention that's a different uh report will have their own policy making for example like I I mentioned some core deps really want to have consider for inclusion and it will appear on the EIP side of a meta policy as yeah that's right yes okay okay yeah um I think I I can I I I understand that and then um yeah um

thanks for for that awesome work um I will um continue to ask clarification um offline with you and also maybe comment on I I'm really appreciate that this is very clear thank you so much I see a lot of comment over here uh any specific comment that we can perhaps uh respond to I see um yeah some people are in favor of eap1 that is good thing to have yeah I was just saying if so EIP 1 is like extremely hard to get changed um so like I think in terms of just practicality if you want to it might be

just much simpler to say like add in your link in E1 to another either ERC or rip and having the process defined there where uh it's linked in EIP 1 but then you don't need to actually bug everybody involved in EIP 1 every time you want to change that um so you can have just a section that says you know for descriptions of the rip process the rip 1 2 3 4 or whatever um link it in EIP 1 so it's easy to find but then the authors of rip1 234 are the ones that need to be involved every time there's a change rather than all the authors of EIP one um because yeah that can just be much slower yeah that's pretty much I'm

trying to advocate here as you can see I have tried to put put it together like the generalized what we can add onto EIP 1 so if we are having status defined on EIP 1 we can just add a sentence over here please refer to respective readme files of eips erc's and rips and here this eips MD or whatever it is sitting there for read me file for respective repository we can link it back and people will be making changes at there and it would not reflect um I mean people don't have to update E1 again and again yeah that makes sense very well all right um so I think if this is helpful we can perhaps go ahead and try

to take a look into the working group that is being proposed by Sam Wilson I have also added the GitHub link and how Sam would like to uh see it rendering on eaps FYI Sam if you would like to take it from here and maybe um explain a little bit more on the concept of working group how we can perhaps manage it from there sure so um out of everybody here who's already looked at e. FYI if it's low I will run through it quickly and if not I will just skip it all right I will assume nobody has looked at it okay um so the general idea I've been going on like with this is that um so people want their own processes

for their own uh like groups of proposals cord devs you know want to have uh want to get rid of last call and have a considered for inclusion and you know ERC devs like having last call um so that uh the approach that we took originally on this is to just split the repositories and let them evolve separately but um Greg uh koven objected to having separate organizations and wanted to keep everything under the EIP editor like umbrella I kind of agree with that approach because in the end they're all documents so I've come up with a set of tooling and uh governance documents that describe uh working groups so I will hopefully give people a little run

through on what working groups look like uh so it's all built this is all you know running code um yeah so it looks pretty much the same as uh it used to um please ignore the empty content I just haven't written it yet uh but uh yeah so this is built using a completely new pipeline uh but it looks exactly the same uh you can navigate through your proposals um they all render you know roughly the same as they used to borrowing a few bugs here and there uh but the important part is this so each working group is its own website

completely separate from the others they all get their own subdomain of ep. FYI so this uh you know lets each group evolve separately they can have their own templates they can have their own uh rendering system they can have their own ew rules everything is completely separate uh depending on which uh working group you go into uh but they all render and look like it is the same website for the most part um how I get rid of this thing go away go over there perfect okay uh so a little bit of run through of the actual code um it's divided into uh a series of Eeps WG uh repositories and each one of these map to a working group um and then

there are some supporting repositories uh we have a pre processor uh a registry uh a theme doesn't really matter what they are um I the important ones here are the registry so this is how we would assign EIP numbers to new proposals um it's just a big long CSV file in git uh we also have the pre-processor which takes our somewhat custom markdown files and turns them into uh something compatible with Zola which is the renderer I'm using for this uh there's an automated script for doing the import from the existing eips structure so that's all automated uh and we have a theme and some build files not going to go into those um so that's kind of the technical structure of of working groups

which may or may not be interesting uh I don't really know what you guys care about but on the governance side we have uh kind of this Charter document so uh let let me let me actually describe the working groups that I'm envisioning first so Eeps WG Eeps that is the working group concerned with the pro of Eeps so right now we have meta so that's what this is uh Eeps WG core is uh stuff concerning the um core Network so networking uh core proposals that kind of thing Eeps WGC is exactly the same as what it is today and Eeps WG wallet would be a new working group

concerned with Json RPC and related proposals um this one is obviously new um and it's kind of coming out of my work with uh all wallet devs uh the other people who would be interested in probably becoming working groups or maybe the nft uh community and uh rips would probably be another working group I just haven't uh created repositories for them yet I'd also like to say I probably should have said this earlier this is all prototype it hasn't been approved by anybody this is just throwing it out there for your consideration um yeah so going into the charter so each working group will have a charter and the charter describes the scope of documents that that Charter is responsible for uh it describes the

statuses that uh proposals in that working group move through and it describes the um the Preamble so uh you know header like withdrawal reason those kind of things and then you define the sections and stuff of the body so each each working group gets to Define their own Charter like this these Charters all go into the uh Eeps WG Eeps repository so um to your question earlier Victor uh there wouldn't be a meta category for each working group there would just be one meta category for all working groups um and then that keeps everything organized and separate um and then uh there was some discussion in the chat about who gets to approve changes to these documents so the members of EP WG

Eeps again that's the meta working group would be the EIP editors so any changes to those documents would be approved by EIP editors uh changes to any documents and any of the other working groups would be approved by their membership ship uh each working group's membership would be defined in the charter for that working group it's down here somewhere so for example in the Eeps WG Eeps um working group it's just defined as the EIP editors uh core for example might say uh members must have a working client or or something along those lines that's up to each working group um yeah so that's kind of the overview of what I'm thinking for this um does anybody have any thoughts on

this does this seem appealing does this seem way too much yeah I like the idea that's working GRS are the one and then I'm all for having one meta for it seems if that is the case we need to update the Quia diagram which separate the uh meta into boxes of each one um so maybe we need to align or clarify that um that said I think you mentioned that EIP editor will need to approve um um EIP 1 and um I think um in the governance side slide of Po's proposal that they will in the future

have uh different ERC editors group and EIP editor group uh if that is the case uh should an ERC have its own erc1 uh or should an ERC has its own kind of VC major meta so that they can impose policy separately um so that's that would be my question so in this design there wouldn't be ERC editors there would be one group called The EIP editors that handles like defining the policies and everything and then each working group has members so you'd be a member of the ERC working group and those members get to manage their own proposals I see um that's great I I I

find that uh in the in this context EIP editors uh applies to all the entire thing and then um if we still call it it kind of felt that EIP has two uh two meanings in this sunet right now either it covers ERC or it doesn't cover erc's so maybe it would be good for us to kind of give it a name to so that people won't be confused that this applies to everything thing and also editor Supply to everything it seems or maybe we can just call what's in the EIP repository the core eips and then we always used it yeah so EIP editors would be um as

defined in 50 or 6 5069 sorry so it would be like the governance file like the the list in E1 right now and then ERC me or uh working group members would be the other term so editors would be one term and members would be the other term okay that makes sense could we maybe uh have a soft expectation or a cultural expectation that each working group have one EIP editor on it just to make sure they the two layers stay aligned yeah so I think this is like way out in like the future I haven't thought too much about this but my my current loose plan is that each working group starts with just one

EIP editor on it and then that EIP editor can choose to add members as they say see fit makes sense just just just like uh just to make sure I understood the presentation right is uh the the pre-processor and the Zola publication that's all built into the the of each working group's repo so if you Fork uh if you uh you know clone one for rip P they just automatically get an RP Pipeline and they also get to use the number picker and all that yeah so there's uh one so each uh repository has uh a GitHub action that uh proxies to a

common GitHub action for all uh working groups and then um yeah so you you clone the template you change your um a few like uh placeholders with the name of your working group and then you're all set to go uh followup question how quickly could this be approved I love this can we just use it is there any reason not to just use it so there are some technical things left to be done um the number picker isn't built yet EIP review bot isn't modified to work with this um and I haven't written enough governance documents yet uh so there's that and then we have to get Buy in from the rest

of the editors which is kind of why I I think we're presenting it today okay I I volunteer to help with the government's documents if uh I don't know if there's Buy in on this enough Buy in on this call to to keep going it will be interesting to hear thoughts from other editors on the call like what do uh people think generally about going in the direction I mean I think all of this looks very

nice my only comment maybe is do we need all this process like we're creating kind of a complicated structure with lots of documents and procedures and I don't feel like we're I don't feel like it's as important right now like we're not I don't feel like we're getting overwhelmed with you know lots of people doing things that's not progressing forward where we need to put structure in place to put them on Rails I feel like more we're spending a lot of time on process and less time on just editing things so I 100% agree with you there um

the uh like whether okay so I agree that we have way too much process there are currently seven EIP editors and we spend you know an hour every two weeks plus whatever time editing and like this has been my full-time job just making this prototype for like two weeks we spend way too much time on process for how how many people are actually doing editing um but on the I think uh on the flip side we also have groups that are you know coming and starting to uh self-govern and it'd be nice to preserve their documents in the same way that we preserve core documents so that's kind of the tension that I'm feeling right now and I feel like when when we have these documents in place I understand

that it seems like too much of work because uh there is something changing here if we create these documents there would be other groups which will be like you know help helped and maybe using these documents for their references as I mentioned in the beginning of the call that I have been roached by few groups to maybe understand how they can make contribution uh I'm happy to uh mention here like we have been joined by a couple of members of 4337 group here to maybe see how they would be helpful to um make contribution to the EIP process and how to make sure the researchers comments are being Incorporated by EIP author so there are a lot of things we are having it in different places what

we are trying to do put them together in form of documents so in future if anybody would want to do something we can just refer to them towards these documents so it's one time effort in my mind what do you mean people who want to do something so for example um there are a few uh people um at ethereum caters Discord we have integrated a channel especially for 4337 people like there are multiple eips with respect to that particular proposal and some um curve related proposals so if they want to make sure that their proposals are getting in they are getting proper feedback and including the feedbacks from researcher and they would like to incorporate that in their EIP to make it

a standard to be followed by other projects they know the process we can just direct towards them they write guide to follow and share their proposal to us for EIP or ERC or rip editors right I mean I don't really see how this working group process does anything to affect that like these could be three completely separate things and they could just say hey we want to do this curve and then someone in the Discord could say oh yeah you should make an RP like there's no need to develop this process around all these things if that's what we're trying to solve uh that is one example working group is there to Define what people want of that particular group and categories for

example core people want to have their different set of proposals I have been informed about another proposal for core which is called versioning eips kind of thing we do not have the presentation group here today but perhaps we will have it in future EIP meeting so if people want to have their own design for Core Group they decide the working Core group will decide what they want to put in on their side of uh proposals similarly for ERC if 4337 wants to contribute to ERC related working group they can do that so this uh Charter is just trying to Define an outline for for these working group now working group will take care uh of the responsibility of what they want to keep it in like

their governance process will be managed by themselves but we could also just let them manage their own process without some kind of overarching structure around it which is what I originally wanted to do of course yeah I mean that could be done it's just that we would love to have any sort of documentation if if a core group uh Core workking Group do not want to have so many processes they can just Define their process wherever they want to and have it link to EIP one so people can follow well I think I think what you're saying Matt is that we can do all of this without having the EIP editors sitting on a throne above everybody else right yeah I mean if there is need for

that structure and I can imagine a world where there is need like I can see where in a couple years there are lots of people who are trying to do things and we need this these rails for them that makes sense to me and so I'm like hesitant to say like we shouldn't do this but I also know that right now we don't have as much of this need and like I am generally wanting to go to something that's simple because I feel like we spend I mean yeah you said it we spend a lot of time debating how to do things and less time like actually just doing things so I would rather come up with a framework that just is extremely straightforward and simple where we don't have to debate things we stop having this mentality of changing the

process like the process is the process and we work and live within it for you know as long as as much as we can yes I think we're we're on two ends of the spectrum here so one is like process maximalism which is what these working groups are and then we could have process minimalism where it's literally just anybody just makes a repository and can track their documents however they want and I think both are fine but this Middle Ground where we are right now where people obviously aren't happy with what we have I think we need to get out of that yeah and I mean I'm not against process maximalism if the energy the effort required in making the process

work is not large like I think it's good if it's very clear if there's a lot of processes it's very clear how everything works but I'm afraid of is having very complicated process it requires many calls lots of people to make decisions about things and then we're just like creating lots of work and that makes sense when you have lots and lots of things that you need to figure out and you need that process to work through all of those problems I'm just saying I don't think that we're there where we have so many problems that we need like very detailed process to solve and so I don't know is that's a question does the process that you're coming up with is it something that is

sort of can run on its own without lots of like heartbeat calls and management or is it something that is going to need a lot of that I mean I could speak just to the wallets I talk to through wallet connect and Kasa and they're they they see this as a process of uh opening a PR on the EIP process is the one and only option um talking to people beforehand is a waste of time peer review doesn't exist like I do think that the reason erc's are kind of messy is that they're they would benefit from a process to you

know some sort of pre- discussion before just opening a PR and making more this is not going toix that I can promise you this will not fix the inability of people reviewing things peer reviewing things what I do think this will fix on on that note is EIP editors can stay ideologically aligned and working group members can be whatever they want so we'll be able to get people who aren't aligned with our ethos to review things and Define their processes uh without having to worry about them affecting uh the guarantees that EIP editors provide so you're saying you're trying to

separate the concerns of EIP editors right now where editors are both sort of dictating this process of standardization and what the values that are should be held with respect to that as well as the actual process of accepting and reviewing standard proposals as they go through pipeline exactly so it's like working group members are technically knowledgeable about their area and they can review proposals but you know they don't get to decide or influence decisions on whether um we allow external links or or whether um a DOI is a sufficient way to reference a document

like we can have our policies about preserving documents for historical purposes and then your uh working group members can decide whether a proposal is technically sound and technically sufficient I mean once once this architecture is set up how much work is going to go into process versus just straight reviewing stuff and you know actually doing the thing that the standardization process needs to be doing I think the people wearing EIP editor hats will no longer review documents and the people wearing uh working group member hats will be reviewing documents and not thinking

about process do we feel like we have people who are going to wear these working group hats because I think we've tried to get people to review these different types of things and they don't seem to exist and so I'm like wondering where they're going to just come from now that we have a name for them so we have um Kyle from Brave who's very interested in doing wallet related standardization we have onar Carl that want to do rips um you know we have U who wants to do Corey IPS so I think there's there's some people at least that are interested and Kasa is kind of doing this already like I I think a lot of the

stuff happening in kaso would be happening in the wallet working group if it already existed to be honest and there there's plenty of uh reviews I guess that's a good question would cassa become a working group or is there at least a path for that uh I mean Kasa is currently a uh I mean it's sort of currently a grab bag that has a few working groups in it some of which could just be the wallet working group um and a lot of it is sort of offchain or or multi-chain like non-m so that probably would it would some

some parts of Costa would still need to not be in here but I do think that yeah like the RPC stuff a lot of the stuff should be here um and like I said wallets people you know companies that make wallets uh even more so now with 4337 don't really know where to go like there's this confusion about how the EI the the broader EIP process could work and I think it would you know I do think those people exist because all of these wallet companies have Dev teams of like four or five people and I talk to

them a lot through wallet connect and they have opinions and want to uh have assumptions in common interfaces in common they just don't really know how to start so maybe begin the work and see where we are after um a couple of months how about let's start with the concept of working group with uh the four broader category that I the four broader working group that I shared in in my presentation slide for core there would be only one working group which is like core working group and that will include EIP editors for code and uh if anyone else wants to be reviewing it they can

be added as associate reviewer or maybe uh the working group uh member they can be a part of it managing that particular working group and most of the decisions making uh with respect to EIP could be taken care by the code of meeting that we have similarly for rip anskar and car are already there for taking care of that I'm happy to have them added as editor or reviewers depending upon if we would like to add them as editors we have a certain formalities to be done uh that that can be done like adding them to get the notification of P request and everything think we can perhaps take care of that and let them uh be informed about the process how to be added as an

editor with the help of 5069 EIP and they can follow that that would be onetime job and they can do that similarly for the ERC category we have at at the moment two groups those are active one is for ERC um all ERC developers meeting that can be one working group and another is wallet developers meeting so let's begin with these four broader category of working group and maybe get back to to working of more than these um in a couple of months what do people think about it Victor just volunteered in the chat to

help oh yeah Victor is already leading the all ERC developers meeting uh I think this meeting happens uh twice a month at a different time to maybe include every participants from all part of the world so anyone interested to be a part of that for ERC working group perhaps they can connect with Victor and join the All ERC developers meeting so is the like action item from this to maybe come up with people who would be interested in participating in the working groups I think both I think we will need people who are interested and also people who other people think they' like to be a peer of like uh they want to know that uh if they are committing time

other people that they're committing time with are also who they they like to work with so I I like to put up a few names and for you guys to review and if if you think good we can go ahead and and and and kind of see if they can make commitments right so what we need at this point of time people who can review proposals coming up in independent GitHub repository for e we have a definite set of EIP editors and Associates so I'm hoping that will be covered and we will be getting the proposal reviewed as by them but if those editors and reviewers thinks that there should be a process change they would like to change something here and

there from the existing one may be able to document them and then share it in the uh upcoming EIP AP meeting or maybe document it wherever they do not need approval from anybody else except the EIP editors group over there similarly for for ERC they can do the exact same thing we need people who be able to review the ERC proposals we have a bunch of ERC uh PRS open I know Sam reviews and um Victor also reviews and Panda paper also reviews but we do have a lot of open PRS we would like to like decrease the number of open PR so we get people who be able to review let them be added as reviewers editors Associates or working group member whatever they want to do but just inform how we can

maintain it like right now I I have created this Google sheet for people to maybe keep on adding and then if they are being added as editor we would like to let them be listed in EIP 1 as well we'll make the changes a step by step so that would be my number one ask from today's call and the number two ask would be uh about the uh web page rendering thing is it okay I see this is very much possible that we we can perhaps represent the proposal uh on eips do ethereum.org ex we can just add our RP uh tab over there we can list the all rip thing the high level U representation would be same there would not be any change to the end user except for the MD file if any group decides to

change from the current format current template sounds good okay um so um I'm just trying to take a look at at least we should cover on the number one agenda item and uh there is one other thing left on that is the updates from pending task for repo split if I don't see Pand on the call but we do have mat I'm not sure if there is any update for issue number one on ERC giup repository with respect to migration that people would like to share

today I have not done anything I don't really know what the latest is I loosened up some ew restrictions that were causing problems but that's that's about all I've done so far and I'm hoping yeah is it even working right now in general merging erc's uh about half of the merge I don't know why the other half don't so there was this one issue that was highlighted in yesterday's meeting uh Sam uh if there is anything that needs to be done um with respect to some of the poll request not merging automatically like can anybody do anything about it I'm sorry Sam if you may be speaking

you are on mute oh I I have no idea what's broken sorry all right no worries um maybe we can take it with panda beep let's see his response on the Discord Channel if he gets a chance to look into it um yeah we have about 3 minutes left for this call anything uh from uh today's discussion that people would like to maybe uh say that they they are strongly opposed and they don't want it I think the decision so far is Clear we will be going ahead with I mean I'm just repeating the decision if there is any change people can mention that uh maybe four working group as mentioned we

need editors we need associate editors and reviewers and maybe a working group members to be participating for the managing of uh the pull request coming towards the individual repositories and one of the biggest thing that I think I would like to get a green light from Matt on this one specific because it seems like Panda and Matt are on the opposite corner of this uh so Panda wanted to have a unified website and people uh from codev including Matt wanted to have a different website so it seems like there is a way in which we can perhaps have a unified website but represent their

content on on their specific GitHub repository so should we go ahead with that and we continue doing it I mean how does it work in what Sam built uh each page renders to its own subdomain so they they are separate websites but they all link to each other but yeah but if I want to update my working group like where does that live in your working group okay I mean I'm not yeah that sounds fine I don't think that they should all be on ethereum.org like if I link to an rip it shouldn't go.org I feel pretty strongly we should have subdomains for

each working I don't know if each working group but at least Eeps erc's and r IPS and then maybe we have specs. ethereum.org which links to each of them plus the the python spec or something so to be uh completely transparent I'm actually proposing that we use ep. FYI as the root domain for this not ethereum.org um and then we could have specs. ethereum.org or something point to that so we would nuke do.org basically uh yeah it would just be so I have a a program that can do the bounce redirects like from new and other than that yeah it just be dead oh why yeah I feel like I did this

because like core dos. ethereum.org is stupid so no but you just do Eeps and then you do erc's but yeah but that it doesn't really line up with the rest of what like they're not grouped appropriately yeah yeah I mean my alternate proposal here was like we keep e. ethereum.org but we keep tabs like right now we we have types and categories so what we are basically doing is adding one more category rip and we keep it as is being displayed there just add another tab it would not yeah I mean that that's what I proposed except the tab just links to a sub another subdomain which is a separate website that that is also doable it it can be done over there as well redirecting tops. ethereum.org

yeah I mean I don't know we can debate the what to do with the EOD FYI but I think we need also need to solve the problem today and each working group is going to definitely be its own website in my Approach like there there's really no effective way to merge them I mean but are we going to have working groups that have different that use the same prefix because so far I don't see any each working group has its own prefix yeah so then I don't see a problem with e. ethereum.org erc's ethereum.org yeah but then then you'd have like core. ethereum.org and like why we just

ecore like it is today like today we have ethereum.org cor I mean we could but then they wouldn't be separate websites right they'd all have to go through the same rendering pipeline at the end I I still don't understand Eeps is core so why would you need core again because because e GitHub repository contains networking interface and core and that also contains like you know meta and informational but I mean those are all core related proposals but these can be Pages rather than subdomains and then if erc's have Meta Meta ercs you just do erc's do.org Mela right like we do for core

now and I think that would work no yeah but again they wouldn't be separate websites that's one of the things that m you were very strong well they well they would right because they'd be e. you'd have e. ethereum.org meta and then erc's a.org meta right but they can't be rendered to separate websites that way like the way GitHub Pages works oh they have to be one website so you'd have them all render and then you'd have a parent one that renders them all together in one one chunk so they wouldn't be separate I mean I I don't really understand how exactly you've set it up so maybe what I'm saying just doesn't make any sense so if you look in the chat here like

doing specs. ethereum.org cor and specs. ethereum.org erc's to do that with GitHub Pages they all have to render from one repository right but so whatever is in this the same subdomain has to render from the same repository right correct yeah so this means if all the erc's are in the same repo we can do erc's ethereum .org that will only render the erc's and then we can have slash for what for whatever subcategories and then we can do the same thing for eips so we can do ethereum.org cor and that only renders the core ones within the eips repo so I think if

they're all in separate repos that would work where basically then you'd have like wallets. ethereum.org right and that's yeah that's that's fine if we want to go that way but yeah Will wallets have their specs where do the wallet eips live will they live in the ERC repo or will they live somewhere else so the repos reflect the governance so at least in my proposal so if the wallet group is separate from erc's it would be in a separate repository I'm also late for something else but um all right right so before everybody hops off I just want to go

over two calls for input uh there's 291 which is adding security considerations to ERC 1271 please leave your comments on there and there is also um removing uh external reference implementations from erc20 that's issue 287 uh that one's past its deadline but I am unclear of what everybody's opinion is so please leave comments on there as well and there's one last one which is 293 and that's merg flaws in ERC 20 just go leave comments on those please thank you well thank you everyone we can perhaps continue discussing any there there is any more questions needs to be answered on the Discord async and yeah

thank you everyone for joining us today