EIPIP Meeting 89
EIPIP Meetings · 6 Sept 2023 · 56:32
Meeting 89 of EIPIP, held on 6 September 2023. EIP editors and community members go over the EIP process and the editorial issues currently open. This meeting covers changes to Final proposals, new charter steps under EIP-5069, a change of type to Meta and the split of the EIP and ERC repositories.
Topics
From EIPIP Meetings, hosted by ECH Institute.
Transcript
welcome to eipip meeting 89 and I have shared agenda on chat this is issue number 260 on eipip GitHub repository so we have added a few issues to be discussed here today there would be discussion from past meetings we'll go over eaps insight and an overview of EAP editing office hour so starting with the first item added here which is um an issue added to eips GitHub repository it is about a dart mode for eips web front I see there are conversation happening I just wonder if we have any PR for that or anyone would like to yeah
okay so we already have a PR for it sweet awesome I don't think anything else on this to be discussed but if there is please feel free to share very well we can quickly move over to the next one which pair is this seven five five four I think that is something else oh I think that client is saying that we is bringing it to the agenda okay
okay never mind we can go ahead and add that to the agenda which could be added as the default item for today's discussion I wonder if people have thoughts on the first one I know there has been a lot of discussion and it was pulled up by gajendra Singh so if you would like to add anything or maybe we are just waiting for Yeah so basically Panda uh sort of provided an alternate side that he has been building eip.info which basically has JavaScript capability and supports dark mode so I mean that looks good to me uh but if we want to add this to our main EIP web front uh for
that I think because Sam had few suggestions regarding enabling it through media queries and CSS but uh I think that those are not working so I'm not sure foreign yeah I can take another stab at adding it um I'm just not super familiar with um uh the the Ruby thing we use for building our website so but I mean can we sort of have this that you know we we have a website which basically if we do server-side rendering with react or some other thing basically that website can probably also work in
links or any other uh known JavaScript yeah I love the um the the vetpress site that pandas put together I'm pretty sure that's all rendered server side so I mean maybe we want to transition to that site at some point if the server side rendering can be enabled and sort of you know I feel like if we can maybe go ahead and add the dark mode in the present website eaps.ethereum.org that would be really
nice to have um I don't know I really do not want to put you on spot Joshua but because if you are from that team maybe if you have any thoughts if this is something that we can request the theorem.org team to have it considered at some point maybe yeah we could chat about it I don't think it would be too difficult based on the current setup um just a quick collapse all right that would be great so we have an issue opened uh that is 7549 where we are discussing of having your the dark mode for this I have also shared the
link of eipsonside.com that also has dark mode it seems it is something which is like you know people like a lot so having that integrated on the additional side ethereum eips.etham.org would be great to have um anything more before we move on uh yeah just following up on this I think um Matt was the one who objected strongly to the vet press migration so I wanted to see if your opinions have changed on that at all I mean I'd have to look at it again but I still don't really want to have a
complicated site no no it's all rendered on the server the same way Jekyll is so um I mean when you say rendered on the server do you mean it's rendered whenever you compile it and then it's available or is it yes that's my understanding okay it's not like a rendered server side is it it's rendered on demand out request no server side rendering is a concept where the website is sort of the entire uh Dom is prepared on the server depending upon the path link that the user is requesting
so this yeah that's different yeah Jekyll is a static site presses yeah it's statically compiled okay that's what I thought too yeah so it's not server it's not server-side rendered correct yeah it's it's pre-rendered and then right server yeah yeah um yeah we need to look at it again but like when I looked at it there was a lot of JavaScript code to do the rendering and it didn't look so straightforward and I mean it's just generally that's not really the direction that I was hoping for the website to go like I would like the website to just be very simple and the pipeline to be very simple
yeah that's fair okay we can uh we can talk about this a little bit more I think I don't want to take up too much time on this call I mean ultimately like if if we have people who wants this to be maintained and who have experience maintaining it and that we're confident they're going to be around for a long time to do this that okay I'm okay with it but I yeah I mean right now it feels like panda is kind of the only person who is really pushing to have this and is willing to maintain it or you know pause that experience I'm sure a lot of us could figure it out but that's not like what my job is and I yeah I just don't really have time to mess around too much with like configuring some like JavaScript
um build Pipeline on this like you know enough of the EIP Tooling in its JavaScript form has been yeah figure that stuff out well I can also help and I'm maintaining because I do have typescript JavaScript as well as if a react experience and uh but yeah it's I mean I can't really commit to so many hours to it but yes I can be there to assist I think there are just more of us familiar with JavaScript now than Ruby
I mean for sure like yeah we're not in a great place with Jekyll like I I would like to move away from it totally but I yeah I just I want to move to something simpler and not embellished and that was my take with my press and I guess now it's out of beta also which is positive but originally when it was proposed there was a lot of stuff happening and it was like alpha or beta software with a thousand stars in GitHub so I guess maybe for the next call we can reevaluate whether we want to do this and see if we can simplify it and get rid of all the complexity that's currently there
sounds like a good summary maybe we can have it on on the next meeting as well it seems that there are quite a few people I see Juan also mentioned on the chat um maybe able to extend the support to Panna and we have gajender Singh as well so we can have more thoughts collected on the issue and we'll bring it back on the next meeting moving on the next one is uh embed discussion to thread on EIP itself I think this suggestion is coming from kajinder Singh and Sam also has added some reference
sources by which it can be done but I do not see any PR yet um just out of curiosity um anyone here is opposed to this because as of now how discussion 2 is is added is just a link provided which is taking to that fem page yes please go ahead Daniel would that result in possibly some people looking at the discussions and thinking those are normative as opposed to the text of the EIP itself
because the discussion doesn't talk about the normative it's the back and forth to figure out what's going on and it's great for history but my concern if it's put in as part of the the presented specification it might lend room for arguments like well they discussed possibly doing it why is it not in there versus when you have to go to another website cognitively you're not thinking this is normative now uh I think the major intent for sort of embedding discussion uh inside the EIP is that you know uh so when somebody is presenting the EIP or writing the EIP the summary is generally started from over there and if somebody is reading the EIP it's it's basically a good point to actually
understand the summary itself so that the rest of the EIP can be followed so with that regard I think that that was my original intention that when I proposed this uh but I mean we can have a side pain that basically renders this particular discussion to link inside the EIP with that front itself so the other person really doesn't has to move out of the experience of the EIP experience but if you have to refer to other sources my argument is the EIP does not stand on its own an EIP is a document should include the rationale and the motivation without having to go to other sites if you need to go to other sites I would think you should summarize that
and update EIP to add the motivation and the rationale rather than saying go read it here basically we need to also sort of formulate a guideline to how to summarize an EIP because when I was for example asking lion to summarize any IP I mean this happened on a particular EIP and they said that okay you know this is already being discussed in discussion to this already has been said in discussion to link and that's where the real summary is and I mean they are so again the question was asked what is the best way
to summarize any IP or how it should be done so that is basically the problem that should be solved I mean there's a link to the discussion too in the IP already my concern is that bringing in the text into the EIP blurs the boundary between the eipd and stand on its own and getting the history on it you can still navigate there from the data but it's it's clear that it's meant to stand alone we don't render the discussion forum in the EIP then I don't really see what really how exactly it's different if we are just making somebody's EIP reading experience better
only but yeah sorry I'm not sure that's the case and it feels like we've consciously excised history from the eips like the same way that we're not we're not really big on examples in pseudocode in there um because you know it needs to be you need to stand alone it needs to be implementation agnostic right so I think one of the first things that we should decide is you know do we need to expand an EIP to include the history and rationale for how we got there I have gotten a sense that we've made an intentional decision not to do that if that's not the case then sure maybe we go down this path um but I think as it stands right now
I'm kind of concurring with Daniel so um that is the case like we are intentionally not include including the hit up over there but just to clarify here um we are not trying to add the text of fem on the EIP it's just that the rendering of uh the page uh right now it is it is opening a separate Tab and taking us to Fem page but uh if I understand it correctly what gajendra Singh Is proposing is like we can have it uh rendered on the EIP page itself people can scroll people if they want they can click on and get into it to add comments and everything else it's just that the
proper rendering is not there on the eips Dot ethereum.org Page yeah I think that's a feature not a bug but happy to be persuaded yeah I feel the rendering in the EIT is what I object to so um is multi-side a option like we can have two competing sites one will be VIP study ethereum.org and then other ones could be um they're providing different features so people can choose their preference
preferred one how do you see that being different than having the link to eat magicians at the top um it's a it's a perpendicular to that decision so for example EIP dot info can have uh the one that renders it and uh but the rendered the one that there's fbm's discussion and uh EIP s dot ethereum.org can choose not to and then we can see how people like them okay thank you
I'm good with this suggestion maybe Daniel if you could add your thought because um that is against the motion here so if you can maybe add your thoughts and if that helps any other developer come up with a solution by which they can address the issue and come up with a possible solution to have it uh you know rendered on the website another way that would be nice otherwise uh this could be another discussion Point yeah there's nothing stopping other random people from fork in the repo and ready with yourselves with their own information I mean that's the
point of it being cc0 you can take the information you can read it again yourself um but if we do an A B test on the official one you know we're based it it seems like the compromise is well let's just do it anyway you know and even with the AAP test on without thinking about the purposes and why we're putting it in there is is the link insufficient I mean it's sure we can go ahead and do this but it's it seems like you just whatever how much how much traffic do we actually have on the AIP report to actually have some a b testing I think the argument against a b testing
is that it's we're not looking for user feedback here we're looking for um like whether we want to imply that adding comments to the page is makes it normal a pure normative or not so it's not like we can you know show this to 50 of our users and then you know ask them oh is this discussion now um do you feel the discussion is normative now or do you still feel like it's non-normative like that we don't have a feedback system that can capture that kind of information so I think like I I don't think a b testing is going to solve anything here yeah but that can easily be solved by a small Banner that says that you know for the real discussion you should
follow the link like how we show the banner right now that okay you know go to this particular rank for discussion too so um just to clear um I didn't say a b testing I think a b testing Juan put in test a b testing my intention is to keep them two separate competing sites if you're not discussing this um I I don't have preference or comments between whether we want to do AV testing on the eips.org but I am in favor of having allowing people to have different size let's just let uh in such as eip.info and then so people can choose
to go to eip.info more often when they see the feature there is more helpful that that's that's something that would be fine entirely separate site not from the the main red ring but a secondary one that people could start using without it you know it's it's not a b tested on the site we don't force on them it's a different way to render the website I mean that's that's fine because you're bringing into a separate with context option rather than keeping the normative reference and adding on these possibly non-norantive texts with it if the website as a front that says this is not normative we're adding other features to help you understand it then I think that's an entirely different situation than any testing so it's an entirely different website
um URL add in this context and that's fine yes I agree all right um it is pretty obvious that we have different opinion here we do not have any PR and we would like to further discuss this issue on the issue section github.eips so we can discuss this issue on eip's GitHub website and the number is 7541 let's move on to the uh next item added here for for the discussion today that
is a issue number 7482 it is a considered adopting a community specification license term for new ERC repo so a sound Bachelor here has provided the description of the issue and I found a few comment uh by Panda people over there but there is no significant direction if we are going to have this thing adopted wonder what people think about this particular proposal I know this is for a new ERC Depot we have not divided the repo yet but that is again work in progress so any thoughts would be welcome here that's true
what's the main difference with this license like why do we want it to change um I I can speak to that it's it's uh it's like a very lightweight uh IP protection like you it's sort of a lightweight Affidavit of each person who contributes through a GitHub account that whoever controls this GitHub account doesn't hold any patents or IP they're gonna exert against a contribution via GitHub so since these since this all happens via PR's it's like a it's like three quarters of the way to a CLA or nine tenths of the way
to a CLA without um lawyers in Translation and you know like DocuSign and all of that it's it's like just using a GitHub account instead of a DocuSign account to promise you won't sue people um or patent trolls or something and I've I've set up Community specification and the CLA bot on some um Casa repos where the participating companies felt that requested it um it's um you know coming from diff uh like Linux Foundation orgs where it's sort of
um code development and quote unquote corporate uh corporate open source it's common to be worried about these things and it's um when you I mean it's sort of like the it's the specification equivalent of apache2 it's like um just enough uh licensing that makes people 80 percent more comfortable with 20 of the inconvenience um if that answers the question I'm not sure that was exactly your question though I just wanted to know most of what the difference is between this and cc0
oh uh yeah cc0 is uh doesn't uh protect us protects against patent s okay so this explicitly includes a patent Grant uh I I uh sorry I'm blanking on the details uh that's fine so we can we can definitely look into this I think um to be totally transparent like I'm not a lawyer I don't have a lot of background I tend to just uh do what people demand of me in a collaboration contexts and like if no one is complaining if no one is saying I'm not going to contribute to eip's
until you have a more uh defensive license um you know it maybe isn't a homework we need to add to our plate um it's more like if you know the best zoo team or if I don't know if if people are are feel like they're hearing of people holding back from contributing or documenting things as VIPs because of this we should we should move on this sorry Victor yeah I think this is a worthy of a discussion thing uh if I from me I have a
I I previously worked at a company and uh for the company purpose perspective uh CLS like this would not be able to be signed which means that it had I uh had we adopt that and then if I were still employed in that company um I wouldn't be able to contribute to EIP so this one data source so this is a double edge sword some company require it to be a patent Grant to be comfortable allowing their uh their their their their team to contribute some company on the other side cannot Grant a patent client and promise they wouldn't source to other people and so if they add the CLS they wouldn't be able to let the people of the team
contribute to that it's kind of like the debate between the the the two kind of idol license but either you keep it open and what people can do whatever to it and or you keep it at like open and require people to be open continuously kind of a fleece license I think um we don't want people who might patent Sue to contribute to the EIP repository I think we're okay excluding those people from it's very uh different uh for example uh like I know that we're currently doing cc0 which don't Grant a patent and on the other side I think uh on the go east choose to use the GPR which is
the the reverse are we saying that we all are going to the GPL site for it's not about patent but copyright has similar issue here it's very different right GPL impulse is Downstream restrictions on implementations we're a patent Grant would explicit like a patent Grant would explicitly remove restrictions on implementations so like we're currently GPL and we'd be going to MIT to put that in like a copyright analogy but in that MIT yes MIT is very widely adopted and even nit doesn't have a GPL although even mot doesn't have a patent Grant
or or to put another way a patent Grant is a defensive thing like you you make people swear they're not withholding a patent when they contribute because then they could exert that patent against things Downstream so like what when we when we talk about a pet Grant it's like uh protecting Implement future implementations from owing someone money they didn't know had a patent on a on a PR you know sorry dinner I think you're next um so I think wherever we go with this we need to get the opinions of lawyers um because I remember in a previous job um the licensing of a specification is different from the licensing of and
implementation so you could GPL a specification and you could Implement proprietary implementation of that specification and none of that flows down from its specification to an implementation um you know not legal advice that's what I remember a previous lawyer telling me um so I think these are some issues that we need to talk about as well and also if I recall the Apache License thing it's not fully so much a grant as much as it is mutually assured destruction if you enforce patent rights against something that is necessarily um you know there is a grant of what's necessary for this but furthermore if you enforce patent rights against implementations of of you know Downstream of derivative works on this you lose all Apache License grants so there's also a um a high cost of
enforcement um and nobody comes in thinking that they're going to create a patent champion trap of these specs you have some startup that gets some cool idea they get the EIP published and then some large company buys them that is into these patent drawing things I think if we do get into patent issues that's the more likely scenario as a small company gets bought up by a patent troll um who then starts enforcing things so you know just hoping that you know Only the Good People contribute it's like today they're good people tomorrow they're a problem so there's I if we can get the protections presented by this that's a good idea I'm just concerned that what's presented isn't going to give us what we want out of it so my takeaway is that we need to go and
find a lawyer more than one how many you got these days not on fire drills and they won't speak on recorded uh Channel anyway so you'll have to be offline to get a report from them okay I'll see if I can talk to anybody at the EF again um see if we can maybe get somebody to clear this out or at least pay for somebody to clear this up for us um yeah yes Victor yeah I I like what uh I I very much agree with Daniel um speaking of uh whether we add the requirement or pattern of patent grants
is one thing I do feel I realized that there's also something we could do is that we can ask people if you are contributing in if you are aware of any existing pattern that you know uh you can consider I'm not proposing but we can consider whether we want to ask people to require that they declare them so if they enter they um intentionally put a patent uh secretly layer and then declare that it's patented later on um then they lose some kind of legal ground to sue people yeah that's I think what I'd like to see is at least just like a list of patents
you're aware of or or a statement saying you aren't aware of any maybe this could be a follow-up to the legal analysis as well all right this uh doesn't look like an issue that we are going to get the solution right here in this discussion but I was also wondering uh Victor if it is possible to collect thoughts from other um authors on ERC Dev meetings maybe we can add some thoughts on the issue and uh yeah sounds good I'll add a um I'll add an agenda
anyway um moving on to the next item here uh this is a pull request number 7554 um it is to update eip7329 suggested by um Matt and yeah Matt if you would like to maybe summarize and share the discussion Point here um could I jump in and request a docket order change because we fold this in um after 56 50 69 and do the 721 final and 5069 first I have concern this might grow to fill time what would make you say that Daniel can we finish out the business first
yeah yeah yeah okay before we go to the fun part so before we before we have one more um proposal here that is to be discussed that is um EIP sorry PR number 7550 which is an update for eip721 proposed by Sam if Sam if you would like to summarize and what we are trying to do here sure so I didn't propose this I just finished it um but it's cleaning up some formatting issues in 721 uh which is a finally IP um I'm not suggesting that we do this I'm just bringing it up here because full descent um
wants to fix some of the formatting issues any a little object to it I know we have like strong feeling that we should not go ahead and edit anything in funnel EIP but if it is just about formatting not in any spec change could we do that I haven't had a chance to look at it if Sam thinks it's good I don't really good I'm not saying it's good I'm saying that I reviewed it there are um there's one thing that could could maybe be considered a Content change but
it's it's so minor I'm okay with it um the rest is all all formatting it just makes it like it's changing simple summary description that kind of thing um yes what's the change uh what is the change um so it's moving simple summary into description it's replacing eip-20 with erc20 um it's adding links to other erc's where they're required um it's putting interfaces in backticks to show that their code um and then it's changing a few of the link formats so that it uh they don't say ERC in them
anymore and I think that that's about it yeah it's basically just cleaning up a bunch of like ERC and eip20 kind of stuff mostly sounds like a fair ask because we have recently changed the format earlier it was written as EIP uh 20 but for all ercs now it is ERC yeah so just just request changes or approve the pr I don't think we need to actively discuss it I just wanted to mention it here could this be used as a poster child to set standards for what changing the final ERC changes are allowed and which
ones aren't uh We've allowed stuff like this before and we've also said no to stuff like this before so we don't operate on precedent here but I think it would benefit from a policy yeah I don't know but sometimes cleanup needs to be done that's this the other part of it all right oh very well um as some of editors mentioned they didn't get a chance to maybe take a look at this PR the pr number is 7550 please feel free to add your comment and if in the next two weeks we do not get anyone like stopping
the merge we can perhaps go ahead and merge the pr moving on to item number two which is discussion continued or updates from the past meeting the first one listed here is for EIP 5069 um I know the last PR we discussed in the uh meeting 88 is now merged and uh from there we discussed it was merged as an informational EIP but uh they were supposed to have it changed to meta so we can enforce the changes mentioned in the EIP Sam if you have thoughts updates on it would like to share with the team uh yeah so I'm just wondering if we want to ratify the just the decision making process and the keeper of consensus role
that we proposed in 5069 last call people please don't take it literally the last question because this is a living EIP it's going to be in this town no no sorry sorry yeah that's the ipip call yeah uh so I think Victor you were the one who asked for a comment period on this so I'd like to get your opinion I'm sorry what was the question uh so this is the end of the comment period we had opened last call for Eep 5069 and I'm wondering if you're okay ratifying what's in 5069 I'm in full support now that no more
further uh comments that's directed by it all right and I think everybody else had previously expressed support or the last call so um we now have a decision making process um would like to well I guess there's a few things that I'll I'd like to introduce we can do that after we're through everything else I guess or we can do it now I don't know anyways we have to elect a keeper of consensus so that's probably the first thing to do um I'd like to nominate gajinder they've been reasonably um I don't know neutral on most topics
Ben Gibson and uh yeah I guess we have to post a formal call for input so we can do that after this call um yeah sounds fair so we would also be changing the type of The Proposal right currently it is an informational category oh yeah I mean I can change that sure um the voting or whatever we are the keeper of consensus where can people go maybe read about it I remember having a Fellowship of Adida magician Page open for this discussion to do we want to
keep it over there or anywhere else people can share their thoughts so like this is for comments on uh this is sorry I'm not sure I understand the question so my question is like we proposed in this meeting uh for having gajendra Singh as the keeper of consensus um I know some of the editors are not present in this meeting we can definitely communicate as an outcome of it but I'm wondering if we can have a placeholder for it somewhere so people can follow and we can let them know yeah so um we have to say I guess the formal process for making decisions now is
um we have to post a call for input so that's actually going to be like a written thing that we put somewhere probably in the eipip GitHub and then we have to post it in the channels frequented by EIP editors so that would be like Discord here um and then 30 days after we post this written notice is when the decision is made if we don't get input from all the editors so because not all the editors are here we can't make the decision today yeah that sounds like a very good process for making decisions thank you for summarizing that anything more on 50 69 people would like to discuss here
all right uh the other two items one is EIP years secret repository split I think uh that is work in progress I don't see Greg on the call so I'm not sure if there are any update on PR 7230 that people would like to share okay um going back to 7554 is yes yeah that's where I was going now I remember the proposal which is now in the last call I don't know if you would like to share more about it um if you want a neutral opinion someone
else should summarize it but I'm willing to go for it is this the um like wanting to put things on different domains discussion or yes but I think a neutral party would be better I haven't followed this at all so I think you're the most neutral informed person we have Okay so full disclosure I'm very frustrated by this um Panda comes in at the very end of the discussions of the ERC EIP repo split and raises an objection that is bad for SEO and erc's um because they're putting it under two different EIP uh two different top level domains um what frustrates me is that Panda never calls into these calls we've had
lots of discussions and there's lots of back and forth argument that would be great on a voice call um to understand what his concerns are and to provide some of the answers um so that's that's my you know as someone who opposes this that's my summary keep that in full consideration as you as you consider my words on it but it's you know he doesn't want he's basically standing up and opposing the split and he also another thing that he threw in at the end was saying great so as I'm okay with this as long as erc's get EIP and as long as core VIP is get an entirely different website and don't keep the name EIP to which my response was people have been calling here see zrc's forever and telling people to go to the EIP website for erc's and go to
um what did I call it um you know see cpr. um ethereum.com to get your EIP information sounds contradictory because the website should be in the name everyone calls VIPs eips I'm just recommending that the names go with what people call them to be and even in the community I've seen people correct people for a non-eip things saying you don't mean eip4337 you mean erc4337 so I think there's a strong argument to be made that the community already internalizes this change maybe I'm wrong on this maybe it's my perspective fully disclosing that you should consider everything I say with a grain of salt on this because of my position on this but that's a brief summary of what's being you know
requested on this he's good Victor yeah if there is any link for this discussion or feel free to share it in the chat yeah um thanks for that and just to add contact there was a one time that's um out of for consistency that the EIP editor group require all erc's to be cited within eips as EIP so there's a if you look at it uh there were linters
that ask the erc4337 to be changed back to eip-43-7 back then and that's a little bit context and I I do know that some people are confusing uh confused by our decision I was supposing to that requirement but now that we change back from people who have been forced to change also were uh were were confused in some way so that is the background by um potentially Panda was requiring that and I just wanna um yeah absolutely and I don't have an opinion on this I find it kind of unreasonable for
nine people to be on this call most weeks and we've discussed this at length and I thought that we had agreed upon the repository and website split to three calls ago and for him to kind of come in in the last second I just I mean this is just ridiculous like it's not very respectful of everybody's time who's is spending trying to make the AP process better so like obviously I think it should be overridden so so this is literally just about deciding what to do with the render docs the there's no debate about splitting the repos right he's okay to split the reposa it seemed
but he doesn't think the website should be split but that was kind of my impression with the repository split was the repos would then also be split because we're not going to then create a new repo just to generate the website yeah like I mean I mean I I I actually prefer keeping them together on one website but like it's going to be way more complicated to do that and in the interest of keeping things simple I'm I'm totally fine just splitting the website too yeah I mean I think we could have a cool nice website that had it all integrated but we just don't have the vampire to do it yeah so like one of the key driving factors of the split was to allow for separate processes and I think
publishing is a really critical part of that process so I mean I think I I thought it kind of went without saying that Seth one of the intents and results that we expected from separating the repos was that you'd have a different and unrelated publishing schedule means opportunity all that kind of stuff um the suggestion that keeping them together is superior seems to really contradict the whole reason we did this in the first place so yeah that's that's going to be a no for me dog having a single website really gen affects Downstream the processes that
are there and published publishing schedules I mean these are existing to figure out as well as how to sort of merge these two repo at a time of publishing by about that is also pretty simplistic so I'm not really sure well I mean the kind of problems that we are trying to solve by splitting the website are actually there I that that's fair but it's also more complicated and more work like I I agree with you it's possible but I I just don't see the uh the need um
I know panda is not on this call and uh as we have mentioned it multiple times that in most of the cases he is the one who is updating the website and kind of working on this uh the the Manpower that we are talking about it seems like editors on call today not in a strong support of uh having it uh on the same rendering website um I don't know I mean I really do not want to say on anyone's behalf here but it seems like um the initial idea of having the repo split will make sense when we have both of the things on different pages to follow to just like
eaps.ethereum.org there could be ercs.ethereum.org and I think that was initially proposed foreign people think about having uh having an announcement to get people on board to maybe work on improving the website along with this kind of split and maybe we can invite Panda if not on this call maybe on a separate call sometimes on the weekend as he has proposed and see if he would like to want the responsibility of it plus he may be having the bandwidth of maintaining it in the long term yeah I mean we could do like a a couple workshops on improving the website and I
think the decision for today is that rough consensus among editors is to have separate websites is there anybody who disagrees with that all right cool um yeah I mean obviously I would like separate websites but I don't think that we need volunteers sort of contribute to this because we need like long-term contributors we've like kind of been plagued over the past few years with people who contribute for on the order of like two to eight to 12 months and leave and sort
of their projects all by the wayside so I don't want to switch to a website where we have some people come in do a bunch of work and then just leave because then we don't have the experience maintaining it or building or whatever so I would like to get people who are contributing to the process on like long term scales working on it um so I was just gonna say with maybe one minor exception one a one-off gig that does need some Manpower is figuring out how to redirect all the links that would be broken if a canonical link is moving like figuring out how to make the Jekyll
uh you know have that like whatever it is that Jason LD canonical link thing uh I mean maybe that just takes someone five minutes who knows how to do it but that's just like one one thing that does need to happen uh in in the process of breaking out uh separate sites yeah redirect I think it's a must-have um I would not be very very uh conscious comfortable having redirect broken I instead of consensus that we will keep but we will make sure that's the economical links to erc's will continue to exist and in a format of redirect or
not if they had I really don't care I'm trying to remember off the top of my head that I'm not really a specialist but if I remember correctly um if you can't do a redirect next best thing would be to keep it where it is and have some invisible you know like non-displayed annotation in the HTML that tells search engines the canonical version of this has moved update your you know index um sort of like when you archive a repo on GitHub it points you to the new one and you know all people who search for it get the new one uh but just just to say that I also agree that it would be
ideal to at least uh have a canonical redirect if not a dynamic browser redirect so eip7329 which is the meta one step four and the specification says set up a redirect for erc's on eipa3 more to go to the new website so getting these is part of the spec so it's a requirement cool good point sounds good and just for people to know uh this proposal 7329 is currently in the last call and it is we are going to make it uh enforced that uh this the ERC AP repository split is
going to happen as per the process to explain in this particular EIP Zone that's a good place to follow what is being proposed as of now yeah um we have about five minutes left I wonder Daniel if you have any other concern with respect to the split that you would like to share or maybe discuss or anyone else yeah I have no more concerns I'm just happy we're not five minutes over sure that is a good one very well uh so it seems like we are making good progress in the direction of this repository split we are considering the process of decision making from here
on and we are also considering important aspects of different repositories that may help people users and authors to maybe follow the process understand how it is and maybe you know share more information because this is something changing in the entire process we might want to educate more people about it we might want to share information as much as possible that's all on the topic let's quickly take a look at whatever is left I think the next one is eaps inside taking a look at the September months Insight we see that there are three eibs in the last call as of now uh the one is 7329 where the deadline is ending on
September 12th um authors please feel free to make your proposal into funnel status create a pull request after the deadline date the other two proposals are of ERC category number is 5114 Soul bound patch the last call deadline is September 19th erc7401 which is also ending on September 19 and the proposal is about parent governed nft token nesting authors listening to this call please uh create a pull request after the deadline to move the proposal and final status anyone else interested in sharing their thoughts about this proposal please reach out to the author before the
deadline because we would not encourage having any changes after the proposal is moved to the final status in this month of September we have received two Finance two final proposals and there are five proposals in draft one proposal has moved to stagnant status The Proposal number is 5139 okay I don't know if this has to be moved to stagnant or do we really uh want to move it to Patron but that is on the author to decide on it that's all on eip's status reporting we had eib editing office hour yesterday
I have added the recording for meeting 24 agenda for meeting 25 is up if you have a pull request that you would like to discuss and ask questions from EIP editors please add your PR number to the agenda and that pretty much conclude everything on the agenda today anyone has anything to add share or maybe something to suggest for the next meeting very well thank you everyone for joining us today I hope to see you in two weeks till then we can have our async discussion continued on editor channel on UMD and ethereum Caterers discount China thank you everyone have a good day
thanks thanks