EIPIP Meeting 63

Transcript

welcome to eipip meeting 63 we have quite a few items on agenda for today I see we are joined by call facts I am assuming that he is here for one particular topic that is um get for our badges um so maybe we can bump that up and start from there before we get into our usual discussion is that okay that works for me yep that's the topic I'm here to discuss all right uh so yeah uh coal facts maybe you can share about the get Pro app that

you wanted to discuss and then we will get back to item number one or whatever items are listed here for today's discussion absolutely sounds great um thank you all for having me here today uh my name is Colfax and I am working on a project called gitpo app and essentially what gitpop is is what we're doing is we're working on issuing poapps that represents contributions Central to the ethereum ecosystem so here I'll just share my screen quickly um we've been working our way through the central projects to the ethereum ecosystem and awarding pops for software contributions as well as other types of contributions we've onboarded about 600 uh repos here

including like ethereum.org many D5 projects uh core tooling projects um and the goal here really is to offer recognition for the work that's happening and uh through the issuance and Co-op so you can see here this is the 2022 ethereum.org uh contributor Pro app uh there's 83 people that hold it um and so what gitpo app is doing is we've uh integrated Co-op issuance into GitHub and specifically most of the projects that we have onboarded are software projects where they work on the flow of like submitting code through PR and then that PR getting merged and I open up an issue uh for eipip to award and get Pops to EIP editors and

contributors and through this conversation uh it became clear to me that sort of the way that eips are developed is a little bit different from just writing software and so what I wanted to discuss with you guys today is uh one we're excited to award uh apps to everybody who's contributed to eips in any sort of way and we would do that sort of by issuing an annual contributor pull up to the eip's repo and we've we're working on onboarding actually a few of these other repos that were suggested and so today what I wanted to do is talk to you about the tool that we've built that I think will be useful for awarding

gitpo apps to EIP editors given that it doesn't work normally on just like a pull request model where the issue or where the pull request submitter is the most valuable contributor um before I get into sort of the spec of the tool I wanted to show you guys this is our working uh designed for the EIP gitpo app I'm happy to take any feedback offline but I just wanted to share this with you guys I can share this uh in the in the zoom chat as well if anybody would like to take a look I don't know if anybody has any feedback or any thoughts to share about this uh right now if you'd like and I know it says 2023 we're going to update the date to the annual I mean it looks good to me awesome thanks I think it's particularly

cool to see sort of like the imagery around the ethereum logo and the different components um and so we're there's a couple other repos that are related to EIP editing that we're working on uh a different git pull app store for example like eipw and we're sort of taking sort of components of this sort of ethereum upgrading process we're diving into it so here's just like a little behind the scenes um sort of aspects of like how we're coming up with our designs um and so I'll share with you next the tool that we're building to hopefully allow the EIP maintainers to award get polypsy IP editors thank you panda pit for some

early feedback um basically what we're planning on doing is building a bot uh and we already have some components of this already built uh and basically would be githo app dash bot and you'd be able to tag it on a given issue or pull request and so here's like an example one here so if you go to an issue basically what you would be able to do is say this was a particularly important issue what you could do here is Tag in a comment like at gitbot and if you tagged get poet bot it would award a gitpo app to the submitter or you could also like tag it in a sentence

if we're part of another comment or you could specify like a list of usernames if you wanted to award it to a specific set of folks or if you wanted to award the get pull out to everybody involved you can do at everyone and it would actually go ahead and then award the git Co-op to everybody and so that that's sort of our initial idea for award and get collapse based on not just like merge pull requests um so yeah I don't know if I was talking to Panda pip before um in terms of awarding for historical contributions we can help sort of automate the process and identifying uh and actually executing the bot for like past ones but

on an ongoing basis we're hoping to sort of build a tool that can integrate into your existing workflows of reviews and you can award them on the Fly for for Meaningful contributions I think Victor uh has uh some things to say yeah hi uh Colfax thanks for coming this is awesome I I really hear me uh you might kind of uh uh okay uh just keep the webcam off I think it usually works better weird so uh is it better now that's better yep

okay yeah I love the ideas the two questions I have is uh one is that um how do we avoid uh rewarding uh spammers because we recently seen that some people were issuing spam uh posting either spec issues and the other one is how do we uh whether we have considered having different Milestones or contributors for example like their first EIP or their first final or things like that so as opposed to annual contribution or in addition to any contribution so that would be true of my feedback and by the way thank you for coming I think this is the perfect value to discuss this because you have Panda cave and Sam who are majorly under um on the automation side of those

awesome yeah two good questions also yeah thank you for having me here I think it's a great form to be a part of so on the first one in terms of fighting spam this is something that's very much on our minds and the initial like the the architecture of git Co-op for code contributions specifically only Awards collapse for merged pull requests uh which inherently have manual review in them so like any spammer that tries to burn one they're not gonna get it because the code is not is only going to be merged if it's actually meaningful and it was something that we were definitely like our heightened awareness uh we had a heightened awareness about around our launch um which happened back in April and so

far nobody's reported back like an increase in spam uh pull requests being sent as a result of earning get pull-ups in fact somebody actually was tweeting yesterday saying that it's uh too hard to earn uh get poapps for spam contributions I thought it was kind of funny um so in terms of like fighting spam I would say that really lies and so it's going to be only a manual process to award apps but I can make but I could have the EIP bot tag the gitbull right you could and so the other detail here is that the git pull app bot will only trigger an issuance of a git Co-op if

it's tagged by a maintainer well the EIP bot actually has admin on the eip's record said I guess we would have to talk about how possibly like if the EIP bot if we want the EIP bot to be able to tag the gitbot we can work out those implementation details but the idea at least the way that I'm envisioning it is one of the maintainers so like either you pen to pip or maybe Sam uh if a particular issue or pull request for a new EIP is valuable you guys would go ahead and then manually tag the GitHub so I I I'm concerned about adding extra

work for EIP editors so I'd like to see this be like as automated as possible so when an EIP gets moved to final then a person would become eligible is that kind of the process we're thinking here or I've been thinking make a bot that when Erp gets merged as final then tags the uh the get Pro I bought uh to then assign to then assign the githo app um and it would be the authors of the EIP or whatever I think it would be assigned to all the authors of the eib okay so yeah as long as we can automate it and it happens for like the trend like after the transition to final is merged I think that works and I think that it's pretty and I think that it

should not be too difficult to do that and since the AIP I don't think that it requires any configuration with Git pop itself just because the EIP bot itself has admin so if the uh if the git Co-op does it by pinging GitHub the API to see what permissions the uh sender has well VIP bot has the permissions awesome that makes total sense um we definitely do that one of our core principles too is we don't want to add any additional work for maintainers so I think configuring it with the EIP bot that would automatically trigger upon the mark finals a great solution I'm I do see a couple of

them might need to the bot side but I I'll quickly mention that Panda people that would be like if an EIP is finalized then the bot will tag the person or the set of authors who have contributed to that but if you are making any changes post it is finalized or um minor changes at its here and there in that case we may have to customize that to uh you know it would only be when the erps move from any non-final statements to final and then it assigns that to everyone that has a GitHub handle in the author field that would be the conditions on which it

would on a higher level that sounds good to me too that sounds good to me too um and the get pop bought as designed can support that we just need to figure out how the EIP bot would then trigger calling to get brought up I could just have it uh use the GitHub API to send a comment it's not that difficult awesome cool thank you cool of course um and then let's see to address Victor's second question so the first question was about spam and then the second question was about uh sort of like repeat

contributors or sort of like scaling that up the way that we're handling that right now um for code contributions is we're issuing annual contributor get Pro apps and so you can actually see if somebody's track record if they've earned the annual contributor get pop over the course of a number of years like 2019 2020 2021 uh we're also we haven't released this yet but we're also working on visualization of depth of contribution within a year so for example if I've been an author now of like three different eips in 2022 granted I'll only have the one get Pro app but we have the we can we basically have the metadata stored on like how you earned it and we're working on different visualization metrics to actually

signify that um so that's one aspect of it and then secondly specifically for eips I think it could be interesting so I think it's a good start to work on just uh issuing this annual contributor get poapp for EIP editors but going forward if you guys are interested for particularly impactful eips if there were some specific ones we could actually create a customized GitHub app with its own design and award that just to the folks who contributed to a particular EIP so for example it could be like the EIP 1559 app um so I'm just throwing that out there as an idea if there are particular eips that you want to award separately from

just like General EIP editing we can do that too incredible neutrality I don't think that will be happening is want to determine eips that you'd like to award extra git pull-ups to feel free but we as editors probably won't be doing that that makes total sense um I'll discuss with my team and sort of maybe we can yeah discuss with the community or something but yeah just throwing it out as an option but I appreciate that um cool we'll add some next steps I'll sort of draw up uh the feedback that you guys have given um Panda pip I'll continue to coordinate with you on our development of the gitbot and how you can tag that with the EIP bot um and we'll go forward from there I

just want to say thank you guys so much for having me here today thank you golfers for joining and sharing this I'm sure this is helpful and it will encourage more people to be able to contribute to the AP repository and make valuable contributions thanks me too and people uh can always leave comment and feedback I have shared the issue that is on eipip GitHub issue number is one three four thank you uh moving on Let's uh start from item number one which is proposals to include in Preamble uh we have collected quite a few proposals

which are there to suggest some edits or updates for preamble uh in eaps um the first one listed here is ADD finalized date to eips I see there are already ongoing conversation yeah anyone has any commenting thoughts to add for this issue uh you're actually missing one of the PR's that uh ads uh an abandoned to the preamble I'm sorry it has been merged I know uh there was one created by Witcher I guess no the one I just put in the chat oh sorry the adoptable yeah yeah uh that one since no uh no

controversy right no one has anyone have any objections to the adoptable that's a good idea did someone approve it any thoughts uh Sam if you're talking you have muted you know um I'm okay with adoptable I guess um yeah I can I can approve it I don't have the vote I'm in favor of this

um foreign okay so we could move on to number two I mean uh sub item for this one proposal to include superseded I think it is a number 5265.

I guess it was added by oh sorry please go ahead oh just for the superseded I prefer if it wasn't a status and I would prefer if it was if if it was an arm in the Preamble to say supersedes something and then it made clear that hey this is not an official thing we're just suggesting that you use this instead of this other thing yeah I I think putting something in the Preamble for supersedes probably gives the impression that we like we as editors have allowed us to supersede something else and I'm not sure I'm okay with that implication that would be a badge like the one for drafts

or things in review and extra badge that basically says hey this is a recommendation of the authors and does not ref and may not reflect best practices I'd rather just not include it at all I think if if somebody wants to withdraw um an EIP and put in the withdrawal reason superseded by eipx they're perfectly allowed to do that but I don't think we need a special field for superseded I think that we have presidents of uh doing that like with withdrawal we generally mentioned that which is I mean if there is the reason that any other EIP is uh better than the proposed one we do mention it in reason

so uh I'm the one that proposed this because uh it was inspired by ietf RFC and there's the RFC field for rcpc so that uh the whole Community can continue to evolve and notify the future readers of what what's something is being updated so as much as I respect and understand the concern that Sam's had I think we can uh I love to kind of uh not try to um propose a proof or not proof of this PR on today's meeting but to further discuss under what concerned uh condition and uh who are able to add such thing and whether we enable field is the best uh format or is there other

way we can do that signal I can I can take that offline and and follow up in the future I think the eip820 does a good job of this so I'm just going to quickly send a link to the markdown file in the chat so what it does is before any of the settings it has like a big thing that says ERC 1820 has superseded EOC 818 so basically it's a hey this this is the authors here saying that due to some uh due to a change in solidity actually you have to use this other thing instead of this yet and this is currently compatible with

what we have we can definitely keep the issue open um for another few weeks people can add comments and thought uh and uh yeah um is that a good resolution Victor yeah um I Heard the concern and I'll document the concerns and then I intend to continue to pursue a proper way to indicate that So yeah thank you for keeping it open yeah sounds good awesome moving on uh the next one is proposal

proposal the print relates to field issue number is 5274 I guess this was also proposed by Victor yes I think uh the people with the interprets that requires you differently some people think of me included see that requires and and thought that it means a uh to implement some EIP it requires some previous pre-existing VIPs to be implemented to be final and to be to be final for sure but to be implemented as well and that's uh that seems not aligned with panda and with mikao and so I think that requires is a little bit confusing uh so I'd like to

see if there's a clarification or do we need to add new fields um maybe we don't need a separate required to field but it uh relates to field but I wonder if we could just I mean I can I'd be okay if if in eip1 we changed it to so that it's only eips that are referenced in the spec that need to be included in the requires field I'd be okay with that change so may I ask uh under what surfences stance do we feel that uh we want to have a special call out of eits being referenced other than the

body already have a requirement to link to EIP if they mention that yeah that's my thoughts as well like why do we need a preamble field if we already require them to be linked well I can see at least a use for having at the very top saying hey read these first but that's required right you have to read these to understand the CIP yeah so I I would be okay if any ip1 we changed it to uh be anything that's anything that's included in the spec has been hidden in the requires I'm not sure sometimes the boundary can

be right for example the introduction of create two is a prerequisite in some of the erc's but that you don't necessarily need to understand that we create two or read recreate it to be a reader you might need it to uh to be able to author it and if someone has handled that for you on a dependency or SDK you don't have to understand create too right so I think so what I feel is that's uh if we make a heart requirement and make it clear of what required means for example

if you we say that technically I'm sorry Victor we are losing you obviously we didn't catch that you uh you kind of like you might die all right looks like there is some audio issue microphone issue with the vectors so we can move on I guess the last one is the advanced digit EIP since uh Mike is not here I

well I mean is there any reason not to add this foreign [Music] yes yeah okay so I I think this would be reasonable to add um yeah I think we had a discussion about this in the past and there was some agreement disagreement the issue was dropped then uh but it's good that we have it back in the form of issue and yes we have consensus there I believe we just need a pull request okay you have shared the pull request that needs to be merged

yeah some can just be proven it'll do sounds good anything more on Preamble topic all right uh we can move on to number two that is from GitHub issues and pull requests the first one that we have considered here from issues is um merge policy discussion how final is final the issue is already added in the EAP GitHub repository so we have seen in the past that there are some improvement

suggestions minor edits are going into Final eips in this month only we have seen three final EIP is being edited with small changes so yeah this is about discussing how do we work decide a final is final I'd say backwards compatible I.E basically if it's able if the EIP is able to be implemented and there's no ambiguity in how it can be implemented then that's how it has to be if either of those conditions don't fail then it is okay to get rid of any ambiguity

or to make it so that the EIP can be implemented at all I think we need to I don't think we can actually write in backwards compatible or backwards incompatible into eip1 just because um like let's say the EIP specify a core EIP specifically specified something and all the clients implemented a different but the same different way then when the EIP goes to find like after the AP is moved to final you would have to change the IP to match what clients actually implemented but I thought about only for erc's

uh I really just think that we should make it policy to only allow backwards compatible changes to final eips but I don't think we should make it a hard rule because there are times where um like if something is wrong with the EIP like clearly it is not what the author intended it's it's just wrong then I think it's fine to fix the EIP even if it's backwards incompatible I think backwards income or backwards compatibility is a good Baseline but there should be we should be allowed to make exceptions to that I guess uh the um important question

here would be to maybe outline it for people to refer to like what is the point where oh go ahead go ahead Porsha sorry about that not a problem so what is the point where we can say that um we are not going to make any edits basically to clarify on what kind of edits may or may not be able to get in and if there are edits which is outside this guide guidelines then we can ask author to maybe come up with a new proposal um not edit the existing one not edit the final proposal I'm really not a fan of anything that

like actually just straight up changes the meaning of an EIP uh I'd be obviously seven uh seven uh 12 verses just doesn't work so that can be changed just because there's nothing it's backwards compatible if there isn't any implementation but apart from that I just don't like the idea of yeah basically if it's written some way that can be implemented and it is implemented that way then that should always for the rest of Eternity be compatible with that EIP E I like to

um respectively challenge that um so first of all what what Sam says if a core EIP has been implemented and every client have implemented differently from the core EIP that one turns final then you need to add changes to the core EIP to reflect what everyone is implementing I think given the idea of EIP being issuing an improvement proposal if everyone is implemented in a same consensus different way than the better way is to keep the old one at final and create a new one that reflects the true implementation rather than

fixing the o1 unless they're not final right if if the final has been reached I think changing things make it essentially life so unless we want to agree that final is still live I am I'm very weakly lean towards making final changeable other than editorial requirement like I don't consider backward improvements Backward Compatible feature improvements as qualified in this case as well and that's also why I propose to have a Super C so that if they also do think that this EIP has been final but no one

is implementing it it's not being adopted and everyone has a new idea then it should they should have a way to Signal what is the better way so that's that's that's my my standpoint and with respect to 721 I think if the author goes to make it a final and realize sorry it's seven one two not seven two it's seven one two right seven one two the type six assigned signature so seven one two on the exact fee side is the same I think if everyone has been implemented in a different way if it all it's a wrong way the best way is probably just to start a

new one copy the old one fix it and then and then publish that one as new Final or um revert on in a one-time exception reverted back to drive towards to anything that is not final then I think we can we can we can modify it otherwise we have to be undermining our credibility of being final I I don't think as a EIP editor group that's the best in the best uh reputation uh best way to hold the reputation of this group so we we can't I think unless we could like completely revamp our process um ever move an EIP out of final unless I guess it's also to withdrawn maybe we

could allow that but um because of the way the um merge Bots are set up once an EIP moves out of like if an EIP is not final the editors can change it without a EIP editor approval so you would you would basically just lose all immutability immutability guarantees if it would be like even worse than making a one-time change to final yeah like if like it's like saying it's final and now it's like me handing you a gift and when you open it suddenly wrapping up the gifts taking it back and putting a new thing in there and giving it back to you so so I I I'm very strongly against ever

moving an EIP out of final okay compared to compared to having a one-time change yeah yeah because as long as it's in final the editors can review every minute change to the AIP but if it's taken out of final then it's carb launched they can do whatever they want to it yeah I would agree agree to some like uh changing the direction of a process flow I I think we had a long discussion on it about a year ago this is one way like when it is moving from last call to final it is unidirectional however from last call to review it can be done

so let me put that 712 as into contacts I I'm not sure if any one of you have attempted to implement 712 I did and then let's say as is it's not possible to implement it there are no implementations let me put it into context um I did and then for what I know it's the the EIP is largely is largely um ambiguous and not even ready I so I I think it's not even ready for one time change to make it final that's why I'm suggesting it it has to go to some status that is updatable that either

start a new one or or move it back to drop because I think it would take another several months several iterations to get to a state that implementations are are are agreeing on each other it's currently we're seeing different I personally see different implementations of uh of what ethers have been doing and what uh the mathematics is doing and and so I think that the consensus have not been breached that there's just one commit to go in is that that is doable achievable at the current snapshot of 712. it didn't take quite long there are two there are two specification sections one of which was

just straight up copy and pasted from I think it's eip191 um and I'm pretty sure all of it needs to be done so just remove that accidentally copied and pasted the specification section and Damage Done currently as is it's incompatible with itself there cannot and will not be any specifications of 712 in this form just because it just because it has two masks that say two different things so as written it is not possible to implement it and so therefore it is also not possible it therefore there are no

implementations and therefore there's nothing that can be broken and uh but we're in consensus that at this current snapshot it doesn't work no one can implement it that I think we're in consensus I wonder if I make myself clear that even with one change it is still not capable of being in the final State like it's in a stable State I I wonder if I made myself clear that I I think in my personal experience ignoring one of the specification the other specification is not ready to be implemented I think we would need to get the offers

on that call I mean I guess I'm slightly weakly in favor of moving it back to last call perhaps just because that last call also requires uh editors to prove all changes um so there's that what is your preference on like have keep it final but let the author start a new one or let someone start a competing one if so if there are large problems with 712 like to the point where it is ambiguous and you like you can't implement it well then I think somebody needs to take EAP 712 and just rewrite it under a new number that that would probably be the

best approach yeah that would be mine yeah that would be my standpoint and we can wait for seven one two thousands to see if they want to do so or if someone else come in and compete that that would like fully compatible with the current process um and doesn't break any uh immutability assumption I I guess I can provide some information about 712 we had tried the catalogous and tried to reach out to authors we did uh try a lot obviously we contacted some of them however they did not show up for pushing at the proposal and final status so it was championed by one of the cat who do so I I believe in this case we

can consider that authors are Mia and having a new proposal of competing proposal will be good and when it is proven that the new proposal is fixing all the ambiguity of the 712 probably we can take an attempt to make it um stagnant sorry withdrawal and of shared the new proposal with rest of the job developers that's for adoption I agree with every part you said except for the withdrawn decision has been made by the original uh author if the original author um didn't care enough to withdraw it

then we pretty much stuck because if we if we open up a precedent that editors can restore on behalf of the original author then I think it can open up another Pandora box yeah I agreed I don't think editors should be withdrawn uh no no I mean that editing that I guess it was by one of the cat hurdles so probably we will reach out to that individual and see if this can be solved but that is going to be a later issue first we should look into getting up with a new proposal so app developers who are looking into implementing of this has some solution they do not start because

this is not Implement table foreign I think in the essence of time we can probably wrap up this topic and if anyone has any other comment or suggestion uh the issue number is 171 is it yeah on eipip GitHub repository moving on the next one is eipw policy I guess uh there is some ongoing conversation and we are waiting on some consensus

anyone would like to summarize I think it was Again by Victor sorry can you point me to the um to the matter I'm just opening up my my computer and oh this is only only checking change lines I think which which uh lost five four six nine yeah let me check four six five okay yeah um so is there any I think the the Sam and Panda probably most authoritative answer whether it's the technically

feasible or not I personally feel that uh based on other venting tools that's possible to do so but like depending on how much it is um also like Sam and Panda do you have preference of not checking only the change line I would say probably I'd be okay with eipw only uh only blocking uh only blocking merges when the IP status changes so that is something I would be okay with now I much I'd be my I am much less happy with it only changing nothing changed lines because then you could

have it going from like draft to review the entire the entire there are a bunch of new things that need changing and that aren't being changed is uh it's only it's only uh requiring eipw to pass uh for status change uh PR is a good compromise I just don't see the value like what's like what's the point of not providing feedback like early on in the process to authors so so Fame uh I can give him it would I can give you some go ahead sorry panda

yeah PW would still be failing uh the it it wouldn't actually be like it would still be like giving all the errors and errors and stuff it just would be that erpw would no longer be marked as a required check but the EIP bot wouldn't merge it unless I get what you're saying but no one's going to read it if it isn't failing yeah if it doesn't stop them from merging no one's going to read it so like what is the benefit of being more permissive I don't see one but I am very I am very much against linting only change lines because um like like I said my comment the Boy Scout rule so if you edit the file you

should make the file better um and I think that uh epw is probably the best way to do that um and I I don't think we should only require lints on status changes because then when an author is trying to move something from review into last call then they're suddenly going to get a bunch of stuff that they have to fix that they weren't forced to fix before and like right before going into the last call that doesn't feel like a great like uh developer experience I guess I think we should just have it lent whenever they make a PR it's not like it's stopping them from making commits it's just stopping them from merging them um but you know I I don't know I'm not a dictator so you guys can

decide something else if you want um so can I can I put something into contest and see if that would uh change your mind or uh like at least make you hesitate um one of the things we see is some contributors not necessary author contributors who come across on EIP realize there's a typo come to fix the typo I think that's a good spirit right and then it's also a good way to get into EIP editoring and um in that case uh the micro contributions uh help out a lot so that's why I am suggesting if we allowed merging just checking the line like if you're touching this line for

this scope maybe it's good idea that you want to fix the whole thing in the line or even paragraph but for the whole file um it scare away people who just want to come in and contribute I I have first-hand experience starting contributing from Wikipedia a lot of page I contribute just fixing typos and then ultimately I become a more regular contributors so in that period I want you to see if you would reconsider that scenario and of course it will be approved by author in our current setup but I think so long as at the time it moves to the next stage should I change status for example review or fight last

call or final then someone mostly they also have to be responsible for what is editorial fully checked so Sam does that make a good argument for you it's I I don't think there's anything wrong with the argument I just don't agree um I I think I think eips are standards documents they're not like crowdsourced explanations of things so I think there's a little bit of a difference from Wikipedia um and like I do appreciate people coming in and so so one I think we should turn off UW for final eips um for sure because that's just awfully annoying and I I don't think we want to

be fixing the formatting for final eaps um unless we're intentionally fixing the formatting for finally IPS but that's a whole other thing um but for for in process or draft eips I think um generally speaking the author will still be active so if somebody puts up a um a pull request fixing a typo in like a non-final EIP presumably the author will eventually see it and um we'll probably incorporate it into their work um but yeah I I just think it's better to keep everything as strict as possible um especially while they're developing so that they don't get surprised on like a

status change or or um when they go to final fair enough uh doesn't didn't convince you um I would come back and try in two years yeah yeah but I I agree that we can keep it as if for now I can close this issue and and or use the pendant you want to pursue the the change the the the way of that it only uh check when their status changed or do we wanna you know I think I think I'd be okay with it not checking as long as the IP is final that I'd be okay with it and I think someone was also okay

with that for sure so yeah so if there's just a random VIP that's final that has a typo then I think yeah that that is probably okay to be merged without having to fully reformat things out again how about well not check for last call uh last last call should be checked just because the changes should be made before it is final oh actually not check at uh for files at final right yeah that is consensus for sure um and still keep it on for every other status every other commitment commits right yeah exactly so keep it on for

everything except finally IPS keep it on for everything every commit except for a final commits uh okay that's a consensus I as minority disagree with that but I would document it as the consensus and we can close it thank you and yeah for closing the issue and also uh Sam and panopy for having this as a decision I hope this will be noted in the notes for this meeting moving on uh the next item for discussion here is a pull request number

5443 it is uh there the last comment is for a manual merch it is with regards to eip4881 anyone has objection there yeah or anyone with the depository snapshot refactor right Sam do you have any further concerns uh I think they fixed the links for your request yeah I think it's good to go um I just wanted to make sure we had an opportunity to talk about it here if um Greg were to show up but I guess it's just

the two or three of us so yeah last opportunity one Greg here to miss this one for raising any concern but anyway this proposal is in very early stages I guess um we will have more opportunity to come back on this topic when this is merged as a review or last call I agree so long as they have not been last call I think it's it should be safe to merge foreign the next one here is a pull request number five four five three

that is the request I guess suggested by Victor and this is about a new proposal smart contract crypto endorsement yeah and I wonder if there's any because my goal is to put it into let people come and like have a broader Rich um company of Interest that's my own proposal so yeah um whatever you decide well currently there's a bunch of comments I put on there that need addressing so that's currently where the that proposals are I see uh side notes uh Panda I saw that

you tend to merge lines is there any particular reason that you're doing so because uh yeah actually supports model and it does also help I would like to be Pro multiline because they they allow you to be addressing very precisely what part of the code you want to suggest so the reason why I don't like that is just because uh text editors generally backlines for you but if you have for example but basically I like if it it can if it can all fit on one line in my text editor I like I I do quite like it that way also a lot of people think that oh it'll

force a line break there no it does not force the line break there in markdown uh third third of all um yes I do agree that you're being able to Target things more specifically is a kind of a nice feature but at the same time GitHub uh git is smart enough to uh to somewhat be a distill some might be able to Target it enough I guess uh I and that's there are two that are exactly the same line but generally you do all of your changes at one that Target is specific line at what time as as you can see like oftentimes I have a required X required y required uh

required the recommended whatever uh recently I prefer it all and the last reason I prefer it all on my mind is just because if I if I if there is somehow a smaller Street then what you get is a full line and then a little extra and then a full line and a little extra and that doesn't look good I I heard what you say can I actually make an issue and discuss whether we are ensuring a style or we prefer not to enforce such a style because I I think the previous consensus I understanding

and amount of group is there's no particular markdown style that is being enforced actually the consensus is moving actually towards there being a specific cell um there's actually which one do we there's actually you know one of my uh PR's is uh open right here let me figure it uh add markdown menu this one right here uh oh okay uh let me check that is still yeah we I think we agreed to have a markdown later but I wonder if uh all the rules in that intro has been agreed upon especially all the of the

rules currently have been agreed uh that are set currently have been agreed upon I'm not sure if the multi-line one has been agreed upon or not speaking of that uh sandwich of mine would you mind quickly merging that one the markdown linter yeah yeah I'll take a look at it after the call I just want to go through all the rules can we enable one rule at a time where like you know if we can understand that uh in fact Micah went through rule by rule and went basically argued why none of the rules should be uh applied uh and and he quit we were successfully able to dissuade him from

disabling all the books but yeah there's only quite a there's only a few of the rules that are actually applied is one I see can I propose my my objection to reinforce uh multi-line to be a contact and Native into one line no what I'm saying is that currently that is not not an issue Tennessee according to the conflict we have set in the markdown later you can do multi-line I personally need to test it but I guess I guess I will no longer force people to uh do uh to not do multi-line even though it hurts my eyes just by looking

at it me too when I do my personal journaling but when I do get commitment I feel that a lot of tools are assuming that line break um so that's why I I in in the in an EIP I prefer breaking down then um just because like gets diff much better with different lines rather than single lines and also GitHub is doing that same thing as well so that would be my personal argument yeah I think opening an issue to discuss multi-line versus single line is probably the right approach here and uh I think Putra brought up a good point about we're close to time so we should move on to the next uh the next topic I see agreed

thank you probably we can continue discussing in that pull request uh adding comments there we are very close to time but I wanted to quickly bring up one last uh item for discussion today it may not be discussed but just wanted to share it with people uh the item that has been added by Panda peep it's a last minute Edition and the pull request number is 5502 it is about adding a new editor uh having a new editor added to the repo and getting them access I know we do not have all the EAP editors present in this meeting today so we can probably consider this as an announcement of uh this will request and

will try to reach out to more editors anyone has any comment thoughts quickly to add on this no objections for me sounds good I think it is waiting on reviewers or editors approval there we will try to collect more approvals from editors who are missing here in this meeting today and if we get over three two or three approvals then probably it can be merged now that we have five editors so three sounds okay to me sounds good cool we have quite a lot of pull requests and other agenda items that we

could not touch today I hope that it will be discussed in the issue number people may follow the link added to agenda and leave their comment thoughts feedback they are always welcome to come to cat orders EIP editors Channel and continue discussing it with creating a separate thread in the meantime before we get to the next meeting in two weeks from now well thank you everyone for joining us today and I hope to see you in two weeks have a good one everyone see you later thank you for hosting yeah thank you