EIPIP Meeting 111

Transcript

oh oh

n oh EIP IP meeting 111 this is issue number 365 we  could not keep the meeting formal meeting on

uh November 20th so the meeting number May seems  to be the exact same one but we have updated the agenda and we have a lot more to discuss today  this is going to be the last meeting of the year so I hope that we would be covering most of it and  we enter new year with some new good news and some new information for Community who are trying  to follow what's happening in ethereum eips and governance especially on agenda we have some  edits to final proposals for review by editors uh generally speaking we do not encourage edits to  final proposal so we try to bring it to editor attention if this can be merged or not then we  have received an update to EIP 1 we have a few

other topics talking about the revisiting  types and other discussions that has been collected from um different meetings all codev  meetings we take a look at the call for inputs those were open for quite some time and this time  we have some significant news to be shared with the community other discussion and updates from  the past meetings and we'll also take a look at the eips inside so starting for the from the first  item on the agenda that is edits to final proposal we have a bunch of open PR I wonder if we want  to go ahead with one by one or uh does someone want to maybe take a look at it and let us know  so the first one here is PR 89 87 in EIP GitHub

repository that looks like it's fixing a typo I'm  okay with merging that one um just one thing that uh yeah if this is okay just one thing that  has been brought to our attention recently that people are trying to add typo in order  to form some um air drops those are generally eligible ible for making pushes to um these kind  of repositories especially ethereum repositories so a recommendation um that was shared was if  we can maybe create issues instead of making small typo as a PR just in order to make  sure that that individual is not trying to

farm I have one of those listed here in today's  discussion that I see as an example but yeah I'm I'm totally fine with whatever editors decide to  go with this I just wanted to share this piece of information my opinion on airdrops is that we  should just ignore them we're not giving them out so uh if they're actually fixing a like a  typo um then it's good to merge as far as I'm concerned is it the first time I see Sam uh  I can recognize your your voice but I never I don't think I've met you before that's crazy  yeah I don't I don't camera much but I got a new camera so I'm I have to use it yeah good to  see you uh this is Victor if you haven't seen me

before all right anyone has any  objection in closing or merging this PR 8987 maybe we can go through it and we can  like you know highlight if someone has a strong objection on merging or if people  are generally okay but we can keep it for another 24 hours uh and if anyone has an  objection they can add it and after that maybe Sam you can merge them uh the next one  here is 9059 this is for EIP 12 34 and there is another one 9146 um so yeah both of them are  trying to do the same uh fixing of the link yeah

so I think the correct fix for one 12  3 4 is like putting in the commit hash like we um recommend people do for other  repositories so I'll take care of doing that perfect the next one that we have cool the next one that we have here is U  number 914 and this seems like a bunch of Corrections to many different files and  uh the interesting part of this is most of these files are stagnant and as we have  discussed in the P that we would not want

to encourage any uh type of PR for stagnant  proposals I have added a comment over there except for one proposal that is 1 2 3 4 but  to me personally it definitely seems like a farming effect that um that someone is trying to  fix all the stagnant files that nobody's looking at curious what editors  think about merging this one I'm not entirely sure about the hyphenation  changes but like a object to an object is

a valid change um so I'll probably just go  through and accept the ones that are obviously Incorrect and yeah it may be valid Sam but all  of these proposals are stagnant I'd still rather they be grammatically correct and stagnant  but yeah yeah no earlier I think in one of the earlier meetings we mentioned  that we should not be encouraging PRS for stagnant because that will like U  un stagnant The Proposal saying that okay fine there is some movement in this  one uh given yeah that's that's fair yeah all right um the next one here is um  broken link for EIP 908 8 and the number is 9147 I think here it is an effort to fix  one of the document shared by vitalic

which has now moved to a different  website seems like the right thing to do yeah I love to think about this one um I'm also  okay just leaving it broken or maybe copying the file into our repository if we're allowed to do  that um I'll take a look that sounds perfect thank you moving on to the next section we have one  proposal um which is an update to EIP 1 I believe it is by Sam Wilson himself uh he is working on  fixing some of the changes suggested by Manu Sam if you would like to maybe provide some context  to other editors because any changes to E1 needs

approval of more than one editor uh yeah so this  is um mostly like typographical and and Clarity fixes um that one of the potential new editors  suggested um there's also a PR on top of this one um that I need to go through and review so uh  don't look at it yet look at it tomorrow and uh yeah thank you so the next one we have are  actually a couple of proposals so I have seen these proposals in the informational category  informational type and I wasn't sure that it belongs there I have shared the link in the  chat they both seems to be uh performing one

action in except in one of one of the proposal it  is a suggesting about the process and another one about the parameters we are joined by the author  of both the proposals and he being a new author is still wondering like what is the right thing  to do here um should it be informational should it be meta core or what does people think  here so I just took a quick read through 7783 um so it's currently informational  so does this need to be the same for all clients for consensus to work or is this just  like a per uh validator strategy that they can choose so let's say something um okay I so I  don't know so the reason why it's informational

is because because I just kind of got told  to make it informational by someone I don't remember who that was but it was initially it  was core and the reason why it is information and I believe it the rational is that uh it's  basically just an information kind just kind of a strategy to accomplish something that doesn't  affect the core of the protocol and it's uh and you know since it's just basically a kein to  some kind of documentation if anything then can be implemented or not implemented but it's  kind of just some kind of recommend recommended strategy just a recommended strategy and I don't  and like I feel like and and somebody told me that this is more relevant in if it is put in  informational uh now whether it actually is

or not I don't know um I just did what I was  told and they all got merged so so I thought no problem until today when I got a text that  apparently it's a problem yeah that's that's it I I would never call it being in the wrong category  a problem it's just a bit of pedantic nonsense um but so this is like how a a validator would  choose the gas limit for a block is that correct yeah it's a yeah it's kind of uh yeah it's  yes yes it's a Valor chooses but not at the Proto not actually the protocol level but at the  client level right at the ux level okay sense um yeah so I mean it it kind of fits into the  minor node strategy subcategory of core so

you could put it there um I don't know what  what are the rest of the editors think about this I am good with the current  category or we can put it in meta but one other piece of information that  I would want to share here is like why it caught my attention was something mentioned  in security consideration normally speaking when we are looking into an informational Cate  informational type of proposals we don't have anything for um security consideration and  moreover um when we are trying to look into this proposal my first question that came to my  mind was like when and how would you decide that this proposal will move into the final status  and um I believe uh the idea is uh to get it um

on with clients at some point of time so  it may be meta if this is something which is not going to um obviously affect the core  protocol but is definitely something that is being implemented at all client maybe sync  maybe async doesn't matter but if it has to be implemented then it should not be  a part of informational EIP is what I'm thinking so the thing is that right now I think  this discussion is kind of a bit early because it's likely going to be brought up in the future  after pectra I feel like at least I see some at least I know that there are some other teams  other than Aron that will probably bring it up

after pectra and so I really don't know how  to answer this question right now uh yeah I don't know how to answer this question maybe may I  feel like it I feel like if if some cents go with did some others might choose not to but honestly  now I don't really know what is how this appro the approach will be because I it's not the time to  do just the time just didn't come yet so I don't know why Why Can't This Be strandard track what yeah my question to other  details Why Can't This Be standard track yeah I feel like it should be standard  track when it was initially proposed it

was proposed as core but I noticed that it changed  to informational and that's why I brought it here I understand this proposal is currently in the  draft status and one other thing that I wanted to bring here is like uh there are two proposals  and it seems like there could be just one because one is the process another is parameter we really  do not need to have two different proposals for that but it's fine to have it uh two different  proposals um except if a author can get some guideline on like if most of the editors feel that  it is a good category for core we can perhaps keep

it there whether or not included in Petra that's  not important that is a discussion to be done at allod Dev meeting that's not part of this meeting  we here just want to decide the category for this proposal looking at the chat it  seems like three of the editors think that four seems to be okay  any objects to move this into core category yes I would definitely put these  together into one e and core seems like it make sense very well um so Julia if  you would like to U maybe make

a new PR um as um before this call we were  also discussing that this could be in one of the proposals so if you would want to  merge them as one we can have them and we can have that as a code proposal and yeah  it's not necessary to be discussed on all codev just yet because it is not ready for Petra  it can be brought back in Future for discussion yeah thank you for joining and helping us sort this out the anyone has any final  comment on this one before move on to the next one I see a comment from Bumble F here I don't  object but I'm wondering if informational was a way of avoiding being marked as a stagnant in  case it didn't become topical or get incorporated

into an accept or reject timeline by ACD  for a year no I think here the confusion was the author wasn't very sure he started the  proposal as core but someone suggested to move it to informational and th it landed  up in information okay okay Sor sorry now we have met in process I was just going  through um you know the basic definition of how we are defining our meta proposals so I feel  like whatever we are documenting in upgrade meta

is just a piece of information that we are  sharing with the community that these list of eips went into a particular upgrade and uh that  suits more like an informational uh piece uh to be shared with the Community instead of you know  um something that that needs to be added as meta so I was wondering I know in for for few years we  didn't have upgrade meta we dis discarded that we went to have it saved as a MD file on execution  specs but it worked till we had two different specs and uh different processes and now that  we are having a combined upgrade both on consec con uh consensus and execution layers it makes  sense to have these documented at one place I'm

just wondering about the CATE about the type of  this type of EIP where we are listing all these proposals for a network upgrade wondering  what people think about the upgrade EIP as meta the just to add one more piece here um  why I brought this here because I feel like meta eips are more of process like we are  defining process that goes around ethereum it may not be the specs those are directly  implemented on the ethereum code base but we are just telling about the process but uh to  me um this particular uh section it seems like more um information that we are sharing  to the community so yeah but yes please

yeah so I think the idea behind it being meta  is that it is in EIP that describes other eips so it's like um just because it's a grouping  of eips it's a meta um but it's not a process recommendation so uh yeah I guess the only thing  in in e one that kind of L like tips the scales in terms of meta is that um uh unlike informational  eips they're more than recommendations and users are typically not free to ignore them so that  kind of a comment kind of makes it sound like they should be meta because you still you can't  participate in ethereum without following the EP um but I'm also okay making them informational  uh I'm also okay making them core because yeah

they're kind of a description of things that  happen to clients so it also makes sense to put them in core um one argument that I have  in mind I also followed the statement like that it's something that is typically not  free to ignore but that is a recommendation for implementation implementers right and that  is already being implemented in client this is just a listing that we are trying to maintain  and it could be very similar to um a proposal something called as 7675 which I have also  added uh in my later discussion which is uh retroactively included eips that also seems  to me like more informational because that is a list of proposals which are added to um  to codebase of ethereum in different clients

um not as a part of an upgrade but uh later on  and yeah uh so it seems more informational to me however there is another proposal um which  talks about the process of the proposal and um yeah um I'm just trying to figure out U okay I'll try to find out the number but in in  between if if anyone has any any other comments and thoughts it seems like gajender is okay as  info it seems like Sam is also okay as info Sam there all these core proposals are already listed  uh so they are already core and having a list

of it as a core I'm not sure yes Victor please  go ahead uh in terms of I I think the question I understand is between informational versus  meta type right of of these the um for for the for the upgrades uh yeah if if yeah if that's  the case I would say one I I don't have strong preference one another I think they both work but  uh one argument for meta is that the tradition so um the traditionally it it has been there and it  has been using meta and then just to not confuse people and also a follow the tradition it could  be Mata as well yeah that's what I mentioned like it was traditionally being added as meta but we  dropped it for a few years we decided to move on

because obviously people felt that that is not the  right way of documentation and that may not be the right place for documentation of it and we started  adding it as a file but it has been brought back again that to very recently uh I'm just wondering  if this is the time to fix if it was a mistake and if people think that this is something that  needs to be carried on this way perhaps we can update the statement at EIP 1 to maybe give  room to this kind of uh eips added as meta yes yeah yeah that's perfectly all right Sam  yeah um either way we can go about it like um we we can have it as informational because um  it it seems more fit over there but if you want

to make it metam maybe want to update the EIP  and the other EIP that I was trying to mention which I feel like is a good fit for meta is  Network upgrade inclusion stages here it is talking about the process it is EIP number  7723 here it is talking about process like how Network upgrade should be done and like how  eips can be proposed and things like that this is something that needs to be changing maybe  it can be kept as a living proposal as well um but uh personally speaking I feel like all  these upgrades information that we are listing should be a part of informational I don't  know should we open a call for input for this uh uh I agree I I would answer yes to  Sam's question in the chat uh all of these

agree with Pua they all seem informational  and I like the meta the definition of meta as referring to the EIP IP issues um whether  or not a call I mean a call for consensus uh on GitHub would be nice just in case one of  us is missing something or I don't know to remind us to read through one by one to  make sure they're all informational but all right um yeah I I think that's a good way  forward uh we don't need to decide everything on the first call itself um it was just a  point of discussion that I wanted to bring

it to editor's attention and maybe we can have  a call for input for this one and try to collect what other people and uh Community thinks about  it definitely call for input is more collecting about editor point of view uh but we will  also get some feedback from Community if needed we can also share it with all codf to  yeah think uh collect what they think about it with that we can perhaps move on to the next  one I'm so sorry today we have a lot of discussion topic so the next one here is adding non-core EIP  to upgrade meta or upgrade EIP I'm not calling it meta for now because that's under discussion  under question so historically when we are listing any upgrade EIP we list all the core eips  those are being selected or had been selected for

a particular upgrade we do not include any EIP in  that list if that was not part of that upgrade for example the networking EIP historically has never  been part of any meta e so um this is the question that I want to check with editors what do we feel  about listing um networking or any other EIP as a upgrade list or upgrade e because generally when  we talk about core eips we say that the core eips are the eips which are selected for an upgrade and  that's kind of like Define line differentiating between differentiating core between any other  standard track proposals that we have on it

basically this is a comment that is coming  from the all codev meeting I believe there is a proposal which is waiting to be added and  I just wanted to bring it to editor attention uh so they can decide if this is fine this  would be accepted when that is added as a PR sorry I think I missed the the  initial question for this one so the question here is historically we  are adding all core eips as a part of upgrade um EIP do we want to start  including networking and any other yeah yeah whatever goes into the for can go in the meta  EIP I don't it doesn't need to be core specific

but that's the definition of core EIP only those  eips go into goes into upgrade not networking or anything else anything else can be asynchronously  added it's it doesn't need to be a part of an upgrade oh I see so I guess yeah  you can make a networking upgrade without having a hard Fork yeah so  I don't know if they're appli to the same time then maybe it makes sense  to add them but otherwise no I guess not okay um I don't know what  other editors think about it yeah if basically it requires a hard  for kind of a coordination so yeah it makes sense to have them uh so basically  we basically need to decide on perp basis

whether they belong to the  network upgrade upgrade or not those uh require half work to coordinate  should they be included in the core core diip or they can stay in network it feels like uh  it's it's fine either way but either we have to um update our definition of core eiib or  uh we have to kind of um rule them out in the in the inclusion EIP so I think the  core eips are the one that changes the consensus rules uh so that way in my  understanding it's very different yeah so yeah that makes sense all right  uh so maybe we might want to add it

to EIP 1 at some point of time but  it makes sense that if a network EIP that may require hard Fork kind of  coordination and without that proposal um um like this hard workk is not possible kind of thing  then it may be listed as um listed in the upgrade EIP we can perhaps add this information  I think I I picked it up from fellowship of eum magician I can go back and update it over there any final comment on this one yeah I mean  EIP is like peer Dash or maybe full Dash I don't know how would you classify them because they  are lot of networking and then I'm not sure

how they change the consensus because they do  change how for example Fork Choice updates work and all that so they would affect consensus as  well so we we do have some kind of gray area over here so I think You' probably split them  in two so you'd have the networking part and then you'd have the core part and the core  part would depend on the networking part I guess yeah I think pias is one of those  proposals which are being considered here because this is the first time we are having  this proposal which is actively um you know tested and it it is as as parallel as any  other testing that is going on so yeah if

editors are fine with that we can perhaps start  um um sharing this piece of information because historically we had been just uh sharing that  only core eips are considered for this upgrade e list and uh that goes into uh Network upgrade  however even if networking eips are not making consensus changes they are sometimes considered  critical for inclusion um at the same time so they are being listed as a part of U upgrade met  not meta upgrade we'll figure out what it will be uh the next one here is here is a list of two  proposals one is a 7675 retroactively included Eeps I had two questions which I left as a  comment in Fellowship of ethereum magician

I don't feel like the title is appropriate  because this contains a list of um core eips which were asynchronously added it didn't mean  that it was retroactively added retroactive uh in general gives me an impression of something  that was done um in the past and it was not it could not have been done at the time but this  list may contain some of the eips which were done just before the upgrade and sometimes just  after the upgrade it has nothing to do with that upgrade it just that it was not required to be  um implemented synchronously and clients were free to make it async uh updates uh upgrades for  these particular proposal so I had two comments here number one maybe we can change the name of  this particular proposal to reflect the category

um clearly we can maybe call it as like atypical  integration of EIP or maybe um irregular adoption of these proposals in client uh code base and  the other one it seems to be informational more than meta to me because uh this this is not a  process again this is a piece of information this is a list of eips which were added out of the  order out of the general order of going into hard Fork so if these are the Eeps that I'm thinking  of they all apply from Genesis so they would be retroactive um but I I get your point about  not necessarily all of them always applying from Genesis so that makes sense maybe  outof band uh EIP would be a better um

description for them but yeah I also really  don't like this EIP because it's never going to go to final um that's right yeah that's  why I was wondering if we can keep it as an informational we can perhaps make it living  and this can continue building as a list of proposals which are not added via an upgrade one  of the um rules we have in E what is it 5069 the like handbook is that we don't maintain lists  so I'm probably just going to open a call for input to withdraw this okay that has a very strong  argument over there all right um wait who's we in that sentence though like it is is Tim Andor the  EIP the client coordination process offering to

maintain the list we don't so we don't allow lists  in the E process the the whole like we don't okay like our our process isn't designed around  handling things that gets updated constantly right like we're designed about getting a document  and getting it to like an immutable State and we we're really bad at handling things that need  to be updated so um I don't want us to be like unless we Define a new process for handling  these kind of eips I'd rather just not touch them okay yeah I just I just looked up 5069  and I saw the section I mean I can see how it feels like a ex a non-exhaustive or non-static  list or borders on registry but it also feels like maybe should should it just be like should  they do a new informational list every after you

know like each time they do one or something is  it is it about Discovery are is it because they search the list of metas to get a a timeline of  when each client change went in or something like I I'm I I think I'm not understanding the  point of this this thing that wants to be a registry I think you'd have to  ask Tim I'm not sure okay okay fair uh very well the next proposal um here is  a 7723 and that is also kind of talking about some kind of Le no no it's it's a process I  guess 7723 um it's talking about adding an additional stage uh which is called declined  for inclusion and that's a process yeah so I

mean particularly I don't um feel the importance  of this proposal if something is not uh accepted it can be brought back we really do not need  to provide it um a status but I'm fine with it yeah what do people think that we  should have this additional status called DFI added as a process  for Network upgrade inclusion stages um I think it's reasonable  um this is per Fork so if they decline to include it per Fork that makes sense um does it mean that anyone who get declined or  any VIP get declined for inclusion will maintain

that status like when can they come back to review  draft and and pursue it this is a separate process so um this document that Tim's written up  here is like uh a meta EIP that defines uh the hard Fork informational eips and  then each EIP in that that informational one has a separate status that  isn't related to the document status I'm a little bit unclear about like  documentation of these stages like where would people go and find it so for example  um um 7723 just suggest that these would

be the upgrade inclusion stages and let's  consider Petra so if we are looking into EIP 7600 then we will be having all these  proposals with um these specific statuses and if so then the declined for inclusion will  be added there like this was proposed but was not included I feel like it is too much of a  less thing so yeah so um this this EIP doesn't introduce new header into the Preamble  um this EI like 7723 is just saying like when you're creating the pectra like the EIP  for pectra itself what headings are in that EIP so here let me let me pull this up you  said Petra is 7600 yeah I think so okay so

um how do I share my screen with  this thing share share screen I need my this all right so um you see here  like there's this EIP schedule for inclusion EIP is considered for inclusion um in like  in EIP 7600 um those are the headings that are defined here in this EIP so this meta  EIP is just describing how these hard for EIP should look like uh EIP 2537 isn't  modified to say it's scheduled for inclusion it's it's just the meta document that's  that's modified does that kind of make

sense yeah okay okay I get it and it will  change when uh when we move on to different I I feel like it is very close to the  uh different stages that were defined uh in a cat's blog post so when we move into maybe  public test net we would be included for scheduled for inclusion and when we'll be moving into final  then it will be added as included here so these statuses are completely separate from final draft  and review and all that stuff so like a document could be draft but still scheduled for inclusion  that's all right yeah uh but when we will move into um um SK schedule for inclusion means here  that are uh being on testet or devet right is that

a correct understanding uh let's see so scheduled  says um that implementation is underway um but it doesn't say anything about whether it's on a test  net or a devet or anything yeah but I think that that is okay we we are moving from proposed to  considered I understand proposed can be a list consider can be a subset of that which a client  Dev agreed to work on and they go back and start implementing those things then we move it for  devet for testing purposes I feel like scheduled for inclusion is the best place for that when we  move it to devet and keep it there till we are on the uh public test net when it is moved like when  it is deployed on the main net then it becomes

history and then we can make it as included I'm  not sure if this is mentioned but I think this is a good flow that's yeah that's what it that's  exactly how it works okay perfect okay and uh this uh these stages could be find in the uh upgrade e  that we are going to follow and I I feel like um I noticed a comment from Kenda it seems like he  thinks uh that this particular proposal is also kind of informational proposal so I don't know if  we would want to maybe open call for inputs for proposals which were discussed today and just to  make sure that they are into the right types and categories yeah so uh EP 7723 the one  that Tim's written up here hasn't been

like formally considered yet um I'll  ask Tim if it's if it's ready it's in review status Sam yeah it's in  review but it hasn't been like CFI we haven't made it like an official  meta that we're going to Force okay okay perfect Okay cool so those were mostly proposals  which we brought up for discussion here and we have only three call for inputs uh Sam if you  would like to quickly go over all of them I believe two of them are already closed uh sure  so um Greg and axic have been removed as editors um if they want to come back they're welcome  to but for now all of their permissions have

been removed um and then we have um ISO 4217  which is um somebody's asking for a specific exception for this one document um and a little  bit of backstory so ISO 4217 is the like standard that defines country codes So like caus um UK  all of those like two-letter codes are defined in this standard the standard is not free so we  can't allow link to it links to it but they do publish just a list of country codes without any  Associated documentation for free um and somebody wants to link to that list um so my opinion on  this is that we shouldn't allow links to the

list because I mean what good as a list if you  don't have the standard that it goes with um but uh yeah if other people want to comment  on this um please do I'll close it later today thank you Sam um move on to the  next uh item on the agenda which is okay thank you gaja yeah every ediors please  take a look at the open call for inputs and feel free to add your comments  what do you think about the proposal um the next item here is other discussion  and updates from the past meetings so um we

have recently received some interest from client  developers interested in being editors reviewers and helping out with the EIP editing process for  them uh we have created this a short um onboarding checklist and Sam has a list of um rules that he  generally prefer as an editor while reviewing the proposal um we wanton to discuss here if these  things could be formalized we should be adding these things for um new editors reviewers and  authors um yeah what do people think about it yeah so feel free to leave comments on  the document um and I guess I'll open a call for input adding it to e one at some  point and we can approve or deny it there

yeah uh I mean I have a few thoughts on this and I  wanted to share it with the group to maybe collect some more feedback on this one uh there are two  two or three documents under discussion I feel when I had a look at Sam's document I felt like  that is a very good resource for someone who is documenting the proposal and EIP 1 talks about  like the process uh and guideline that helps a new author to maybe document the process or  someone new to the community to learn about it so if we can perhaps add it to what belong in a  successful EIP section of EIP 1 that would be good for authors as well as editors and these can be  uh looked into before someone um goes ahead and try to document The Proposal so this can be added  as dos and don'ts um is what I think about this

one uh for Sam's hackd file that is there that's  very good list of like what author should uh keep in mind while they are sending a proposal for  review and and similarly I feel like EIP 5069 is more for guidelines for editors so perhaps we  can um include some of the information that we are sharing with the onboarding document uh add  it over there as you know when we are talking about dos and don'ts we can um add more to it  and uh and we can uh remove some part of EIP 1 where it is like um EIP guideline we can have  a small section there and we can have a bigger

section on uh EIP 5069 yeah I don't know what  people think this is this was my general thought process about these two uh documents that we  can perhap put into com put in a place where a community can have access to it yeah that's  the point like I want EIP 1 to be concise and that's why I want EIP 1 just to refer to 5069 for  uh all the roles and responsibilities of editors and not list everything right over there in  E1 however Sam's rule seems more good fit for EIP 1 because we do not have um any author uh  guideline separately E1 is supposed to be the one yeah people please feel free to add it on the doc  yeah sure um then in that case maybe by the next

meeting we will try to bring it up as PRS and  then we can perhaps further discuss on it and we will try to share that PR in the Discord  channel before we bring it to the meeting so whatever feedback is there we can incorporate  it and bring it to editors for making a decision if possible um yeah it seems like people are  generally okay to have these things documented somewhere as a part of e and not as a part of  floating hackmd file going on here and there so that's good the next section that we have is  EIP numbering by E editors um there is this small thread that's going on on caters EIP editors  um Discord Channel U people may take a look u in general there is some recommendation for how  EIP numbering should be done maybe one of the

associates um have not been following it properly  but it's a good practice we can perhaps do that moving on quickly to eips Insight I see um  ven has joined we may not have um a lot of time to discuss um everything but yeah over to you vien  I I I see you have added a comment that you would like to demo some of the tools so maybe if you  can quickly take couple of minutes on each of the tools and try to finish it up in next 5 to six  minutes yeah thank you Puja uh I'm Shing my screen so we have added a couple of tools that would be  uh helpful for all the editors over here and the first tool that we have added is the individual  charts for every editor so far and you can compare

the performance individually for them and also  download the reviews that they have made it would be better for compassion like this and this is  the activate test timeline uh scatter plot and this is mainly based on the times that they are  submitting their reviews so uh you can also um select the filters and choose the uh timeline that  you want to find out the activity of the editors and using this you can U find out what is the best  time to either expect a review from the editor and Sor and uh regarding the update in the EIP  board we have updated it such that so previously

we were giving all the PRS that were um pending  for the open I mean that are pending for the review from the editor but it was also including  the pr that are waiting for the author's attention and not the editor's attention so we have modified  it such that it will be only U containing the list that that requires the editor's attention and not  the author's attention with the help of s we were able to complete this and this is the new chart  that we have added and this contains the total number of um PRS and issues that are currently  open in eips ercs or RPS for example in eips it is it is currently showing 86 which is the sum  of 880+ 6 in the eips repository it can be quite

helpful for comparision uh I mean for evaluating  the performance of how we are doing and everything and this is another new tool that we have  added this uh this is this can be used for getting all the eips that were authored by  a particular person and this can be uh quite helpful to keep track let's say like client  you can get all the eips that were authored by this uh author so this can be quite helpful  for keeping track for editors as well as for the authors who who are um maintaining them  and we are also providing the RP data uh we

have noticed that RP data is currently not  available elsewhere so our website can be quite useful for viewing the RP data you can  see all the data over here and also we have a dedicated page for that and we'll be adding  more uh information for other enthusiasts if anyone wants to visit that this will be quite  helpful for that yeah uh that's it from my side that's awesome thanks so much  for all your work and thank you s wison you're raising the issues  and that is quite helpful for us as well I would recommend othered  for doing the same as well thank you

thanks Vin yeah I think one of the issue that  you have solved of EIP board was highlighted to me by Gander Singh so thanks gajendra Singh for  highlighting that as well um I would sincerely request all the editors to maybe um take a look  at the tools those are provided I believe that that would be helpful not only in just like  uh understanding and keeping track of how we are performing as well as when you are opening  um um the list to maybe review the proposals um going through the emails or the get her  notification you can just simply download the CSV file from here and try to take a look at all  the open proposals and yeah that's quite helpful thank you team one thing that I think I have  added as an issue yesterday I would love to see

more information about RPS as you mentioned that  rips informations are not available elsewhere I was trying to learn more about their meta  and the process like how someone can add a proposal to rip there is a small community  right now they frequently meet at rollup calls but those calls are not governance related call  so it would be nice to add some information about how their governance is being maintained and how  people can learn more about uh layer to proposal so yeah looking forward to that yeah we'll work  on that uh I see the issue that you have raised on our gup and I'll welome that thank you and  also if there there are any particular tool that anyone among the editors or onboarding  editors needed please let us know or raise an

issue in the GitHub so that we can work on that  and provide it to you thank you I can think of one tool um like you know um as I was talking to  Julia this morning we had some conversation around that he didn't know how to like you know proceed  and how to document everything there can be many more authors who may have such kind of problem it  would be interesting to see if the team can maybe create a UI for EIP template like people can just  input the question answer to the questions and it can generate a MD file and that can be submitted  but while we are doing it maybe with help of AI it can also assist them to figure out what is the  best suited category types and category for that proposal if we can have a UI for that that would  be awesome I'm just a we work on that yeah thank

you cool um one last announcement for today uh  that is the EIP editors Workshop as I mentioned earlier that we have received a few um interest  from developers to help us with the EIP process we are hoping to have an editor Workshop in January  I have created an agenda the meeting is planned for um January 6 January 17 at 1600 UTC um I'm  hoping to maybe keep it simple keep it um you know um introductory for uh new people or interested  parties and one of the main goals of these meetings this meeting this particular meeting is  to onboard more reviewers than uh editors because

I feel like we do have uh editors who are already  engaged in the editorial job helping out with that but if we can get technical review that would  be nice to have so more reviewers on boarding is my goal there but I would love to see anyone  on the call all who may be interested in helping out with EIP ERC or rip reviewing as well as  editing so please note down the date and if you have questions you can also list it for editors  right there in advance so editors may be able to help with that so that's all on that um as um as  we know that we are having this call once every month so we are going to have this call next time  on the third Wednesday of the January which is going to be oh for some reason my calendar froze  okay which is going to be on 15th of January so

thank you everyone for joining here see you all on  15th January at 1500 UTC happy holidays everyone n

oh n

oh n m

oh oh