EIPIP Meeting 20

Transcript

hello everyone this is eipip meeting 20 and i'm sharing agenda in the chat so the first item that we would like to discuss today are some comments coming up from the eip survey we have edson here so let's check it away yeah so the first question is how can we clarify what steps eip authors need to take for their eap to be included in clients the this is the question specifically for our query ips uh can you hear me

before you jumped on i had some responses to that but if i'm the only one that feels that way there's no use probably saying it more because i think everyone already knows my opinion brent i think you can go ahead and say that because that was uh like pre-discussion so we were unfortunately not able to record that so if you have anything further on these comments please feel free to add it here okay yeah and this is all just my opinion so but basically how can we clarify what steps the ip authors need to take we've had this discussion in the last um in multiple meetings where people and and also the peep and eat that discussion came up yet

again people are asking what but in my opinion if you can have a petition like system where everyone can sign the petition including people that that are in charge of clients and they say yes we are going to implement this and everyone signs and everyone signs the petition then that by definition is yes everyone we have hundred we've achieved consensus so it by definition we'll move forward and and and and and so eventually if if we learn how to do that kind of communication where everyone communicates to the one and we work on building as much consensus as possible eventually we'll probably come up with measures where we can say like well you have to have 75 of the quadratic ether you have to have

75 percent of the core devs you have to have 75 percent of the population or something like that but even if we did come up with a measure like that it would still should be the goal to get ever have a petition like system where everyone can sign on and everyone say i'm on board with this and have a room for a competing camp where people that aren't on board can join that camp and also a hierarchical structure so that you can keep the focus on what people agree on in the super camp and push the disagreeable stuff to lower level subcamps and and again if you can find out concisely and quantitatively what everyone wants that is by definition consensus and you can 99 of the time find a creative way to get everyone everything they want and so that that's just my opinion so

so as far as the present process i believe like at this point of time the the process is to bring it to all coders attention and there the clients are providing their opinion and asking questions and that's the way uh an eip author can actually request for including that to be in the clients for the corey ips as well as um with this new process in place the network upgrade process there is at 1.0 repository there they can go ahead and create an issue and with the help of hardware coordinator uh that can be brought into clients attention

uh is there anything else that we can add mic up because you are the editor i would say the get your eip to at least into draft i've seen plenty of people try to bring eips to the core devs without even being in draft yet and that's almost certainly not going to work well for you another thing i think you can do is if once we institute the review step assuming that goes through then getting it all the way to review i think would be most appropriate the review stage will if if we go forward with that indicate that the eip is ready for general consumption and review

and ideally it means there will be an editor will go through and make sure that everything is you know structurally sound well worded stuff like that and so you'll have by the time it gets to review hopefully you'll have someone at least one other person who has looked it over who is familiar with the process and understands how things work and has at least tried to work with you on getting it into a good state i think the last thing is i mentioned this in the discussion keep your eips small small eips that are very small and short so change the least possible amount of things in an eip as you can and also try to keep the the text to a minimum

while i know it's tempting to write you know a long essay about why your eip is great editors are or sorry core devs are very short on time and having something that's quick for them to scan over and read is very valuable and this is where the abstract comes in very handy in the simple summary keeping a simple summary very simple you know like one sentence like a subject line of an email really does help and the abstract keeping it have it be a human readable and very short version of the specification so an editor who just wants to get knight or sorry cordov who just wants to get an idea of is this something that i support can just read the abstract and be done with it in you know a minute or two

so yeah so if you want to get your ipv merged that's that would be my advice none of this isn't a guarantee of course but i think that's your best bet um is there somewhere where we could put this information that's what i was thinking the internet yeah like should we write an article should we put it in the eap specs repository or where should we put it should we link it with me if you want uh i would say no to eip1 because we're trying really hard to keep the eips repository out of the hard fork

coordination process and this is really a hardcore coordination question the ife specs definitely seems more appropriate to me since that is the hard four coordination repository yeah probably these can be added to the readme section of at one spec uh just to add more clarification on what steps author needs to take i think there is some text already there but we can add some more information that would be helpful for new authors to follow along okay uh the next question is how can we

make the eap process more well known my vote is that we don't i think too many people know about the fp process as it is i have way too much work so generally uh there are very small group of people who are actually involved in writing an eip those people are from the uh you know who are already engaged in ethereum development and most of them are there in the all core dev meeting so if we can get this thing out uh with the participants of the all coder meeting i

think that is one place from where we can start and let people know about this process but for that uh since we are avoiding any kind of eips for like stating the processes we can definitely add it in read me section uh to micah's point i think the reason we don't have that many editors is because how many people know about the process otherwise there'd be more people asking to be editors as well uh that's that's fair um i i worry that the rate of growth of people wanting to draft eips will outpace the rate of growth of editors

just because that's historically been the case i don't know how to solve that don't take my my comment too seriously it's mostly meant glibly um like i do think want people to use the eap process where appropriate my main concern is that the eip process is currently in my opinion misused by a lot of people like i spend a lot of my day just explaining to people why this is not a good eap or why this isn't this thing that they want to do it's not appropriate for the ips repository and so it whatever solution we come up with it would be nice if we are making sure we're attracting the right crowd

like attracting people who actually should be writing eips or who we would benefit from writing eips rather than just getting you know a bunch of people on the internet who want to express their opinion and they think the eip's repository is the way to express their opinion to core devs it makes a lot of sense and again i don't have an extra solution here just whatever mechanism we choose just ideally have it hopefully targets well and not just uh like i wouldn't want to put a put up like an adwords campaign on reddit for example on getting people to write eips that feels like attract the wrong crowd so recently i have come across uh some

queries around the process of the network upgrade like because that that has changed like we we did some modification separated uh the eip process and the hard work process so we came across some queries but i personally feel that eip1 is the best place to you know at least understand what the eip process is or if somebody is trying to write it down for the first time now that is the best reference available at this point or the readme yeah like i say as a frequent github user i always start

with the readme like when i go to a new github repository first thing i do is read the readme and see what it says again i don't know if everybody does that that's just my process i'd do that too personally i haven't checked the read me section for that eip is repository but i have checked that eip1 and that i found like yeah so it it has certain information regarding how the process should like eip should be created or the process should look like i may have to check that again i mean the readme is not great uh don't talk about me it's got like maybe two paragraphs about

the process um and a lot of it's duplicate of vip one maybe i mean this is getting a little off into the weeds but um there has been talk in the past and i tentatively agree that we should just have the readme and just get rid of eip1 and have the readme be eip1 if you want it would be named readme but you can call it eip1 or something or i don't know if github sports some links reason being is right now like the two kind of share a purpose which is describing what this repository is the readme is the way that most uh people who use github regularly get their information and then eip1 then

duplicates that kind of same purpose but in a different location and so i think that's part maybe part of the confusion is that you have people coming to the re coming to the repository reading the readme which is what they're used to and then that read me does not give them the information that necessarily we want to give them but at the same time we also don't want to just duplicate eip1 and have to update two places for everything uh i i may have a different opinion here about eip1 to be replaced by readme because i believe that that eips.etdm.org the website where we have the collection of all eips i'm not sure if i have seen that read me section there but if eips

i mean the directions are mentioned in eip1 eap1 would be there and it would be an easy reference for people you know so personally i feel that it is good in a any eyepiece itself but again that's actually a good question does anyone know where the front page of eaps.ethereum.org comes from it's not eip1 and it's not the readme yeah it's apparently a third place that duplicates the exact same set of information that i don't even know i don't know where that comes from we should figure that out so so yeah we have three places that essentially are trying to do the same thing which is describe what this repository is and what its purpose

is i feel like we should try to consolidate that single source of truth yep i think there is one more place to it in addition to automatically and that is ethereum dot org slash eip so basically ethereum dot org slash eips is a new page that was created for eips but that actually refers back to eips.one eips.ethereum.all so it was some some change but yes at this point we have four places so yeah so it definitely feels so now i'm better understanding why all four of these have gaps so each one of these is not ideal like they're each missing

something or they each have a little problem that we've run to one point or another and i think the problem is just that there are four different places that all share a purpose do we do we all agree that they share a purpose like the goal of each of these documents is to try to explain the eip process or do we think that these are different purposes not for the ethereum.org especially if you use that one just introduces what the eap process is yeah that was just to make it more popular like people should know about eip so it does not share the same purpose so what uh can someone help me understand what the difference is between that and like everyone or the readme or the front

page of eips.ethereum.org all right specifies what the process is while the ethereum is just introducing that there is a process so ethereum.org is saying hey eaps are a thing this is generally what they they're for and in theory eip1 says this is the process for eips would that be accurate uh yes that's my understanding yeah okay so in that case we should rip out the what is an eip from the eip1 since we have other places that are saying the same thing in more depth and just have eip1 be the process that way we have more clear delineation

like right now eip1 is trying to describe both the process and why the process exists and what the process what eips are and it's not doing a good job of those other things and so i feel like we should just tear that out and just say hey go look at one of these other three places um so maybe the the read me then perhaps it should mirror ethereum.org eips does that make sense like should the readme of the eaps repository just describe what an eip is and why you might want it or should it be more like eip1 where it describes the process does the read me link to emp one because

that might be part of the issue it does all i believe all of these link to each other so we have this kind of mesh of these four things that are all very similar in purpose and so um yeah like the this first paragraph of the readme says please read the eip1 and then it goes on to kind of reiterate what eip1 just said which if you follow the instructions you would have already read so i think so i think that eip1 it does not only say about the you know the purpose of it that is there in the readme itself but also explain about other things what are the types how you should create

and how you should categorize and the process is included yes the mp1 is the longest of them certainly it sounds like we need to get the ethereum.org that sort of mirrors the readme to find out where that comes from and why it comes from and get those to coordinate so that we have a single source of truth for that information yeah i would be okay with that if we could just get those two pages to be mirrors which leaves the last one which is the front page of eaps.ethereum.org should that also mirror just the

the what and the why of eips or should that be more process oriented yeah it sounds like we have mirrors of all those all those three things are a description of what eips are and the processes in the eip1 i'd be okay with that that would that would definitely clear up a lot of things i think like right now when we're making changes that's kind of random whether someone updates the readme or eip1 or the home page of eips.ethereum.org or the ethereum.org eips if we had a more clear delineation of ev1 is just a

description of the process that's it these other three are all identical like they're mirrors of each other and they are describing like at a high level what are eips why do you want eips history maybe etc then we would have much more clear lines and i think will be easier to do updates to these and get it in the right place i would agree uh that makes a lot of sense like we have just one place for processes and arrest others just to you know let people know about it like there is a place where you can find the right process nice addison who would be who wants to take up the task of figuring out where

ethereum.org slash eips comes from i wouldn't mind looking into that i have no clue where to start but i could spend some time on it i think that's in the etherium.org repository and okay they do have a link at the bottom so that seems reasonable also also um micah had some great descriptions of the process and what to go through and those are contained in the notes and it looks like uh pooja you're on for notes for to this today's meeting is that true yeah i saw myself there but i may not be doing that uh somebody else would be doing it on let people know but yes it will be done

yeah but i was wondering if whoever is going to do the notes if i could work with that because we've captured what mike has said on those steps and and we should work on capturing that and get that we talked about what needs to be done but no one's volunteered to do it so anyway i'd like to help with that if i could i think the other challenge will be i i don't actually know how to mirror the same content across all three of these locations because i believe all three of them are just different spots in various github repositories i don't know about what a good way to mirror is um i think in an ideal world world where engineering was free we

would write a little bot that just made it so anytime one of them was updated the bot would go and submit and accept and merge a pr into the other two so they would always stay in sync um but that's non-trivial engineering work and so i don't know if there's a better process there's always source source uh source page include where you just blatantly suck another page into your page so that shouldn't be too but anyway i could look into that i'll i'll take a task to look into that yeah that'd be great it's like you figure out how to do that in markdown specifically like uh does markdown support just like iframe or something yeah yeah yeah so the three places are

eip the ethereum dot org slash eip and the other one is just ethereum.org so eips.ethereum.org the front page there either theory um.org and then there's ethereum.org slash eip yeah ps yep and then the readme for the eip repository yes um the other thing there is one other thing that's in the readme for the repository which is how to build the eip site um that's very common in re enemies for github things if we can keep that in the footer

like so the top would be a mirror of everything and then just the bottom it just says hey this is how you build this repository um that would be nice if that's not possible we could probably move it to another file and i don't think anyone's gonna cry too much about that now help me understand because i thought the eip repository was just a list of vips is there what what gets done with the build of the eip repository it's it gets turned into eaps.ethereum.org oh that's what you mean by the bill oh oh okay yeah yeah it just generates that website from the market files got it okay it'd be nice if that could also be in the readme just at the bottom because

that's where people generally look for that type of information yep we can't because the way we're mirroring or whatever makes us we can't add stuff to the end i think that's also acceptable like we can put it in another file like a development.md file or something okay great thank you glad i can help i hope so i could go with the next question um it says how can the community track progress free aps and who has it implemented

uh this is again for corey appease i think at least i believe that would be the hard four coordination process which would be the east specs repo um i don't i have i don't actually follow that repository i don't know do you follow that processor puja and understand how it works or is that a james question but james question i'm just helping him out and keeping it up to date for example the current process what we have done is like we have created two uh two files for yellow v2 and v3 and if you get into that v2 and v3 you will get to know what state of development any client is say for example like earlier we were considering that

uh open ethereum may not be able to join yellow v3 but recently they have uh shared their consent that they would be joining version three so it is marked like open ethereum would also be a part like they have mentioned that they would be participating but their progress is uh still to be captured as they move along the process is captured there and every client's status is being updated in this at one dot oh spec so people can follow along with that repository to get to be up to date with where a proposal is with any particular client i hope it answers the question action

yeah so um is there a way we could let the community know that it's trapped in the ap or buzzer yeah yeah oh what is that so i'll repeat my question is there a way we could let the community know that this is tracked in the ap repository it's not in the so if community wants to if community wants to track the progress of any core eip

like where is it going the core eip progress can be tracked with the help of at one dot oh spec repository there we have created folders based on the devnet developers network uh that they are doing for uh at the moment they are working on yellow test net yellow fnet so based on every version of yolo the progress can be track whatever is the latest version of yolo there before any upgrade and the list of eips are there those will get into the hardware and those eips can be particularly tracked with the help of like client tracker that is already a table is already there

so if you can look into that you can get more information of those eips and that's how we can follow the progress uh let me repeat my question is there a way we can let the community know that they can track it within the eth1 specs repo do you mean is it being documented anywhere no i mean does the community know that that's where you go for that i think we have mentioned it in couple of all chord meetings so yeah that's

i suspect that my intuition is that not everybody knows about one specs repo yet but that could be wrong i i don't have a good answer to how we can do better at that um yeah on that like this network upgrade process this is actually a new process and uh yeah i agree that many people may not know completely about that as i mentioned earlier in the call that i have received some you know queries regarding how this process goes around so uh there were two things like i already have like drafted an eip that was eip1929 about mentioning the process how does it work but

that is still there and we still have not decided whether we should be keeping that as an meta informational or any form of eip or we want to keep that information anywhere else but if that is not going to be in the form of any eip i would be happy to draft a medium blog on that and explain the entire process how how we are considering it uh like this with this new network upgrade process if that helps i think i'm in the process of writing a blog on medium for that um so what i'm doing for the eap specs repo

um i guess you could do the one for the network up your process um i'm not sure both are one or the same i like i i think in my opinion they'd be different because i talk about the network every process only briefly i don't spend a lot of time on it got it got it yeah so yeah i can go ahead and do that like i'll uh sync up with you and see where we are if that has to be separated yes we can go ahead and do that okay i'll post my draft into the publication um do we have time for the other ones um we have i think six minutes left

i can move on to the next question or so i think we can pick up at least one okay how can discussions about eaps be more easily followed more easily than following the discussion link in the eip i guess this is for efus for discussion that happens outside of the discussion link i think this lesson would be just having all the discussion happen within the

discussion link there yeah or at least having when a discussion happens outside the discussion link uh kind of back port the conclusion of that discussion into the discussion link so i've done this in eaps before where i'll have an eib drafted up have a discussion to link but then have a conversation over in discord somebody and then i try to go back if that discord conversation generated some new change or some new content or some new conclusions i'll go back to the discussion link and say had a conversation discord this is the outcome of it so that way anyone who's following along only has to subscribe to the discussion to link and then they can get

kind of a feed of all the things that are happening all the discussions going on etc so that would be my recommendation for people yeah i guess we could recommend that so yeah i think we should pick up the last one too and then that would be covered for today uh for that should we put that in the eap1 or where would we recommend that um that might be reasonable for eip1 it's it's not really a this is yeah i'd say that i i can get a board

keeping that in the mp1 i'm generally hesitant to add things the ap one because it's already so long that no one reads it and it'd be nice if we can keep it short but i do think that's valuable enough and it's short enough that we can have like you know one sentence that just says if you have discussions outside the discussion too link please make sure to kind of backport the conclusions of those discussions so people who are following can follow along okay and the last question is how can we keep attention away from the process towards the technical discussion i would love to know the answer to that

one i think these questions are more from the network upgrade side i really wish james could have been here to answer all these questions um but um i mean like if a proposal needs some attention i mean we have ways for that but technical discussion can be you know uh kept up in the some for some time like for some some proposals that can be there in the github pull request where it is there but that's my my thought on it but

i just noticed we have greg here welcome greg hello am i late or did we start early uh daylight savings time you're an hour late huh google lied to me they do that a lot these days yeah i think we're wrapping up now damn so yeah uh so yeah we were about to wrap up um

but since greg is here greg if you would want to quickly share your thought on the issue that you wanted to bring it up about the proliferation of eip statuses and see if people can like hang hang around for a few more minutes to discuss about it i think it just comes down to not seeing the point of a review status drafts are always under review so i just i don't see that or that it's very much so i guess like the first issue was

brought up is since the introduction of the last call status a lot of people were waiting to review until it was last call and last call was meant to only be two weeks um so it's a problem introduced from having the last call as a status that people would wait until to give the review until it's put into the last call another thing is we would want somewhere a point of maturity where the eap is out of draft and into a point where the author is asking for external review which should be helpful in the hard four coordination process because at that point um we could have a prerequisite for an

eap to go into cfi by needing to be in review you can make that explicit well the core devs are free to pull to pull drafts into the core dev process at any point that's pretty independent um from from the ipp process point of view um as with the vip process it was modeled on yeah the main transition is just a final um and also for the itf process things just stay our rfcs so i i just don't see that adding yet

another status solves the problem people who want to procrastinate will still procrastinate and from what i've seen important vips start getting discussed even before their drafts and get lots of discussion all the way through the process so it's it's really just down to the author um to to push the discussion forward out of curiosity is your do you hold the same um contention if this was a like a new field in the the front matter that

was like review last call and the status was only draft and final you still hold the same opinion in that case i'd be happier with just an optional field that authors can use to track status in whatever way is appropriate i've just used just adding a notes field that gets removed at the very end of the process so that i can inform people what the status of the document is yeah but not as not the official status but just things like this is where it is these things are still in flux these

things are not yeah some non-normative material basically at the least i don't as an editor i don't want to have i don't want to have to touch the change to review status it has to be there it's the author's call and the bot just just pulls them in so my main desire whether it's through statuses or something else is just that we have a mechanism for authors to signal that hey i am i think i'm done with this i am ready for other people to start

looking at it as an editor i have way more work than i have time for and so i need a way to filter out eips that are not actually ready like the author is not ready for me to start looking at it yet because they're still iterating um which we we want to we've been trying to encourage we've been trying to encourage two people to get an eip into draft quickly and then iterate on it and i need a way for them to be able to tell me hey i'm done iterating i think i need someone else to look at this who's similar to the ip process and understands you know what makes good idea and to help me get it improve it from here and whether that's a status or whether it's a separate field i care much less about i just as what

i'm looking for personally is just some signaling mechanism that is standardized so that's you know tools like for me the tool is github so when when the in the github bot so when the bot says hey you're trying to change the status you can't without an editor that's my signal to step in um the bot could of course look at anything any other field and that would work just as well as long as i'm getting some signal that the author is saying i'm ready and that's that was all my problem i lose track but doesn't help have a labeling system i know it does for issues and accent went through it and labeled it so it makes sense to just use github

system rather than claudia wrong no uh sorry so labels work on pr's and issues but you cannot label um files which is what we would need in this case okay that was my question so that doesn't work um it's just drafts vary but they should be ready for people to look at as soon as they're a draft and some people will want to immediately start looking at them and start helping an author say whose english isn't up to snuff just at that level yeah other people's drafts will already be excellent in that respect and ready for substantial discussion um

typically the purely editorial work happens on the pr's and the substantial discussions happen on the magicians and other discussion two places so i just don't see that adding as fast status really helps the issue of people not paying attention to things they care about you know they will they will continue to not pay attention um yeah so for me i i think i agree with greg to a certain extent and that i don't think the statuses will help with getting people to review uh

normative content um for me it's it's purely just as an editor like i would like a signaling mechanism i i agree though i don't think that anyone else is actually watching the status besides me and perhaps some other editors like i think everybody else ignores it in fact i think people ignore it to the point where like we have things going into hard forks that are still you know drafts that have had zero edits done to them because you know the author has had no one look at it or no one you know review it um so i think the status is ignored by basically everybody right now except for me and you know other editors why not more free form fields rather than trying to decide in advance what information you need

just a place a place for keeping track of information that's that's currently relevant to a document and just see what turns out because uh there for for me be again because i'm looking for automated signaling and right now i ignore all pr's that are auto merged so any pr that someone does to their own eip gets auto merged by the bot and i immediately archive i don't even look like i do not read it because i do not have time to read every single change that everybody makes to their own stuff and so i wait until the bot says hey i can't merge this and then that's when i go and look and so again i i'm okay with any solution to my

problem it doesn't have to be the status right but that's currently how i do it but that's your choice as to where to engage other people engaged sooner i've been encouraging people to engage with the editing much sooner you you don't have to be an eip editor to start reviewing prs yeah if you're interested in a pr start reviewing it be helpful [Music] that would be awesome so far we have not not had much luck with that well there's enough people interested to keep these calls going um and

i've said that the only real privilege editors have that other people don't is write permissions on the repository yeah i agree with that part um and that also means authors um it can be scaring up reviewers you know and don't you know don't just put it out there and hope somebody wanders by to look but go looking for colleagues and say hey please take a look at this yeah the people that want the stuff you

know i'm a stickler for process but i like the process to be simple enough that that's not hard to do just go back and look at vip one it's a very simple process it served bitcoin for longer than we've been around yeah and look at the ietf process which is served for even longer they're very simple makes sense but this this is in my review of the pr

so discussion can continue there um i did notice that particular pr has no discussion too like so usually ppr is applied vrs don't only eips do or do you mean the eip1 doesn't have a discussion too link i believe it does not uh that's probably true all right go check real quick i don't think everyone has a discussion too it makes it harder to have these discussions uh that one discussion two was uh recording on this wall uh several months ago it was just

apr just finally being made now for discussions done in march february april i wouldn't be against creating a magician's thread that's specifically eip1 discussion or potentially even a whole sub forum on the magicians if that's more appropriate that's a discussion too yeah i'm afraid i was desperately trying to find a place to shelter my lease was running out just as the lockdowns were starting

so it's fun but i can live with it better to the extent that editors don't have to approve these if it's something the author can do for whatever reason but it just doesn't seem to accomplish a whole lot i generally i try and get review going before there's a draft getting get an issue going and start a less formal discussion on the issue itself [Music]

just because it's so much easier to edit than this year than to put pr's this would be something easier to auto merge because ideally well not a deal i guess like typically only the author would know when eap was ready for external review because they've done all they can to iterate on that um at that point i think it should be fine for the eap bar to auto merge an author's request to move it to review would it rather help to either just make the last call longer given that people tend not to look at it until then so provide

more time or make it more clearly iterative it goes into the last call if it's not making it it bounces back to draft and can keep going in that circle until the authors give up or it gets through and what you just described is the current process um i think the the problem is by the time someone moves to last call in my experience they are to a point where they're no longer willing to make changes like they're psychologically at a place where they're like i am done with this and it's not getting changed um this is particularly for corey ap is not as big

of a problem it's a real big problem for ercs where someone's like oh i've already implemented this and there's 17 implementations out in the wild on production and we've been in production for six months and now i'm moving to last call and so yeah like the i recognize this is this doesn't solve that problem like of people waiting too long the hope is is that it's a little more clear to people that review is very early in the process whereas last call is very late in the process right now people think last call is very late and so they wait until like they are done done this thing is out the door already i'm just formalizing it and the hope is i think by having it labeled review they'll instead think

oh this is a stage that's early in the process that means i'm done iterating but if so now is a good time to give feedback um i don't know if that will be successful in that i don't know if people actually pick that up or not it's hard to say well then should review be a major milestone rather than an afterthought the author's happy with it the editors are happy with it so as far as form yeah a big announcement is actually made through all the channels and you know sort of leave no doubt that the community has been informed that this thing is under review

think that's kind of the hope is that by having this review step in the middle that's not at the very end and it's not the very beginning so drafts is very beginning last call is basically the end but having the step in the middle it kind of gives a a nice big milestone like you said like a a time that is appropriate to announce to the world now is the time to look you know now is the time for everybody to start caring you know before this probably me and my friend you know care and me and my my close colleagues who are working on this together um whereas last call is you know like i said it's in production by the time it's last call and so it'd be nice if there was a milestone in the middle so is this a formality the author sort

of says okay or do we make it a big enough deal and make sure it really gets pushed out to the world um i'm more ambivalent on on that whether it's i guess the question is whose job is it to announce an eip if we decide there's a milestone in the middle whose job is it to announce is it up to the author to go and outside everywhere or is it up to like they mark it as review an editor reviews it and make sure it's actually as good and then like cat herders announces it like who who's in charge of that process well nobody can tell the counters what to do that is the kind of thing they might volunteer for

so in one of the previous meetings we discussed about this eip part thing i mean i'm not sure we have started it yet but that is something that we can consider with the help of james so i guess you're referring to the twitter bot right i mean if that will help the process i share greg's opinion on twitter in

general but i think the idea is is some sort of automated system for letting various channels know that aip is worth looking at twitter being you know one of the channels that perhaps you and i don't like but it is popular it's good for making announcements sure i guess i'm coming down to either review is a actual milestone that um is a hurdle to get over and the world knows about or else it doesn't really serve a huge point

um yeah the author's free to make blog posts and otherwise let the world know hey this is here i really wanted i like the milestone idea personally i'd be in favor but that's that's where the author needs help yeah and because that that really is a problem for authors if you're really good technically you may still have no clue how to get the word out to other people that something's happening do the cat herders think they might be

interested in uh that part of it like getting word out about eips that have moved into review yeah i don't think we would mind at least like letting people know with the help of twitter or even with the the medium update that we share but if there is something specific in mind like any particular format would love to know that or channel and we've done some of that stuff already yeah yeah i think also like the peep and eap review stage would be a good time to do the peep neat video i think the yeah um twitter maybe if we had a place to announce in

discord if that's where people are hanging out for especially for core eips maybe announce it in all core devs channel the first time once it hits review um so i got people twitter all core devs maybe maybe there are others channels people listen to is there is there a i guess the ethereum blog i don't know if that's this is maybe too specific for the ethereum blog i think it's more general yeah we can take care of other communication channels like this eip uh channel in the at rna discord we can announce it over there we can certainly make use of ethereum

cathedral's twitter account to share about it but um yeah not about the ethereum blog part and yes any video about that and when it gets into review is also a very good suggestion uh we'll try to get in touch with others especially for the corey ips we'll try to make an episode on that i hope that is going to help so one more topic that we were

discussing before many of you joined is like there are a handful of proposals which are there they have been reviewed by one of the editors but not many editors attention were there so how and like what can be the process in which we can agree to move those proposals i mean that is being reviewed by one editor but if he has a reservations of pushing it like merging it directly how do we handle this kind of situation how do we want to keep it going and not just become a blocker because we did not get opinion from other editors now that we have three editors

here on the channel so if anybody has to share anything on that this is specifically for changes to eip1 the readme evp template stuff like that when those suggest prs are made if one editor reviews it and all the other editors remain silent for say a month or weeks or whatever should we take that for a cent and it's okay to merge or should we continue to try to wait until we get some sort of quorum of editors actually reading it

um wait am i muted sorry i thought i was hardware muted um i think for right now like the current time period we should take that as approval and it can get merged however the root problem is not having enough active editors so if we can tackle that as a priority and i apologize i haven't been able to be on the last few calls so that might have been heavily discussed but um uh that that should make that problem less of a problem uh yes achieving quorum is much easier when you have people who show up yeah exactly so um solving that would be nice and i'm i'm

starting to brainstorm and talk to people about funding options for editors um to get more incentive since there's not really an incentive to do this other than goodwill um and you know it takes time so people should get monetary reimbursement for this in the meantime in in the meantime so if i understood you correctly just i will make sure i didn't misunderstand um in the meantime until we get more editors you think that it's reasonable to just like if we get one editor to review a change to like eip1 or the template or the readme and everybody else remains

quiet for some amount of time then we should just go ahead and merge it and that's okay and if so what's your time frame ideal like a week two weeks a month six months two weeks is the ideal time frame and that is my position but i don't hold it very strongly um i'm open to other people's opinions on it um obviously i mean the one caveat is uh everybody should be aware of is that micah is going to become a benevolent dictator or malevolent or to be seen yet uh very soon if we can move forward with this there's like a dozen it doesn't eip that a dozen prs out there

that are changes to the process or changes to the template that i'm the only reviewer on and as soon as i have the green light i'll be merging them all and so i just have been hesitant to give myself the green light without anyone else having to say i personally like the idea at this point in the eip editor life cycle history whatever of having somewhat of a active benevolent dictator or a group of editors who were semi-active too active uh who are making all the decisions because if you look back at the history for a long time like the overhaul that i made to eip1 back in 2017 i think i just did on my own and

merged it on my own so there's a precedent for this um that i'm comfortable with right now but it could quickly quickly go bad if we don't have the right people yeah i'll just say hudson did a year and a half ago i'm safe blame him throw me under the bus i'm cool that's my plan uh by the way uh they just launched the deposit contract for eth2 which is why i was i was having to run around doing a little bit of comms work for that and um there's like a blog up and spread the word about the address so people don't use a fake scam i address you people will use this fake

scam address yeah yeah great uh so for the time being we consider that the eips that have been open for over a month uh i am particularly targeting this eip um that was for eip one number pr number two nine nine six in which we are trying to uh uh address the recent status change that can be merged if there is no further discussion on that uh considering greg you you are here and the concerns that you have raised uh can we consider that as a result like what is the consensus can we go ahead and merge that as to the eip1 as the new eip

statuses i think that's okay greg was the dissenter i think we're waiting to see if he is okay with it sounded kind of like maybe either greg still i'm you okay my descent is mild enough i'm happy to to just continue discussion on the draft once merged okay yes so uh the uh the main uh difference that we were trying to create here the draft and

review is like that we also announced in one of the all core dev meeting as a proposal gets into the process of network upgrade at least that should not be considered in draft because now that is heavily under review so it makes sense to change the status to review and that would be like obvious for everyone that it is under review clients are considering and that will give a clear signal that it has moved from the status of draft and people can start looking into it so that was the whole idea of it so if it is not a hard descent i think it makes sense that we can continue with the process uh the statuses that we have decided earlier with the help of this group

and go ahead and merge that if that's fine with you correct yes okay um many of us um who got here on time um besides me because i've got the daylight savings time wrong um i have been on for an hour and a half do we want to wrap it up um you were not alone there's like two of us here on time and six that showed up late oh okay yeah but i didn't want i didn't want like people to feel like they have to be here for two whole hours um um i can keep going if we have useful things to talk about

i don't know what other oh okay cool so that was like the main item of discussion and the number two questions brought up on the eib survey we already have discussed it so people may find it in the recording the next question uh the item that we were hoping to discuss here is about the eib triaging permission uh do we have any progress on that like is it still something to be considered and what is the update on that if there is any

which item is that again no like like client may know if there's any change uh yeah that's about the triaging permission for eaps i think hudson likeline oh take that oh yeah sorry about that yeah that actually is me um i i misheard um that take that one off we can't do triaging permissions because of what type of github plan we're on and i think we discussed that three meetings ago and it just stayed on the agenda accidentally sure i'll take it down thank you so while we have a like good amount of editors on the call

there is another um item which was sometimes discussed but it has never appeared as a part of agenda item here about the meta and information in eip what is general opinion on that like we have heard certain people's opinion including mine too but if there is anything new to be added to do we really think that we should have meta and information eip be the part of eip repository or not [Music] i believe we should have meta that serves a bit better purpose than informational i'm indifferent on keeping informational because i think it's not used very much and it i'm kind of i think it was

micah or gregor both who kind of said that this is a specifications repository and therefore having an informational eip kind of throws a wrench into things as far as the purpose of the entire you know repo it's a slippery slope uh because there's no clear line to draw in my opinion there's no clear line for this is acceptable for this repo and this is not because i've seen people submit informational reports that are informational eips they're like hey i'm documenting my my app in the eips repo and it's informational so that's okay and i don't have as an editor i do not have a strong argument other than i feel that it's not appropriate for this and i'd rather have

better statements than i feel yeah we've had those for a while we picked them up from vip um i think i think we can just tighten down the standards on those they should still be technical documents not necessarily specifications to build something but technical documents um offered for technical discussion and it's not that slippery so a recent addition in the information category is eip2982 uh that is about the serenity

phase zero or that is uh created by danuran and metallic butarian it talks about what uh these uh you know this uh itam 2.0 phase zero is so i personally feel that these kind of information is valuable and for that purposes we should certainly have the informational eip in that repository and yeah of course we can do screening uh what to be approved and not approved but that's general my thought on that well that's that's an example where substantively it's very controversial

yeah but i think when we were done the editors and the authors were satisfied that it was a technically useful document that wasn't you know making commitments to do anything or just going over the history of things but saying this is a plan to improve ethereum that we're working on and it's a separate project but here's what's relevant yeah and so it was a useful technical document that was informative to those working on the 1.0 chain i think we can start to draw those sorts of lines

right drawing lines would certainly help but the purpose of informational document is to provide all kind of information that is valuable in ethereum ecosystem so uh that is still a question we want to go about it and about that meta eip historically we have been using at iip for having all the proposals which undergoes any network upgrade now we have berlin coming up do we want to maintain that meta eip for berlin i believe we've all agreed in the past

to move it to the east 1.0 specs repo for hardware coordination so right so uh in that case uh do we see any more use of meta eip there like do we still want to have it although it explains the process and uh that was one um i mean example that i came across explaining of the process and the other one is to keep the list of eips and if we are containing the list of eips in at one dot or spec repository do we still see the need of having mata in eip depository

well isn't eip1 meta that is yes what else would it be if it wasn't meta that's kind of my own that's my number one reason for keeping meta is for eip1 so there were certain i think the question is is there anything else that would go into meta beside the ip1 or is it literally just eip1 um it's literally just eip1 for now and if there's anything in the future that requires it like if we were to like eventually split out ercs and eips for instance there might need to be a meta um talking about that otherwise otherwise no so we have this discussion

uh like in this call today about the eip1 so eip1 is like considered to be the process explaining the process of eip and it's a documentation for explanation of the process for eip standardization similarly we have a process for different other things i mean like again i i do not want to get into that network upgrading this thing but yes we decided that network upgrade process should not be documented in meta but it should be in the readme file so there was this another discussion of eip1 uh before some of you joined today about having readme

and eip1 in the same page like do we need to have these two separately or should be should we have it one uh before before i move on real quick is there i wonder if it would help with the uh and i don't want to go too deep on this rabbit hole so just know i don't actually have strong opinion here um i wonder if there's value in renaming the meta status to special just to indicate that this is not a status that anyone should probably ever you know go create an eip with this status this is for very special and specific things that only the editors really understand

so don't try just kind of making it more clear that the meta eips are not a thing for end users to be using so stop creating media piece i'd be fine with that sounds good no that's all right that's that's really helpful so i think we should you know uh when we are having that blog um i know edson has dropped but we would like to let these points to be included in that blog so that this information

should be publicly available for people to refer and then the confusion around this will be solved like should it be meta should it be informational and others that's my hope i'm fine with blogging about anything anyone wants a lot of eip authors you should go blog about this instead of writing any ip yeah cool so yeah i think uh most of the items that were added for discussion today we have covered and we went a little over time sorry about the confusion

created with this daylight saving um this meeting eipap generally takes place at 1500 utc and um we would like to keep it that way if uh if we do not come across like many people saying that we would want to change it but if not then the time is 1500 utc so if anybody has anything else to discuss we can take five more minutes otherwise we can wrap it i would like to take a sec just to review the decisions made it sounds like one decision made is we will have a review state and the

other decision made was we're going to convert meta to be special and and we're going to have that and all and eip1 is the only one that has a special state have those decisions been made that's what i got from this conversation okay just wanted to make sure oh and micah is dictator for life uh more specifically we're saying that if there is a change to the process that is proposed via a pr to

the eips repo the editors will be tagged on it and then after two weeks if none of them have responded or if the only ones that have responded have responded positively then we will go ahead and merge that oh great thank you for summarizing that in the notes so that'll make it easier for the note taker yeah that's really helpful so thank you everyone for joining today the next meeting is on november 18 at 1500 utc see you all in two weeks thank you really really quick uh before you stop recording um since we have hudson and greg here

they're speaking of micah as a dictator um there are a few eips that i personally am not merging because i disagree with them but i believe that i'm alone in not merging them and so we need some other editor to step in and merge them like we should not have the power to my github notifications are a little out of control so um i i'm happy we're just keeping up where's a good place to get a hold of you uh discord or telegram either one is equally fine okay yeah i can send them over to you i'll have to dig them up puja you actually know what they are because i think some of them are yours um like basically any informational and

meta eip i have a i've been personally blocking not not blocking just refusing to merge my hope was that some other editor would step in and merge because they think those are okay and i i don't and so they want my personal opinions to be you know dictator-like but they're ending up that way just because of you know i'm taking a personal stance by not merging but you know someone else merges i'm not going to fight it and that's turning into i'm blocking things and it doesn't make me feel good okay sounds good i could help okay i'll set try to find them and send you links tomorrow all right thanks for watching this puja thank you everyone for joining

yeah have a good one bye