EIPIP Meeting 85

Transcript

um welcome to eipip meeting 85 we have agenda issue number 248 at eipip GitHub repository for discussion we have some eips which are already in final status and there are respective PRS to make some changes in that will be discussing the issue of EIP and ERC GitHub repository that we have been discussing for past few meetings and I can provide updates on eips inside and maybe followed by EIP editing office hour so starting with the first item listed on the agenda changes to final proposal

the first PR here is a 7295 this seems to be a small change but it's a keyword in the spec uh I suppose the user is trying to remove the word memory here wondering what editors think can we merge it or do we have to say no um if it was valid solidity When It Was Written then um we should probably keep it if it's invalid solidity then it's fine to change it I am not sure if we have anyone from salinity to confirm that

yeah I'm checking right now both could we move on to the next item um and I just wanted to bring it to the attention yep perfect so the next one is a PR number 7261 it is a change proposed to EIP 6059 this also seems to be a small change the author here is a willing to add a statement a sentence uh which is like you know when this proposal may not be good and it's just a statement to like let implementers know about it no spec

changes here again the pr number is seven two six one um I'll have to think about this one but I'll keep it open perfect okay um before we move on I see we are joined by more editors here so just to let people know that we have already uh

taken up two PR's seven two nine five and seven two six one those are proposed changes to funnel eips if you guys have any thought comments or objection on that PR please add as a comment so we can close it and we can also inform the author and if it seems generally good and not a big change we can perhaps merge that moving on to the last proposal here the player number is 7183 it is a change to eip2612 it seems a bit confusing because I'm not sure if the proposal is just trying to adjust the space or too much

changes into it so it would be really nice to have a let us take a look at it and maybe respond will do thank you all right moving on to the next item which is discussion continued from the past meeting we have EIP ERC GitHub repositories split that we were discussing um so for a quick recap uh light plan opened a PR 7206 to split the GitHub repository

in the last meeting we were evaluating the effect of split on ERC community Victor an ERC editor wanted to have this proposal shared with ERC Community via all ERC Dev meeting and respond back in today's meeting and in the meanwhile we were to assess the functioning of existing and the process for the new repo Juan pulled up the task list for ERC EIP split it's in a hack MD which is also added to the agenda and he also mentioned that he is willing to volunteer on the editorial board post split um I don't see William I'm sorry I don't

say Victor on the call today but he has already updated on the Discord that he had a meeting of all ERC Dev and it seems like ERC developers or authors are not strongly opposing to this split they are generally okay with whatever the process is they just want a clear communication so it can be followed um yeah with this perhaps we can start sharing updates and add comments and um I suppose it would be a good idea to take a look at the hack MD and discuss next steps to you know getting volunteers for specific actions

I don't know Juan if you would like to maybe um talk about the document and share the next steps yeah and yeah perhaps update all of us I uh I don't have very strong opinions about the process I was trying to just sort of as The Outsider play secretary and just write down ideas I saw in different threads in different places on the across the Discord additions and um the pr threads and I don't necessarily you know I'm unqualified to own it or to

uh mediate if people disagree with any of the items I was just trying to throw it together to have you know a draft to work from if if anyone has strong opinions um the heck MD hopefully is not access controlled and anyone should be able to change it um yeah I mean thanks a lot for making that hack and D I was yeah pretty useful there's like a lot of stuff that was kind of like outlined in different places but yeah putting it all together here so that we can see that was it was an awesome thing thanks um uh if uh but maybe Puja was the was the request that I walked through at line line by line or or item by item or

just overview it and I was wondering like you know uh what would be our next step it seems like we do not have a strong opposition to go ahead with the split so what would be the right Next Step to begin this process I understand from Sam's comment I've expressed strong opposition blocking opposition over and over and have not changed we decided last call that we're just going to go ahead and do it regardless this is blocking I will resign you made that clear last call okay this if the other editors are willing for me

to resign over this issue I will resign do have a Greg's uh proposal added as next item I am fine going over that because if I remember correctly like mentioned that if we take a look into his PR that perhaps will help him you know get motivated to you know think about it and it will solve some of the issues do you think that would be a good approach to First discuss that and we can come back on this hack MD after that issue I've made clear that my opposition is not to splitting per se my opposition is for splitting without a plan for how

that split is actually going to help the problems that we have we've outlined how it's going to help but you don't like the you know what we've said that is going to improve the situation I believe it will cause more harm but I don't want to have that yeah but then again but it's but we have given reasons that it's going to improve the situation well you just said that we haven't we said that we're going into this without a plan and we do have some specific things we think it's going to improve and whether or not you think that those are useful that's like a separate discussion but like we do have some plan it's I'm not finding it adequate that's why I've made the pr to indicate the

direction of a plan that makes sense to me [Music] um we we can discuss this or not okay I think that is the next item on the agenda so if you would like we can perhaps discuss the pr that you have suggested and then we can come back on the hack MD yeah yeah and yeah totally oh no sorry and no worries all right uh so let me bring up that sorry quick quick question point of order is is screen sharing distracting or is this is this not really the standard way to do this I I just sort of default to screen sharing anytime I talk on any kind of

meeting I think we're too lazy to screen share usually okay okay cool yeah but that should be fine the uh the comment on the commit pretty much summarizes I think um of course if you have particular things to go through that's fine too but for General discussion the comment is I think um still a good summary uh yeah I I think uh maybe since it's your PR and there's you know change requests throughout and some topics you could you could uh guide us to what what you'd want to

discuss with a group to decide on change requests then update see Victor wasn't able to make it today um the pain I've seen and experienced as an author um is in my opinion we're in general way too picky but especially we're way too picky way too early it's it's a pain just getting a draft into the system but until you have a draft in it can be difficult to get discussion threads going to have a number to refer to so

people know what the proposal is so I think it should be easier to get a draft in in the first place we're not going to run out of numbers Microsoft's not going to run out of hard drive space um so the main concept here is just to make it easier to get a draft in and tighten the standards as we move through the process and so I've made specific PRS but I'm not wedded to the specific PRS I simply and presenting the concept of tightening as we go and doing it at the transition points so people can get into the process and work

on their proposal without a constant battle um of your doing fine you make a change and the ipw says Nope not anymore and suddenly a short session of work becomes a long session of work um or you discover that oh you can no longer use that link um your whole proposal is stuck just these are pain points it's just a painful process for people um on link policy I really think uh I think we're too tight on it but certainly at the draft phase if some if

someone needs to use a link or wants to in the draft okay we've set it up that will need to go through a process of approving that but please let it into the draft so that the draft makes sense while we go through that process um and I've suggested actually tightening up legs as much as possible having a full citation into the literature um so that if a link goes 404 you're not just scratching your head you have an author you have a title hopefully you

have the journal A publication date so you can probably find another copy online uh if necessary you can go to a library get a copy on interlibrary loan you can send an email to the author lots of ways to get a copy if a link goes 404. so having a link is nice but it's actually less important than a proper citation or or a DOI I love the DOI idea because yeah dois or even ipfs cids sort of create a uh yeah location independent fall back I like that a lot um I I think I don't

think there's going to be much pushback on any of those details um I I think the um block like the things to resolve to merge this quickly would be um the technical assistant idea there's seemed to be a little uh contentious and yeah um I I don't know the history there you uh if if I I definitely know the analogy to ITF um and um I guess if you you uh it probably isn't the right place to talk about like money

or or formal recognition but if if it is a concept that already exists if there are if there is already a way to call someone an expert enough to advise um is where's the where's the disagreement I think um the problem part of the problem is we've got too many low quality drafts that is a problem I don't think we can bot our way out of that problem yeah and we haven't gotten like the ITF um a solid working group system and I suspect it's just too hard for us to do that because

um what comes in is erc's just covers a huge range of stuff and keeping a group organized hasn't happened um and then I ask what do other Publishers do and the answer is peer review something comes in for publication and you know two or three experts uh review it before it goes in and we've had some talk on this that if if you can't find two people to help you with this draft then is it really worth standardizing if nobody cares to read it but you uh what's the point

um if we can establish this as a practice and often Publishers push back on the author to say hey find some reviewers we're not experts here we're just we're just editors uh find us some reviewers uh to work with you on this um so that we have you know we have some reason to think it's technically sound that's a barrier that I'm happy to put up before a draft goes in a technical barrier the chat's actually going wild right now with ideas about uh that oh I don't have my chat up oh sorry

uh so I think I think people are uh uh I think people are thinking about um being permissive of PRS but postponing the numbering perhaps uh and that I don't know if that uh balances the the pain of proposers against the pain of editors well enough but uh I do think you know like just to just to um give a comparative perspective Casa which is you know pretty different pretty different animal but like diff two um sort of has an informal two competitors rule like

uh it it's I've been trying to make it more formal at dif um that a new work item proposal that just comes from people that are already collaborating on a product uh or you know a thing they're building where they're already collaborating like that isn't really a place for a standard I think that to publish it as a document you could require BYO technical assistant or you could require of orbs something that looks like the thinnest possible precursor to a working group like um those might be ways to I mean particularly if combined with this idea

of a pre-numbering or you know except the PR but don't give it a number till it has someone to review it um that's uh that's what draft PRS are for uh maybe other people should speak I'm not sure I understand that the unnumbered proposal well enough Sam oh it's just if we give drafty IPS a number and URL that changes when they get promoted to a review whether that's you know a different number or using the title or whatever I think that would give enough difference between a draft and a real EIP um that I'd be okay with like a lower standard for those eips

I'm I guess I'm suggesting an initial stage which is just a draft PR they can hang out there forever and never be merged and they don't need a number um and that's the stage which you want some peer review uh before it's numbered and becomes a draft um and then it has you want the peer review before because like because right now we have drafts have very very um like you don't even have to have a finished EIP right like you can you can leave to do's and all sorts of stuff yeah and that's where we want peer review not after it's you know complete I think so so we we're just getting flooded with drafts that are too low quality to

bother looking at um or just they're too far out of anyone's technical expertise to help with so it's simply not uncommon for technical journals to do a phase of peer review before it gets very far at all um they don't put in the work of of actually editing until some peer reviewers have said this is technically sound um and I mean we've tried for a pretty long time to have people engage with the eaps as they move along the process and they just don't I understand it it has to be sort of a rule it's just like no I mean it is a

rule it's in eip1 it says before you create your draft you should ask the community and make sure this makes sense I don't I'm saying a rule the editors will not merge a draft until uh some peer reviewers have actually looked at it it will need to establish a little bit of process there so it's clear this is a process this isn't go out and find some things it's like no we act we want actual actual work on the draft PR um until the reviewers are happy with it so I think this is a good spot to jump into my meta complaint um this doesn't address the issue that

the core eips and the erc's are two increasingly Divergent communities with two increasingly resurgent process needs getting a person with the technical knowledge to review a core EIP proposal is going to be easy yeah it's all over the place and getting someone to review a random ERC for random token protocol that may or may not be viable is going to be increasingly difficult and the standards that need to be put to a core EIP versus some ERC standard that just needs for to some extent have well-formed solidity are increasingly in diversion and have very different needs um this this addresses the lowest common denominator needs but that's the problem is we're trying to put two Divergent processes together that really need to

diverge well [Music] it doesn't seem complicated with GitHub

you put in a draft PR um it doesn't merge until the editors approve it so it's easy for the editors to say we're not going to merge it until you know until I guess at least one uh technical expert helps us review it and that can be at either that can be a standard process or at our discussion uh often an editor has the skill to look at it and and do that job often that it or doesn't have the skill we don't need this type of a process to move stuff in core core will ignore the EIP process and set up their own

standards rather than go through these the needs are Divergent very divergent This is not something that core protocol changes go through except as a final box checking step um just to satisfy some people we're increasingly abandoning the EIP process because it's not serving the needs of the core protocol I understand which is why we need to split it if you understand it why don't you support splitting it again I'm sorry for jumping in um but I am how did Greg respond oh yeah please go ahead because I do want to hear sorry I just want to hear I thought he is against this I've I've set I've I've had this discussion so many times for so many

years um and I'm not alone in my opinion it's more like the people who agree with me have just gone away um but I'm not I'm not an alterably proposed what's laid out doesn't look so bad I have strong fears um that the Divergence will actually hurt us so we're better off preventing the Divergence because how is it going to hurt us it'll simply spread resources out and cause ethereum more and more to become a fragmented Community more than what resources will be spread out

because we already review all of the eaps and erc's and that's not really going to change when we split them well see now we're we're getting into the details that I don't want to get into because but you're not really giving actual reasons against I know I'm not giving vague you're giving a vague generalizations yes because I don't want to get into the details we've we've we've done that I'm trying to discussion proposal not that but I'm saying that you your arguments against splitting like they don't have a lot of basis and like reason it's so far I've heard just generalizations about oh it's going to fragment the process it's going to make it harder you know Etc but

there's not like specific things that you're stating like this is a bad thing whereas we've given specific things about the split that will benefit the core Dev community and generally people from the core Dev community and the ERC Community are not opposed to this questions yes I'm waving my hand in the general direction of more detailed conversations in the past but I mostly want to discuss my own EIP here yeah I think I've said so you mentioned can I respond to one of the points you made Greg yes please please do sorry you said that you were not the only person in favor of this but everyone that you had that disappoint with you has since

left this is the symptom of failure sorry guys and I still am not in support of this change people are leaving because they can't get what they need out of it that's the problem I mean people have left the discussion the discussion just stalls every time we have this discussion we decide not to split the repo we do not come to consensus on splitting the repo we've never had it consensus and what we're on the precipice of is people abandoning the EIP process it's already happening in the core protocol we have execution specs we have execution spec tests nothing networking has gone through in a long time slowly but surely it's peeling off and this is

bad I mean if you're going to wind up it's just an ERC repo anyway if we don't acknowledge this I understand I want to fix it I have I've I have an EIP which will not totally fix these things but I think we'll reduce the pain for everybody and I think it's a good idea if we can reduce the pain for everybody it doesn't reduce the pain enough people are still leaving we've been through this you know going through this for years and people are still abandoning it I'm suggesting we do the parts of this that we can come to consensus on and will reduce pain if nothing will reduce all of the pay

this is death by a thousand paper cuts could be um and you're the one with dream of paper no if I walk away I walk away that's okay um I'm I'm a very busy old man um so um and that's that's not a that's not a hostile act on my part it would just be you people need to do what you need to do and if I'm not comfortable with doing it that way um it's okay for me to say okay do what you need to do it may well work out just fine um I think it's time to do what we need

to do we've had the eapip process for three years now you need to change the way you organize your repos so your repos are more useful to us and I do look and say a fair amount of your process could you try again yes um some of it looks like the core devs are trying to use the EIP process for things that have nothing to do with the editorial process the the status of something as a as a as an edit edited document and the

status of a proposal moving through to get into the protocol have different stages the core devs can pull something to CFI at any stage in the editorial process they're not bound by that process splitting the repos is not really related to this yeah I'm trying to say this I'm sorry I'm not being really clear here there's too much on the table um yeah we don't we don't have core devs here to discuss this with in part what do you mean you have I'm a core Dev okay okay yeah Dano here Daniel is requesting

that on behalf of the other core devs that we've talked to on all core devs who were in support of this and we have Arias two weeks ago who said they wanted this I had our Tim was complaining that well we've got stuff spread across hack MDS and this and that I'm scratching my head Tim wants to split the repos I understand but I'm just going why is it the editor's problem that you can't keep track of the status of your work because we need we want to change the process and it takes like a year to get a process change through and that's just it doesn't align with what we need with our workflow which is where we're

putting in hack MDS we're putting in separate repos why we're basically abandoning the process because it's not suiting our needs why why are the core devs trying to use the IP process to track their development process is the ethereum Improvement protocol it's where we can get consensus on the changes that we're working on for ethereum not for the application layer I mean it's like the it's like the w3c is capturing the ietf is what's going on no this feels more like the the ITF editorial organization has decided that there's way too many different kinds of proposals for the internet and so they're going to break up the ietf into multiple organizations

like the w3c like the what would um like there's all sorts of things that are like like the PIP I mean they they split to reflect the needs of the communities when they diverge those from new organizations that that rose up for new needs but this one at the end of the ietf the other tables the ietf editors did not divide themselves into multiple organizations just because the ITF uh covers a huge range of Technology um so I

that's where I'm going loosen our workflow so it's not in their way and find out well how can you clean up your workflow um I get that the that the protocol level um they've been working directly uh with their python specification um and that's where some process probably needs to change um that the EIP really isn't done until after they've done their work uh on the reference implementation and I don't I don't have a problem with that

we just need to work out and that's work out how that works and part of that I think just making it easier to get a draft into the system and move it through so there's always a document in the system that can be referred to and the author has control of the problem is we have two Divergent layers trying to use the same system that is not serving either one of their needs very well at all okay and your concern is going to split it I think it's going to strengthen it people are going to see that they can get what they need out of what out of each different group and they're going to use it more

you think yes I do yeah and I don't and we're going we're going on hope here not a plan we have a plan you made us tablet so we could discuss your plan it doesn't address the issues IT addresses a few other issues that I think are easier to fix and would help a lot um but we're focusing on a low-hanging fruit when we need to go to more substantive issues we're distracting ourselves with avoiding the core issue that we're diverging these communities a lot of these ercs do not necessarily ever need a raw and Main net they could run on all sorts of the pick your random alt L1 or L2 the application

layer has nothing to do with with changes to the consensus layer with changes to the networking between the two clients between the the two different layers they're fundamentally different layers that the only interact in very few places okay we're just editors in the end we just want to publish a high quality document and I get that we don't want the process to be in the way of that but I do think that people are trying to use the IP process for things besides simply having a final document at the end to manage their own workflow and I know

that GitHub tends to pull things that way and cause problems that way but still I'm going um it's not our problem if if you prefer to use hack MDS rather than use ethereum PM um go ahead like Clan I'm just saying it's not that we prefer to use hack MDS like people want to use the process it just doesn't work with how they normally work I don't I'm looking back to how it was working you know I only sort of disappeared for a year and all of a sudden it was a

different world so I've never recovered from that and I'm the last OG left so I'm the last one going this was our intention um it was a pretty solid long-term intention so that's a lot of what's going on here and I have a lot invested in that um yeah but the community has moved on from was intended and maybe what is intended isn't what's working I mean I think you're articulating the core issue here yes and that's where with no hostility I will need to move on if I've decided the philosophy no longer corresponds to the philosophy we had which is that were Publishers all we're trying to do is to get a good final document at the end

um and with the core devs we always considered them to be a separate organization um who could pull documents out of our process um because their workflow is not ours all we wanted was to do our best to get a final document um ready to describe what actually went on to the main net um I mean that's still the goal it's just the way that we're going about it is disenfranchising the people who are writing the documents and involved in the process of dealing with the documents so it's like I'm kind of ingenuous to say that that's the goal to

have the best final documents when we don't listen to the feedback from the actual creators of these documents and I'm hearing two sorts of problems one sort is just the difficulty of dealing with the editorial process um and that's this IP is trying to solve some of those problems and lo it's low hanging fruit is low-hanging fruit if you just but again like at the very beginning of this debate we came to a specific propose that you made where you feel that there should be more peer review that happens before something goes to the draft Daniel says specifically this would be easy to have with core devs yeah at some stage in the process it's very hard to

have with erc's because they're so fragmented and so this is just like a clear place where we can't easily have some uh you know rule across both categories of VIPs and apply them in the same way The Proposal is at the editor's discretion the editors can go this is reviewed enough this is solid or we can't tell if this is solid we need help um and it is purposely a technical barrier the core core proposals can meet much more easily that's true so we're already saying that core has a different process than erc's why are we keeping them in the same file cabinet no

I'm simply in this case I'm simply saying the court proposals or more likely to be reviewed and solid um right away and erc's are more likely to be not solid or not useful so right if you had the same like the same rule for both core eips would get approved easier and erc's wouldn't be and that's okay yes it's not okay that's not serving the needs of the two Divergent communities the added at the editor's discretion and the authors can argue with the editors you know we can either say we will look you know we will move this

to draft it meets us because what we're seeing is the authors are abandoning the process rather than engaging in that fight that's not a fight for the core things we don't say technically we're not going to put this in we say we're not going to put this in because it doesn't meet our rules um it won't get through our bot so we're not going to put it in until it does that's an easy pain point to get rid of it's clearing out low-hanging fruit that's not very controversial is worth doing it eliminates some pain right away um and we're going to see pretty quickly that the core issue is that these are

two communities that have different needs from their editors I would be happy to see the court issue get quite clear in that way it is clear you're just refusing to see it no I'm disagreeing that it all needs to be fixed in the editorial process what I think what needs to split is that the core devs need to own their workflow and we need to simplify our process so that it doesn't interfere with workflows um how is giving the court devs special privileges any different from splitting the repos I'm explicitly not giving

anybody special privileges and already it's the case that the editors have to approve a draft before it goes into the repo I'm simply saying if the editor's discretion they can ask for outside technical review and tell the author that we are not confident to review this or to the extent we are we don't think this is up to Snuff and you need help so we'll work with you to try and find that help um and this is not a core Dev versus CRC thing we will get Court proposals that

have the same you know you look at it and you just go this doesn't make sense um if it does somebody needs to help this guy so we're going to increasingly have editors apply different standards to different kinds of eips and that is just reinforcing that there's two communities going on here at the same time I just said we we will get core proposals that also need outside review fewer than erc's likely if a court proposal does need such review it will be much easier to get that review I don't think that'll be a problem at all

I I would like to like cite an example here for one of the latest CL side proposal that has been added to EIP repository as core and the proposal number is 7044 and there is another proposal in progress which is a eip6110 for both proposals what I noticed for them is like their discussion to thread is completely empty there was no discussion that is public because discussion definitely happened it happened on client Dev meeting and perhaps in the client a specific uh spec repos so it is not easily accessible following the process of whatever has been established so far is also helpful

for core EIP is what I'm considering it's just that we need to let people know about the process one other common thing about these two specific proposals coming up from the CL side I I'm sorry 6110 I guess is on El but 7044 is on sale that they are not aware The Proposal I think the spec has already been implemented because that is a part of denub upgrade but the proposal still is in the draft status it is not even in the review status which would be an ideal status for that proposal so what I felt like the proposer the author they have no issue moving the proposal from draft to review it's just that they are not aware if we let them

know that this is the process and you want to follow I'm still hoping that it will work out for those people but going back to uh Greg's initial PR I think Greg it would be a good idea to talk about 7230 the pain relief point that you are suggesting and get an agreement on what we agree and if this can be merged because I'm assuming that if this can be merged perhaps we can move on so I see from the chat Lifeline is not in favor of the draft and numbering idea please correct me Matt if I am mistaken over there but if this change is added

would you be open to discuss and perhaps pull in or yeah like remove this part from the pr so we can go ahead and merge the pr where we are on that would be a good idea to discuss I'm happy to split this PR up because clearly some things are more controversial than others it's always a good idea to have a smaller PR so we can get clarity on situation we can keep moving on like if this particular section like draft numbers thing can be moved out what is the next point that we don't agree on like as an editor's group they are not comfortable moving this to eip1 if they

are then that's a small step but a step forward in improving the process any other point from Greg's PR that people would like to be removed or be a part of a different PR so we can go ahead and have this one merged we can take it up in in the thread on PR m the idea we can definitely take it up in the thread and Greg um not saying that

it is going to happen just today but again considering both the possibility of splitting as well uh being one of the possibilities for repo it would be a good idea to follow the you know proposed and next steps to understand if at all we go ahead with the splitting we are in a good position we are in a comfortable position and nothing is breaking up so if it is fine we can perhaps uh in next 10 minutes uh quickly go through the hack MD that is being proposed here it will give an assurance to community I suppose that if the split is happening we are not abandoned we are in a good hands yes

all right um uh I think of just to make good use of the time let's quickly go over the points we will continue discussing Greg's PR in the thread and see if it can be split and uh PR number 7230 can be merged at least it will give some relief to the present process and editors and then we will we will separately discuss the pr which is split or coming up as new and for this time for people who are in favor of having this a split but they are wondering if the split will be useful or helpful let's go ahead with the hack MD with proposed process I think collecting thoughts from Matt and other people who

are in support of this split would be a good idea and it will be helpful for people like Juan and us to you know coordinate and have uh things in place before before the split Juan if you would like to maybe uh pull up the document and we can discuss specific points there foreign did he leave shoot oh yeah looks like he he has been disconnected but okay fine uh the Hakim day is with everybody I have also added here in the agenda I'm gonna re-share it

okay someone did pull up thank you any specific point that people think is worth discussing uh in this group we can perhaps talk about it any objectionable point would be priority because that's what we would like to resolve first omega's first thing is what is the latest on this numbering bot is that ever going to happen I'm not sure panda is not on the call I suppose he is working on the numbering part but uh unless the part I think he is probably working on the number I thought I did stop okay I mean that's even or not

one one series uses the odd the other Theory as soon as you can forgive them you know the problem is is that it's only works post split and so it's not really a good thing to enshrine because then nuke People's Community will think that oh odd numbered eips or or erc's are you know one or the other category and then you go back and you look at 1559 and you're like that should be an ERC because it's odd and it's not so I'm pretty against even and odd it's it's a technicality yeah do you have to do the technicalities do we have any alternate proposal for this EIP number I mean I have proposed on many occasions even outside of the

conversation of the splits that we should just have a shared document some sort of hack MD some sort of GitHub or Google sheet whatever some spreadsheet that we can all use and just update the latest number that's used in the pr that it's assigned to and just manually assign them like that like we have so many problems with numbering like we should just do that instead of using the pr numbers that's something we can do right now so this question will be equally valid for core eips as well what are we planning to do there are we planning to continue with the pr number and I remember Danny proposal okay well I'm still proposing that it's like roughly sequentially

the only thing is is that we just have a spreadsheet that we look at to see what the last assigned number is whether it's EIP ERC it doesn't even matter about the split we can do this now okay I think that is a good point and perhaps we'd like to get an agreement of all eipi editors because they are responsible for allocating the EAP number and we have been joined by a new editor kind of no I don't know we can call them editor but definitely helping with the EIP number allocation and it would be a work in which all all the EAP editor and that user would work together to allocate so I am open to keep this as a discussion discussion point for next

meeting how do we want to go ahead with the EIP numbering um maybe we can I mean can we just do it like is anybody against doing this it's easy enough and if we find a way to automate it it's easy enough to switch to the automation cool great well I mean theoretically Panda should have automation done at some point but that was you know one and a half two months ago and we don't have it yet so I think I just I think they need to be sequential and they need they need to never be the same um yeah I agree agreed and if the

numbers diverge too much that gets confusing as far as time um people so it looks like so it looks like we are generally in agreement with the allocation of EIP number using one common file that will be shared among the EIP editors as well as a user who are supporting us with the EIP number allocation sounds good I'll make a Google sheet and share it with people and the idea is that like when we merge the draft PR we rename the file uh I think we can just assign the EIP number and have the author do it okay works for me so this is just to get in

the routine of doing it yeah okay do we want to have it like for a particular number um in mind because it would be easier to communicate it to community that from this number onwards whatever number allocation you see is based on this process yeah we added seven thousand something right so let's check on the latest number and whatever is closest to 100 of that perhaps that would be a good idea to start from there even if it is not an ideated number we can start that as the first number sounds good okay

so uh okay let's go ahead and do that and then the other I mean yeah like I said other main questions just like what is going to be the situation with the Bots has any progress been made at all on having the configurability to have them manage multiple repositories uh so as long as you keep the same config for Eep W it won't matter um and to start I think that would be the idea and yeah I I've added configurability to the command line tool I just haven't added it to the GitHub action yet so that'll probably happen shortly okay I have no idea about reviewbot I think Panda said that it would work fine as

long as it has um secrets so yeah I mean yeah okay that makes sense which I assume by forking it will be there right uh we won't be able to Fork because then we won't have no we we won't have issues or um uh like pull requests and code search won't work so we have to create a new repo and push the commits to it okay in that case we need a plan to have the secret uh shared over there as well I mean we would just have new secrets for that okay repository yeah and you can you can transfer issues maybe I misheard but were you saying that you you it's not that you saying

for the fork yeah if you Fork a repository on GitHub the fork has like limitations like it can't have a Wiki a code search doesn't work there's a few like minor things we'd want a clean copy got it got it sorry yeah I think that's the biggest outstanding things but we can see if there's anything on the pr okay so definitely will communicate this to Panda and uh whenever we are ready we are just trying to make sure that our checklists are covered so whenever we

are ready we can do that if at all needed correct I am still there if at all needed um I think it's a good discussion for today considering we still have some pros cons going on and I'm hoping that if some of the concerns of Gregs are already [Music] um answered and the pr is merged perhaps we can have him on board as well and we will get to understand better um we have just two minutes left on the call and uh yeah anything specific very well I have also shared the hack MD file which is for eips insight and I've tried to add this image for you know how many proposals we get every month and

how many gets merged as final definitely we agree that most of the proposals which are not merged as final are from ERC side because the number of ERC proposals are higher but at the same time this is also true that proposals which are being merged on month-to-month bases are mostly from ERC side as well so ERC people are also trying to follow whatever they have been um advise to and get their proposal merged and ERC well that's a discussion for the next meeting um going through the EIP is inside we have received four final eips for the month of July as on July 12th and all four belong to ERC category there is um one proposal in last call and I suppose

its deadline has passed so we will have to reach out to the author to ask him to make a proposal to make it to the final status with three new drafts um the EIP repository seems to have a lot of open pull requests which would need some addressing but EIP editing office hour has been doing great thank you Sam for taking out time and responding to particular questions of new Authors who are trying to follow the process we do have added the EIP editing office our meeting recording from yesterday you can find that in agenda and agenda for the next meeting is also linked there so if people have any question with respect to any specific pull request

please be sure to add it over there we do not take a general review in eipip meeting only final proposals can have a discussion in eipip meeting um well that's all for today anyone has any final comment if not then I think we are good for today and hope to see you all in two weeks thank you everyone we did great we made some progress thank you everyone thanks bye hey guys bye