EIPIP Meeting 100

Transcript

welcome to EIP IP meeting 100 this is issue number 312 on eat her/ EIP IP GitHub repository um today on agenda we have some discussion with respect to EAP process standardization open issues and PR will take a look into call for input and um some other discussion continued from the earlier meeting followed by eips insight for the month of February so starting with the very first item which was suggested by Greg here it is about adding AATA section for final EIP we understand that this discussion came up multiple times in the EIP meeting but um because this was

specifically requested to be discussed and make a decision in this meeting so let me invite Greg to maybe provide some background why he wants that and we can open the floor for editors to share their thoughts over here um yeah I'm looking through the agenda item it's probably not that important it came up recently on on a on a request uh from an author to add a co-author um there was some discussion some discussion of that so far as even what authorship

meant um so there's some disagreement on that um but I think it's pretty clear uh IND industrywide for publishing that a major contributor to to any uh to any publication is considered an author and certainly if if a primary author is saying you know this person is a co-author then there shouldn't be any real any real doubt of that and if that person was was left off left off the list that that's an error that should be corrected

somehow and in general um for instance for a final EIP um that's a core EIP the uh the EIP needs to describe what's actually running on the main net and if it does not describe that then it's an error that needs to be fixed um and for years uh the intention has been that we can have AATA and we simply have never gotten around to um to uh deciding on just uh how we want to do that so I

wanted to just settle that settle how we do that so we can even have reasonable discussions of whether some requested change is an AATA because it just keeps coming up um and I think in the industry it's done in one of two ways either the document itself is corrected and a footnote is added saying uh a pre previous version you know had such and such mistake um or the original document is left alone um and then there's some sort

of footnote um or separate something saying you know uh this is this is the correction um the ITF does it the uh the latter way so there's an original document uh in the header it will say there are Arata and then there's they maintain a separate uh list of all the arat and actually have a a usually a link a link to a version in which uh shows the the version with the merged uh Arata um we can do it either

way um uh the latter way I think jit hob would support by uh creating a fork of that document uh that's been corrected um but it it could be done either way so i' just like to open up a discussion on that one um and if we get any consensus on that then there's the particular issue on the uh on the pr are to to add the missing author somehow so what would the Arata section

like bring over get commit history um well first I guess the first decision is um you know do we do we allow for AATA um I think that decision needs to be yes but I don't know if we have consensus on that um I think we do allow very limited Arata right now um and we use get commit history to track them so I think you know EIP 1 does say that we're allowed

to add clarification and um ertic so yeah okay I'd suggest that [Music] um only normative things need to be fixed if it's not normative then there's no there's no compelling reason to change it um but anything normative that's wrong um needs to be made right um and I guess authors are on the edge as to whether that's normative um but it's it's important um um you

know even a even just a search uh with the duck or with Google you know we'll find policies for you know for Journal after Journal um you know indicating that uh you need to give credit where credit is due um it's I think in some cases it's almost a legal a legal thing someone can actually Sue uh that they were an author and they were not credited um so if we already have a procedure into which we simply correct the document um and the history shows that a

correction was made um then I think maybe we just we need a a field in the header um pointing back to that commit or or what do we already have a process uh so I think the process right yeah actually uh the reason that you mentioned that somebody might SU is the reason that we should not be having the author list because people can keep coming back and saying that you know I contributed to this but I was left out and it is already always it will always be a bone of contention so I think that

we should change author to maintenance and we should call it a day instead of opening this Pandora box of allowing the changes to final IP um well wait a minute the first question is um do we have a process um do we have a way of of um make making a change for anata how do we do that and how do we indicate uh that that's been done yeah so right now we use the call for inputs for that so if somebody wants

to make a change to a final EI IP uh they or or more likely I uh can make a call for input where we collect uh editor opinions and then um decide if we're going to allow the modification or not and if we make the modification how do we indicate that something was modified uh you just modify it and then uh the changes are shown in the history okay that would it make sense to add a field to the header and indicating that that it had been modified and given

giving the commit [Music] um so there is a proposal that um the testing team brought up recently for uh EIP versioning and I think that would be a reasonable way to um yeah sorry I think that would handle reasonably what you're suggesting so you you would um indicate why you're changing the EIP and then you'd also include like uh either a patch minor or major version number bump yeah thank you Pua and um that would be in the header so you would be able to tell what what

changed and when okay I'm on a phone now so I can't easily I can't easily read the chats there's not much I can't even see the screen outside where I am it's it's too bright um just so if people are putting things in the chat I can't see them um I'll put it in Discord for later okay if that's already settled then then then the issue is whether whether we can add an author later and I strongly think that if the primary author is saying um we we missed an author and we need to we need to give this person

credit um I I cannot see any reason why we would not make the change so I think this is where gaj jinder's objection comes in uh where if we have authorship as a field and and please jump in if I'm misrepresenting your opinions here but uh if we have authorship as a field then people can always come back and say oh this person was an author this person was an author even though they didn't contribute meaningfully to the uh document um and so uh he's suggesting we rename the field to maintainers um and

remove the implication that they are that they have authorship credit um very often the authors are not gers they they were authors right exactly so we should rename the field so it isn't authors anymore um and make it purely just people who have permission to merge PO requests um so good Jinder posted in chat um how can one miss an important author all this while while while the EIP went through through to become final if you change that often there are

eips um core eips even where the original authors no longer maintaining it at all exactly so I think the idea would be to not call them authors anymore so we go in and make a change and say I forget who the authors of vc20 are but I think they've all moved on and if not that one I'm sure you can find a number of uh of you can find a number of of eips uh even very important ones for which the authors are are have moved on

and have no no further interest in maintaining the document yep so we have such eips where someone is trying to for example move them from stagnant to uh to basically draft status and uh we can't do that we don't allow them to do that because the original author does not agree to that and original author also doesn't want to maintain the EIP so I mean we already have I mean this current uh Behavior Uh with regard to the eips that I mean if the final eips anyway don't need maintenance so again it doesn't matter whether the authors

have moved on or not and for the eips that have become stagnant if the author is not willing to let somebody else take charge and so they can't really do that so uh in that case a new IP has to be created so we already have this process where we force people to float a new EIP if they want to worked on an old IP and uh if the previous author is not available or previous author doesn't agree through that um this gets

strange [Music] um for instance EIP 615 uh Christian is still an author um he contributed substantial text which is still there um he actually opposed thep at this point and I asked if he wanted to be removed as an author and he did not he wanted credit for the text that he contributed

even though he no longer wanted the the EIP to uh to be accepted um by the c devs um in in the form that it's in now um and I don't think it's ever been withdrawn it's it's simply in probably stagnant status yeah regardless that's just a an example U where if for instance eof failed I might very well decide to to re to resurrect that one um and would see no reason um necessarily to have to give it

a new number uh just because one of the authors wasn't interested um it's it's a dicey situation um but legally it's legally it's much more uh um much more appropriate to leave the authorship unless unless that author actually wants to be removed as the author so just to kind of restate this again the idea would be that we no

longer track authorship at all as part of the process and we only track permission to merge Port requests and that would be the the change I think that gender is proposing only the editors have permission to actually merge so when unless you're changing the Status um authors can merge without edit or approval and [Music] this all gets very

confusing um do we um if the winds up being conflicts between existing authors um then what I think uh what has been suggested so far um I'm just trying to take some excerpts from the uh discussion here if there could be confusion between or like disagreement between two authors of the

proposal the best way to go forward would be to come up with either a new proposal or just to you know remove the author with obviously the author who is disagreeing can can agree to be removed at that point and we can move forward with the proposal if I understand correctly people are suggesting here is like we uh should not make edits to the proposal when it went into final status however that's not the case with proposal 615 that is still in stagnant can be brought back it can be resurrected and uh it can be updated with the author list over

there but uh in case a proposal is finalized we should not allow to update however the another proposal that came up was versioning scheme that may allow to some of the nonar things and if people are open to consider that updating this author as Nona it could be a part of that do we want to go ahead with um call for input here uh to have collect points from other editors what do they generally think about it and we can perhaps make a decision in in upcoming meeting I this seems to be an easy case um the the primary author has said

basically it was mistake to leave this person off and we want to to add the person to so the decision on that particular EIP has been reached um and I don't think anything new has come up so let's not reopen discussion on it okay the decision was incorrect and I object strongly to decision and I had to I would block the consensus if I could um it is completely unfair to the primary author and to the person the primary author wants to add um

noce yeah can we can we do this so Greg I I think we like should very cauly use our way to our power to draw consensus if we are like the minority opinion I think it's okay that we kind of just like how Supreme Court do we can just publish in my only opinion but still allow the uh if we feel strong enough but still allow the general editor group to follow the consensus of other people because any time a blocking opinion a blocking uh ISS anytime if any one of us raise an I um an attempt to block consensus it's kind of a damaging to not only our efficiency

but also uh like how we collaborate so I like to say that I agree with you on opinion side I'm okay to site with you on minority opinion I am not very comfortable that we are using this to block a consensus um I don't know what to say um I read it carefully and the the arguments the arguments to not give this person credit simply I I think they're wrong I absolutely think they're wrong and I think I think they

set a very bad precedent um I I agree with you on that yeah I totally agree with you on on on the fact that I dis agree with not giving this person credit and and then we pretty much claiming a right of Editor to deny adding new Authors which I don't think is a good idea to begin with but also think it's very sort of jump in here but this call for input was open for 30 days and I'm using my keeper of consensus Powers here we are not reopening this discussion unless we have new arguments that weren't listed on the on the call for

UT I agree with that Sam I I would go with that consensus and so this is now a policy going forward that we will not correct off sh then can we say this is not a policy no I as as far as I know we aren't like precedent based we can decide whatever we want at the time yeah okay so uh I guess I interpret the consensus being without setting a presedent at this time we're not adding it unless seeing new argument and what uh what has been the reaction of the primary author

and the person who should be added but especi as far as I know they haven't said anything since opening the PO request okay um as usual I'm not a lawyer none of us are um and CCO might complicate things um but they're I believe their substantial legal precedent about um you know failing failing to give to give credit to an author so I don't think I

don't think there will be any lawsuit in this case um but um I think we're doing a bad thing in not and not allowing a primary author to uh to give credit and I'm I'm sorry that I did not notice I didn't notice um I think I was in the discussion early on and then time went by uh before I noticed discussion had closed off um but so I apologized for that um and you know I sit on the edge of

whether I should remain an editor um I basically way behind in difficult work on an $18 million startup so I can only give occasional attention to what's Happening Here I try and keep an eye on things that are very important to me um of course yeah and you know we don't want to unfairly disadvantage you because of your the amount of time you can commit right um I I'm hoping that our our 30-day windows are sufficient um maybe we need to make them longer I'm not sure yeah or I need to figure figure out

some way to to nrow my notification stream um I can I can like email you like what whatever makes it easiest for you to follow along um I can I can definitely figure that out yeah I I need to look at the titles to see if there's something discriminating my currently my filter pulls in pulls in so many notifications they stack up in the folder to where I have I think something like 5,000 unread emails of of notifications of ethereum related stuff um so uh yeah if you're if

you're willing if you're willing to keep an eye on things and notify me before they go to final yeah just let me know how um we can we can discuss that on Discord or whatever I don't want to take up too much of everybody's time mostly I just I try to notice when VIP meetings are when these meetings are coming up and check the agenda and be sure to participate um I I don't know on this one but I really appreciate if if anything that requires consensus does come up at this meeting rather than the consensus happening on the discussion Fred um because it's it's hard even to

tell on a discussion thread whether a consensus was reached or the discussion just sort of trailed off um so I don't know yeah so yeah I mean for that we have called for inut uh included in EIP meeting every other week whenever we have this meeting so I think that would be a good place to follow up with the um the points where consensus are required yeah I I do not know in this case whether it came up at a meeting that I just missed um and I don't does the agenda go out as some sort of separate um email or something um for So currently I publish

them on Discord and the the GitHub if there's some other way you'd like me to send them I can I can certainly do that as well unfortunately dis discord's mailbox feature is useless it only it keeps track of the last two weeks of messages and so if if I'm away or even just traveling for more than two weeks um I I'll come back and it's well here the last two weeks what happened before that well we erased it too bad um and just I don't know if Discord even has a good way to say please email me um

anything that would have gone in that box um so yeah that would help I try to attend all these meetings unless there's a conflict um but I think I think the only way to actually check the agenda um is to is to you know look the day before um and that's it's hard to I may have already scheduled a conflict by then so and I don't know if we can reopen this but but I really feel strongly uh that we are doing a big disservice to these people and I doubt

they would go to court but I think doing things this way actually actually opens us up to Legal liability and it's hard to tell because copyright law varies internationally so the exposure is international um and just um somebody said something about it's not for fluffing resumés and it isn't really credit and that's that's just a wrong argument trying to decide Things based on something that might hen hypothetically with low probability happen in the future is silly um and it's not just about fluffing resumés

it's about giving credit where credit is too and that's just a long established principle in uh copyright and and authorship um so gaj Jinder mentioned in chat that copyright has been given up through cc0 um right but only only the copyright holders can give that up so if someone is is there with both that person and the primary author um basically you open up a different kind of liability where a

person can say wait a minute I was an author and I did not release my rights um yeah that that can happen regardless of whether they're in the list or not right like that's yeah and like I can I yeah please go ahead son oh and there's no like restrictions on who can add author like I can add you to an author and pretend that you released it via cc0 so that like we can't use that list as any kind of like legally binding set of contributors

[Music] sorry I think we should perhaps consider this as um as an uh I mean even if we don't want to quote it as a precedence that we have made this decision this could be an opportunity for new Authors to make sure that whenever they are moving any proposal to to a final status please be sure that there would not be any further edit it's not just about authors it's about any other thing authors are definitely important their contributions are immense towards a standard but um this can be an example that be double triple and no matter how many times you need to be very sure that this is it this is going into final please check it out okay I

mean I don't feel strongly enough to block it but I would very much like to reopen the discussion on this um I I I simply we made a wrong decision in in my opinion and if we have no way to go back and say we made a wrong decision and we're going to correct ourselves um makes no sense to me I think we can let it rest over here uh because this was already closed so as I mentioned if we come up with some new

references new example we can perhaps open it or if there are any other new cases about this maybe we can reopen the discussion I'd like someone to reach out reach out to the author see if if they're as unhappy as I am or if they're willing to just shug and say well the process was gone and I'll accept the result simply just I hope the author follows the EIP meeting and may be able to reach out to us or may be able to comment on the um PR that was

open uh to add some new references for our consideration okay well I will register my extreme unhappiness um with the situation we are we are doing a we are doing a disservice to the authors we're just being unnecessarily rigid um and that's a regular complain La about us and our process that we're just rigid and bureaucratic and impossible to deal with that

way right I mean this is decentralized yeah maybe even a even a further v v uh Wilder idea would be to not render author SL maintainers on finally IPS anyway I mean when can render them on or maybe not even on the other eips because it's about who can push and who can edit and we can just totally remove this tab when we renter it on the website the authors can even even

release rights under a CCO and so if you leave anyone so one has to credit the authors at some point even even for that CCO to be meaningful and so it may not happen but whenever we do this we set up a situation where an author an actual author this person actually is an author can come back and say I did not release my rights um yeah I'm with Pua on this one let's

let's End discussion on this topic and um we can continue with asynchronously uh so next up we have the working group Charter uh so I posted a link at the top of the chat and I will repost it now um so this is kind of my work in progress draft on um what I am going to be showing to editors later to vote on or to rough consensus on whatever the term we want to use um and this is describing how working groups are going to work their General responsibilities kind of the shape of all of that um I just wanted to bring it up here in case anybody has any early feedback but it it's not done yet um that's it for that topic um I'll turn it

over to Puja and you can continue the call so the next one here is about uh an open PR I believe uh we made a decision to merge this one in the earlier meeting but it seems to be open and the author is wondering if there is anything to be done from their side can someone maybe take a quick look and see where we are on it the pr number is ERC 213 yeah I think this is fine it's adding comments so I'll just go ahead and Mer this merge this unless somebody objects this is a final ERC and it's adding at return annotations to um some

functions yeah right I mean it was approved yeah it was approved in the last meeting as well but perfect very well uh the next here are coule of call for inputs which uh have crossed the deadline um Sam if you would like to maybe share more about it and if there are any def definitely so uh we have 306 and 308 so 306 is for back references from a later EIP to an earlier one uh so this would look something like um ERC 223

would have a header in it that's superp seeds and it would have the value of 20 so it would be like suedes coal and 20 and that would be an ERC 223 uh and then uh on the erc20 page we would have a list of all of the things that are claiming to supersede erc20 so this would like improve navigation between proposals that claim to replace one another that's kind of the 30 second summary of this um yeah yeah um so I guess we'll just do a quick temperature gauge here how do we feel about these back references I know good Jer you said you are not in

favor yeah I mean as long as the Clutter can be managed I'm fine with it I mean if there is so many back references that can clarate all right and Greg do you have any opinion on this right now or would you want to bit more time to look at it I'm not sure if I completely understand I'm I'm sorry I'm I'm on a phone here so it's hard oh no no worries so are we are we generally not wanting to supersede or are we generally

wanting to have supersede I think that's what we're trying to figure out right now um I'm in favor of it and yeah I think for what's on the main net um there's only AATA it's already on the main net um and if if there's an upgrade then it's just sort of um is just sort of automatic um that um H it's just sort of automatic that a that an EIP the core EIP needs to describe what goes on the the main net

and the appropriate thing I guess is a new a new EIP um the purpose the main purpose I think of having superseded is so that somebody who's trying to implement it doesn't go in and Implement an older EIP that's no longer the way that we do things um a little less a little less important for erc's but still important um I said in last week to write a small web server and started in on using one EIP to do it and then

notice that it had been superseded and had I done it according to the first diip it would not it would not necessarily would not necessarily work because things have changed um so um I can see a need for it um but I'm not I'm just not quite sure whether we want to do it do it that way or not um for all right yeah I'll add those to the thread and uh

yeah thank you if you could send me a link to the thread I don't I don't I don't think chats tend to stick around after calls I may be wrong I just don't know where to find them yeah I'll send it on Discord okay perfect uh with that perhaps we can move on to the next one or is there anything depending on call for input uh no I think that's all of them I don't think there's any new

ones no I don't think so yeah I think we're good very well moving on to the next one uh that is continued or updates from the past meeting uh it's about RP process documentation but I haven't heard back from RP team seems like they are uh doing well with what they are doing right now I have noticed an introduction of another rip uh this month but yeah we might want to hear more from the team whenever they have an opportunity to share about it apart from that uh in the last meeting we discussed about web page rendering to include EIP ERC rip I know

at this point of time e. ethereum.org include eips and ercs but they are not able to include the RPS part um Sam also made some progress on working group on their website may have missed this samply please help me remember that does that include RPS as well uh so the working group proposal would include would include RPS yes h no I'm talking about the rendering of uh the website uh yeah so the the version of the website that I'm working on for working groups would render RPS um I I okay yeah I haven't really touched anything without working groups

yet right yeah know because um one of our contributors were working on e. ethereum.org and um unfortunately we have not seen much progress on sharing RPS on the page as of now if there are any change in future we'll we'll keep the group posted about it sounds good thank you moving on the next one is eips inside for the month of February as you can see uh we have total of eight draft including one in RP total of six erc's and one new EIP have been added to the repository we

have five total proposals in review section there are proposals in last call but most of them are on four side uh proposals which would be moving towards final when they are finally deployed on the main net but because those are on public test net they are in last call and just for people to remember this last call duration for core proposals are more than 14 days it's not limited to 14 days it would be whenever they are deployed on the minute they will be merged as a as a uh final proposal there is one proposal uh which is EIP 2070 which was hard Fork meta for Berlin that has been withdrawn and uh the inclusion

of the information added to this proposal is included in a proposal of shared by Tim boo uh to include all the missing so that's all about eips insight for this month I'm quickly taking a look uh yeah so for the next uh EIP editing office our the agenda for meeting 32 has already been added it's just a request to all authors irrespective of the type and category whether you are an EIP author ERC author or rip author if you are looking for attention of editors uh for a PR that has been in the repository

for quite some time and it could not R an attention of editor please um add that as a comment to the agenda added over here we will definitely try to include that in the next meeting which is it is on coming Tuesday at uh 16 100 UTC so it would be on February 20th at600 UTC and yeah that's all about it any other thing anyone would like to quickly bring up or may perhaps want to add it for the next meeting I'll be happy to add it to the next

agenda if I could back up a little bit on supers seeds um uh Sam I think um is the is the executable spec at this point considered canonical um as canonical as anything is you can link to it from eips if you want to um the point being if someone is setting out to write client um then following the executable spec is the way to go as opposed to trying to gather together all of the

eips that happen to go into yeah it's certainly easier okay um it's almost the only way because the yellow paper has been updated as well um okay at least two the merge yeah yeah I didn't see that after the merge there was any commitment to keep that going and even objections to keeping it going um a fair number of our developers don't have any mical skills apparently um and nobody wants to spend money on Hing doing an edit or right to just clean up the presentation but

anyway um um the supered seems a bit less important on core eips because they're they're not where you go um they're not where you go to see what is the the canonical um the canonical thing to implement if you go back to an older EIP that describes an older chain U it's sort of your bad yeah this this would be more for things like um there were two proposals for deprecating self-destruct um one was withdrawn and

the other was was finalized or I think it's in last call um so you could have a supersedes from the one that's actually going on the network to the withdrawn one if you want it's for like document [Music] status if he was withdrawn there was really there's really nothing to supersede yeah it would just be to get the link to like from the withdrawn one to the next one kind of thing that's not available inab uh not not right now I don't think

no he's not even report I mean as of now supered is not a legal status in EIP process but if people really want to share the information of which EIP may have superseded in case the earlier proposal have been withdrawn we can perhaps add a sentence over there to uh let people know which is the next EIP they can follow yeah we have withdrawal reason for that VIPs are withdrawn um make note in the

withdrawal of the things withdrawn in favor of um a different proposal anything else anyone well uh thank you everyone for joining us today hope to see you in two weeks have a good rest of the day everyone thanks for hosting talk everybody later