Pooja: Welcome to EIPIP Meeting 81. I have shared an agenda in chat today we have a few items to be discussed from issues and pull requests those are new and one from the past discussion meeting we will go ahead with EIPS Insight update and EIP editing office hours update. Starting with the first item which is to discuss open issues and pull requests here we have proposal #6953 which has recently been added as a informational EIP to the repository I suppose the question that was being asked in this PR, is which direction we would like to move in? should we move ahead in the direction of making this proposal as living? or we should move in the direction of making this proposal to final? Tim unfortunately could not join the meeting but he has left his comment suggesting that he may not have very strong opinion in either direction but a weak preference going towards final. I'll be curious to hear what EIP editors think and what is the recommendation for authors here.
Sam: I think living proposals are very very rare I think we only have two so I'd prefer if we went in the direction of like this is a list of all the transition specifiers up to today and then that can go to final and then when there's a new one introduced it can require the previous one and introduce the new one and I think that would probably be the most EIPIP or EIP friendly way of doing it.
Victor: I agree, I think it's in team's intention that only he will create a new EIP if that mechanism changes, therefore final seems to be what he intended to the good characterization of his intended status.
Pooja: All right I can see a plus one from Gajender Singh on the chat as well so Just for record purposes we would be moving ahead in the direction of finals so I believe that the pull request open to move this proposal to review status.
Victor: there's just one thing, can I also bring to the attention of the other EIP editors that this is categorised as informational? I wonder, is it more of a Meta or informational one if it talk about mechanisms that's binding.
Sam: so if so my rule for Meta is if it affects the EIP process itself I think that's probably the only way we can have a clear difference between the two. But.
Victor: So, core core EIP, so activating for half what used to be one of the main use case for Meta and here this one talk about activation mechanisms and if it's binding seems to fall into the same category so in the context using that as using category I was I think it seems to or more on the matter side but I'll also be open to other approach information is totally fine but it just made this not as strong as it actually are
SAM: yeah so it it if a new proposal were to come along with a different activation mechanism I don't think we would stop them from using it like if so I don't think it's strictly a Meta proposal but it also could be a core proposal since technically core proposals are anything relevant to core Dev discussions and I think we can argue about this in circles forever I don't care if we just want to put our thoughts on the PR I'm okay with that.
Victor: It's okay, I don't have a strong opinion so I can suggest this it could be a matter if they want. If not then I'm totally okay for keeping it informational and we can defer it to the team's decision. Is that a good consensus?
Sam: Yeah, I think that's fine.
Pooja Ranjan: Yeah, I would like to be sure, like Sam, did I get you right? you are also suggesting to move it in the direction of being final because going through the proposal it looks like we are trying to record the activation timestamp for all the upgrades and my assumption is it could have future upgrades timestamp added to the proposal as well.
SAM: Yeah, I think I think we'd have to recommend that you remove that part.
Pooja Ranjan: Okay so we might have to remove the table that has been added here.
SAM: Yeah exactly.
Pooja Ranjan: Okay and I am reading the proposal right now it seems to me more informational than Meta because this has already happened in the past and it is just a documentation of uh, something that has happened in the past but not that is something to come up to suggest any change either to the Ethereum protocol or to the EIP process. So, I believe by the definition of meta EIP it is probably not qualifying to be added as Meta, but it's going more towards information. It's a piece of information, but, yeah, open to what editors decide here.
Gajnder: Yeah, I think we can remove the table of the hard folks of the main-net because I mean that's what not PR title anyway says it says what are the types of hard folks that are there in Ethereum. So anyway this information is stored somewhere else in Ethereum Gate repositories Maybe a reference to that git repository could be made over here.
Pooja Ranjan: Okay, all right so probably what we can get from this call is like people are in agreement for moving it to the review status and probably moving in the direction of final there could be some changes required in the proposal and that if someone can leave in the comment so author can follow and do the needful any more comment on this particular item.
Sam: I am doing it right now.
Pooja Ranjan: Thank you. All right.
—
Pooja Ranjan: Very well moving on to the next one is an issue which suggests that unlicensed code should not be allowed to be included in any proposal I believe this discussion is again stamped with the discussion of copyright like what kind of information we can add to the documentation of proposal and the proposal here is suggesting that copyright sentences should not be added element should not be added to the EIP and we should be including a licence fee like CC0 should be there so we should not have things like that. I wonder do we have any kind of documentation, anywhere in EIP -1 or anywhere which suggests this and we can share this with authors so they cannot do this mistake if this is a mistake or I suppose there is another question that is coming up from this issue is can we have a bot check, is that possible?
Sam: Yeah, so there's a PR for this for licence Checker I'm just trying to find it now there is a yeah there it is there is a bit of a disagreement between myself and Panda I think we should allow any open source licence that doesn't impose restrictions on on Downstream implementation, so we could allow Apache MIT and a few other ones but not GPL and panda is of the mind that we should only allow CC0 but regardless, we definitely should turn on the licence checker for to prevent unlicensed bits of source there's the poorer question chat.
Pooja Ranjan: #5379, that's good to know, that we already have a pull request for that licence Checker but again is it covering all sort of licences or only CC0?
Sam: uh, so I think as written it only allows CC0.
Pooja Ranjan: All right, yeah,
Victor: I left a comment in September 2022 my position is that I'm okay of requiring any assets to be put in EIP repository as CC0. Um, coming from a author and implementer background myself I also want to give authors other authors and implementers the options to not doing so by allowing linking from asset page from assets to file, because, it's very hard for people to put an Assets in this very strict licence requirement while also allowing them to reference to it. So, we could either relax our link policy to allow linking to implementation that is less that that is less open or we can we can not require the CC0 for assets but not likely if we do both it basically damages the ability for authors to be more open to share the and share those work with us.
Sam: It's not just ,uh whether, we can distribute it question right like we could distribute for example GPL code and it would be not a problem for the EIP's repository but a reference implementation that's GPL as an example there are other kinds of licences that would also be a problem but a reference implementation that's GPL in facts the downstream projects that they also have to be GPL so if we allow reference implementations that are like non-free so you can see the source code but you can't use the source code I think DB has an example of that licence or maybe I don't remember what are the database projects has an example of that where you can look at the source but you can't use it like those kind of licences are not useful in a reference implementation because like they're basically a copyright trap for for implementers and I don't think we want to encourage that. So I'd be against allowing any licence that imposes restrictions on Downstream implementations.
Victor: So I'm totally with you on those, since is, could potentially be a copyright trap and if we include them in our distribution that could be that that that could cause those problems we could be affiliate facilitating these kind of trap my argument is that however, we should be allowed not Distributing them but reference to them like create a reference link to them for example in our current policy if we only restrict to CC0 people would not even be able to link to go Ethereum as a reference mplementation would not be able to put go into Ethereum code to the repository as a reference implementation now I'm totally with you that we should not put go Ethereum code into into the EIP Repository and redistribute it because it's on GPL license but I think we should give author the freedom, instead to point to other code that already exists that has massive adoptions as reference invitation to say, hey, by the way, there exists other implementations and if you want you can check it out but you totally are up to yourself to make your own because we don't want to distribute those so our link policy restricted us from being able to let people show other type of information implementation. And also I think there is this implied difference that I and you you seem to hold with me can I verify that with you, that when you say reference imputation you assume that people is gonna copy and use that that's the main use case for reference implementation where I think reference reference implementation is only to show how it's done and then majority of the people will decide whether they want they want to go down the same route or re-implement it in a different way. Is that a difference that I implied to? Is that a good is that a right implement assumptions of how we see it differently?
SAM: um, it's close, so, I see, anyone who reads the reference implementation and writes a new program as creating a derivative work of the reference implementation which is an incredibly old-school legal view of software development but a lot of companies you know don't let their employees look at GPL code for exactly that reason so there there is an argument to be made that looking at a for example GPL reference implementation will force all like derivative implementations so anything that uses a similar kind of you know programmer algorithm is in the reference implementation, might be like subject to the licence of the reference implementation.
Victor: um, I think that's none of us are legal expert and I think you make your point it's I do know that that's one school of thoughts, there's also another school of thoughts that says, hey this doesn't seem like a copyright infringement and this doesn't seem like a patent protected in under patent so it's okay to look, so but yeah I don't know maybe we should consult someone who has their expertise my point here is that if we hold differences in this way. Uh, wouldn't it be okay to revisit the link policy to say you eat otherwise you wouldn't be able to let people put reference implementation so my strong position is that we should let people share reference with implementation as much as possible because otherwise it doesn't matter it doesn't make sense and doesn't help we advance the open organ open standardisation so that's what my my strong position is this and then you we can choose either ask them to even relax the copyright requirement or we can relax the link policy but if we restrict both then it's very hard for people to provide versus the representation.
Sam: So, yeah, so, that's why I think we should not relax the link policy and allow more licences than just CC0 but, not going so far as to allow GPL.
Victor: Yeah, um, I think that's a good direction to go, I seems to be agreed by and I also want to see that the gay and Greg, based hand so.
Pooja: Greg!
Gcolvin: Um, do we have any, sorry to not know but do we have an actual case right now of a GPL software that somebody wants to link to.
Sam: No, we have so let's let's bring this back to the actual discussion at hand somebody accidentally committed code with the unlicensed spdx identifier, which means that, you know, technically we can't even be sharing it right so it's just about adding a bot to catch some of those problems.
Gcolvin: Okay. Is there? I think we should have a general policy that we prefer we prefer proposals that have actually been implemented and those actual implementations May well be GPL to proprietary you know otherwise not something we would want to publish but preventing someone from linking to a working implementation does not help the quality of the Proposal but I'm quite happy to take things one case at a time rather than try to make up a rule in advance but my general attitude on each case is if there's an existing implementation the author should link to it it just makes for a better proposal. Um, if somebody feels that looking at a proprietary implementation is legally dangerous they shouldn't follow the link.
Pooja: Victor, please I see your hand raised as well.
Victor: uh, yes so one example that I can think of I I should probably follow find Links, because, we don't let link is there were authors who attempt to link to go Ethereum, which is currently the most adopted executive I don't need to explain to you but maybe audience who are watching the recording and it was rejected on the ground that we don't allow link to we don't allow links, to Outsider EIP and other approved sources. But let's assume, instead they want to put those files into our EIP app, repository under a /assets, it's not allowed because go Ethereum is under GPL and therefore even one of the most adopted clients would not be able to be and also supported by Ethereum foundation with grants. It would not be able to be put in the EIP repository. And, that is one of the example, of what these two rules together will prevent from I'm done speaking.
Gcolvin: Yeah, Ofcourse, can't go in the repository but a link a link to a you know to a link to the relevant commit # and that should be acceptable for.
Victor: Sam, if you want you can speak!
Sam: All right. So, let's um, I think the licence discussion is a much bigger topic perhaps we should open a discussion thread on which licences. We want to allow but I think we can all agree that we don't want to allow unlicensed code in the EPS repository is that correct trap.
Pooja: Yeah correct.
Sam: We don't want authors accidentally sending code, that they shouldn't be sending um. So, I'm going to make a recommendation that we turn on licence Checker and but we make it very Broad and we allow everything except unlicensed.
Pooja Ranjan: Um, I would like to share something here I recently was in a conversation with the author of #5773 I think he suggested, a very good idea in which we can probably share reference implementation even if we are not including that in the part of proposal. So, what they did, is like they came up with this an npm package for their code having reference implementation and shared it with one of the hackathons and I think there was some ZK related hackathon, going on so they shared with the participants and they were using it so when they are using the package they may have to pay the licence, but if they don't want to pay the licence, they can definitely go to the specs that are specified in the EIP and make use of that and implement the proposal. So, I am assuming here that there is a way out that we will be able to share multiple reference implementations, by not making them a part of the standard the repository, in standard we just mentioned the specs which should be generic and be available for everyone.
Victor: Can I also share something on that direction?
Pooja: Yeah. Please go ahead.
Victor: um, if I may seamlessly promote this effort that I'm promoting which is an open source effort to allow authors to contribute their reference implementation of ERC's and it will be in a NPM package which we currently packaged in. So, if anyone is watching this and think it's a good idea to share your reference invitation please do. And also we want to know how to us get how to licence this as well currently allow CC by zero but we are on defence of whether we want to be due licence or triple licence so that it can maximise the chance to be accepted in any repository because CC0 by CC0 is meant to be close as close as possible, to public domain if I understand it correctly but now that it's given a name is no longer considered as fully compatible with ? domain it seems to me in some of the cases so we don't know how to be as even broad as possible than CC0 so in that ground I'll ask what EIP to think but also just to bring awareness to this effort as well. ERC ref search for it yeah. I'm done.
Pooja: All right, um, I think we can take us at Sam's suggestion here that for this particular issue that is there. There should be a bot and the pull request is already there so we can go ahead and do that activate the bot and we should open a thread on Fellowship of Ethereum Edition to discuss which kind of licences should be allowed. Um, with this bot Checker like the licence checker. And we can probably have an elaborated discussion when we get some more feedback because in this closed group I think we have repeated this discussion multiple times. Sounds fair, anyone would like to add anything maybe to yeah wrap up this conversation. Okay, um, so yeah, I I think we should have that as a summary for this issue #7027 and let's move on to the next one.
So there are, oh, please go ahead and correct. I'm sorry Greg, do you want to add anything? Okay. Um, so, the next items that we have here are edits to final EIP so there are two proposals um, EIP #4955 and #4804 both are in final status and we have received a pull request to make a small edits to it so taking the first one which is PR #6937. I wonder what editors think should we go ahead and merge that PR? or we can let the proposal know that we cannot make any changes because this proposal is already in final status?
Sam: it's it's a pretty clear typo for #4955. So, I'm okay with that.
Pooja: Anyone here objecting? Okay, so is it waiting for anyone's approval? Like.
Sam: Yeah, it needs one more so I think, the way it's set up right now is to edit a final EIP it requires author and two editors so if one other editor for I think it's ERC yeah ERC so that'll be Greg, Matt, myself or Panda, what if you could approve it'll go through.
Pooja: I think Victor as well. Right Victor?
Victor: Uh, yeah, I added I do it I don't know if it approved it and then it's definitely gonna be EIP validator blogs.
Sam: But yeah, I'll merge it. I just need I want to follow the process.
Pooja: Yeah yeah! We can get one more approval if we have plenty of editors here so if one first can add a profile then that can be much perfect. So, the next one is PR #6860 which is with respect to proposal #4804. Any thoughts here, I'll take a look
Sam: Yeah, it's a that's a no-off, that's a no for me that's a significant update to a final proposal.
Victor: And it's changing specification, I think you can't change specification in a Final; which is a No-No.
Sam: You are allowed to add clarifications if I remember my EIP-1 correctly so theoretically this could be allowed but I tend to not.
Victor: I think they are adding must condition in line 64-65, which is not clarification
Sam: Yeah, so this is so resolve mode always had two modes it just didn't say what the return values were um.
Victor: Yeah, probably needs to be an additional EIP.
Sam: Yeah, yeah, maybe that would be better
Victor: I really like the idea of being able to have new EIP superseding the old one like IETF.
Sam: Yeah, I feel like you should be able to transition from final to withdrawn if you're the author.
Victor: No, they probably want to keep the number because they are trying to ask people to implement the number.
Sam: Yeah, but we do have withdrawal reasons so you can put like you know goes from final to withdrawn with a withdrawn reason of superseded by whatever whatever so maybe we do something like that
Gcolvin: Isn't isn't this just a smaller matter at all yeah
Sam: So this is, so the return values from the function resolve mode were never specified in the original version.
Gcolvin: That's an error.
Sam: Yeah yeah, um
Gcolvin: The specification was incomplete that's, that's an error well
Sam: Yeah yeah I guess you could implement it you just could return whatever you wanted. So like this is I don't know I don't know how, I feel about this, I won't really go one way or the other on it.
Gcolvin: Right, I think we have other little things stacked up for lack of an erratic Process. like broken links and ERC20.
Victor: And Sam, you are on the author list right.
Sam: That's a historical remnant but yes.
Victor: So, I guess it would be better for someone else to make.
Gajinder: I think hardcoding their values must be done in a superseding EIP rather than this one because obviously, it changes the specification of it.
Gcolvin: we're the, were these restrictions in fact there and followed is this a specification of what in fact was being done or is this a new restriction that would break existing implementations?
Sam: So, I'm only aware of one implementation of it. and it would have only returned one of these two values but it would break a theoretical implementation but I don't know if that's you know important.
Gcolvin: or not I'll not worry about Theory, I'm worrying about fact existing code. For myself if it breaks nothing and the existing implementation behaves this way then there was a failure to fully specify in the EIP that's an error and it's easily fixed if there's actually ambiguity between implementations that it looks more like you need to supersede to accurately describe the existing practice this just seems like a small error to me.
Sam: Um, so I guess I think I think the safer option for everybody would be to make a new EIP so maybe we ask the author if they're willing to? and if they're not then we revisit this discussion again.
Gcolvin: Yeah, I'd want to know if the author considers it a small error or if they think a new EIP makes sense also. I don't, I don't see, from the point of view of our policy that it makes a huge difference as far as precedent or anything like that but it's certainly an opportunity to introduce an Errata section. Um.
Pooja: The two things that we can take out from this conversation here is like, probably we need some policy around Errata and one suggestion that Sam, mentioned about an option for author to move from final to withdrawn because as of the current process that is not possible withdrawn and final both are the terminating statuses and we do not have any connection over there. So, if it's okay we can go with like more discussion on either of these policies and maybe we can bring it in future meetings but for this particular pull request if my understanding is correct, not many people are in favour of approving it that means this pull request cannot be merged. Is that a correct understanding and in that case maybe we would like to inform the author. Yes, please go ahead.
Gcolvin: I'd like to hear from the author, I'm basically in favor but we need to introduce a section Colorado so we can simply say in Irrata that you know, that there is a change um, that, that would be my preference, if that is agreeable to the author because I think producing whole new EIP’s gets confusing people remember the numbers, associate them with the EIP, and this isn't like such a big change, and it's not a breaking change, especially, it just isn't going to break anything. Um.
Sam: Well, so it would break an implementation that you know obviously didn't follow these new requirements. So, I, I think that, that is something to consider here but yeah.
Gcolvin: But there is no such implementation.
Sam: True but like who are we to judge whether an implementation exists or not right, like we might not know
Gcolvin: And you do your best to find out and you make the change at which point if anybody follows the older version they're making a mistake. Um. I'm not hard over on this it just a whole new EIP for a few words, um, and the few words are only there to document how it actually does work. Um, seems overboard yeah, at the other end a change that actually would break, existing code requires a new, new EIP, so that people can continue to follow the old EIP and not break their code. Um, it's just just like you continue, you can continue to conform to an older version of a language standard the old standards still there and still a standard it's just no longer the current standard
Pooja: I suppose the equivalent.
Sam: Here would be just a new EIP number and then the Old One's still there the new one exists.
Gcolvin: Yeah, it's, it's a judgement call, which is why I really, would want to hear the author's judgement you know. Sir off we're asking the author to submit a new EIP and they may say no, I'm done with this you know.
Pooja: I suppose if someone can drop a note, in the PR that way we will get to hear what author, Thank you, what author has to say in this direction.
Pooja: Very well, um, I think that's about it we concluded item number one we can move on to the number two which is discussion continued from past meetings. Um, I do not see Panda on the call and I'm not sure if anyone else has any information about the EIP number bot? do we have any progress? I remember in the last meeting we discussed that we started but has to be stopped. (No update) So, we will leave it as if and we'll try to check with the panda where we are on the EIP number Bot.
Pooja: Very well, moving the head to the next item here which is EIP’s inside. I believe in this month, we have received 4 EIP’s in the final status and there are 8 EIP’s proposed as draft out of 4, I guess 3 are still open as last call, for last call proposals. Um, I suppose this is the last chance to add any kind of addition if they have any suggestion for the author proposals are ERC #5570. Um, the last call deadline has passed it was yesterday and other proposals are ERC #5169 client script URI but obviously the deadline has crossed so if author did not receive any kind of suggestion they can go ahead and create a pull request to make it into the final status. And there is this recent added proposal which is the ERC #5008 which I've entered into last call recently and the last call deadline here is June 1st. So people listening to this call if you have any thoughts about any of the proposals listed here in this hackMD for the changes of suggestion this is the last call for you as well. Please go ahead and suggest that to author because we would try not to make any changes to final, uh, proposal as you may have heard in our earlier conversation. And yeah that's all from the EIP’s insight.
Pooja: We did have EIP editing office hour yesterday um, it was really great we saw a lot of new Authors joining our call trying to understand the process many thanks to Sam Wilson for organising this like for leading this and explaining answering, questions I can understand sometimes it can be overwhelming coming so many authors but we didn't get chance to look into all I believe there are four or five open items that were not covered in the past meeting. Any of the editors on the call if you get a chance please take a look at that. So, we should be able to close it before the next meeting. But for new Authors who are trying to draft a proposal and have any kind of question with respect to other process documentation and they are trying to understand because it is their first time please join us on the EIP editing office hour we hopefully be able to help you out and you can propose your proposal as a standard.
Pooja: That's all about item number four and I'm just quickly taking a look from this summary of the past meeting. In the past meeting I think, yeah, so EIP part numbering we already discussed panda is not on the call today. So, we can let it be the bug with #5507 was response so it's covered and a reviewer working group of Williams sorry. Victor shared something. Yeah, Sam, sorry, I suppose I know yeah
Sam: Um, so, one feedback item I received from the core devs is that, um, we aren't giving them enough opportunity to provide feedbacks and some changes one of them is the suggestion to not number EIP drafts and only assign them a number when they move to review. um. So, they're asking if we can provide um, uh, meeting summaries somewhere in the EthR&D Discord, um, but not in the all core devs Channel yeah so just so you know I'm going to be posting an update there after this call.
Pooja: Awesome, I mean we do have EIP channel here on EthR&D Discord we can make use of that right.
Sam: Yeah, exactly that's where I'm going to put it.
Pooja: Okay, perfect. So, I'm sorry I think I missed this part. So is the suggestion that we should not put an EIP number while the proposal is in draft status? It should be only allocated when it moves to review?
Sam: Yeah, that's something that Panda's been pushing for.
Pooja: But that could be like very difficult because there are so many proposal I can actually name ERC #4337 which is still in draft status. I mean, I understand that is one of the most advanced proposal but that is still in draft status just imagine that proposal not getting a number.
Sam: So so, I think it could work if we it like. Yeah, like I'm kind of torn on this like being able to have a number as soon as there's something merged is really nice. And you can refer to it right away but on the flip side it would probably encourage people to move to review faster, um, which is kind of the point of the review like you really shouldn't be implementing a draft EIP because like it hasn't it might not even be fully written yet. So, if we make it so that drafts are unnumbered, authors might be encouraged to move to review sooner which might be a good thing. I don't know I haven't made up my mind on this yet myself.
Pooja: But I think this is gonna have like you know another kind of discussion what would be the the EIP number should it be the PR plus some wordings and and obviously in this either bot or editor has to do numbering.
Sam: Yeah, so the bot would definitely do it and it would just be that the highest number the highest existing EIP number plus one.
Gcolvin: This could just push the problem to things moving to review before they're ready to review.
Sam: Oh! Agreed. Yeah.
Gcolvin: Just to get them a number because if they don't have a number you can't talk about them there's there's no no unambiguous way to refer to a proposal that has no number you know um.
Sam: Yeah, so maybe we keep the number, I don't know but it's it's definitely something we need to talk to Panda since he's the one making the bot.
Gcolvin: Is there real is there really an overload of core proposals?
Sam: No definitely not.
Gcolvin: Has anybody forced the core devs to pay any attention to a proposal that's not under review?
Sam: Did you get brought up on all core devs.
Gcolvin: Uh, yeah, but then you know if they get brought up it's not our problem they don't need a number to be brought up, they don't need to be an EIP at all to be brought up.
Pooja: If I, remember correctly according to the process the network upgrade process that they follow if a proposal is in draft or review that can be proposed for consider for inclusion like whether accepted or not, so that is a separate discussion but that can be proposed even if the status is draft and I somehow agree what Greg mentioned if we enforce having EIP number at the review status then the draft status would be as good as the idea was earlier so now people do not think of idea they just make a draft now eventually they will just come up with idea and that would not be an idea that would be a draft and the draft would be the review.
Gcolvin: It just seems the core devs are making their problem into our problem. Then it's we're just a publisher and our system works best if we give things a number as soon as they enter our system and then they keep the same number.
Sam: Core Devs want the number all the way through, that's my understanding.
Gcolvin: Then they just shouldn't waste their time on drafts they don't wait.
Sam: So sorry are you saying that you want a number all the way through or that you don't want to know very much.
Gcolvin: Want a number all the way and if the core devs don't want to deal with drafts they shouldn't deal with drafts.
Sam: Oh no, the coredevs don't care at all what status EIP is in as far as I can tell yeah no they they just want a number to talk about it it's it's Panda Micah from back in the day and myself a little bit who is toying with the idea of not having a number at a draft but if the the view is overwhelmingly that we want numbers I'm totally okay with that too.
Gcolvin: Yeah, I'm more I prefer looser standards for draft and I'm not worried about running out of numbers, you know.
Sam: Yeah, yeah, I don't there's only there's only what 6 or 700 EIP’s.
Gcolvin: So, yeah, it's just what it is, it's how we operate but we purposely have low standards for drafts because we don't ever again want to get dragged into political and legal issues about whether we should or should not have published a draft. Um, nobody else is here who went through that but I was. So, it was very unpleasant we literally had an editor who left because he believed it would be illegal for him to publish a protect their VIP.
Sam: Really that's a story.
Gcolvin: Yeah, so, he was he was Japanese.
Pooja: yeah I remember the storyline there that was I think somewhere in 2019 if I remember it correctly.
Gcolvin: This was part of why we have a bot ,to get to get ourselves out of the loop for that arrest the original yeah originally getting a draft into this system was a purely editorial function and partly automated. So, it it wasn't a big legal issue up front so there's a reason not to impose too much on getting things into draft stage as far as that goes there's a reason to give things a number and keep it.
Pooja: Okay. I think we have good context probably that's a discussion Point whenever panda is around we will try to bring it up on the EIPIP meeting. How we would like to design the EIP number and aggregate status it should be provided when Bot would start allocating. Um, yeah, I think that is also we can make it optional that's another good suggestion. Yeah, okay, so, if I get it correct Sam, are you gonna post a summary to the Eth R&D Discord Channel at EIP. Sorry, yeah, EIP editor Channel whatever it is yeah all right awesome. Cool thank you. And I think that is all from the items listed here anyone has any final comment to add.
Victor: Yeah, if I may mention that the thanks pooja and thanks many editors who helped we had a first ERC Dev call yesterday it was quite good I think the peer we start to sense the few some Sentiments of peer review we get people suggesting each other that's a great start and just want to say a big thank you but and and also look forward to have you join next time I think Pooja will present when she is ready and then also Sam I already put you on the on sharing the WTF for next time as featured topics so yeah if any other suggestions for how. It could be run or who should who can come to talk. That would be great and also feel free to point authors of ERC's to this venue if they want to seek peer reviews.
Pooja: The recording of the last meeting is added to cat headers YouTube and yeah I will also share the link on the meeting update Channel at Cat herders Channel right.
Victor: I shared it on Discord, I shared on Twitter, and the repository meeting notes as well so thanks so much for also helping out with the recordings.
Pooja: You're welcome! Very well thank you so much um, we have two minutes if anyone has any final comments to add. All right and yeah.
Victor: I just want to mention that I do presented a proposed status change the criteria for ERC's it's it's on Ethereum magician a post. Um, I want to talk about it next time sign up and but for editors I love to get your attention and maybe comment on it before next time so I can present it to you and walk to you too and get feedback. Thank you.
Pooja: If that is planned for the next EIPIP meeting it would be really great, if you can add it to the agenda which I will create it right after this meeting so yeah that would be good we can bring it to the next meeting if you would like.
Victor: Thank you.
Pooja: All right thank you everyone, for joining today hope to see you in two weeks have a good one everyone.
- Jason windawi
- Gajinder
- Sam
- gcolvin
- pooja