EIPIP Meeting #122

Transcript

Loading developers...

[music] Okay.

Thank you. Jesus. Heat. [music] Heat.

>> [music] >> Heat. [music] Heat. Heat.

>> Heat. Heat. >> Down.

Nat. >> things.

Okay. [music] Oh, heat, heat. [music] >> Heat. Heat. [music] >> Heat

up here. >> What's up? [music]

>> Thank you. >> Welcome everyone to EIP IP meeting

EIPIP Meeting Introduction

number 122. 2. This is issue number 7 on Ethereum/PM GitHub repository. So on agenda we have got most of usual items for call for inputs, editor discussions and anything in specific that people would like to discuss. We generally try to collect some community feedback and update and share it with the community. we will uh take a look at the EIP insight means uh the statistics of uh present uh proposals on different repositories. Uh to get started uh I want to kind of explain what this meeting is all about

and u um why do we have these meetings. So, EIP meetings are for Ethereum improvement proposals improvement process. We organize this meeting once a month in order to have all the editors in one place and discuss the current process as well as any suggestion that comes up from the community. We can consider it. We can discuss it and if needed we can make changes to present process with the help of incoming PRs like anyone making suggestion if the suggestion is accepted by editors or the editors think that it

is perhaps a good suggestion we can perhaps include it and change our process we in we uh appreciate the individual to create a PR and those PRs are added here for discussion um we are still waiting for more editors to join but while they join we can perhaps uh go through some of the agenda items that we can discuss and yeah obviously I hope it helps people to understand why we are here the first section is call for input I will wait for Sam to join in yeah >> Sam yeah >> I'm sorry

my screen was shared so I could not see you in Sam, thank you for joining. So when we have Sam, perhaps we can go ahead with the the agenda as mentioned in the list. Sam, over to you to maybe talk about call for input. Do you want me to stop sharing and you want to share your screen? Either way is fine. >> Doesn't matter to me. I'm just uh getting to the page here. >> Okay. >> December 16th. No, wait. We're the 17th. >> Yeah. And Sam, before you go ahead and get started with this, I want to uh apologize for this tiny error that I made on my end like I closed this issue for call for input 394. Uh but then realized that it should be um added as a

decision by keeper. So reopened it. Uh perhaps you can take a >> Oh, sure. Yeah, I think that's fine. >> Yeah, please take it from me. Yeah. So, um I I agree. I think nobody objected to that. So, we can close that as uh uh affirmed or whatever the the term we use is um updating links to ethereum.org. Oh, yeah. Okay. Um Okay. So, we have three against and one in favor.

Discussion on Call for Input Issues

Um, I think we should probably talk about that one a little bit more. Um, I didn't notice Kajinder on the call today or No, it's just us. Okay. >> I'm sorry, Sam. If you could let me know the issue number, I can perhaps open and that would be easier. >> That's one. You're on it. 395. >> Perfect. >> Yeah. So, um, yeah, I guess we have, uh, at least two editors here, so we can talk about this. Um, how do you feel about this one?

>> Yes. So, okay. So, just for the for the record, uh, I just got added as an editor. Uh, and this is actually the first time I'm actually looking at this call for inputs. Um, so Sam, maybe you can quickly share what this is about because I'm I'm reading it. It's about dead links to the old Git if you wiki replaced with live links. Uh, and you are against this change. So maybe you can uh explain. >> Sure. Um, so there's a final proposal 1186 I believe it's or I guess it's stagnant. It's not actually final. Um, so I guess we could edit this one. Um but uh there are links to um the GitHub wiki which no longer works. Uh and

Link Policy Discussion: Debate on updating links to Ethereum site

somebody has opened a poll request to point it to the live Ethereum website. Um and this goes against our uh established link policy because the Ethereum website is not one of our approved external resources. Um presumably because it doesn't support like versions. So, you can't link to uh like there's no guarantee that the link won't change in the future. Uh so, I'm against making this change because um if we update it to point to this new URL and that URL goes dead again, then we have to update the link again. Um and I think we'd like to avoid having to update final EIPs over and over again.

So, um I would prefer that we not update this to point to the Ethereum website and we find some other way to to reference this information. Um but that's just my opinion. >> Yeah. Okay. Maybe then then yeah to to add on that. Uh I think I that's like my my first minute thoughts on this that I agree with your uh well disagreement. I would think that I would also vote against this um because if these uh links are not part of uh the rules which we have established. So the these are not part of I think this would be part of the approved links in EAP1.

Then if you would want to merge this PR then we should first update EP1 and then we should um then we are able to merge this one uh this uh PR uh so to update these URLs. Um, but I think like as a side quest or side task that we should then also think about um like how how would this work um because if you could point to like an archived version of these URLs that would be nice um to maybe think about.

>> Agreed. Yeah. Um I don't think anybody's brought this up before but maybe we could allow links to archive.org. Um >> yeah yes but then we would of course need to verify that this points to the correct version of it. So that would be like uh we will check the latest change to this ERP that like the commit uh date I would say and then check if we have like an archive version around that date so we know that we are pointed to the correct version but but this will be some some line of thought I would say to to think about.

>> Yeah that makes sense. Um, would you like to leave a comment on the issue to that effect or would you like me to write that up? >> Yes, I will I will write a comment on the I will like I will vote against and I will also explain why and what we should do about this also for the future. Yeah, sounds good. Sounds good. >> Uh, then we have the Unicode technical standard links. Um, we have two yeses. So um >> yes may maybe you can also quickly introduce this one. I think this is adding like an URL to uh the uniode technical standards uh and I see you are

in favor. Um so yeah. Yeah. and the deadline has already passed but yham if you would want to add your comment uh in favor against that would be helpful for Sam to make a decision and close the call for input for that. >> Yeah, I would also think that I would approve this. So I will also leave a comment here. Yeah, thanks. >> Awesome. Thank you.

Call for Input Visibility: Discussing moving issues for better access

>> Thank you Sam. And uh next we move on to editors discussions topic and the first one here is about the call for input itself. Do we want to move this call for input issues to Ethereum/PM GitHub repositories for increased visibility? I understand um from today's discussion like Yam was seeing it for the first time despite he being added as an editor because not many people go to that GitHub repo anymore and uh we are more frequent visitor to Ethereum/PM GitHub repositories.

Um, I think if we're going to move it, we should probably move it into the EIP's repository itself. Um, I don't know how we would do that like technically, but it would be nice to have it uh, you know, versioned and stored alongside the EIPs. >> Yeah, that that makes sense. We can perhaps repo as well. uh but uh sometimes we have questions with respect to ERC's repo in that case should we move it to ERC's issue or I I I proposed PM because PM will address maybe both site like one place but here we can have it divided whatever >> um yeah I'm not sure um

>> I mean we can continue having it on that as one as well uh but yeah that was general proposal. I wonder Yam if you have any thoughts and suggestions around it. >> Um yeah, maybe the the first thing I want to add here like if we would want to move this to Ethereum PM um then maybe we should change the name of call for input because you would abbreviate it as CFI and this is also part of the EIP networking process. So that would translate to consider for inclusion. So that might lead uh yeah considered for inclusion uh that might lead to some confusion I would say. So that that is maybe not um yeah I don't know then then we should maybe think of like um a new name for this >> that's a good point.

>> Yeah. So it's call for input like when we add it in the issue it will show up something like this call for input and the one CFI we use for upgrade process is consider for inclusion. So the expansion is definitely different and we may not be using acronym here just to clarify it if that's helpful. Yeah. Um I would be somewhat not really scared but somewhat afraid that people will uh maybe abbreviate it but that yeah okay that that might like u an ungrounded thought. Um so let's let's indeed let let's just keep it as call for inputs and if people start to abbreviate it then we should say okay

let's not do that because it's confusing. Um I think for increased visibility um yeah and Sam is also right about uh let's let's let's not uh bring this up as like a point. That's a good good uh good point. Um yes I think for increased visibility this is like a good idea and maybe also to to uh to state a little bit um well maybe like the question is why have I not looked at these uh confer inputs before? Uh I would say that uh because I said yeah I haven't looked at these because I'm not an editor. Well that is maybe like the wrong um line of thought because this is of course the governance process and everyone should I

think at least have an input on this. Um so I think the visibility of this should indeed be increased. Um and how to do that. Okay. I would not really know how uh we should do that but to increase the visibility that that should really be um yeah something what we should try to do. Um and how I would not know but we should definitely increase this visibility. Yeah. >> I mean maybe we could add a banner to the actual EIP's website.

H >> I'm not sure. >> That's an interesting suggestion. We can do that. Maybe we we have to look into how it is possible. But that's another good idea. And in that case, even if it lives in the EIP repository, that should not be a problem because people are getting reference link right from there. >> Yeah. >> Okay. We should think about it a little bit more. And uh I don't know would you want to get a call for input to collect inputs about this particular idea and maybe we can >> we don't have to make a decision right over there. It would be just collecting ideas where where do people think is the best place to have this.

>> Yeah, that works for me. >> Yeah, I think that sounds good. So that's an call for input for call for inputs, right? [laughter] >> Yeah. Right. All right. Okay. Um uh let's leave it right there and we will have a call for input to collect input from other editors as well. Moving ahead um the next big thing in my mind was the increasing number of EIPs and ERC's repositories. uh no these are the reviews. Okay. What are this inside this one? Yeah. Right.

EIP and ERC Repository Management Challenges

So I was taking a look at the repository. This is for uh EIP um uh repositories and as we can see the trend is like increasing. It's it's increasing too much. Um we do have around 324 open PRs on EIP GitHub repositories and somewhere around 150 in the ERC GitHub Uh I was wondering if editors can think of an appropriate way to maybe manage this increased number of uh PRs. One thing I want to mention which was also identified during one of the office hour with Gachander Singh uh that was the uh

the ability to close or force merge PRs. Right now I believe it is limited to only a few editors. Do we think that we can grant more editors this permission so they be able to force merge and we don't require two editors to review same proposal? >> Yeah. Yeah. C can we maybe uh so um to help a little bit on on on uh so we have like a lot of PRs open um and uh the reason like what's the reason for this because I know that some PRs um like if you are not an offer of an EIP or you are not an offer of the EIP you are

editing then if you propose a change then the EIP offer has to uh approve this uh and I believe that oh well I that's that speculation, but I believe that some of these PRs are open because these are not getting approved by these offers. Um, and I'm not sure if it is then a good idea that we that we as EIP editors would force merge these changes. Uh, but maybe like as a step back, um, why are there so many open PRs? Like what's the reason for this? Because I also hear that for some of these we need two EIP editors to approve them. Uh, and what would be the rule or the the reason for this?

There's a set of rules in the EIP review bot that determines when we need to um have multiple editors. Um so editing final and stagnant EIPs I think need more than one editor. Um there's a few other like editing the website needs more than one. Um we set these up like years ago um and it was basically for things that we thought would be contentious. they need more than one editor. Uh, but I think we've kind of dealt with most of our um decision-m problems. So, I think we can probably bring them down to just one editor. Um, but that would probably need a I I'd

probably want to do a call for input before making that change. >> Uh, I am not sure if I'm 100% confident about this thing. So um what uh I first I would like to respond to Yam. So what I meant by it requires two editors attention because um uh one editor does not have the permission to either force merge it and even if he reviewed the proposal he will have to leave it open just adding another editor to take a look and force merge. So that was my point when I said that two editors may need to review one proposal. Now uh the second part of it that there are some PRs which requires two editors. There

are certain conditions as Sam mentioned. One condition was like if it is related to any um like very important proposal for example EIP1 in that case we would want to have it reviewed by more than one editor and at that I believe still makes sense to get it done. But one point that I think was discussed and perhaps it's my mistake that I have not documented it somewhere. Uh when a PR is waiting for author's approval then in that case we see that if that PR is for an EIP which is already in the finalized status or is in the active status. So if it is an active

status um that means it is not finalized then we wait for the author to make the decision whether you want this PR to accept it uh to accept it or not. But if the PR is for a final uh EIP then this decision falls on editors. Now I will add all such PRs for editors review here. As you can see that I have added it already that um whether editor want to merge it or not even if it is not authorized by the author. Maybe author has long gone because the proposal is finalized. Now in that case if editors agree that the PR is reasonable and it can be merged then we do merge those PRs

despite we do not get the permission from the author. And there was another idea that was floated and I believe we need to document it somewhere as well like if editors agree for even for the present proposal they find it like very uh trivial change and that can be merged then we will wait for that PR for next two or four weeks just to make sure that we get input from author and if we don't get because editors agreed we can still move it like we can still merge it. So yes, we are working in that direction to uh merge most of the PR at least make a decision merge or close. I hope that answer.

Discussion on Force Merging PRs and Editor Permissions

>> Yes, I I think this makes sense. Um but then on the question on uh or like the agenda point or should we grant more editors to need to force match and poke it? I I think or well that would be my first thought is that it actually makes a lot of sense that two editors need to look at this because um like it's also like the point of like everyone makes mistakes. So you can also review a PR or like not be reviewing but like make the decision okay I should force merge this but I think it will be very good for the process itself that someone else meaning like another editor also takes a look at this so that we don't well accidentally start to merge like things which should not be uh be merged um and I think for

also because we are seeing like a lot of well an increase of the open PRs for the EIPs um I think what I will do is uh try to well going over all of them it will be like a lot of work but to also get like a feeling why we have so many PRs open um and to get like an idea like what like the root cause of this or not the root cause but what like how to categorize these and how to um yeah well how to how to solve this uh this problem like uh if we need something in the process or we need need yeah we need to take a look like what's what's going on why we have so many PRs open. Yeah.

>> Right. Uh so uh quickly responding to your uh this force merge situation. I do agree uh to your concept of uh you know when we are having another pair of eyes it definitely helps us prevent making any mistake. But this particular situation that I'm talking about here is force merged because of some bot error. Like sometimes if a PR is made by the initial author of the proposal then also it is not getting merged and in that case editor um can force merge it. So this is the particular situation but I would agree to your idea as far I wonder Sam if you have anything to add

on it. >> Um I I don't think there's anything technical preventing us from adding um more people to the force merge group. Um I just need to talk to the DevOps people. Um should be easy enough. >> Yeah, I think that would be great. Uh because and that will also distribute some of your um um burden like you know you don't have to go for every um every PR which is not being able to motion. Thank you so much for taking that. Yeah, to to to chime in on your point, Puja, of like uh that the boss has an error like if it is obvious then uh I think that force merging it is is fine. That's that that that that sounds uh yeah like

a like a good idea to me and I would also think that in that case yeah I'm not sure but I think that that's maybe like one editor like if it is super obvious that it should be merged then um I think like one editor should just of course merge it. Maybe that also works like this already but that that will be fine I think. Yeah. >> Awesome. So maybe we can um revisit this in the next meeting. Hopefully um we get a response from DevOps team. Maybe Sam if you would like to take the initiative on this one and have a word with the team.

>> Sure. Uh who do we want to add? >> Maybe Yam Gajender. >> Sure. Because I have noticed Gajender has flagged multiple uh PRs which he finds is okay but he always tags you that Sam please take a look may require a force merge and that way I have to just move his list of PRs to your office hour meeting in order to like you get it merge.

Cool. Um with that we can perhaps move on to the next item which is a topic suggested by Yohham. Yam has added a couple of points for discussion here today. Maybe I can just let him talk about it and we can take it from there. >> Yeah. So uh the comment here is about that currently on the EIP website we have the EIPs and we know the status of these EIP uh of these EIPs but um it is some some like we have these meta EIPs which are about the hard forks. So you can see uh which hard fork has which EIPs but in some cases it is not really clear. Um so if like an if an EIP if it

EIP Website and Meta EIPs Discussion

is a core EIP and if if it is in final then uh it is not clear what fork this is part of. Um and I think it will be very helpful um to um well to add this to the EIP like okay this was this was part of this specific fork. >> Yeah I think uh we have brought this thing earlier. I I believe there was a proposal to have it added as a part of uh preamble but that uh could not get approved uh for some reasons but I think I received this feedback from another contributor. He proposed that perhaps we

can have it added here. Um >> yeah I understand this is like again coming from preamble. Do we have a way to add it here without >> adding it to preamble? >> Yeah. So, what we can do is and this would require some work in Jekal or um eventually work in in E's uh next generation, whatever you want to call it. Um, and you would have to look at all of the hard fork metas and then like build an index and then add that information back into the um the EIPs when they're rendering. That isn't impossible. It would just need a few minutes of coding work.

>> Maybe I can uh I can uh suggest whoever wants to take this task to take a look at this uh Ethereum network upgrade timeline. Here we can with exporting this data we can get all the um EIPs those were part of uh particular upgrade. So this is one way to simplify the live here. But yes, yeah, taking a look at metaip is also >> yeah the way it would pro so the way it would probably work well sorry to keep it permissionless um it would just look at any fork meta and add that information to the e itself. So, like if some random

person came along and made a fork meta, that would also appear. Um, but that's fine. I think you can just ignore them. Yes, about like uh creating these random meta earpiece. I think this Yeah, this is actually a good question because from the editorial part, would we merge this or not?

>> We would merge it, >> right? Yeah, I see. I see. Yeah. Okay. So, that will then get added. Um and maybe like as a second question because the specific EIP which I mentioned in that comment, so it's 684. um that EIP is final but it is actually not part yet of this well it's not part of this EIP's inside SL upgrade uh um process. So this this raises the question like a little bit like what is like a final EIP because is it is this part of like is this part of the fork if is if this is this part of a fork or not. Um I think that's that's like an interesting question and this specific EIP it's a RATO activity one. So this is like a

case which can't really be part well it is part of the consensus but should then added to like the frontier fork or not like yeah not as like a final EIP is is part of a fork or not? Um yeah. >> Um I would say it's part of the fork where the code was added to clients to prevent it. Um I think that would make the most consistent sense because then you wouldn't have to go back and edit old EIPs. and as to your question of what final means, it just means the document can no longer be edited. We have like a convention of marking them as final once they're deployed on a network, but

there's nothing stopping someone from marking them as final beforehand or >> Okay. Yeah. That that that Okay. So then um yeah, I think that because we were just talking like also about this preamble. Um I'm not sure is this preamble like part of the markdown fell or not? And yeah. Okay. So then um if we would move something to final and if it will be part of a fork um then we should require this in the preamble I think if that makes sense.

Yeah, I believe that was the initial proposal to we can we can have an optional field um in the preamble perhaps not completely um following the network upgrade stages but um we can just have an upgrade section as preamble I believe this team has kind of implemented it if we take a look here so here it is saying that it is Fusaka SFI I guess that was the proposal so we say for example we don't incluse the include this inclusion stage. We can just include the upgrade name and included Fusaka here if that was part of Fusaka.

So we don't have to go back to the meta EIP of Fusaka to identify that 7951 was a part of Fusaka upgrade. Um is that the correct reading of what the ask is here? >> Yes, I I I I think so. Um yeah. >> So we can't we can't add it to the EIP itself. Um, I mean we we could, but it would be weird. So, okay, the person who's assembling the EIPs of a hard fork is not necessarily an author of that EIP.

So, for example, if Tim is coming along and assembling the Glamsterdam uh meta EIP or or assembling the Glamsterdam fork, he's not an author on all of the EIPs that are going into Glammsterdam. Uh, so he would have to go and make a pull request against each of those EIPs. is the author of that EIP would have to approve it or not. Um, and that's not exactly the the the governance pattern. The governance pattern is more like Tim or whoever's making the fork gets to pick what to include in that fork. Um, and they don't need the permission of the authors to make that choice.

Um, so it's kind of like they're separate like concerns. So the [clears throat] Then you also have the problem of um if it's an author controlled field then uh anybody can just claim that their EIP is in a particular hard fork and then it falls on editors to decide whether or not that's accurate. Um and that's kind of a subjective call that I'd prefer editors not have to make. So um the way we have it now where you have a meta EIP uh and anybody can make a meta EIP and can list whatever technical EIPs they want to include. That's a

EIP Governance and Upgrade Process Discussion

completely permissionless and objective system for editors. We don't need to participate in governance to for that to work and I think we want to keep that kind of pattern working. >> Yes, I I get your point. I I also agree with this. Um so maybe to to to um to add to this so we have like this EIP now which is uh the network upgrade inclusion stages. So that's 7723. So this is basically how we currently do these forks.

>> Um and I think for like the governance process you are right. So this will this was something with which we should essentially move to to well to basically like this EIP or some other EIP um and to not get into the the way to say of of like this process. Yeah, I have I agree with you. So so we yeah okay good point. Yeah, >> I may have a suggestion here uh that might help us without getting into too much of trouble. So uh the upgrade field that we are talking about if we have that field as an optional field as a part of preamble in EIP template where we can use it when we are moving any of these proposals for example uh not this

one for example this prop again okay again not this one sorry this is also a bad example let me try to take a look if I have a better example yes this is the one so this 7825 um proposal it went into Fusaka upgrade now it like listed as an last call. So when a proposal is moved to last call, we add this field last call deadline. Okay. So when authors are making um a status change right here after the proposal is merged in the upgrade, they will remove this last call deadline. And at this point they can include the field upgrade with the upgrade name listed here before moving it to the final. And at that

point of time it may not be very difficult for anyone to like uh figure it out if that is the part of the upgrade or not. So in that case the liability on editor will be to ensure that this upgrade field is only filled when the proposal is moving in the final status and that too we can definitely let it let author know that please uh refer meta e whenever you are making the changes for the proposal to move into the final status. Does this anyway help ease the burden of editor as well as give us the flexibility to have the upgrade name listed right over here. So we will have final standard track core

and the upgrade name right over here. >> So I think that would work. Um I don't see how it's better than just parsing the meta though. Like I think that is the most correct solution. Um, but yeah, if we only do it when it goes to final, um, I think that would also be acceptable. Um, I can't see a case where an EIP. Oh, I I guess technically if there's like a chain split and then both chains want to use EIPs as their like uh, proposal thing, it could get a

little messy. But that's such a corner case. I don't think it matters. Um, so yeah, I don't see a technical reason why that wouldn't work as well. >> Yeah. And the reason why I would advocate for that because you know that is the final status and that can be followed. However, I do understand why we received this request. So uh this uh request and this suggestion that was shared was from a testing team developer and he mentioned that because he was actively working on multiple upgrades. Right now we are preparing for Glamster as well as we are also looking for H plus Bota uh upgrade. So now when he's referring to EIPC he wants to keep this thing in on top of his head like I'm

working on this upgrade right now not on this one. And if he has to go back and check the upgrade in the meta ape, it's kind of like troublesome. I'm not sure if he would be in a position to help to that status. But I think perhaps we can uh work it um when proposal are moving into final status at least we can provide some references. Yeah, I I think what what we should do here is to to write down maybe this proposal to um like like for these uh well added some rules or or like the the intention of these uh to get also some more yeah for input I would say. Yeah.

Um but yes I I think like from especially from like well the the the comments you mentioned like this pain point uh it's just really nice that if you have an EIP that you can directly see what fork it was in that that would be like a good addition because you now need to go uh first read all the meta and then figure out okay what EIP uh what fork was this EIP in. Yeah. Yeah. >> Very well. I'm open to maybe uh put together a document in which uh we can uh propose this like we want to have a field upgrade added to EIP preamble and the conditions when this optional field can be activated and the

responsibilities as well. Um maybe we can first take this step and then we will start looking into the options which are there in order to help more uh testing team. Um I I guess there were other proposals as well that were in progress in order to help them know which EIP is for which upgrade. So maybe we can lean on them. >> Yep. Sounds good. Sounds good. >> I believe there are some more points that you would want it to be discussed today.

Editorial and Technical Review Signals on GitHub

>> Um well I I think that's like my second comment which which I just added to the end of the uh yeah this point. Um can I do this or uh do we want to Oh, wait. >> Yes, please go ahead. Yeah. >> Yeah. So u Okay. Uh so the point there is that uh I think on GitHub if you um like so I just got added as an editor um and I previously reviewed these EIPs from more technical perspective and as I noted that comment is I think that if you would comment or review an EIP on GitHub um and keeping in mind like the editorial and the reviewing process in mind I think that there are like three different signals which a review can give. So as an editor if I would now

approve an EIP that means uh because of well like if there's a new EIP then uh an EIP editor has to approve it you have to assign a number you have to approve it um in order for it to get merged. So that would signal that I as an editor would approve this EIP. But there is also like uh if I would review this uh from more like a technical standpoint then if I would approve it then it is more from the technical side and what we also see on GitHub is that um some EIPs like you see there's an EIP editor and they uh well they contact some people on discord like okay can you approve this uh EIP um to just signal that you support this EIP in the sense of that you want to get it into a fork. So I

think that is three different signals and my question is then and that's maybe yeah especially for Sam for input on this if it makes sense to use a different account for the editorial part to really signal okay this is the editorial review and uh the technical review side of this so that I use two GitHub accounts for this if that makes any sense or not and uh also about these three signals that the GitHub review can have three signals editor tutorial part, reviewing part and the support in a fork part.

>> This is a really good point. Um, so I think if you're if you end up giving a lot of technical reviews, then yeah, it probably makes sense to have a separate GitHub account for it. Um, personally, I just give like technical reviews on Ethereum Magicians. Um, and I but I'm not really deeply involved enough to actually have like a go or no go kind of like approval. Um, we could change it so that editorial reviews are um like require a special comment or like

a special message in the the review. Um or vice versa, we could like change it so that a technical review you can put a comment and the bot will ignore it. Um >> I guess yeah, we can think about this more and whatever works best for you. Yeah, just also to chime in on your part uh about giving like this feedback on the F magicians like just also for the record like I completely agree like for the history of these comments that these reviews should go on uh magicians. um except I would say at the part when an EMP gets introduced as draft then it could make sense a lot of you u like um

as an editor editorial point of view it could follow the rules perfectly but then from like a technical point of view like some things will just not make sense. So I would not feel comfortable to um or well yeah like if I see some obvious errors in the EIP like some technical errors I would not feel very comfortable to approve it both as an editor and also for the review part and that's why I like I also review these EIPs on GitHub to like directly give feedback on these I would say like in a pre-draft state status of this EIP like okay this does not make sense and it maybe should be improved before we can uh merge it. So that's like the the first feedback loop. Um for your idea of like the technical reviews uh like as a

comment I think that we should not burden the current editors to uh to have like a specific approval like okay uh editor says okay. Um so that would then maybe um uh like for a technical review like okay bot ignore this review. I think that will make sense. Or if that's even easier for the uh also for the overview to maybe just create like an second account um for the editorial part. Yeah. >> Okay. So what's the like takeaway from this?

I think um what I will do and this is maybe a little bit awkward because I think the change to EIP1 got merged also with I think the rights to the bot is that I will create an uh new GitHub account for the EIP editor. Uh use that account for the editorial part and also use that account to propose like this uh change to EIP1 and for the bots that will specifically use that account for the edits. I think that that's will be the most >> okay >> visible and logical uh change. Yeah.

>> Okay. Yeah. So, just make a pull request with your updated account and we can we can make that change. >> Cool. Cool. Cool. >> Um I think that was the last point Yam or do you have? >> Yes, those were my points. Yeah. Thank you so much uh for adding them and u and I think uh that's that's pretty much all we can cover today. We do have 5 minutes left. Maybe we can uh take the next point. If we can finish it up in next 5 minutes or so then it's very well. Um uh the next point is restructure and

EIPIP Meeting Restructure. Discussing renaming and inclusivity changes

rename EIPIP meeting. Um this is based on my discussion with Yohham and some of the other uh developers at Dev Connect. Um we were discussing how we can make it more inclusive. We don't want to have some decisions being taken at uh certain events or in a certain telegram group. we can make it even more public and everybody get along with the decision and we can share this information with community how to follow along. Um I understand there is now Ethereum governance team at the Ethereum foundation and there are certain uh process change. We do have forecast

website where people can go and look at the EIP which are considered for upgrades and things like that. So um I was wondering if we can rename EIP IP with ACDG like ACD governance and we can include um we can extend our invite to Ethereum governance team client devs alongside EIP editors. This could be once a month meeting where they can talk about the changes those are there in the process because I'm sure that there are so many client devs who sometimes still struggle to understand what's going on why I am at CFI why I'm at PFI and having all

this discussion on all core takes a lot of the code's time which I believe uh could be moved to the governance call so they can discuss decisions not the process is right over there. Yeah, that that was my thought. I wonder what people think here. Um I definitely think we can extend the invitation. I don't think that hurts. Um I haven't really thought about it deeply, so I'm not sure about [clears throat] the rest of it. Um honestly, I'm just not sure if devs care that much about us really.

>> Maybe maybe to chime in on on this uh and also maybe my line of thought. Um so we currently have this uh so this network upgrade inclusion states EIP um and I think so this is maybe like part of like like what what are we doing here? So what we really want to do is we want to improve the process itself and I think like the EIP 7723 so this is the network upgrade inclusion stage. So this uh explains what is considered for inclusion proposed for inclusion denusion u those those things um I think though this part of the process it it it should be discussed not on ACD uh E and ACDC but like how can we like improve

this this forking process. I think this this would maybe like be part of uh the governance process and I think that if you would start to do that here and also call it like I think HDG would be like a very good uh name for this. This is like really talking and discussing the process itself and leaving the decisions to the ACD the ACDE and ACDC calls and the governance so like like this this process itself to like a separate call. Um I think that that would make like a really good process and also like to collect okay the confusion like why is something cified why is it deified like the also maybe some frustrations collect them here uh at the governance call and

uh discuss these kind of things to really improve like the process for for everyone I would say if that makes sense. Uh I know this is a fresh topic and not manybody many people got a chance to take a look at it. Um maybe we can revisit this discussion next month. We will bring it on the agenda. Perhaps people can collect some more thoughts following the recording of this meeting who could not join the meeting. But uh yeah we should uh think of uh more ways in order to make it more inclusive and open to people.

Um we have just one minute left. But uh I wonder if we want to catch up with anything in specific in particular in the next 1 minute or um uh if not then uh perhaps uh we can wrap it up right over here. The next meeting plan is on January 21st at 1600 UTC. we can continue discussing some of the points uh that were unfinished and not decided here and um yeah we will also take a look at the new call for inputs.

>> Sounds good. Thanks for organizing Puja. >> Thanks. Thanks. Thanks a lot. >> Thank you everyone. Have good holidays and we'll see you in new year. Take care. Have a good one guys. You too. Byebye. What's up?

>> Heat. Heat up