EIPIP Meeting 86

Transcript

okay so first up we have the semi stagnation of last call eips it's a proposal by Panda pip um which is saying uh suggestion that we move last call eip's back into review uh if six months has gone by since the last call deadline um I don't know if everybody has any opinions on that if you do leave them in the pull request uh similarly there's strength and wording of status update aprs uh this one looks like it um limits the content in status change pull requests to only the status change

again if you have any comments leave them in the pr that we have changes to final proposals um these are mostly formatting changes I don't think there's anything we need to talk about here yeah they're just formatting changes so I'll take care of those um then we have update eat one add numbering guidelines if anybody wants to talk about anything just jump in by the way I'm kind of just steamrolling through these um this is non-controversial not not worth having depending on personally yeah okay this one

um I was hoping people who have already been dog fooding this because I noticed on the Discord there were EIP authors already asking for access to a Google sheet and stuff is anyone who's working with those authors uh reviewing this to make sure it's cleared up or maybe none of them are on the call I don't think any of them are on the call yet okay um yeah so I have some comments for this one but I don't think Panda pip is here

so I don't think there's any point in me talking about them I will leave them on the pull request then we have the split [Music] um yeah and that's uh probably the rest of the meeting there so um I have nothing to say about the split everything I wanted to say has been said so I'm just gonna sit here until people who want to argue show up uh also people who want to say anything other than our good girls are welcome here like if

you know just operational stuff if this should be updated because of anything that's happened in the last two weeks I'd be a might be a non-confrontational way to proceed let me say what's non-controversial for me um although it may be controversial for others um the one the one thing that's just absolutely blocking for me is that we remain um we remain a single autonomous editorial organization

um splitting up the organization into more than one editorial organization just is not at all what I signed up for as it were it's not at all um the vision that we were working for um back in I guess 2017 2018 um so it's it's partly that and partly just that I don't I don't see any good coming of uh taking the various conflicts among the editors creating more than one organization and getting to argue the same issues in more

than one organization getting different answers and different organizations and trying to trying to handle all that we need one organization and that's that's just bottom line for me I have strong opinions on the rest but I can probably live uh with the consensus yeah I think that makes sense I mean in the end it's really just editing documents so I don't think we need two different organizations to manage editing documents in ethereum um

well in terms of like how the conversation has evolved over the two weeks like I I dove into this PR for a little while and commented on some threads and I saw a lot of you know I thought it was 48 uh separate commits uh you know this this has been you've been putting it a lot of time uh fine-tuning this uh which I really appreciate I think one thing I noticed in the last two weeks um sort of an option I personally didn't realize four or six weeks ago was an option was to um have a very strong working group notion like to to interpret working

groups not as one-off uh topics for like us individual EIP but like standing bodies like the core devs could be a working group and wallet wallet implemented implementation group could be a like a permanent working group um do you do you think that that option might be under specified like do do people realize how different the thing is they're describing as the working group when they talk on this

yeah nfts I just clearly like nfts are like half the half the PRS on on the repos that they should be talking to each other it'd be great to force all the interview people to talk to each other uh yeah I mean do you do you feel like that that might be uh um a way to make some progress whittling down the like building Common Ground if people understood this idea of still being one entity but having more sort of like status change power until review or until final be staying within

the working group or something um that's a fairly loose noise notion at this point um um I clearly there could be some groups that are pretty ad hoc their job is done uh no reason to stick around um true the notion of a higher level um a higher level group this Less ad hoc that keeps um a higher level group uh the CL teams Cel teams we don't expect um we don't expect to not have teams at that level they can certainly split off

smaller teams when they want to and clearly protocol is different than applications um they're running on a schedule they've got to coordinate and once something's on the main net it's on the main net there's no there's no going back but um yeah what I've suggested is nowhere near uh as as it hasn't been laid out or reviewed nearly as much as the current split proposal um so pretty much I've I've simply made suggestions part of that PR is just

you know here's low hanging fruit here's good things we could have without splitting um and then uh if we can't come in if we can't come to consensus on those it doesn't seem like splitting will will help that a whole lot and uh I just I just don't see how it helps um so you can get two groups to to argue about those things and and have trouble with them uh still um and I'm I'm nowhere near enough of an expert on GitHub and how the bot works and how people try to use Street Hub but I just

I don't see the point of a two-way split if I look at as Dana left unfortunately uh I think he said he was coming back at 4 30 I think he had a had to pop out to another meeting 4 30 okay I'm on I'm on cesd no that's fine that's fine we should just talk UTC server time uh yeah he said at the 10 minute Mark he'd be back at the 30th Mark as refactoring it's sort of I just really see three pieces there um and we're splitting it in two and it's it's true that what we classify under eip's has a certain status that's

more than arcs because it is the protocol there'd be nothing else without the protocol and the protocol's not working nothing else Works Etc so looking at my EIP I'd be pretty happy to replace a lot of wear I'm giving privileges to the core devs uh I'm giving privileges to working group to just say I'm giving privileges we are giving privileges to the core devs um and we'll consider down the line um weather particular working group should have that level of privilege but some

way for the working groups to be able to handle um and the core devs being able to handle the status changes in their workflow without having to push back on the editors and you know keep complaining that last call is in the way um and have to come back to us if they change something it's the editor shouldn't care where it is as to considered for implementation is it going on that the test nets all of that that's not our problem we're editors we're Publishers and the main eips repo has been the repo

that the editors have been working in and Publishing documents out of for years now that we've we've granted authors I think sort of the privilege of being able to edit directly in that repo and I think at this point we've got so many proposals even on the EIP side that that's unworkable we're just getting too many notifications for too much stuff uh on too many documents so even from that point of view it just seems to make sense to get to get most of the editing flow out of the editor's repo um in in other standards bodies uh the

working groups pretty much handle the documents up until it's time to uh to present them to the the whole Community um or whatever part of the community is actually cares and and actually get them finally published um and in some other groups the uh the working group has a lot more to say over the actual format of the documents if motivation reference rationale is just not an appropriate format fine um the editors don't start concerned

about that but if you tell us what your rules are um we'll review for that um things like that these are not precise they're just things to put on the table as instead of the split it's basically we need to split things up so what's the best way to split them and things have gotten very polarized I think because we're just considering the split um so even if we want to split them up we're arguing um over this this single uh single way to do it when there's really a broader

range of possibilities um so that's sort of my take on it um trying to be as as calm as possible things have gotten pretty heated [Music] um and I've gotten pretty heated because I've I just put a lot of work into this over the years and breaking up the editor's group is just sort of uh I wake up with Nightmares From it um that's that's what it means to me so yeah um okay well definitely um

thanks for thanks for uh pushing on this and trying to iterate this so much over the over these weeks um uh I see the participant let's keep changing I guess people's conflicts are over height did you want to talk about this yeah this PR or other topics uh the the pain relief PR um I came a little later I had another work meeting that I had too I'm also a 10 so I'm double booked of course um so one of the high level concerns I have with looking at yet another approach is we've been in a cycle of looking at yet another approach for years

um and it never comes to fruition it never actually gets to the final step we talk about it we argue the benefits and the drawbacks and no action never happens um so that's one of the reasons why I advocate just going straight for the split leaving the editors in two different groups um you could join whichever group you could probably even join two groups people have disagreements on that but I don't see the problem of joining both groups and they can even coordinate on standards together but the key thing is it's action and there's the more we talk about it the more the less likely we are to ever see consensus specs in an EIP form um we need to act now or else they're

going to passively split and then passive split is going to look like on execution layer specs also leave an EIP process and that is not a good outcome so the pain relief yes let's do all these pain relief steps but that does not remove the need from the split this is not a mutually exclusive proposal I think agreed yeah uh maybe another way of maybe a follow-up question would be um what is still on I mean is this PR in draft or is every little net sorted I mean because this looks I'm not seeing anything I have opinions on still

open I I don't understand much the the lint linting part but other than that it seems like this could be merged and that would help uh close some of the gap between between people um is there so remaining stuff that should be added or changed I still think the EIP ERC split should be resolved first before we merge this and then we can merge this second after it splits and the reason is because the split was proposed first the split is what predicated these and the conclusion from the all core devs Engineers we had a meeting last week we talked about it we asked does anybody feel any different

multiple times and what what what the group being served there wants is two different repos so once we get to two different repos I think we can look at these paid release and see what's relevant to ERC group versus the EIP group for example I don't think the protocol group really needs the working group structure but I think the working group structure would be immensely beneficial to the erc's set of ones and we get one for D Phi we get one for wallets we get one for smart contract patterns I think those would be immensely beneficial for those organizations but the awkward damage group kind of has their own setup that isn't really really quite working groups and it's kind of a square peg round whole thing there they have a process and they just need to reflect in the documents they produce um uh that's what a working group is

sorry sorry don't know you uh what while you were I don't know where again yeah sorry he missed he missed that whole conversation like we my question like actually I think just after you dropped was hey I saw on a I think it was Discord or Discord conversation not not GitHub conversation the idea that maybe all core devs is like a standing working group that's like slightly more official or long term or has different privileges than a more lightweight working group that might be topical and we've been sort of kicking around this idea that like is kind of working run a repo I don't know so my concern is asking to set the

working group standard for the ERC side of the house too high because we have weekly meetings we have very specific processes we have very um nailed down processes and so the other groups coming in think well we can't compete with that so we just won't form working groups or the working groups will form and they'll be held against the standard that is completely impossible for them to meet um if they're in separate groups they can set their own working group norms and standards it might just be an email list it might just be a group of people that review the PR's on a regular basis um when we when we grandfather in ACD as a working group we set the working group standard immensely high and no one's ever going to achieve that that isn't producing protocol specs maybe ACD hasn't created a working group

they've created an entirely separate process right that's that's what a working group is so why do we need a third group above us I think was the other discussion that was on Discord there's like basically little to no value and one of the concerns that I got that I got in the chat from one of the other Engineers um who was in awkward devs was we don't want a hierarchical group over us um and third group sounds like hierarchy we don't want hierarchy what was needed as a peer relationship between ERC and EIP and not a hierarchical group above them we need a peer relationship between the editors the core developers and the many

developers in the community I said I think while you were gone at this point as I understand things I am not opposed to a split um it's as you say like a software refactoring having decided to refactor I want to get it right and I don't think that's a two-way split and I think it's a three-way split at least just get out of eips which is where the where the editors have been working for years it's the directory we work in and where we publish but it's also gotten

cluttered up with all of the editing for all of the IPS and we've set standards on workflow as well as editorial concerns and workflows none of our business the core Dev should have complete control of their workflow we can work with the editors as to the best way to express that in headers status Fields whatever whatever but doing it doing a split what Corian devs don't want they don't want someone else telling us what headers to put in and what format put it in that's what I just want jurisdiction to begin and end there that's what I'm saying editing and everything there's there's nothing above core devs that says you can't publish this then then you should just form your

own editors group and be done with us if you don't want to what the split's attempting to do and that that's that's the core of it yeah to do it right that is my block that there be a single group it's not a hierarchy issue unless you make it one once you've done the split then you get the question of how do we handle the hierarchy that we just created when we discuss our needs on all core devs and then you say you can't do that we'll discuss that at another meeting you've made it a hierarchy issue um what can I say to that um

that's what we're reacting to we've got independent okay I don't want to use emotional terms here but it's the clearest analogy you were sort of saying rather than a clean split we've got a contentious divorce and to me I'm sorry it feels like a hostile takeover um that I hear these complaints and we need to coordinate better you know I think we need some process where the core devs can say things like uh this has to go to final um

and I don't know what that looks like but some sort of appeal um to deal with that um and that's where we lose devs that's where we have lost authors that have sworn off the process how does having one repo really help it's not the repos the jurisdiction it's where we can say in all Cortez okay this has been implemented for years in the clients let's just go straight to final and no one from another group can say no you can't do that you have to go to two-week final call and see if anybody has any more comments all the clients are there everyone who implements it is there they've had a year to comment just because we didn't go through a process checklist to ensure that it goes to

final and we did that quickly on the call to make sure that everyone didn't have an objection that's the autonomy that we need in the process that's the autonomy I think you should have the last basically I'm hearing there shouldn't be a last call I'm going no there shouldn't be um we need those stages for erc's because they're not currently organized enough uh to hand over to DRC to say what's your process so we have sort of a default process the core um we shouldn't say what their process is

we cut they come in pretty early just to sort of snag a number and say Here's a graph we're working on after that the stages are up to the devs um final happens when something is finally on the main net it's final if there's some delay in finally getting that documented and some back and forth it isn't in the way of getting it on the mainnet whatever your last spec is that you work from uh for for actually getting the upgrade done that's all the document you need to actually get it on to the main net so any of working out

any of this it's late sure what we're dealing with is authors who have been subject to that process and I have zero trust of any outside Authority on that and won't contribute so we can say honest will never do it again but they'll say I'll believe it when there's a structure to protect me well then the editor should resign and tell the core devs um we will no longer publish your we will no longer publish your things if if you feel that that you should be the Publishers of them and not let anybody else uh have any say over that you can fire you can fire us Inspire us as Publishers and

create your own group and Encore death meetings you can argue overlink policy um maybe maybe he just interjects we're getting in yeah we're getting to a level of detail I wanted to avoid I guess I'm just wondering what uh how could we still be talking past each other if uh Greg is saying you could set your own status to final without or without the broader group and uh that still feels like an authority over rather than a facilitation role

so what what does this third group do then I mean we can get Seth repo set it up but I want boundaries and expectations what their role is and if they have and if this in its ERC and EIP um has full rights to ignore anything that that the editors group imposes on them then I want that written into the document so the founding group uh just just to be clear when you say third group do you mean the ethereum PM the combined editors between the ERC and the EIP side got it okay um so if they are strictly advisory enrolled to these two processes the processes are free to ignore their

advice then that sounds like you know how a third group could exist but that needs to be explicit not implicit okay let me lay out how how I'm seeing this um these are these are possibilities I've I don't want to get into this well what if what if what ifs um sorry um there's the workflow and there's the editorial standards if we mix up the discussion on those we don't solve

either one I don't think the workflow for the most part should not be part of the editorial process it just shouldn't um we've set up a default workflow and we need that for the erc's because there is no standing group uh to to handle any of that for the core developers there is I think you missed some of this discussion so I'm trying to repeat myself more briefly um the for the core devs um they are different from the erc's in an important way

which is there wouldn't be in ethereum without the protocol um and once something goes on the main net um it's there the behavior of the main net pretty much defines the protocol so the document does need to to describe that but it doesn't need to be inside the editorial process I don't think and the intent I'm sorry but the intent back you know back circuit 2017-18 I think into 19 but I don't want to get a calendar out

um was that final that basically things went to the to the devs uh in draft State and they came back in final State uh and what happened in between wasn't the editor's business and somehow somehow these stages started started getting pulled into the editorial status stages um so to some extent I feel we're just arguing about the use of a status field um and Let Me Maybe This would help what if

so you said that uh working groups as sort of self-governing as all core devs um should have full Reign to add and subtract headers change the options about what the status can be what if all quartets had a status called Almost final and going from almost final to final we're just a a matter of like let's make sure this is you know documented in a way that's really future proof and can just be an immutable could go into ipfs and be useful for five years and that were the only

sort of uh distinction so that if that process takes too long every once in a while everyone in El cordovs is like oh we already put it at almost final we already put it at what we consider in our Orchid group final so like that's just something that one or two people are pushing that last inch of the way for archival reasons would that be within this within the what's imagined by this yes yeah that's what was imagined years ago um so I think on the core dev's current workflow there would be a document called it the mainnet document

um which would be a stage of the EIP where there's consensus that this is what is going into the next upgrade so there's a document everybody's working from it may or may not meet editorial standards um but that's not the point the point is that the dads understand it and can use it to coordinate once it's on the mainnet we do want to publish a description of of the behavior of the mainnet by that point we should have a working executable specification working clients and the mainnet spec and the the final can be produced if there's

some delay it's not a big deal if there's disagreements over editing standards they can be worked out so we need that we need some sort of process for collaborating um I don't think the editors should be um should be in the way of the core devs I understand that I do understand as a Dev that you don't you don't want the editors in in control of whether you can ship um and you don't want to just hit a wall if there's a disagreement about you know

stuff is stupid as um you know whether I'm not allowed to links to something yeah so in that sense that going from what I'm basically calling the almost final step to the final step is really more of a like a service to the other two working groups that are Downstream right like you want to have a version that's nautical and permanent so that when people are designing wallet interfaces or or solidity interfaces they have the you know final it's sort of like uh so then editorials role in that last step is less about making

sure all core debt has passed the right thing and more about making sure that what all cordov has passed is documented well enough to be like unambiguously helpful to everyone else so that makes it more of a coordinating role between the three sort of layers of the stack so let's see why that needs to coordinate across all the layers though like it doesn't right so what I don't really understand the argument here like what what are what is that it doesn't why have it difference that we have there wouldn't be an issue without the split but and I keep saying I at this point as I'm coming to understand it

um I'm not against a split it's like yes we need to refactor things but as a software engineer looking at refactoring if someone comes in and says this has to be refactored and here's how we are going to do it and I I look and go this refactoring doesn't seem right you've taken three things lumped two things together and [Music] it's it's still a problem yeah what is the problem the problem is that we have a repo we've been working in that repo for years and the editors use that repo to do their work

and then we do a split so this repo becomes both the place where the editors work and the place um where only eips are done and somehow the core developers feel some direct ownership over it which pretty much pretty make it makes it pretty unclear who the editors are and what their role is and then we move the ercs out and then they're suddenly abandoned it's not clear what their place in the process is and I'm just going the editors or the editors we've given people the privilege of being able to add it directly on our

repo and by by this point there's simply too many documents for that to be workable even on the course side there's there's just too many documents and people don't need on that repo to be seeing so many changes in the documents the core dads need their own repo where they can take a document all the way through um to the mainnet without without the editors having anything directly to say about it I mean I don't understand why you are just kind of coming up with this saying

this is what they need they told us what they wanted and what they felt they needed they just want to have the repo focused on core eips and separate the applications out that's what the group of all cordov said but instead you are taking that or death so now you're putting the core devs on top of the editors there's no EAP editing without the core devs yes there could be there's no ethereum without the core devs that's true so in the discussions I'm seeing people talking complaining about uh decentralization about hierarchy and this sounds like the core devs I mean

you took a PR to the core devs and if you tell somebody there are problems here's a PR that fixes them do you want us to fix it they will of course say of course fix it um fix what fix whatever problems you believe displaying the repos will fix um I mean there's one problem that is very important to court of that none of these things fix and that's just being able to interact with the repo using the notifications just like they did for other repos like no core Dev watches the IP repository anymore right and because it's unusable it should be like core Dev should have an idea of

like what standards are being proposed how they're evolving this is how they're used to working on the consensus layer specs on the devpdp repo on the execution apis repo there's no reason they shouldn't be able to do this for the EAP repo so what's the problem with the editors keeping the repo they've been working in and the core desk setting up a repo for managing their own workflow and documents we're not proposing splitting getting rid of editors um that seems to be when you say when we don't want the third group that seems to be the undertone that core devs reject editors we want editors we want them split between the

two groups we want editors focusing on the needs of ercs and editors focusing on the needs of VIPs they have very distinctive District needs and different things need to be done with those two repos so when we propose the split we're not saying no editors no standards nothing that can't be put on um put on an ipfs link for five years we still want that we just don't see what value a third group over both of them has they can both create high quality standards independently there's nothing about unifying the processes that magically makes it better well I know you don't you don't seem to like the analogy and you want me to break it down in huge detail but the ITF manages standards for the entire internet with a single the

itdf does not have a board of direct does not have a board of editors it has a director it has areas and those areas have working groups working groups have a chair and one editor per working group so there is no you know centralized editor group doing this editors within each working group have independent full control over it so unless you can show me what the higher levels of the ietf would add to the situation that is not just overhead and frustration I you know I don't know how any ietf comparisons really matter because we're not really doing ietf process which is a very email heavy driven process they have more process they're a much bigger group um the standarding working groups are and I think in a similar way

the Developers yes um if you feel a need in managing your workflow to set up somebody um typically the project manager has done a fair amount of this to say these are the standards we need to enforce for our documents fine but the chief editor and staff there in the ITF have become more bureaucratic but they do set standards for just your basic editorial stuff there's nothing stopping us from having this at some point like I'm not against the structure

fundamentally but we just don't have enough people we don't have a need for this right now we can't even get the other three editors to show up on this call we have you know basically three editors there is no need for another group to manage the three of us like we just need a group chat bye I think maybe I'm actually proposing a working group at ITF as we speak so like I have all of this fresh fresh in my memory 2023 ITF process is something I could actually speak to off the top of my head uh but I think I think that maybe uh Dana made a good point that the

area groups uh are standing working groups and working groups are sort of topical chartered short-lived and the area groups each have an editor who's sort of coordinates within the area group within the multiple working groups and the uh area groups coordinate amongst each other to with dispatch to make sure all new items only go to one area group don't create redundant working groups within across area groups so like I do think that function um it's sort of like I think that what Deno just said in terms of like maybe one

editor per let's just call them area groups right let's just say ERC EIP and wallets are area groups and there's three of them this fourth group uh whatever we want to call it um I I really don't uh I think that if if anyone if anyone in any of the four groups thinks that fourth group is the overarching hierarchy or the final say or the ultimate Authority doomed to fail will never work we aren't ITF we aren't big enough there aren't enough hands to justify that right I I think all those points are totally valid I just think coming from like a project management and coordination community

uh background I see that fourth group as the uh the the core of like almost administrative function that just helped that group chat of the editor in each area group uh work right it's like the dispatch function and the just avoiding redundancy avoiding seeing conflict in advanced function and I'm more like I I I'm just advocating for that not even out of any like Personal Agenda here or history like I'm new here I just do this

in other contexts and that just strikes me as like the the baby that I that I fear will get thrown out with the bath water if that fourth group is in any way the overarching authority over the other three I I agree it won't work like all Cortez does not want anyone above it and that's fine I think we need to just uh find the common ground on like what form of that fourth group would work for everyone well I think what we really need to consider is what Points of Authority I don't know if there's a more formal term for it or not but what Points of Authority exist in the system so like for example um core developers have the authority to

choose where they publish their documents and where they read their documents from and you know EIP editors have the authority to decide what pull requests get merged in their repository and those are really the only two points of like power in this entire system everything else is just it's imaginary right like you know you know all quotas can say that there are peer we have a peer relationship with them or whatever it doesn't matter our Authority is over pull requests it like our actual authorities of over pull requests in the eip's repository and core dev's actual Authority is you know where they read their documents and where they publish their documents to and like I I don't think we need to

think of anything outside of those two like decisions do all core devs use the eip's repository to publish stuff yes no and you know what rules do EIP editors have for merging stuff into our repository and I think those are the only questions we really need to answer and what and because we have only seven minutes I wanted to get to Litecoin client's question about meeting Cadence and this is a good example like if the uh if there was a coordination group that included hopefully at every meeting

one editor from each of the area groups uh it might need to meet more often but maybe uh it would only need to have more participation from the entire all core devs or wallet devs or EIP devs every fourth meeting or every eighth meeting or something because then you could just sort of schedule for that meeting everything that needs more detailed or wider review I don't know but I'm not I'm I'm totally uh hijacking like client's agenda item like client I think you you were just talking about quarterly reading full stop I don't know what else what else yeah no I mean I'm just pretty

frustrated that we come onto these calls we don't ever get panned on here for some reason Victor's kind of stopped coming we're talking about like the most important topics related to EAP editing right now can't even get them to like really interactive Victor Victor is getting his wife to the doctor this morning he very much oh okay um okay um okay quarterly doesn't necessarily help but let's not let's not get into into like that's not an important issue for today um I mean it is like this is insane the number of meetings that we have as long

as our meetings have agenda items that we're discussing to the last possible minute I don't think we can reduce meeting frequency I don't think that's going to solve any problems I mean the fact that we have it available exactly the fact that we have these meetings we have all of these debates like these that we don't make any progress in these debates we've been talking about numbering for like years and we still feel yes the sort of meeting thing though that's just somebody needs to implement the bot that's like we've all just like that discussion has been decided we're doing a bot it's gonna happen eventually when we get around to it this meeting could be an email most of the time or a discussion on pull requests if editors are unable to just like

respond to pull requests in a timely manner then that's like a bigger problem but I don't want to come on here every two weeks and debate should we add VIP should we add you know whatever you know new links you know this is just like a total waste of time and we can't even get most of the others to comment I am like frustrated that I come every two weeks almost and the other rest of the editors come whenever it's convenient for them so they can and especially because panda is the one who's creating most of these changes and we have to come on and debate his changes but he doesn't even show up I might be uh a signal of an orthogonal and also very serious problem which is that if

the coordinating body that is supposed to be helping other processes is holding back other processes that's like a funding issue like the the like you're doing this on top of your day job and but everyone's doing this on top of their day like no one's being paid to attend these meetings every two weeks is like its own problem okay sorry that exactly but like if the uh if if this were someone's job they were uh holding up the processes they're supposed to be enabling then we would say like you are bad at your job we need a new person to sit in your role but like maybe that's a sort of structural issue to like where the money comes from to keep this

process going that the timeline is that it's it's we're not doing important enough stuff to be paid that much money we don't need to pay five full-time people to do this we don't need to pay any natural time if I like as someone who gets paid full time I disagree but go on that's my number one concern about a third organization is it'll become a trophy job and it won't provide actual value if that can be shown that this provides actual value that Above and Beyond Simple collaboration between two groups then that would be persuasive to me but I'm concerned that a third group is just going to be a trophy job like we haven't really figured out what

this job does outside we haven't figured out what this job does versus like what tembeko does what's like 10 Bako looks like a an editor in some ways he looks like a somebody who's in charge of you know organizing a group a area group and it makes sense like he does a lot of work he does a lot of work like coordinating things and this is like you know not something that editors do at all by Design right but it it's not an editing job to say we've we're considering this for

inclusion it's not an editing job to say it's time to put it on the test Nets it's not an editing job to say yes we've decided we're going to put this into the next upgrade um and it doesn't need to be an editing job um to to keep those directly in the editing status that that's what I'm saying to work the core devs need to be able to just do that and if we're in the way we mostly should just get out of the way and we we do need some process for coordinating on that um but

just saying we have one repo um that's that's where both the editors and the core devs are going to work and we're going to create the CRC repo and it's an awful lot less clear to me um we're going to manage that are we going to wind up with like just Victor that whole thing I mean I'll be an editor on it too and I'll go and try and review some of the erc's but we need volunteer work all volunteer too so then who takes care of we take a small struggling group of people we split it into two groups and we'll have two small struggling groups of people and then we're not struggling

yes we have editor we have editors who have enough time to just write you know multi-paragraph essays rebooting other editors like we have the time we just need to apply it to editing eips we've got ERC sitting there that haven't been looked at in months we've but instead all of the editors are sitting here arguing about numbering and about how to deal with the process we're not even serving the community you've moved the overtime window I think it's pretty clear that right now we're we are wanting to solve this we're all tired of this discussion um you're the one who's extending this discussion yes

yeah I said up front that the only the only thing that's an absolute block for me is dividing up the editorial organization into multiple organizations I mean personally I don't see why this is a problem but I I honestly don't really care that much about this point I want to split the repos if we have to have an I don't know what it means if we have to have an organization that goes above the two that I don't really care because I don't think this organization does that much but I don't want to then spend the next three months trying to figure out what the processes are going to be for the organization what the Constitution is going to be for that organization I like splitting them both because you could

just clone both of the repos clone the processes and then let them run yeah this we're running into some fundamental disagreements and going around in these meetings isn't helping they may be fundamental enough if the other devs it excuse me if the other editors um if the other editors want to go with the split you know D split not a split um okay but I'm just hearing just fundamental disagreements as to how the editors should be relating to the developers and that that's the blocker for me uh the

editors need to remain a single autonomous organization um and I'm also tired of arguing about that and they're that's what I've just sort of laid down that's a long-standing intention I see no good coming of break coming from breaking it up I'm not interested in participating in the process of breaking things up and having an organization I help create um split up in pieces and I can keep arguing about it you were not in the original editor list for crying out loud after a few years access joined I went in to edit eip1 to add his name and I

looked and said Gee my name's not an eip1 it's been a long time I should probably put it in um you'd have to go find the old Skype dogs to figure out when I first joined if if they're even still there and complete I don't know um as to whether I started in 2016 or 17 Hudson might remember uh Nick Johnson would remember perhaps but he's he's pretty much moved on CE you're the oldest serving member but you were not one of the founders of the process so that's what I object to that's fine um this I

wasn't in the big house in Switzerland which is the true Founders um so [Music] um but I think the I think the uh fundamental question for me just as a newcomer as an outsider walking in on this uh family dispute it seems to me like it's actually kind of important uh how these so I've been doing open post for a long time I've been trying to coordinate processes across companies for a long time uh it it seems to me like part of the issue here is that core devs have pretty

conventional employment relationships and it is their full-time job to advance uh uh you know one of those three working groups within that area group in in Daniel's analogy uh execution apis or whatever and uh because of that this feels like some weird external process outside of their job outside of their company outside of their colleagues outside of their sort of Specialists who were all focused on this on you know company style uh timelines and so to give more color on that I would say we would expect client teams

to spend time in the IEP process maybe possibly promote an editor there to make sure things facilitated and pushed through because the EF has people in protocol pushing it through and if you're going to be proposing changes to it as part of your job part of your job is to write eips um it's not it wasn't built as an independent thing that should have independent standing like the ietf it was built as a facilitator in a formal process to help these protocol things go forward and to serve the community my concern is what what um is what like client was saying before he left to go to his meeting that I should probably be on sorry is that we're spending time not serving the community but fighting about our own standards and we're not spending time reviewing eips in the erc's coming

from the communities which should be the purpose of it we're too busy worried about structure and format to serve the communities it's set up to serve and that's one of the things I think the ERC split will do erc's handle just erc's EIP essential core protocols um and all of the the minutia of people you know what you know the app developers don't want this thing for the protocol and their process so great let's split them up um and that's the core core win for the process and it's easy to split them now and if the third group needs to form after we do the split because there's value to the added to be demonstrated we're fine with that we just don't think that should be predicated on the split split now let things figure out what need to be done and let's focus on

serving the communities rather than arguing about what our jobs are and whether we should be paid because if we do a good enough job the pay will follow some company will hire us or there will be formal funding for this process that's always been the Mantra of ethereum is get in and work um and if if you've really found something valuable there's a company that has an empty slot that does what you do so that's kind of where we've been maybe we're growing past that part we need to have it I don't think we're quite there yet maybe we'll be there but I don't think that those issues should stop what needs to be done now which is get core processed separate from application process they're very Divergent communities and are continuing to diverge this split among authors not participating has been happening for

years it was about to come to a complete end we're trying to stop that before it completely ends no I I take your point but I'm wondering if this if the original idea was for this process to facilitate were the was the initial idea for those facilitators to be completely unpaid because that's like never that that's where I'm confused it's like it's almost like this uh the problem isn't that volunteers write uh too long of PR's it's that they're volunteers with no sort of incentive structure to make them I don't know structure a criteria of success around

fast happy communities they're serving so that what these are based off of was the it was the Bitcoin Improvement protocol as well as the the python Improvement protocol and that's kind of the heritage of this more so than the ietf processes and in those there is no real paid editor um a lot of people work on python you know to have your your page IP python you're not paid to work on python you're paid at Google to count ads and they decide that um it would be valuable for them to have somebody building core python because it helps them build apps I think that's more to the core of what it was originally founded on and he looked at all the list of the original Founders they were all either employed by the ethereum foundation or they had companies that were building early

ethereum things built off of hopes and dreams um rather than actual money so that that truly is the foundation of where this came from is is hopes and dreams not a formal process because that ETF wasn't even found until the mid 80s um it was just an RFC process back before the internet was when it was academic research process and I think if we're going to compare the EIP process the ieta process I think we're still in the RFC land we don't have yet a need for formal LLC around this process I don't think we're large enough yet I don't think the community is large enough yet I want to get it there there and the way we need to get there is and I'm serious I will volunteer if there's a need for people on the ERC side I'll do it on the EIP side but I don't think

that's where getting a shortage is going to be I will volunteer to help review these and get these through the processes if that's what needed to grow it because the process needs to serve the community to not serve the editors I mean I my only disagreement with anything that's been said today is that we're making no progress because just attending the last four feels to me like each of these meetings the Gap seems smaller between between everyone's definition of success I mean it sounds to me like the uh the I've I've just been talking to people in other corners of the universe about like the wallet stuff primarily for me that's the fourth group that

should exist but like it kind of I agree for everybody if the wallet is the working group at the court and throw a working group and the sort of like one volunteer like the way you described it as like one one multi-editor he each would have at least one editor but definitely one editor that also coordinates with the other groups like that so I mean if if that's pre-i TF that sounds right to me I'm not worried about whether or not we're as complicated as I ATM from my perspective for this third group this this group on top to succeed it can't be forced as a function of the split it needs to naturally grow out

from all from ACD and from from the EIP process from the ERC process or from the wallet process and grew up and show and find the the gaps they can't be filled from simple coordination that requires the organization I think the need reads acquire the org rather than the org searching for a need that's my concern if we create this that it's not really going to solve any problems we're just going to shuffle where the problems are this is this is a bold move that we need to just separate it and it is absolutely a leap of faith but if there is a need for third group then it'll be apparent that this is what we need and the people that see it will come together and build it on top of it but I honestly think right now that just email coordination and PR coordination in each group will

still have high standards and still have high processes do they necessarily need to be the same and centrally coordinated that's what I questioned but if there's other values that come from a third group and that's where the value can be added so you keep talking about a third group but we are here in the meeting of that third group being told that actually we shouldn't exist we'll have two groups and then decide whether to put put ourselves back together again like Dr Manhattan I I guess I don't know the reference but I'm at all it's a Watchman reference the first thing he's the only real superhero

in the Watchmen and the first thing he had to learn was how to put himself back together and that made him stronger um there's no reason for me to think that that we're superheroes um but when I hear let's make a bold move and then like I said I keep going and then what maybe things will get better maybe they'll get worse but you have moved the Overton window I'm not trying to drag this out forever I'm trying to get to a workable resolution for everybody so but the only way we ever get progress on major issues is to move the Overton window and that is the definition of

dysfunctional this is not the first time that the original window has had been moved we have to do the end move to break this pattern otherwise it's just going to become a continual series of one upsmanship I'm 10 minutes late to the eof call I really should know that yeah that sounds important don't worry uh thanks for staying after uh I I found it very helpful at least um yeah um I I yeah I'm not sure how to what what vital words are all I guess uh try to mimic puja's minute note

PR policy uh to close this up thanks everyone