EIPIP Meeting 13

Transcript

all right and we're live hey welcome to eipip meeting 13. there the agenda is in the ethereum cat herders repository under eip issues number 25. the this is also being live streamed is it on the ethercat herders live stream yeah eve cat herders live stream on youtube it's on the ethercat herders live stream uh thank you all for coming we just had a really good session with the youth magicians about the eipip meetings that i'd recommend people go watch if you want to know more about the meta process of how eips came together let's just go right into the agenda

which i saw the first thing that was that was moved up to being the network upgrade process which you had a note on that you wanted to talk about that first edson do you want to introduce that yeah so um it's something that we started with uh uh statuses separating the network upgrade process we never actually finished it before we started talking about onboarding and updating the ap template one thing i wanted to suggest for writing out a new process is oh like one one method for creating solutions which is um there's two parts in

creating a solution so you have the idea and then you evaluate that idea something that we can do uh something that's used in creative process is um uh creating multiple different solutions um before the call and then just having um so for like for the hard work process it would be multiple different ways that hard fork coordination could happen and then once we have a selection of things to choose from we can evaluate them and then break it apart and see what works and what and maybe deconstruct and combine solutions to have a better solution that we would have gotten had we just gone with the first thing we thought of

does that make sense yeah i like that so the process is pretty simple it's just instead of just creating one solution we create say um 10 different processes we can choose from quickly present them on the call and then as a group evaluate them if that makes sense to create uh one process that we can decide on the has anyone i've had i've had one in my mind i've been i just need to write down but i i mean i feel like it would be better if there was more contribution than just myself

is there others that are interested in writing out a a like if we if let's say we scheduled for doing it for the next eipfp meeting is there are some other people that want to draft even just roughed ideas on how it works together i can uh draft a few sweet i almost felt like we should not work together but just kind of spend a bit thinking about it and see what we come up and then come together if that makes sense uh that makes sense like have it prepared beforehand and then discuss it as a group they're evaluated as a group that makes sense someone else had a call had a comment

i can also maybe draft some ideas sweet the i have it makes sense to me a couple of things i would propose in this when talking about the network upping process is that we release it before we do the eip changes the eip status changes and that it be its own separate eip which i think we've talked about before that's just has cemented more on my and recently but that's a good direction why do you think it should come before the changes and the eip process because the if we remove the hard four

coordination part from the eip process and then like accept it is no longer a status then there's a huge opportunity there's an opportunity for un or backlash from the community because there isn't there's like oh well how do things get put into maintenance and so i think it would be easier to have that defined somewhat even if it's not fully defined i don't think we want to define it all out but we should at least have an eip that we can point to people saying oh yeah well we separated it and here is the proposal for the other part not just we separated it and nothing is and there isn't anything for the okay

i think that sounds really good i think the separation is needed and i also think that which we've discussed before obviously and kind of everyone kind of agreed that there needs to be a separation but also having it explicit once we make the changes even if it's in its infancy like just like a basic form is important i'm not sure if this is the right point to bring this up but so it's just coming off if we want to talk about another time but i had a comment on the agenda thread that i feel like there should be a status for a state of the art or mainnet eep and i feel like this is if

we have an additional you that describes what the network upgrade process is how it's not tied to the roles of the editors and the repositories and that just becomes sort of like a bookkeeping duty uh for the editors to change an ep status to state-of-the-art mainnet once it's like it's actually included in the hard fork so there's actually oh sorry go ahead yeah i was just gonna say so micah had rebutted this point and he was basically saying that his general view is that the eve's repository is not actually just focused for ethereum it's more focused for any ethereum like things if another project is used in the evm maybe they want to have a finalized eep

that they're using that's not ever going to make it onto mainnet ethereum where i am coming from a different point of view where i feel like the east repository is for ethereum and if other projects want to use that then they should develop their own procedures for maintaining what standards they have yeah i'm with you on that if they i mean like all the other or the every major evm chain has their own version of eips so i don't see why anyone would eat from other chains would even want to like no one from other chains has even asked to use our repo so i don't see the point there i think so from my understanding

um looking at other like smart contract platforms they actually do use the eap repo but they use like erc's um so they use like they have their version of erc20 that's based on the uh eip20 and then they have their version of non-fungible tokens that was taken from the ap repo um but as far as standards go usually standards are platform agnostic just in other industries and they exist there to be kind of like you know like experiments exist and then you can reproduce them it's kind of similar to standards it's difficult with ethereum this is a

different um very different paradigm if i have an upgrade for tcp then we can still negotiate our protocol using like an older version of tcp potentially where with ethereum once we make a network upgrade everyone is on this there's no way that i can say i'm using this old version of ethereum that's just a complete different fork of it and so i i feel like that should be represented within the process even if it's just a bookkeeping thing and the actual selection of those eaves are in the totally separate discussion the the so i i definitely need there is like what is ethereum the definition of what is

ethereum as in what is mainnet should be kept track of somewhere and where how the best way to do that i'm not totally sure but the i definitely think it's worth something we should keep on like keep on the agenda and keep bringing up until we figure out the best way to do it and i think i'll go ahead edson uh one thing we we can do say we define the network operating process because currently we don't exactly know what it'll end up being we could just create a new header that tracks that um as a compromise that way um it doesn't have to be tracked manually it could be tracked i mean obviously you have to manually edit the

header um but um you we could have another section in the eip website that just tracks mainnet and that would simplify it for people who are trying to create a new client um so they have somewhere to look at in addition to the yellow paper um the only thing is light client made the point that the that there would be overhead for editors to go in and merge those changes all the time so i think that a good in between would be having those hard fork processes as separate eips but have them be an active status so what that means is there never needs to be editor input in order for

it to be merged an active eip can continually be edited and merged without consent of the editors is how we can change we is how we can frame it right now an active eip that's not the case um because like i think for an example um i think eip1 is an active vip like that's the status but um if we make it so that we can just have these active eips be able to be changed whenever except for eip1 i think that would be okay so i actually um we had already proposed that so i think efi we're going to make active but uh well my client was saying

uh we should just have the status instead of creating a new ap oh i see i mean if we so the like black client that talked about how we could make a permissions that there are there's a group that could do tags and edit tags if we could make it so there's a group that would be able to edit that field that isn't the eip editors so so it so it if it's bookkeeping then we can have permissions for bookkeepers that aren't eip editors i feel like the overhead on editors is pretty small i mean we're not doing that work upgrades that often and there's really not that many use that go into it should be pretty quick for them to see okay this this is mainnet

this was included in the hard fork yes we're going to update the status for that yeah cool also i really don't like the idea of the active eeps i think that eep should be static standards and i feel like this is a pro this is a sort of a tooling problem like the the reason we're going to have this active efi eve is because we don't have a better place to necessarily put it i don't see why we can't have this as a part of the eavesdot ethereum website where someone is modifying the repository i don't see any reason well i don't see any difference between having an efi ease that's active all the

time versus having on a website somewhere because the process the network upgrade process is already different than the eeps process so having an active registry is really just trying to hack something into the standard process that can live outside of this so your proposal is to completely have a separate repo with the hard fork process right i i don't really care how it's done it could be a separate repo it could be a separate folder in the eep's repo it could be a form whatever i just don't think that the registry eavs make a lot of sense it does feel hacky sometimes what were

you saying puja so if i may break this question into two parts like there is one part about active status another part is about efi we are talking about efi e in order to be in the active status so i believe that uh for active status we are clear that it is required not only for efie but for the eip1 and possibly we would have a couple of more eeps that that may require this kind of a status and for efi uh the registry i think that if it is just about maintaining a list i may partially agree to like friends saying that it can be maintained

separately but since this is everything related to protocol i i feel that if i if we give that efi the status of if would help people understand more about the level of importance of that list and the protocols that are there i think like something to consider with the efi if it isn't active um is it it won't actually track what's deployed um what will track what's deployed is an eap that is a hard fork eip where it tracks the hard work names like mere glacier uh what eips are included so berlin eap um uh

bls is included it has a list of eaps so that that will be its own eap which you can look up and see what's i guess what's canon to ethereum what's in mainnet um and then efi would just be tracking what's currently being discussed um so things might go into efi and things may leave efi does that make sense right whatever goes under the main net deployment that is separately uh listed in the hard fork meta for that upgrade but the eaps that are currently under consideration we do not have any specific place to kind of list those eips which may or may not be going into the heart

for i listening to light client i am actually more on the on the page of having it be separated because it it would be so for example i sometimes hesitate making prs because it inflates if i make a ton of little changes then i've moved us our the eip number up 100 for doing tiny things where if it was in a separate repo then i would just i would be a lot more comfortable making changes all the time and the pretty much all that eip1 the meta eips are related to the hard fork stuff

and registry things i don't know i just i think i have maybe been a little bit too um it's having a having an attitude of we only have what we have and how to work with what we have versus stepping outside of that a little bit and this is i don't know this is actually making me think hudson you what are your thoughts if we had like a separate network upgrade repo um crazy no i think that's a good idea i think that might actually be cool also because you can start on that before we even finish the eipip

stuff yeah and i could be a like i'm hesitant to be an eip editor because i feel like that's kind of a conflict of interest or something i don't know like having having if i'm if i'm doing the network upgrade process i shouldn't also be over the eip process so then it would be really easy for me just to get started working on the network upgrade stuff and be it be an admin there but not in the eip part so there's separation um yeah i like that idea i anyone else have comments on that i think chloe had something on the chat stay active would that satisfy both

issues oh um yeah i think that's that's similar to what we're talking about um we could have it as a subsection of the eip repo but i guess the one issue there would be we would have to give different github level permissions to james that would allow him to potentially mess with other stuff not that we don't trust james but he could get malicious suddenly and mess with other stuff within the eip repo you know grow a mustache twirl it you know tie someone to train tracks that whole deal so we don't want him messing around in there that makes sense hundreds i was just wondering would it work what was that james

i like the idea of of separating out explicitly also as as the signal that we're there separate yeah sounds good i think we can go i think we should go ahead with that unless anyone has any objections to doing that i say we it's really james but james if you want help obviously tap me in or other people mean and then that we would need to do it under it would be under the ethereum repository i assume so yeah i can make a reboot if you need me talking to you about getting it done cool that would make a lot of this easier that was a good point thanks for bringing that up like that does that resolve your concerns there

i like it did you say you like it i do like it okay cool i think we can go to the next item right james or is there anything else on this one i muted myself and then started talking oh uh so yeah for the next item onboarding eip editors survey to and we've got about 30 minutes so i'll move through some of these a little bit faster survey to set expectations of an eip editor triaging permissions um i created a survey let me bring it up

and i'll send a link but it's just three questions i'd like feedback on um if i should add or remove anything before i send it out do you want to go through it right now or just have us read through it i sent it i put a link um i asked what tasks are expected of an eip editor um what is a good requirement for someone to become an eip editor do you have any recommendations for new eap editors i'm not sure if it's just me but the

first question is showing f i i i edited that um it should be correct when it's sent out i went cool i would add how much time do you feel an editor should spend a week being an editor yeah and maybe a couple of more specific a couple of more specific tasks like you know uh questions maybe like in what circumstances like we we are trying to collect information about when we can on board i mean like when who and how uh these three things so like if if certain criterias are met we can onboard that people and what are

those criterias we need to define that and we also need to define when i mean like in in cases when we have to like remove any editor so what can be those circumstances if we can get this information as well and uh how is like uh like if we can like i mentioned in the previous meeting uh also james added that there should be uh availability for meetings like uh quarterly or monthly or whatever number of hours per month or per week or some general guideline that would be in my mind would be helpful and like making it more firm any other feedback on questions

um oh actually hold on i had one and i just lost it um this is okay the the onboarding survey what did i have in mind i'll tell it to you later ed sent it i lost it so i think um never mind no this i think that i think it covers everything that was discussed last session uh really well the as far as onboarding well the triaging permissions so let's talk about the triaging permissions group thing could you explain that uh what that is the hudson light so the triaging permission here i added uh

coming from the previous meeting where we discussed that possibly you would be looking into adding permission to some of the people who are from ethereum foundation and may be able to kind of label the prs and that would be helpful for eip editors yeah and i i talked to hudson and then okay it turned into talking to like clients so then hudson knows what to do with how to do it yeah if someone can tell me how to do it i would be happy to facilitate or if we can get like a test repo up so someone can walk me through what it'll do because i'm always reticent to mess with settings on a very important repo um sure so yeah yeah we could do i'm

available to do that at any time but you know basically the only thing it's going to let people do is they're going to be able to use the tagging feature to tag information about pr's and issues so i think that you've probably seen axic go in and add some tags a while back this would just allow new contributors to do that without having right permission to the repo oh that's great you should be able to do it if you just go into the settings and you look at you would have to invite someone as a collaborator and then you would set their permission rather than having right access you set it to the triage access okay once we figure out who wants to do that um i'm happy to just real quick ask the editors if that's okay and then

and so they're not off guard by someone adding tags and then um add out a person whoever wants to be a tagger sounds good i think we should call them the ethereum bookkeepers i like tagger because it reminds me of people who spray paint illegally [Laughter] that's pretty good um who would would it be possible uh for me to be able to add people to that list but not be an eip editor or our permissions that i can i can i help with that part i think it depends on what your like

organizational role and the ethereum group is on github i think if you're an owner you can do that but if you aren't i think you have to be i think you'd have to have right access to the vip repo is this just to do the thing we were just talking about yeah i think someone with right access to the eip repo are the people who can add a triage contributor oh i have super admin so i can do it i just was wondering if that's something i could help with without becoming uh having total right access to the repository oh probably not yeah like light client was saying yeah because i'd i'd be happy to help

like at like uh there's a bunch of people here that should be there already yeah i can we can just get a list and i can add them it's not it's not a huge deal so i'll just point them i'll just collect lists and send them to you great um any last comments on that the treehousing permissions group or [Music] i'll give it a second for anyone who has final thoughts now we can move on to number four number three is the new eip validator and a suggestion to handle current validator is that you like client

yeah i don't think there's any major updates from the last meeting i was off for about a week so i'm still working through i have a list of requirements that i'm trying to get the validator to reach and that's all in the readme so if you see anything on there that you disagree or if you feel like there should be new things added you can just paint me or add an issue to that repo and i can have that added um one other thing about that i had a comment on getter i'll just post it here again so people can see there is like maybe a little bit of confusion between the validator um script and the merge bot those are two different components so right now

i'm working on the validator this is just going to statically analyze eaps to make sure they're conforming to whatever standards we have like do they have all the sections are all the links to other each relative these sorts of things that editors are currently having to do manually after that's complete hopefully i can do some more work on the merge bots and the merge bot is going is basically what manages the state transition types of changes it's going to be determining if the author has moved from draft to review and it's going to like automatically upset accept that rather than forcing like an editor to to review it but if they want to obviously remove

from like review to finalize then that's something that they eat better and so all those things are managed by the merge bots yeah and that's great i've won thank you for looking at that because i have wanted some updates to happen but it's just you get someone has to do it like someone has to change the code yeah i think the merge bot you know is written by nick dodson i think that it's pretty pretty good in general we just need to add some additions to it the problem with the validator is that it just seems to crash in really unhelpful ways and so that's why i'm rewriting it from

scratch rather than just working with it i think the merge quad kit is a lot more amenable to being updated i would be um happy to help with the merge bot great something i'd like the merge bot to be able to do is to have subgroups of permissions so like if we had the the triagers if we also gave them permissions to be able to edit the footer and then the merge bot would accept those that would be cool that would be it would be helpful and then like the if the tracking things that are currently ethereum like the whoever is a tr

the triage bot making updates to that it would just be nice if there was another layer of bookkeeping that's possible and have a group that is that is allowed to make those changes that's a really good idea that's something i've been trying to i've been struggling with because right now if you have right access to the repo you can do anything and so this would be a really good way to have to give people like very small amounts of access to things yep i like that let me pull up the agenda again uh any more thoughts or questions on

i've that mentioned there is a suggestion from greg that is added in the i mean the link is added on the agenda item so if that could also be considered or people would want to discuss it i will go and read it the one from uh which one are you are you talking about so is it the link to called a suggestion right the which which so i'm seeing a comment from like client 29 days ago is that the one you're looking at puja uh it's from um

greg oh i'm sorry i'm just not seeing the thing you're saying i think i think i by mistake i may have put the wrong link is it never mind i will just post the link in the chat uh when lifeline and elta would be looking into it made consider that it's coming up from the previous agenda but uh we just somehow missed to discuss that uh he has commented in the previous agenda yeah the i'm just the so it's the is it the one that says the github allows a special type of contributor which is admissions right okay so then i am looking at that so the number three has it would be good

to agree on a specific naming convention for eips since official documents use several different formats uh um i'm sorry uh i think uh uh it's like the current validator has a spell check it might be good if some things could be handled as warning merge the draft but let author know there is a work to do things like body abstract and missing section yep that's something that the validator i'm working on will do okay thank you i just wanted to bring it to the attention thanks peter thank you okay so there is there another point to

discuss puja oh and here's gray's comment i'll open this is this like a general question like are there any other points or just for this topic specifically um on the well you i'd open it up too if you have a comment on something yeah i wanted to i think that this is a really quick topic so i was considering um kind of refactoring the current eip1 in terms of layout i really like the layout of the um improvement proposal from python that or from javascript i think that you sent in the chat um or that's in i forget who sent

it but um regardless so i was thinking of going through and refactoring eip1 is like a bit of a draft to give like a different layout because the current one feels kind of bulky or clunky so what uh i think elita is referring to i i posted um uh the the process for how javascript's creates new releases so like ecma 2019 2020 like es6 on their website i think they have a

table with the status and then the description of that status so it's like in a table format i think is what she's referring to yeah and it was also um a little bit of like because we have a bunch of different um categories and stuff and so you could say uh just kind of organize you know into columns and say um i'm not exactly sure how it would end up looking or if it's even feasible but just in the sense of you can look at a single table and know you know what are the guidelines uh like maybe even with uh you know spreading out some of the stuff with just some you know markdown stuff so we could

have a linked table that just goes to different part of the document really easily because the document's really long so you can kind of have it nice and spread out so the reason i actually brought that up was um this is how they decide what become what um is released into javascript so i was thinking of it as inspiration for hardware coordination um but uh i mean i mean it's up to you guys what you think about um reform writing eip1 i can also just like give it a try if you don't like it we don't have to go with it i think um i'd be okay with that too well that sounds good to me you have any

thoughts hudson sorrows muted no that sounds good better formatting is better cool i'll try to get that by next meeting um moving on to discussion on mirror glacier porce modem report pr2 2809 and network upgrade postmortem template pr2810 do you want to take that puja so before that there is a comment from micah i guess uh that is linked to item

number five uh constraining the eip repository school so uh thank you so it's actually related both of them so please take them uh go ahead like lion sorry i just wanted maybe to suggest a different wording than postmortem because i feel like post-mortem usually has to do with when something goes wrong and we're writing a summary of what happened where i think this is just generally we want to have an ease that states the stats of the hardboard yeah i was more inclined to what's marking it as like

assessment report of you know upgrade network upgrade assessment document or report something like that but since traditionally we use the word post-mortem so it was i have no issues uh changing the wording i like retrospective personally that is that's a better word for it yeah i agree are there not already eeps that are tracking what like the heart the network upgrade will consist of i think there are uh so micah's suggesting that we just remove all of that from the eip repo and keep it only standards which i think we've already decided in the beginning to call

this what we're going to do we're going to keep um we're going to create a new repo basically for well we're kind of we're skipping into discussion on the mere glacier poor vault force more so let's we let's finish this uh number six course and then we'll go back to the to micah's comments because i we jumped around a little bit on the agenda which is my bad um yeah the retrospective i think is a better way better wording it there's definitely things in your glacier that went wrong so that's why it was a postmortem but we should we can call it a a retrospective for all of them that's fine that's fine with me

so i have uh i think i missed asking this question earlier so uh i will be changing the name to like network uh create a retrospective for near glacier for this particular but uh there is this proposal of two pull requests one is for the template in general and one is for the mere glacier post um and retrospective report for mere glacier uh what i'm getting is like from previous meetings of eipip we have categorized it as informational eip and i've tried to document it with that but michael left some comments over there feel free to go back and reach to that and for this the template one i was wondering should it be informational or should it be

again if we say meta it's going to bring a lot of controversy but i was just thinking about eip 233 which talks about the process that is to be followed to create and meta for network upgrade so i was trying to relate i'm happy doing either way whichever uh community is like okay to do that so just looking for some suggestions here so it sounds like it would be something that fits on the hard fork on the network upgrade repository right so if there was a network upgrade repository that the post mortems on the network upgrades or the retrospectives would fit there which i think also solves micah's

concern yeah i think that definitely alleviates it a lot for sure okay um [Music] i don't know i i feel like this fits well in the eeps repository it doesn't have to do with the governance at all this is just purely informational this seems like the exact reason to have an informational eep that states something that happened yeah but i think but if um i guess the fewer eeps that are non-standard the better is how i like to look at it but that's like more of a personal opinion

i guess you're saying non-standardising they are not standards no they are not standards like with an s yeah okay i mean i kind of feel like that we should have more informational eeps and maybe this isn't the right kind but i feel like you know seeing you know peter has been posting some stuff about the implementations of get there's been a lot of talk about how the databases are implemented i feel like those are things that could be written as informational eats they're not consensus requirements but they are something to help future developers understand decisions i'm totally on that and that's the argument i was trying to uh give there when in one of the

comments uh to this pr like uh according to erp one we have these three different categories of uh keep like meta standard and this informational so informational section is in my mind is created to provide more information and that is a placeholder for imported information and community reference uh kind of place so in my mind i don't find it wrong to be placed in eip repository but if people agree to have everything related to network upgrades separately i don't mind that either i think micah micah's point of view is that he's coming from this

place where he believes that the eev's repository should be um generic to the platform and so he doesn't think there should be a network upgrades because he believes that you know there could be spinalized thiefs that are not ever going to be used by the ethereum mainnet it might be used by a different project and you know my point of view is that that's not that shouldn't be the case we are this is the ethereum improvement proposal repository we should be focused on ethereum related things and so one of the most important parts about ethereum is what is on mainnet and information about mainnet i definitely think the governance process about what goes to mainnet should be separate from this but i feel like we should have a singular focus on our ethereum

yeah so that i could go either way it could be in the hard fork one that james is creating or it could be in the eips but for now since this is already a pull request in the eips repo and i just looked over the looked over it a little more closely and it's purely informational um it doesn't well i can see these eventually becoming political as they get more detail is something i just thought about so like if someone screws up and then we have to put yeah like the discovery of the problem this client broke this because we have had cases in the past including a pretty major bug where a pre-compile was incorrectly or

there was a idiosyncrasy with a pre-compile which is a really polite way of saying one of the two clients messed up reading the spec but we don't know which client it was because there was disagreement about what the specs said based on their interpretation of it so then there was this huge thing and later yoichi who used to be more active in the eip's repository wrote up a really long long like article that like a github thing that explained you know if anyone was at fault like who was kind of at fault who wasn't and it became a whole deal so i can see these in the future becoming more controversial and then them not fitting in the eip repository yeah i'm and i similarly can see them

both uh i see both sides so i don't want to push one in either direction and we could take more time to think about this and talk about it on telegram in the next meeting make a more immediate or make a more final decision i guess yeah that's a good idea unless i mean if obviously if there's other comments don't i don't want to stop anybody yeah i mean there's been a big push to keep the eap repo purely technical and remove politics wherever possible this is some feedback i've just been seeing yeah and there might be a time when politics need to be involved in a report like this

especially if it's going to continuously be written by groups that are not editors and people that are not or like groups like the cat herders and james and other people who have similar groupings to james's position and what the cat herders do so you'll just you'll send all the all the politics and controversy to me yep shifting it your way one way ups okay um the we've got 10 more minutes so let's go over to on item 5 constraining the iep repository scope i think we already talked about that in

hardware we we're considering creating a new repo for hardware coordination to separate that out from the eap repo something we can define is in addition to we're separating stuff just defining what the scope would be so it would be um we could formally define it as for specifications and for standards so that would include that would include specifications that would also include new processes um but i guess i guess we would put that in eip1 if we were to create a scope yeah and um thoughts on

what we should call the network upgrade repo upgrade uh mainnet um which repo coordination well so if we make a network upgrade repo or hardcore coordination repo like it when hudson creates the new repo what should it be called oh that the one that's in the ethereum organization okay i thought that for some reason i was mixing up organization repository um yeah i'd like to kind of open it up to

think more about that at the last part of the meeting so i can have some feedback from people before i just kind of run with it hmm okay i'll think about it before the end of the meeting do you want to ask like the ef hudson what it should be called nah they don't care not that they don't care about the process i'm just saying as far as naming goes they don't they don't care if a repository needs to be made for whatever official reason we don't have policies basically like it needs to be a good reason that you're making it and it doesn't need to be abandoned but otherwise like naming wise there's not like hard and fast policies is there anything else left to talk

about related making a new repo for the network update process that someone would like to bring up yeah so we're separating it would it follow the same rules as the eip repo uh we could divert it but i think just starting it off we just have the same template or i mean i mean i guess we could figure that out i don't think it needs that much structure i think it should just be whoever wants to put stuff in there have people who want to be in charge approve it people like james and uh there needs to be organization like folder separation like how the pm repo is separated but

like one of them could be like a folder for retrospectives and then there can be a template maybe but that's like similar to eips but it doesn't need to be super super strict unless people want it to be and have an efi section yeah have an efi subsection and then retrospectives or maybe even not efi but like whatever efi is so like a hard fork policies or stuff like that i don't know what the wording would be but like that subsection that has efi i guess it might be hard to decide what will go into it until we define what the new upgrade process will be good point well what i would like to

hear what from the group you would like to see in in a repository like that given that we could do whatever we want in it what what would you like to see pie in the sky kind of stuff i think you should write up that question in the naming question and post in the telegram post meeting because then we can think about it more and i'll reply in there that's a good idea one last question on this uh um this is related to the peer that i have already made so my if i understand it correct i have to hold on to this one and when the new repository will be created i have to just close and create a new pr over there and any other part any other suggestion on this

change of any part of the peer i saw one comment from like client that uh even the template could be an informational one i'm fine with that but other than that if people have any other feedback for this to be submitted as a pull request to the new repository feel free to add a comment here okay um we have about five more minutes the last place is let me review action items from the last meeting um james if i may ask for one more uh agent

item to be covered quickly i think it can be done quickly uh the number of phone this for the standard citation format i think uh this proposal is almost on the final call so micah was asking if somebody has any objection on that i mean that is just about the standardization of footer for all eips if people can give it a look um it does it it adds citations or is it the same citation rich one or is i think that is about a citation for every eip that people should be using reference i think um i think it's good uh so if if it's citations for eap specifically

i think that is good i think it would be more ethical um because if there's it's using work from someone else that's copyrighted i think it should be referenced or linked back to the original work um if i looked at the pr it looked like just um static text or i wasn't quite sure how is it is it taking um part of the a section of an eap and putting it in there or is it just one citation for every single uh eap i think it's an edit to the layout the

the uh template eip so that in the template there would be i don't know i'm trying to figure out what the hell this is i i i thought it was for the eips.ethereum.org so this looks like it's for the website for eaps i this is what is confusing me anyway we just wanted to bring it to attention so even if people find anything uh like uh to be commented on uh this is something getting into final stages so feel free to go back go ahead and comment on that full request

okay uh any other things you'd like covered puja in the last minute no i think i'm done thank you so much so yeah you can go ahead with the um whatever you i'll review the action films at 12.1 edson will make a survey to conduct editors on the expectation from an editor time commitment qualifications and he did that 20.2 james will look at the necessary permissions and how to set up users with the triaging capabilities and i i talked to cletson about that and then we talked about that today 12.3 a process for removing editors and criteria for

removing editors is a future item to discuss we did not discuss that today so we should add that to being discussed at a later time 12.4 link to the live efi document through eip1 rather than continuously updating eip1 efp1 can be used to help for statuses this is changed to having a repository for coordinating network upgrades 12.5 remove remove emergency columns from eip agenda until item until it becomes pertinent we did that so thank you everybody okay i figured it out just before we go this is for the eip.html jekyll layout file so this has stuff

like the okay so basically at the if you go to eips.ethereum.org and you click on any ip and it gives the header information like the author and stuff and then it gives the content of the eip at the very bottom all it does is it says please cite this document as and then it gives the ieee specification for reference formatting to include the author the eip number the title what status it's in the and stuff like that and where it's available um so it just i i think it's fine to merge oh that makes sense i i agree i think yeah i'm gonna just put a comment in there saying this looks good thank you

and have a great wednesday all right bye everyone yeah bye everyone two weeks yep bye everyone see you in two weeks