- The EIP IP meeting 92 is discussing various agenda items, open issues, and pull requests related to final EIPs.
- The meeting will also cover discussions on the split of the EIP ERC repository, including the need for support from the ethereum.org team.
- The meeting in 7 days will focus on the actual repository split, but not on CI or website updates.
- There is debate on whether to split the website, with some arguing for better user experience and others against it due to maintenance concerns.
- The meeting will also address other tasks related to the split, and there is disagreement among participants on the need for two separate websites.

- The speaker wants ERCs and EIPs to show up on all websites
- They propose changing the layout file or creating a different layout file depending on the repository
- The discussion is tabled until the meeting with Matt next week
- The forum has moved on to discussing EIP 273
- EIP 273 can be closed as everyone has agreed and the pull request has been merged
- EIP 274 is discussed, with some in favor of renumbering and others against it
- The arguments for and against renumbering are summarized
- There is no consensus on renumbering
- The debate about governing editors and their voting power is discussed
- It is suggested that anyone listed as an EIP editor should have voting power

- Proposal to consider all EIP editors listed in EIP-1 for voting in the call for input process
- Discussion about whether editors can vote if they have the power to merge pull requests
- Suggestion to define the initial set of EIP editors with voting power and use the editor ad removal CFI process to update the list
- Debate about whether there is consensus on renumbering EIP-5000
- Concerns about setting a precedent for retroactively changing EIP-1
- Proposal to delete stagnant EIPs and set a threshold for removal
- Mention of the authors of EIP-5000 being absent and not maintaining the proposal.

- Discussion about a proposal to delete stagnant EIPs
- Some argue for deleting stagnant EIPs, while others argue against it
- Proposal to keep stagnant EIPs in git history but not display them
- Debate about rough consensus and objections being heard
- Disagreement about changing EIP numbers and wasting time on the issue
- Consensus reached to leave EIP 5000 as is
- Discussion about accepting EIP 275, with one person opposing it
- Agreement to allow links to the yellow paper
- Consensus reached to mark EIP 276 as yes

- Discussion about the quorum being reduced to 0 editors
- Proposal to have a "no consensus" status for unresolved topics
- Debate about the need for consensus in adding a new EIP
- Review of a PR to remove an out of scope function in ERC223
- Deadline set for collecting inputs from editors on the PR
- Discussion about abstaining and the importance of gathering opinions
- Review and approval of typo fix PRs
- Speculation about the PRs being submitted by bots

- The speaker believes that the suggestions made by bots are valid and should be approved
- They suggest splitting up a long list of typo fixes into separate submissions
- The concern is that the typo fixes are coming from different GitHub accounts, which could indicate farming or potential scams
- The speaker acknowledges that there is no evidence of this, but it is a possibility
- They mention that these contributions are the kind they want, and question if the bots doing CI for them is necessarily bad
- They suggest checking the GitHub accounts of the resources to determine if they are genuine or potential bots/scammers
- The speaker mentions that there are other discussion points that couldn't be addressed in this meeting
- They ask about the action item or decision from the past meeting regarding the superseding comment panel, and suggest adding it to the agenda for the next meeting
- The VIP split meeting is mentioned, and the speaker expresses interest in seeing how it goes
- They offer to DM the email address of a resource from ethereum.org for potential invitation to the meeting
- It is mentioned that everyone in the meeting has disagreed with splitting the website and determined there is a better alternative
- The speaker suggests waiting for the results from the meeting planned for next Wednesday
- The meeting concludes with thank yous and farewells.

- EIP IP meeting 92 discusses agenda items, open issues, and pull requests related to final EIPs
- Discussion on splitting the EIP ERC repository and the need for support from ethereum.org team
- Debate on whether to split the website for better user experience or maintenance concerns
- Disagreement on the need for two separate websites
- Proposal to change layout file or create different layout file depending on repository
- Discussion on EIP 273, which can be closed as everyone agrees
- Debate on renumbering EIP 274 with no consensus reached
- Discussion on governing editors and their voting power
- Proposal to consider all EIP editors for voting in call for input process
- Debate on renumbering EIP-5000 and concerns about retroactively changing EIP-1
- Proposal to delete stagnant EIPs and set threshold for removal
- Discussion on accepting EIP 275 with one person opposing it
- Agreement to allow links to yellow paper
- Consensus reached to mark EIP 276 as yes
- Proposal to reduce quorum to 0 editors
- Proposal for "no consensus" status for unresolved topics
- Debate on need for consensus in adding new EIP
- Review and approval of typo fix PRs, speculation about bots submitting them
- Speaker suggests checking GitHub accounts to determine if genuine or potential bots/scammers
- Mention of other discussion points not addressed in meeting
- Mention of action item regarding superseding comment panel for next meeting
- Interest in VIP split meeting and potential invitation to resource from ethereum.org
- Agreement to wait for results from meeting planned for next Wednesday
- Meeting concludes with thank yous and farewells.

Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/281

On agenda we have some items to be discussed, some open issues, and then we will get into some pull requests which are open, but they are with respect to final EIPs, So we will perhaps get some solution and thoughts from EIP editors whether to merge that or close the PRs.

We will have discussions from the past meeting which will also include the EIP ERCD post split.

Then we'll have EIPs insight followed by editing office hour and review action items from the past meeting.

Since past few meetings, we have been discussing about the split of EIP ERC repo.

And currently, this is a work in progress.

I know in the last meeting, we discussed about having a meeting of EIP editors to discuss more about it.

Panda, if you would like to briefly update us where we are on that and if we have that meeting, what are we planning to take care of?

So, that meeting, so there's a few things.

1, the EIP review bot is not in a state that can be kind of like, like no changes to accommodate the split will be able to be made, or will be able to be merged into actual split repositories by the, in some days.

Additionally, there's not, additionally, we can't do the website updates on our own, we have to actually get some people from the theorem.org team, in order to do that.

As such, really, the only thing things we can do during that meeting are actually split the repositories and transfer a bunch of requests.

Just to be clear for you mentioned about we might want to have some Ethereum or team member to take care of certain things.

I don't see him on the call today, but he was in the last call.

If you want, we can extend the invite to him and if any support from ethereum.org team will be needed, we can perhaps take care of that.

Greg, would you mind actually in Discord DMing me or Sam?

Just your email address so that we can forward on the invitation to you.

I had to find my mute button, and I have a mouthful of apple, an invitation to what I'm sorry.

This is the meeting in 7 days, where we are going to be doing the actual repository split itself none of the CI, because the CI isn't in a place where we can do the split.

And we're not, we're probably not gonna be doing any of the website related stuff for, because we need someone to actually do the configuration stuff.

The job would just kind of, I guess, the reason we're having like, just like, I imagine there's going to be some debate as to, well, we want this 1 in the ERCs.

And so kind of just like the more people there, actually, I guess the more people there, the more discussion there's going to be, but like the fairer the discussion would be.

basically we're basically working hard to do something I never wanted to do in the first place.

All I could do was try to reduce the damage.

I am, I'm inclined to agree with you here, but it's being done.

The IP IP time kind of Wednesday at 9 central time, that would be 10 Eastern time, like, I don't know, Is it 14 you at UTC.

Why don't I just say no, rather than, than saying maybe and saying no in the end anyway.

We've got our seed funding and we're trying to work every waking hour.

We take Ethereum in payment, but internally it's nothing much to do.

And so I'm busy trying to build a very secure VM that can run Python.

So in terms of actually stuff that would need to be done for the split.

The list is quite long, considering that there is also this request to split the website, which I'm still very firmly against and would veto if I felt that that veto would actually do anything.

Yeah, I think if I remember correctly, like I'm sorry if I am misrepresenting your viewpoint here, but the argument here is that 1, it might be a little bit more work to make it happen, considering the repositories themselves will be split.

There might be a bit more, and the argument is also that the user experience would be better because you don't actually have to sift through any of the, not any of the EIPs that you don't care about, which I find to be an extraordinarily odd argument because you don't have to do that anyway if you just use the search functionality that's already available in my rewritten version of the website.

Which LiteClient did not accept for admittedly somewhat fair reasons, although those reasons are now updated because VitePress is now in a stable release.

By the way, for anyone that doesn't know what my rewritten website is, would you mind if I just shared a link to it in the chat?

Rewritten in the press so that it looks a prettier and B loads faster and C is actually in a status that we can actually develop on which the Jekyll website currently nobody knows how to completely like, like if we needed to add an entirely new plugin, I don't think any of any of us have like, like none of us are Ruby experts.

I am the closest 1 to being able to make major changes to the Jekyll website, but even then, like, I'm not able to make that big of change.

And that also kind of goes into another problem with what splitting the website would entail.

And that's that, well, there's nobody to maintain the EIP's side of the website.

They'd need to find someone to learn probably an entirely new language.

What possible objection is there to this?

What, I mean, what do they want to split from what?

They want to have EIPs.Ethereum.org and ERCs.Ethereum.org.

We have 6 panels here and they don't like 1 of them.

Is is anyone here in favor of having 2 websites and if so, would you mind speaking up?

I am in favor of having 2 websites, not because I want to have EIP and ERCs showing up on 2 websites.

I generally am in favor of competing, like having people have access to different approach to see EIP and ERC.

So I want ERCs and EIPs to show up on all of them.

I can easily just change the layout file or create a different layout file that changes depending on whether or not it files in the ERC's repository or the EIP's repository.

This would require about 10 lines of code.

Would anyone like me to go ahead and get the framework there so that we can have a kind of, I guess, repository dependent layouts.

I think you're kind of debating a ghost right now because like,

So I think we can just table this until the actual meeting we have with Matt next week.

And then we can hammer all this out then because I don't think we're going to make any progress on it without Matt here.

The deadline's passed and everyone has voted yes.

Doesn't that mean that the forum has now been reduced to the 3 yeses and it passes?

Yeah, so we're going to stop talking about ERCs and EIPs for now.

Everybody who has said something on it has agreed with it so we can close it the actual pull request implemented I think was already merged so it's kind of pointless.

So, does anybody have anything they want to add on renumbering EIP 5000 before we stop talking about it forever?

Well, I mean, there's no consensus yet, so it's not closed.

The deadline's passed, but that just means the quorum is reduced to the number of active, people.

That's kind of the whole point of having the keeper of consensus.

Yeah, we don't need unanimous, but we do need consensus.

And The keeper of consensus can only decide when consensus has been reached.

So we have 2 for renumbering, 1 against, and then Victor, you're in support of renumbering, and then I'm in support of renumbering.

So, I mean, I, if nobody else has anything to add here I would say that this, like we, we would merge it.

So I'm just going to reiterate, kind of summarize the points, kind of, I believe that are for and against it.

For renumbering, it kind of sets the precedent that if you find a loophole that allows you to do something like renumber your EIP to something nice or any other loophole that you get to kind of abuse it.

It also, I guess, kind of makes editors look bad for accepting what could be considered some form of preferential treatment.

The arguments against renumbering, and I am again against renumbering, is 1, it wasn't actually against EIP-1 at the time.

2, yes, and 2, the correct thing to do in response to something like this is to modify EIP-1 to prevent anything similar from happening in the future.

Would you say, would everyone here say that's an accurate categorization of breath points.

I guess I have 1 thing to add to the no, and that's that we can't set the precedent that rules can be changed retroactively, which I think we should set the precedent that if something is okay at the time it's done, we can't just subsequently be like, oh, that doesn't feel right.

We can't have that and punish, kind of punish someone for something that was totally okay when they did it.

With No other comments, assuming nobody else wants to make them, and the comments on the pull request being the latest.

I will go ahead and merge that pull request.

We've got Victor voting hold on Victor voting yes we've got Abbo Gossip I totally butchered his name probably voting no that's 3-3

we are we are considering editors voting here only, right?

Yes, but is he a governing editor or not?

I think we landed that anyone, well, the intent was that anyone in the governance section of the editors don't YML file has about.

All right, so does it mean that, like, we recently had a voting for who can be editors.

So whoever are selected in that list and continues to serve as an editor should have this governance power, like governing power and His vote, his or her vote should be counted.

So, so I think there's kind of either 2 ways of like, there's 2 ways of doing this, the reason why the EIP review bot can merge pull requests, can merge pull requests is that I dedicated the power to do so.

The config file itself is just a representation of who has the power to do what.

And in and of itself, the IP review bot delegates some of its power to the people in that file.

And so I guess we can work backwards And say that therefore anyone in the governance section is an editor.

Is for the purposes of the definition of editor, not an editor and for the purposes of.

So, it's confusing and probably should be made more clear.

I think for the time being, if people are open to accept this concept, perhaps what we can do is apart from bots, let's talk about human here, whoever are listed as EIP editor in EIP-1 should be considered for voting and their like, you know, their opinion should be mattered for at least for this call for input process in place.

So it is up in the air whether or not people that are in the government section or not in the government section can vote because for 1 thing we had all those call for invents for editor removals that Sam opened.

And 1 argument could be made that when people were voted either yes or no to having them removed as an editor.

When it was voted no, they aren't removed as an editor.

That kind of implies that they are an editor, according to the Charter, and therefore can vote.

The other argument is they can't actually have any effect on whether or not PRs that modify a living EIP such as EIP-1 are merged or not.

The intent, when the intent, at least according to Light Client, that when Victor was brought on as an editor, was that he couldn't have a vote.

I would argue that he should have a vote.

He has clearly demonstrated that he is a very competent, very engaged member of the EIP project, and almost certainly deserves a vote.

In fact, everyone in the EIP editors.yml file, I believe, deserves a vote.

Yeah, I think everybody listed on EAP-1 should be the set of editors.

Like, that's the only thing that works for me.

I mean, I guess the best thing to do here is create a call for input that that's for, hey, let's define, let's define kind of an EIP editor as, well, let's, let's define the initial set of EIP editors, right, that have voting power.

And from there we can use the editor ad removal CFI process to keep that list up to date.

But just so that we're on the same page as to what the initial list of editors is.

I mean, again, there were all those CFIs for editor removals that you opened.

Yeah, and everybody survived, so I think-

everyone survived, but more to the point.

Even like client voted no, that's not remove Victor as an editor, which strongly implies that Victor was an editor and still remains an editor.

So I've been operating under the assumption that our EAP1 is our governance document and the editors listed there are the editors, but yeah.

I think we should continue like as long as possible to have that as governance document.

And it is listed in the EAP 1 is, I mean, our editors, The 1 caveat here was, which I understand, is like they may or may not have permission to merge their pull request.

We can perhaps talk about it, but as long as governance is involved, especially if we talk about Victor's case, the only thing for him was that he would not be maybe actively involved for core EIPs, but other than core EIPs, he was definitely involved in every other set of EIPs, interface, networking, ERC.

Except he's not listed in the governance section.

And I'm pretty sure- That's maybe because we do not have a specific emerging power for ERC as of now, but I hope that will be fixed when we have.

We do, we do actually have a separate section for merging, ERCs versus interface versus networking versus core versus informational versus meta.

There is actually very fine grained detail in EIP review bot for this stuff.

Maybe we can have that and let's see where we are now.

I know things were different in the past, but a lot have changed in over a period of 2, 3 months.

For the purposes of this meeting, let's just consider all of the editors in EIP-1 to be voting editors.

In that case, wouldn't the PR to renumber EIP-5000, either it would be 4-3 in favour of renumbering or 3-3 tied.

Either way, I'd say arguably there is not the rough consensus needed for the keeper of consensus to determine that consensus has been reached.

Because there's about just under half of people that disagree with it.

That's not consensus by any stretch of the imagination.

Oh, like rough consensus it can be, right?

What is the definition for rough consensus here?

Because I thought that rough consensus was like, okay, there's a few objections, but we need to get this merged anyway, even though that there are some objections, we can sort them out later.

Not half of people actually just don't want this and are strongly opposed to it.

So working groups make decisions through references.

Basically, I didn't think that the keeper of consensus had the power to determine what consensus was.

I thought it was to determine when consensus has been reached.

So I think it is there for a reason like all editors are putting their faith in the keeper of consensus.

So whatever decision at the end is made should be acceptable by the group.

At the same time, definitely There should be a valid reason for going ahead with it.

Like, the decision making rough consensus could be, like, you know, even if it's like, kind of very close tie or not all of the editors may have voted.

So there are some gray area that we are giving permission to the keeper of consensus to maybe take a decision there.

Before we emerge the EIP 5000, renumber PR, you're aware that this effectively does set the precedent that we can retroactively change EIP 1, right?

Like say, okay, that is basically, even though that was allowed, then it's no longer allowed.

Because that is the precedent that's set here.

I think the precedent that I'm okay setting is that the EAP editors can do whatever the hell they want, whenever they want.

But these are general rules we're going to follow.

Well, That is kind of not the precedent I'd like to set, but okay.

Yeah, I mean, I know my vote does not count here, but what I meant to say here is like, or should do the numbering thing before the PR is merged as draft.

See all Ethereum Cat Herders transcripts on Youtube

EIPIP Meeting 92