EIPIP Meeting 19

Transcript

hello everyone this is eipip meeting 19. um the agenda i'm going to share in the chat so the first item on the agenda today is onboarding eip editors uh this was uh to set the expectation and guidelines for the editors that we are planning to onboard we have limited number of additives and the numbers of open pull requests are uh way too many for few editors to handle so edson conducted some survey so what do you want to go ahead and take it away uh yeah so results from the survey is

um [Music] so the titan commitment required for new editors would be zero to five hours a week so relatively small that's one hour per working day at most a minimum requirement would be someone who um is already reviewing eips um someone who understands what a standard is and

understands what content should be left out of what a standard is uh and someone who understands ethereum to an intermediate level and is a good mediator for contentious conversation um so the tasks that would be expected just so we could let them know for new editors would be that making sure that the eaps are well formed and technically complete reviewing eaps for proper grammar

structure if it's related to ethereum and then picking up prs that aren't merged automatically by the auto merger bot um so for recommendations i think the only one was recommended was like client for the ap editor yeah i see a few uh comments i have linked it like maybe in one of the previous agenda you wanted to discuss some points like should i be author creator reference implementation and

client as requirement oh sorry is it something related to a different topic yeah that's a difference that's a different topic okay my bad so yeah and we've been hoping to you know get these things uh the expectations and the responsibilities would it be possible to get it documented somewhere or maybe have complete file or how do you want to see it okay so uh thank you so i was mentioning like we should try to document all these things i'm not sure if uh eap one would be the good place to document

all these things or do we want to keep it in here comedy what is general opinion here um to document it like we could write an article maybe on requirements for your eip editors or put it in a repository somewhere so repository somewhere or maybe in the ap one um i mean i'm not quite sure if it belongs in the ap1 i'm not sure if it belongs in the ap repository at all

like requirements for editors as always my vote is not in the eips repository i mean i could write a quick article on it on medium and then we could refer people new people to that yeah i feel like as long as there is an article somewhere that people can know what the information is that should be fine personally okay i do not have any strong feeling that where it should go but yeah i agree

like as long as information is available and people are able to access it it's fine but you know the reach would i mean like it's my personal thought again which is like the reach would increase if we have it mentioned even the link of the article that you are writing uh mention it somewhere which is easily accessible to community and that somewhere most of the time comes to my mind is eip1 like just mention it that eip author's responsibilities or the expectations are mentioned in this document just link back to the document medium document whatever you publish yeah so what i was thinking is eap one is for any one thinking of writing

an eip the people that it would apply to eap editors but their responsibilities are would be just the editors themselves and not just editors but new editors so it's a very small amount of people um so at the moment they become an editor we can just send them like personally that link to that repository article yeah makes sense uh did you want to get to the comments from that um from the agenda okay so these were brought up in the survey

there weren't things that i thought of but uh different suggestions that people had for the aps themselves um and let me open it up it was should a reference implementation be made as a requirement should there be a tagging system should should the ap include use cases should the eap include pros and cons so these are a small selection of suggestions other people had made throughout the survey we wanted to discuss it greg was saying that those suggestions can fit into

or the already existing format if that was the case maybe we could include them under those sections within the ap1 saying these are optional like suggested like you can include a set of use cases within the motivation section stuff like that i think i personally have seen these things in some of the eips but i have not reviewed some i mean not looked into too many mika you have any thought on that i think the idea with that is that um like already you can include those things in motivation

that is the appropriate place to include use cases and we have advised people on that at the moment in eip one um users it's not clear enough to users what the different sections mean and what is appropriate for them and so we often as editors end up having to kind of walk people through okay this is what goes in the abstract this is what goes the motivation etc so anything we can do to give to help users get it right the first time without an editor having to jump in and tell them how to do it is valuable whether this is valuable enough um i'm fine with it like i don't have a problem with with adding it i think in general though we do need to get

better descriptions in the eip1 because as they're written right now users are not understanding it and like people who read eip1 walk away not really understanding what goes in each section so this would help with that is not the whole problem but it's at least part of it so i'm in favor again this is nothing new nothing's really changing it's just more of an easier education thing right so uh like it's a would you want to take a stab on it like uh open a full request with specifying these uh things i mean these are already there but in the specific categories maybe yeah yeah i can write a pull request okay what were the other ones so one of them was

the one i was commenting on specifically was the um motivation uh use cases one what were the other i think two or three um a reference implementation so oh yeah that was true yeah that one was for me um at the moment people i've noticed are using the implementation section as a way to basically advertise their product that they're trying basically people are using eips as an advertising thing like they the belief is hey lots of ethereum users are reading eips so if i go and create an eip that documents my app then i can put a link to my app in that

eip and people will learn about my app and i really want to get away from that and so the way i've been handling it is telling people hey try not to link just put code directly in this repo don't link out textual recompose and the argument i generally make to users is that we want to make sure that the aips repo never gets 404 links and all that stuff but really what it comes down to is we we don't want to open the doors for turning eips into an at like a place to advertise um and it's a huge amount of work for us like i i would say well over half the ieps i review in my opinion don't need to be standards they just are someone documenting their app on the earpiece repo and so it's a big burden on the editors

to constantly be dealing with that so anything we can do to make it more clear that hey this is not a section where you go link to your your app this is a section where you put code um is kind of what i was going for to play devil's advocate since the other people who don't like this idea aren't here i'll try to represent the best i can their argument is that the implementations first of all try and write the spec it is very useful to be able to go look at someone else who has written the spec and so in those cases a link out to a third third-party repository can be very valuable and oftentimes those repositories are much bigger than as reasonable to put in line in the iep or even as like in the

assets directory and so by constraining that section the implementation section to reference implementation specifically and requiring the people in line their code we're making it harder for people to kind of provide code samples that other future developers can follow on this topic specifically um i would like to make a mention here the category started peep and eep series uh that is dedicated to eip and we discuss about proposal the very first episode of that is about creating an eip i mean like kind matt he has described certain use cases when

to do's or not to do's and when you think that you should come up like making a pull request to propose that as an eip like you should not be just one case specific as mika mentioned that it was just one app specific but you should be very sure of that that is equally applicable to many other applications so i i think i'm not sure if if it is appropriate to make a mention of that we can probably put a link of that and people can go and watch that because in that uh like clan has explained a lot of stuff which would be very helpful when you are creating an eip for the first time yeah and i think the more we can educate

users the better but there's also the separate problem of users who are educated but ignore the rules in order to try to advertise their product and those are the ones that i'm kind of more interested for this particular the reference implementation thing i'm trying to make it so it's very hard for the such people to be able to use eips as an advertising channel mainly because as an editor most i believe all the editors have agreed that we do not want to get in the business of deciding what is worthwhile as an eip and what is not and so by removing the opportunity for someone to use eips as a means of advertisement we don't have to then decide okay this

is valuable as an eip or this is just an advertisement because there's a lot of vips are kind of borderline where it's like i think this is really just an advertisement for for an app but i mean the user can make an argument and now we're getting into the debate of okay is is there argument sound is it a good argument whereas if we just made it so they couldn't advertise then all those people would kind of just go away and they wouldn't even try to fight us because even if they did get an eip created it wouldn't help them advertise and so so i guess there's two problems one people writing apas don't know how to write good aps and i think the peep and eap is episode that you talked about is great for that improving efp1 is great for that the separate problem getting advertise

people out of vips who are just trying to advertise i think isn't going to be solved just by education i think we need to other solutions for it i think maybe some kind of guidelines i mean like of course these are the guidelines but there should be some rules uh uh like maybe uh criteria defined like in in what cases there are high chances of it getting not accepted that is not formally announced anywhere or it's not listed is it something that can be considered so at the moment basically the only thing that gets you kicked out of the

ap's repo is if it's not technically sound like like it's very cut and dry there is no wiggle room for editors making uh opinionated decisions it's just like does this meet the technical requirements of an erp yes okay it's an erp um historically the editors have all and and i actually agree with this that editors have all been very hesitant to introduce any uh judgment calls by the editors like we've tried very hard to make it so all the editors our only job is just make sure things are technically sound like make sure they're written correctly make sure the grammar's right make sure the bot passes make sure that spelling is good make

sure that the things are in the right sections etc and so this is why we don't have any rules like [Music] this is why we don't have any fuzzy rules all our rules are very clear-cut which and which is also why i would like a rule that is clear-cut that makes it you cannot link to your personal repo in any ip and like i said they're they're downsizing this it means that for the legitimate use cases people can't link to repos and so if we want to stick to our hard-line stances we need to choose we want to allow people to link to personal repos and project repos in the emp or do we want to say no external linking at all do you have to include everything in the iep

or do we want to break our historic position of editors don't make opinionated decisions i think there's a three possible path forward that i can say i can see one thing that you have mentioned that mentioning their personal eip i mean github repo that is uh there in most of the genuine cases because while working on some project they came across something and that is again sent to the eip repo as a pull request so it is going to be linked back in most of the cases so i'm not sure if that can be a hard rule but in my opinion like editors should have all the you know powers to make rules

it's not that if they are taking a step back who is going to do that i understand this is a community project but somebody has to like step up and take these responsibilities to set rules so i agree things would go way smoother if that was the case um however historically both this all core devs has this exact same problem where everybody is very hesitant to give anyone else the power to set rules and enforce rules and so i'm not confident that would go over well i do agree with you though things would go way better if we had like an authority figure or figures who just said no i do not accept and i don't need to give

you a reason or at least i don't need to convince you of my reason i should say um but yeah that's uh it'd be very hard sell i think so curious um sorry uh so what's the issue of just being no linking external code in the repo i mean i understand it would be more difficult uh for certain projects but then couldn't those projects just write out hey like and i understand that like having a link would make it easier um but you know it seems like yeah what's the main issue against i guess as i understand it and again i'm trying to represent people who aren't here so uh it's best if we get it from them once

they're around but i my understanding of their issue is that they're concerned there are some eips that when implemented are very complicated particularly core eips where implementing a core eip like a reference implementation may be like yes like that's your reference implementation it's like an entire repository of stuff and like the eip is implemented you know all over that that repository like especially evm changes you know there's not just like one line somewhere where it's like oh here's the evm change it's like here's the entire evm and here are the 12 different places in that giant code base that we touch with this eip and so reference implementations for those are very

difficult whereas if you're just linking to geth then it all of a sudden becomes much easier you can just say hey here's the guest repo they've implemented it here's the 15 files that it you want to look at if you want to check to see you know the places that this touches uh whereas a reference implementation was like okay go write another client it's kind of the replica yeah the reference implementation yeah that makes sense i guess like the issues that you were proposing of people or teams trying to simply use the repo as advertisement uh is i would assume that's not something that usually happens from client teams though so could like uh or sort from corey isd so could core i eips have a specific distinction of allowing

uh links uh just to keep things the way it is and then just have other like all other eips not allow links would that be a way just to kind of okay well you know what these more complicated uh eips we're going to allow links still but try something different with um or this new way of doing things with other efps potentially uh that could potentially could could help i think that there are situations where um an eip is complicated enough to probably warrant its own you know linking out to separate repo and it's not a core ap those are definitely much less common um i think i'm i'm not against that what you just suggested again playing devil's advocate i think the argument is is

we're now adding more complexity into our process because now we have to draw a line between what is core and what is not um and there there have been examples recently in the past where it's kind of blurry sometimes what's the core ap and what's not and then like what if someone's linking out to a fork of death and because it's not implemented in gaff yet such as their fork but whether that fork ends up being you know another ethereum client or another ethereum network um like you know turbo gas for example is is that part of ethereum network it doesn't actually sync with the ethereum network right now fully i don't think um but they're also not you know building for tron or something yet there are ethereum clients that are forked from geth that are building for tron should we allow them to link

like it's just i think i think there's going to be a fear and pushback of like where do we draw the line because now we have we're the arbiters of what is an official client and historically no one has named any official clients like geth is the most popular but there's open ethereum there's another mine there's bessu there's turbogeth and the line there is very blurry of okay where do we draw the line who's allowed to do this and who's not um again i'm not against what you suggested i just that's that's what a problem i can see coming up potentially well that makes that makes a lot of sense thank you will it make sense to kind of

mention this thing like in this particular group this eipab group what we are trying to do is kind of improve the process which is ongoing we discuss about some of the issues and we brainstorm potential solutions and try to come up with solution but the implementation part in my mind would not be effective if we are not getting support from everybody and if they are not willing to accept the you know decisions that are being made or the proposals actually is not decision the proposals that are like going out from this meeting so will it make sense to kind of uh guard the all-core devs sentiment on this part like

how good it is to define certain rules like so far there are not hard lines now we want to define hard lines is it something that is acceptable then then this particular group can come up with certain rules and we can share it with them to get collectors so if i pretend to be james for a moment i will i'll say that putting my james hat on uh i think james would say we're trying really hard to separate eips from the core devs and not have they are a user of the ips repo but they are not um special they're not authoritative they like basically we don't need to get permission from the core devs do anything um

the efps is not a coordinated thing it is a totally separate entity separate people managing it totally get it so just again i suspect that's what james would say if he was here yeah i know i i'm getting the point here so in that case in my mind it feels like you know the eip author should be like uh the the group the people who should be like uh making rules and and we the cat headers or the ipip group group can support to get it enforced like we should list it out um i see that greg has referred

to some of the comments i mean like uh related to the rules responsibilities of eip editors now before before we move on what was the third item edson pros and cons and let me go back to sorry who just want to make sure we finish this before we move on that's all yes go over everything use cases pros and cons and reference implementation and one more thing was tagging system so greg said that eap is already tagged

with labels um i'm not yeah i don't think that's the same thing yeah so um for tags i don't know what would be added so like tagging implies that multiple tags could be applied to the to a single eap and then it'd be used to filter maybe like in the eap website and then pros and cons you could we can maybe suggest that for the motivation section so as far as those those two very good

i think i'm liking a little bit uh we can hear you so the pros and cons i'm fine with um again i feel like that something goes motivation we should make eip1 better and encourage people to put that sort of content in the motivation section on the abstract not in the simple summary not the specification yeah i agree what about a tagging system

i'm not against the tagging system personally um i worry that what is a tag and what isn't and which things get tagged with which things is going to be complicated and i don't know if it's worth it like i my personal opinion is people should really only be reading final eips like too many people read drafty ips and there are relatively few final eips so like i don't know if we have enough final efps to warrant having a mechanism for filtering them yet and for draft eips i'd rather people just like get them out of draft yeah i think that's fair so tagging

would be more beneficial if we had a lot an overwhelming amount of eaps especially in final um i'll make the prta p1 and then it could be reviewed yeah yeah i think by making this pr new people will get to know like what

should be added more in their proposal in the pull request so that's about it and the next item in this was also referring open issues okay on the expectation guideline there was already a pull request open as a role of editors in eip process i'm not sure uh did you also consider that while considering the expectations for eib editors i'm sorry i couldn't really hear you did

you can you read that okay uh so there is a the next topic which is on the agenda item first about the expectation of uh responsibilities of eip editors there was also an open pull request talking about these things uh i think it's one four six seven pull request one four six seven role of editors in eip process just wanted to bring it to your attention while documenting the expectation if this can be considered as well okay anything more on agenda item one on

onboarding eip editors i think we came up with uh two decisions one uh edson would be writing up a medium post on elp editor's expectations and responsibilities and he would be also opening up a request for um for what more could be added when we are proposing an elp okay so the next item is a eip repository scope and editor's duties talking about it uh just one thing

before we move on i'm i'm looking through the issue and it's saying that eap editors assign numbers i don't think that's actually true we should probably update the eap one with that i think i have seen some comments of greg on that part he mentioned that it is actually the role of editor but most of the time author uh does by themselves they do it like i don't know i have found that bot does not give it a pass if we don't add the eip number or something like that i'm not sure so the ap number right now is determined by the full request number right which isn't in the ap one but that's how

it's done i think we should update eap1 to reflect that because right that's not actually a role of the editors right now um they just suggest using the pr number i think i think that's the opposite the the editors if i remember correctly i need to read it again but i remember correctly the editors choose whatever number they want it just so happens that the editors right now choose the pr number yeah i think and this is also mentioned in eip1 the current eip1 that mentions it's clearly that it is the responsibility of an editor to provide the piano i mean the eip number to any pull request so yeah it's completely up to them oh because i was looking through the

core devs chat and they had suggested that i think they had decided that uh the the ap number is the pull request number editor wishes to give some other number which is open and yeah they can has that happened yeah a couple times has happened where something other than the full request number was used um one of one time it was because someone was trying to squat and so we punished them by giving them a different number like they're trying to squat on a particular pr number and the way they did it was they spammed the ips repo with a bunch of issues to

bump the number up to what they wanted and then they took number they wanted and we just said no and we gave them something different and that made them very sad and that made us very happy uh yeah so i think that that does not need to change i mean that will still be considered under the responsibility of an editor to provide the eip number even if it is the same as the pull request number i mean generally like um so i think it's the exception where the

eip editor changes the number but most cases the eap number is the poor cost number and i don't usually see authors asking permission from the editors for that in that case yeah currently that is the case the vast majority of vips are just the pull request number because it's easy um we've also given people like if they start with a an issue and like like we recommend they do they start with an issue as an idea they flesh it out a little bit and they create a draft sometimes we'll let them use their issue number instead just because like maybe they've already referenced it or they've already talked about it um what is the

what is the advantage of codifying that or solidifying that okay is there a problem with the current system i guess like the biggest benefit would be to new uh new authors because it's not anywhere in the ep one but that's the way it's done so oh you're saying we could save the editors some effort like right now author creates an eip they put tpd and the eip number editor just immediately posts a comment saying change this to the pr number we're saying we could avoid that step if the author is just did put the ip sorry if the author is filled in on the first draft yeah yeah exactly

well on the contrary i believe that keeping it with the editors will help us prevent some squatting thing as well right so um if we don't do that and if we allow the editors to just choose the pr number then i'm not sure if we would be able to stop that we could all we could also just specify any if you want these things aren't allowed like uh inflating opening issues to get a specific number opening a pr with that's empty for a specific number yeah and that's how uh i'm ambivalent if other people feel

strongly i don't care that much my thought is it should be with the eip editor itself like they should have authority of like we are giving everything to the eip editor we are saying that they are the boss and they would look into everything so the the like top most thing is the number that it is referred with but that's again me is anyone else here edson repeating himself i think either he's lagging or i'm lagging i can't tell which right now i hear no one talking so

i can maybe try to rejoin um i should be using headphones so this shouldn't be an echo that's not an echo it's like you'll say something and then like maybe a minute later i'll hear you say the exact same thing again and it's only you i'm not hearing it from anyone else uh let me try rejoining okay sorry i already rejoined it didn't fix so maybe that will fix any other thought on this proposal on eap number and peer number like i said i'm ambivalent i i can go either way i think that

right now the editor telling someone what the number to use is by far the easy easiest part of the job i do um and so it's very minor to me to have to tell people hey like it's just you know triple backs back take suggestion type in the number triple back tick like it's super easy for me super easy for the the author and so that's why i don't really care like there's so many more time consuming problems when as an editor that one's easy okay so i'm not sure like we should mark

it as like decision item or should we just keep it open for one more meeting and share it outside this group present group to get some more response on that uh if general opinion is it does not matter i'm fine with that so here here's uh can you hear that time so here here's the thing for when i was first looking at the eap repo so i thought that you needed to have a number first to even create a pr which which was an understanding on my part until i did research like oh the pr numbers the pr number is the ap number so

i was thinking of contacting the ap editor just to get an eip number just to open the pr because most eips it's the file name is the eap number so um it would be weird to open a pr with the file name that doesn't that's just empty i think that's what is traditionally done we just open a pull request with the file name and later on we add the eip number to it and it accepts it like it works that way i don't know so so for an author i think that the

the situation is going to be basically the same because we can't hear you yeah pretty i'm pretty sure i'm liking i will try to just listen and type up i have some importance okay so do we have something like some consensus here

before we move on or do we want to keep it open for one more meeting and then decide on this part i think it's fine so like all i was suggesting is maybe specifying the ap one that the typically the eip number is the pr number um because right now it looks like editors are writing the ap number for every single eap so like as far as i remember it is already mentioned in there but um not all the time that you just do that like in in my case i have made three four pull requests so for a couple of files when it was not getting i bought pass so like ken suggested me micah suggested

then i i went ahead and i corrected it tried the wrote the eip number and it then started showing me the green check so it was fine by me i mean i haven't checked recently but unless i remember it wasn't mentioned in eap one okay okay anyone has any anything uh concluding on this topic okay then in that case like i would like to keep it open like maybe add it only this point before you go ahead and

make couple requests for changing this particular point like the eip number would be provided would be added by the author itself and it does not come in the responsibility of eip editors uh just this point and let's some more opinion on it if people think that it is not very important thing and like it can go and all the authors should go ahead and do that um that will be added in the pull requester one the one you are creating for uh i'll make two separate pull requests so make sense yeah that makes sense then it would not be dependent upon whatever you are trying to uh make pull requests yeah yeah exactly okay make sense

okay so are we good to move on oh my god we are okay so there are a few other topics that we have to touch today uh i am not sure like uh we would be able to get on all of them but there is one topic which was suggested by mika about the mika has too much power is it something that we would want to discuss now i see that mika has written a like big comment about it also greg responded to that that at this point of time only exec subtacular greg and mika are working on it

my my hope is with having more editors on board this problem can be solved i mean i have no problem having mika so much of power but it's like on his part he is getting a lot of work to do a lot of responsibility on him so i believe that having more adidas will help now the biggest question would be like how do we invite people to be you know considered for eap editor one suggestion we have like client as the edison mentioned but what are the other ways how we can invite people yeah i i agree i think it might just be a side effect

of there not being many active editors i think what micah can do in those situations is just tag the currently active editors to mediate the rest of the discussion so yeah historically a selection of editor was a simple like complete the present editor they select somebody and um uh that person is now auditor and they can start taking up responsibility but i think we can i mean if it is okay with the group we can make a uh you know tweet about it asking for in inviting for adjectives and let's see if

people who are from the community and they are interested it's just that they are not aware of like we are looking for more editors if they show up then we can pass along the names or if there are any other suggestions of how we can invite these people because we need more than one of course yeah i mean we could start with looking at who's already active in the eap repo okay maybe we could um ask current core developers

since they already have an understanding of the like ethereum they should like a at least an intermediate if not advanced understanding of ethereum yeah totally agree like historically those people are editors they have done this responsibility in past so if someone is interested now we can possibly invite them yeah like i think i'd be comfortable awaiting anyone from geth anyone from netherline anyone from a baesu just any anyone from there would it be a good candidate or like a and like the rest of the clients

i suspect the problem is going to be time availability like my understanding is the core developers are all currently way overworked okay so in that case maybe uh this document that edson specifying what is the expectation five hours a week but maybe i'm not sure if they are comfortable or like taking out time and doing it it isn't hard to you know check with them maybe we can make an announcement and see what's the response we are getting yeah so the the time requirement was

minimum zero to five hours so i mean even one hour a week is fine as long like one hour of work for eap repos i don't think it takes much time to review uh eaps because it's mostly just approving or specifying why it's not approved i don't know maybe is the best person the most time-consuming part is teaching the most time-consuming part is teaching people how to write good standards like most most people don't uh it doesn't come naturally too so maybe we should put more time into

education what if we created like an online course or something like in i'm definitely a fan of educated people more the thing i worry about is that the people won't go educate themselves before they create an eip and then uh like should are we supposed to just be like if someone shows up writes in the iep and it's bad am i supposed to just say go go take this course and come back or

should i okay i feel that's a little bit rude but i mean at the same time i don't have infinite time so that may be the only option i have yeah so i was thinking that right an entire course but um there could be say say there's something that they that they miswrote or some something that they have that isn't uh meaning the requirements of a specification instead of writing it out entirely you could summarize it and then link to an external source that says read this to understand really what i'm saying you could also um like say create a core or let me just think about like a

documentation um for how it works and then you can just reference that documentation whenever you have a problem with that documentation having like the full explanation regarding the problem itself that's like relatively common or whatever that might be easier yeah if you personally if it was a course i mean you can call it like a course or documentation or whatever it is but i think having you know the editor being able to link just like you know not having to teach uh because i feel like all the teaching that you're doing like uh is probably could have been put into a course anyways probably notice you so you know if there was this like place people to go to for michael can just be like okay well

i mean you're way off base you know start here i think that might just streamline the process potentially a little bit a little bit easier i mean like because we we do want more editors but um uh if most of their time is being spent educating we could just do the education beforehand and then have the editors like back because like the ultimately like one of the larger goals is just reducing the backlog but um i still i still think we should add more editors and we should brainstorm how to how to

onboard more editors i'll agree like giving them education i mean like having some documentation part or some reference material at least will offload a little bit from the editor's job yeah mike i i see your mic moving but i'm not hearing anything regarding

yeah so i think that we need more there's two reasons one to help keep up with everything um like i fall behind frequently and it's hard to catch up and we still have a backlog of prs that haven't been touched for a year because i have not like currently i only try to keep up i do not try to clear the backlog um if we had more editors we could do both the second thing we need more editors for is so that i don't have so much power and so even if we do solve reduce my workload i still think we need more editors so that if if i decide i don't like informational eips i don't have the power to unilaterally implement that just because

no one else is merging the earpiece and at the moment i do and so because i don't like informational aps informational eips are de facto banned from the repository because i won't merge them and i do not think that i should be have the power to do that like without discussion without agreement like no one agrees with me on this which is my personal opinion yet that is effectively what is happening and i do not like that and so even if we do reduce my workload i still do think we need more editors uh yeah i i agree with that so yeah i think the best uh way that is

like we should uh try to first finish up with this document this uh the medium post that tarzan will be working on then we'll try to reach out uh the co-developers or the people who are heavily engaged in ethereum development if they would be interested to be uh you know editors to to be giving some time maybe an hour a day or something like that then we can set expectations and let's see how it turns out to be but i think that is certainly needed at this time what happens like it's my experience like as mentioned as mika mentioned that when when he says that information eip is not agreeing to it and it's there nobody

you know nobody else is there to either take a decision whether to close it not move ahead with it or maybe merge it it's there forever and after the bot after three months it will be closed automatically nothing can be done about it so we should not just let go any proposal just because nobody is there to attend there should be a like you know decision before we are going to close a pull request so i think that is something that you need to be looked into okay so i think this is not something that we can decide right away it's going to take time maybe in next three four meetings we would be

in a good position to speak more about it how we are proceeding and uh like we are almost time i would quickly like to cover a few things which was which is coming from the action item from the previous meeting a light line shared a twitter account uh eip info for tweeting eip updates um i have shared that with james so everybody else is interested they can get in touch with james on this part there is another item should meta and information eip be part of eip at all so that was listed here

in today's agenda uh like eip repositories scope but we could not cover it it's a long discussion and we could not cover it in this time so i'm going to move it to the next meeting and puja will reach out to eip authors to get them to follow the documented network upgrade mika and i mentioned this in the all called meeting that the author should be creating pull requests to change the status of their proposals which are getting into berlin mika reached out to aragon to tell them they need to put in comment to eip3000 uh i'm not sure mika is it a closed item

now yeah that was handled uh they i told them to add content and they did after like a day and then it covers it great move agenda item four to six to the to the next meeting that we tried to cover in this meeting and yeah that's all from the previous meeting anything else people would like to cover today we are like one minute past the time but yes is something that can be quickly seen i don't see a light line or james on the call or hudson so skipping the triaging permission item but anything else if anybody would like to discuss cool so we made good progress we have

some decisions or being you know to do's for us thank you all for joining today see you in two weeks november 4th 2020. uh one more thing like on november 4th the time is going to be changed for the daylight uh people living in the daylight area like est is going to change so we um be sure that the meeting is at 1500 utc even if it is like change in eurozone thank you yeah all right thanks bye thank you thank you very much everyone in two weeks