EIPIP Meeting 97

Transcript

welcome to eipi meeting 97 this is issue number 302 on E cat herders SL EIP I so first there is this announcement that the ethereum cers GitHub repository address has been changed so please uh make sure to reach out eum caters GitHub repository at github.com cat herders on agenda we have a first item called EIP process standardization then there is a list of open PRS U there are certain PRS with respect to proposals

which went into final but there are there is a request of making small edits mostly with respect to typo we'll go over call for input and uh then we have some discussion continued from the past meetings we have added eips inside for the entire year and uh yeah uh that would be all for overall discussion today so let's begin with the first item on the agenda which is e process standardization and the first item listed here is web page rendering so we have been approached by a few groups to understand what are we thinking of a uh rendering rip related proposal but since

uh the repo split of EIP ERC we are also discussing the rendering of EIP ERC uh on a certain web page uh so I would let Sam explain I know he has been working on a rendering part so Sam if you would like to maybe let us know where we are on that sure um I haven't really done anything over the holidays um you can still see where we're at um at github.com ewg um yeah so eventually I'd like to add support for RPS if they want to become a working group and um yeah as long as they follow you know a general EIP

structure of a repository the scripts can can import them so yeah it shouldn't be too much work so there was this uh important point was like the process if they would follow the general process or the GitHub repository structure because we know that most of the pages are with the GitHub repositories that we have I wonder if we can perhaps discuss the RP process documentation uh we may use some of the you know Clarity on that part uh for example what could be the type and category for roller proposals and how should we move it forward we don't have much documentation around

that yeah I'm not really sure how we want to approach it um I've kind of been just working on um the working group stuff and was going to work on that after um but you know I'm I'm not the only editor so I wonder if anyone else has any thought on this the one concern that I specifically want it to be addressed is the type and category thing for example uh currently

there is only one rip in the RP s GitHub repository and that is standard track core as we know standard track core are mostly eips which are on the E which are for the ethereum main net and uh most of them when get Di deployed are marked as final now the special case would be when this RP gets to final and if it it retains the category as core uh that would be a core which is not deployed on ethereum Main net would be marked as final and if we want to keep it as is do we want to update the definition of a

standard track code uh in EIP 1 so I guess my opinion is until we have a unified process I think they can do whatever they want this is interesting I think they have actually proposed their first uh proposal here on the uh eips GitHub repository to create room for uh especially for um RPS I guess I'm trying to find out the link here so I can share what would be the right approach I

wonder because the RP meeting that happens they clearly say that it is not governance related meeting and we only have editors meeting uh as EIP meeting so this is a PR where an informational level proposal is added to reserve pre-compiled address range for rips so they are definitely trying to align with the EIP process but Community can use some clarity I don't see Matt on the call I wonder gajendra Singh if you have any

thoughts or any suggestion how we can move forward with these proposals to be maybe included in the ABAB process in long term I don't really have any opinion regarding this work here maybe we can check on the Cod of call what people think and how we should align if we do not have enough editors here to provide feedback or thoughts yeah okay let's move on to the next one we'll try to get it included in the next agenda item in for meeting moving forward we have a few um open PR

with respect to final proposals and those are fixed typos the first one here is a PR number 8061 to fix 684 and I have added two more how do we want to go about it can someone maybe take a look and yeah they're all they're all merged okay perfect thank you I wonder if my GitHub is not updating it but that's good very well the next item here is call for input so we have two call for inputs added here 291 and 293 the deadline for both call for inputs are completed Sam if you would

like to maybe provide a brief summary and help us with the result and if we want to close these call for inputs sure um so the first one here is ADD security consideration to ERC 1271 um there's a security vulnerability or or flaw or missing piece of information in 1271 but 1271 is final um so if you don't object Ginder I'm going to not change um 1271 um because I think I'm the only editor who's commented on this so far so are you okay with re in a change to 1271 or yeah I'm fine I'm in all right

perfect sorry I didn't mean to cut you off there yeah no I said just uh I'm good with uh what you have decided to reject the change okay um yeah and I think the other one is similar this is adding a new informational EIP describing flaws and erc20 um yeah I'll take I I'll close both of these later if you have any comments just leave them on the those PRS or issues and I think that's it for calls

for input perfect thank thank you Sam and with that we can move on to the next item which is the discussion continued or updates from the past meeting um so there were a handful of proposals to update ERC 1363 which unfortunately we could not address in the past meetings they have been listed by a user uh in the comment so I wonder what editors think about it there are three updates adjusted for 1363 um these are pretty substantial

updates um so I I'm in inclined to say no um yeah that's kind of my opinion on these okay if we don't need to do them I think we should just leave the IBS like that we don't unless the updates are really required yeah even then I think we can just tell tell the author to make a new EIP yeah correct that is the right way to do it that the new EIP override is

the previous one and we sort of uh in the uh UI ux experience we can basically tell the user to go to the latest one yeah perfect I'll I'll take care of commenting and closing these thank you so much them moving on um there were few questions those were like a uh raised earlier maybe to get some clarity and if possible we can perhaps document even if it is not officially document somewhere

in notes or summary um why final eips are immutable specify conditions under which final eips can be updated I think uh this would be useful for accepting pull request for final eips if we can create this as a guideline for user then in that case they may perhaps understand when to create a new proposal Al together or when they can perhaps uh send PR to make changes so just like a little a little document that's like here are some non-binding rules on what is a chain like what we are allowed to change what are we allowed to change yeah I think that would be

helpful if we can document anywhere that would be nice yeah exactly yeah guidelines um yeah cuz like things like formatting changes um as long as they're minor and don't change anything substantial are fine spelling mistakes are fine um but you know anything like you know adding text or changing the meaning of things um it's probably not fine yeah so EIP 1 is considered to be purpose and guideline document uh do you do we think that we can perhaps make use of updating it I'm sorry if I over spoke somebody please go ahead yeah I was saying yeah because if

the text is changed uh somebody competent actually needs to check whether the semantics of the EIP have changed or not I mean we can sort of figure out few of the things but there are some technicalities where you know expert opinion slash the EIP author's opinion is needed and yeah that that's why we should basically try not to have too many text changes and the language changes in the E yeah exactly I am not sure maybe an EIP

template would be right place or maybe EIP 1 would be right place to document um these changes changes not changes actually guidelines I meant so you you like one of us sorry wherever our chapter lives I think that is the fine place I mean we can have a short paragraph over there yeah sure I think that's a good idea um okay yeah that sounds good okay in that case then uh we will get

the link and we will start sharing that link with people so they understand very well uh the next item here is uh another proposal that was discussed in the past meeting which was woring scheme for eips um I don't think this proposal has been merged yet in the draft I can see this is still open and um like uh also shared a little bit change to the proposal um to have versioning but this versioning will help us understand the status specs patch I was hoping that if we go by this this might help bot a bit more to you know

work accordingly we can use the values there with status and everything else I would love to get any feedback if people have here or maybe add later on so I just have added the link to ethereum magician um and I'm aware that there was some discussion going on in on Discord Channel I wonder if there is any update on moving ahead with this or yeah if people have anything to share here um no updates on the versioning yet at least for me yeah same here no opinions yet

okay um very well I find this proposal quite interesting and I'm looking forward to get this merged and draft and yeah I have shared the link here in the agenda for people to add thoughts on Fellowship of ethereum magician with respect to this proposal moving ahead on eips Insight so I have added summary for past three years here like I was just trying to uh collect data with respect to how we are doing uh in terms of proposals that are being received and how many proposals are being moved to final status I'm very happy to share that this year 2023 we

have in the past three years we have increased the number of proposal that reached to final status and as for December we received three proposals in final all three belong to the ERC category for last call we received five two eips two ERC and one rip so here is the thing like this rip proposal that was added as core proposal and there is no history of The Proposal getting into draft or review it just went to the last call so that's something that we would like to breach at some point of time and um yeah the proposals going into

stagnant has also decreased significantly last month only four proposals moved to stagnant status so this is a good news and thanks to all editors contributing to help move these proposals forward we are in a very good state where we have increased numbers of proposal move to final thank you all and thank you for keeping us organized yeah no I'm really happy we have been trying and this is like third year and the result is definitely better here all right uh people can check out

the hackmd or eips insight.com for a different charts and details the next one is EIP editing office hour so uh this meeting is organized to support new and existing EIP authors if they have any pull request that they would would like to uh discuss with editor they have any question they can reach out to EIP editor and the meeting is planned for January 9th at 1500 UTC this is issue number 301 at eaters eipi GitHub um we are hoping to support new Authors to document their

proposal in in a well way and we organize this meeting every 2 weeks to answer any question so people if you have question or if you know someone who may be in need of some kind of support with respect to documenting an ethereum standard irrespective of type and category core ERC RP please feel free to share about this meeting we would be happy to extend support and I think that's pretty much it I'm quickly taking a look at the summary section from the last meeting I think we have covered all the open items from here so this quite short but uh I look forward to have more

discussion on governance and streamlining the EIP process anyone has any thoughts final comment they would like to share I think we good thanks so much P all right um Before I Let You Go um just one final question I missed on this part what about the meeting time it was mentioned by one of the EIP editor that 1500 UTC may not be working we moved here because there was no protocol meeting there at this time uh do we want to keep it or is it okay to move it by

an hour an hour hour is going to affect my etherum just update meetings we can move early or we can move a little bit more later I mean I suggested a time we can move early as well I mean that is also fine okay Sam what is your preference is that okay to move it to 1400 UTC so 1 hour earlier um yeah yeah I can probably do that it's a little a little early for me but it's okay all right as of now after the proposed timings as well I mean we can

move later as well 17:30 yeah because I will anyway be completing my eum Js update meetings and post that I can join this okay would that work for you Sam 17:30 yeah yeah I think so Thursdays are pretty open or whatever day this is Wednesdays are pretty open for me yeah okay um but I I don't think we should decide anything until like more than two of us say something cuz yeah yeah no I I wanted to just collect your feedback thoughts here so we can propose alternate timing in theot channel to maybe get some consensus there Perfect all right so let me propose 1400 and 1730 and whatever votes like maximum

votes we will collect we'll try to keep it that one for the next meeting planned on January 17th sounds good talk to you then thank you thank you everyone for joining us here bye take care bye-bye