EIPIP Meeting 84

[poojaranjan]

Date and Time

June 28, 2023 at 14:00 UTC

Location

Zoom: TBA in the Discord #eip-editing channel

YouTube Live Stream/Recording: https://www.youtube.com/playlist?list=PL4cwHXAawZxpLrRIkDlBjDUUrGgF91pQw

Agenda

1. Discuss Open Issues/PRs, and other topics

• Proposal: Make EIPW only check changed lines except for changing status ethereum/EIPs#7198
• Update EIP-7199: Move to Review ethereum/EIPs#7222
• Update EIP-7199: Move to Withdrawn ethereum/EIPs#7225

Changes to Final proposals

TBA

2. Discussion continued or updates from past meetings

• Discuss the EIP-ERC GitHub repo split Ref: PR
  • https://hackmd.io/A1zfRkO7RKKV6BIaSXpcbw

3. EIPs Insight - Monthly EIPs status reporting.

• Hackmd
• EIPsInsight.com

4. EIP Editing Office Hour

• Recording Meeting 20
• Agenda Meeting 21

5. Review action items from earlier meetings

• Summary here and here

[xinbenlv]

Propose to add to agenda: ethereum/EIPs#7198

[timbeiko]

Given the support by client teams for ethereum/EIPs#7206 on ACDE164, I'd like to discuss how to practically move the proposal forward.

[ulerdogan]

Propose to add the EIP-7212 to the agenda.

[xinbenlv]

Given the support by client teams for ethereum/EIPs#7206 on ACDE164, I'd like to discuss how to practically move the proposal forward.

Thank you for asking on ACDE164, @timbeiko

I will personally respect the community consensus, despite it differs from my personally views.

That said, since removing ERCs from EIPs repo pratically affects ERC authors the most, I would greatly appreciate to have a chance to solicit feedback of this on AllERCDevs 4th and bring the input back to discuss on EIPIP 85 if that's ok. Let's give ERC authors some time to react. If it turns out ERC authors have no objections, I am ok.

[timbeiko]

@xinbenlv I think it probably still makes sense to discuss how we'd approach this, and work through the "implementation details" on the call. If we want to wait to start implementing things until EIPIP85, so we can potentially incorporate feedback from ERC folks, I think that's reasonable.

I would just recognize that the desire from the "core" side to split is pretty obvious at this point, so even if ERC authors don't "agree", they should probably think about "how to deal with the change" rather than "how to prevent it".

[poojaranjan]

@ulerdogan
PR-7212 looks like a new proposal. If you have any questions, perhaps that can be answered on EIP Editing Office Hour 20.

[gcolvin]

ethereum/EIPs#7206 (comment)

Per ACD ethereum/EIPs#164, we're going to move forward with this. We'll discuss more of the specifics on EIPIP next week.

No, we are not. The Core Devs do not control the EIP organization and process.

The core devs had at most a day or so of warning to discuss a contentious decision that is not theirs to make. I learned very little in that meeting as to what their pain points actually are, just that given a single proposal that purports to fix them they approved.

So I am still blocking consensus. We need to fix problems, but absent a fairly complete plan as to what needs fixing and how splitting repos will actually help and not harm my objections remain unanswered. Blocking consensus means that if I cannot be convinced to support or at least acquiesce I will resign.

[gcolvin]

https://twitter.com/sproulM_/status/1671079363281051648?s=20

[timbeiko]

No, we are not. The Core Devs do not control the EIP organization and process.

I think this is an overly adversarial framing: the EIP process should serve Ethereum as a whole, and core devs are the main stakeholders involved in Core EIPs, both as the significant majority of authors and as the implementers of anything that goes live on mainnet. Given this, it seems obvious that the process should accommodate them. What is the alternative? Having it there for it's own sake?

The core devs had at most a day or so of warning

I don't think this is true. We've been discussing variations of this idea for years, and there's been a thread open on EthMagicians since Feb of this year.

I learned very little in that meeting as to what their pain points actually are, just that given a single proposal that purports to fix them they approved.

Unfortunately, given the amount of discontent people generally feel about the process (you link to a Twitter example in your next comment), I think we're past the stage of "gathering feedback about what causes friction". There's a more general feeling that the EIP process is too rigid and high friction, as well as a concern that it cannot adapt to suit client devs' needs (this conversation being another example of it). When discussing this with (mostly CL) client devs in person earlier this year, "showing that we can split out EIPs from ERCs" came up as something that would signal the process is open to change to accommodate their needs.

That said, I don't want to minimize the work that's been done by editors more recently to improve things. I do think we're trending in the right direction, but realistically we are years late in fixing these issues, and now the consensus from protocol maintainers is that having a separate process over which they can have more ownership is what they'd like.

---

Separately, it feels like this relatively bureaucratic/procedural change is being framed as a much larger political/alignment one. The base case, if the process really is fine today, is we just split a repo, set up some infra/websites, and have the same process mirrored in two places. There have been many more confusing things in Ethereum...! Best case: both processes do change and live side by side, EIP editors can choose whether to engage in both or not, and we've made them more welcoming for the EIP and ERC authors + implementers.

[gcolvin]

Per ACD ethereum/EIPs#164, we're going to move forward with this. We'll discuss more of the specifics on EIPIP next week.

No, we are not. The Core Devs do not control the EIP organization and process.

I think this is an overly adversarial framing:

A PR was brought to the Core Devs on very short notice that had not even been discussed at an EIPIP meeting. I'm not sure the Core Devs understood that this was an barely-reviewed, contentious PR -- not a consensus proposal by the Editors. Then the claim was made that we are moving forward based on the Core Devs' consensus, rather than our own. I object -- sometimes process really matters.

Unfortunately, given the amount of discontent people generally feel about the process (you link to a Twitter example in your next comment), I think we're past the stage of "gathering feedback about what causes friction". There's a more general feeling that the EIP process is too rigid and high friction, as well as a concern that it cannot adapt to suit client devs' needs

Agreed.

I've been clear all along that we need a larger plan that identifies and reduces the pain points and friction in our process. Splitting the repos may or may not turn out to be part of that plan.

And yes, the "split the repos" debate has become a stand-in for larger political issues. It has also seems to have highlighted "philosophical" disagreements among the editors. I'd really like to clean up our own house before engaging with the politics. And yes, I think we know enough to not need more circular discussions. We need plans on the table before can we make progress.

Towards that end, Victor and I have started a PR on EIP-1 that I'll add to the Agenda soon. We've tried to identify and relieve some of the pain that we see, so that further discussion can focus on concrete proposals. I do think that if we can fix the known problems in the process it will go a long way towards healing the political issues, and make it easier to further adapt our process to the needs of our users.

[gcolvin]

ethereum/EIPs#7230

This draft PR is very much a work in progress. So far it tries to alleviate some known pain points in the EIP process. These include

• getting a Draft into the repo in first place
• editing a document while complying with changing rules
• referencing relevant resources that aren't specifically allowed
• ensuring that all referenced resources remain accessible
• ensuring that the many Drafts we edit are technically sound and of high quality
• integrating the EIP process with the Reference Implementations and Core Devs workflows.

We propose to relax the enforcement of EIPW rules for Drafts, enforcing tighter rules only on change of status to Review and Last Call. This should reduce a lot of the friction in the workflow.

We propose to allow editorial discretion on the careful use of external resources, in line with IETF practice. All references must include full citations with authors, title, and publication information, including available DOIs. Links are optional, but should meet the origin requirements of EIP-5757. This helps to ensure that over time external resources can almost always be found somewhere.

We propose to introduce the role of Technical Assistants -- volunteers with relevant expertise who can assist Authors and review their work at the Idea stage. Editors may ask and help the Author to find one or more Assistants when a proposal needs more technical review and reworking than the Editors are able to give it. This should help to reduce the strain on the Editor's and increase the quality and general usefulness of proposals, especially ERCs.

We propose to require that Final Core EIPs link back to the commits on the Reference Implementation that implement them. This should generally help to keep these specs aligned, but I'm not sure if it goes far enough towards accommodating the Consensus Layer team's workflow.

We still need to tackle the problem of Github integration in the face of the number and variety of EIPs in our repo. Filtering the stream of notifications is one known problem. We can improve our RSS feeds, and would like to tag emails for easy filtering. It's already possible to filter PRs by label in the GitHub user interface. Other ideas are welcome. There are tensions here between what Github supports, how the Editors use the repo(s), and how outside developers want to use it.

[xinbenlv]

As my commitment to my own principle of "I'll follow the consensus despite I might hold minority view.", I put together a list of task items i think could be used as a starting point of discussing "How to split": Task list for ERC/EIP Split. Please feel free to edit.

[abcoathup]

I support splitting ERCs from the EIP repo. The EIP/ERC processes should be given a chance to evolve for their users.

Numbering whilst a trivial factor needs to be handled in the split.
Existing ERCs shouldn't be renumbered.
EIPs and ERCs shouldn't duplicate numbers.
A shared number scheme is required. In the short term this could be a spreadsheet where the next sequential number is assigned by an editor. Though this still has issues of number gaming. Alternatively if editors have discretion then there could be a perception of preferential treatment to insiders.
I'm happy to keep being involved in the numbering process. Whatever the process it should be quick at least for EIPs so they can easily be referred to.

Longer term a different number split could be looked at. Odds & evens (but ERCs vastly outnumber EIPs so there is either number wastage or ERC numbers would be out of sequence with EIP numbers.). Reserve a subset for EIPs e.g. 8xxx-9xxx. Or look at issuing the missing numbers.

Sorry I can't attend the meeting because it isn't compatible with sleep in Australia.

[bumblefudge]

A shared number scheme is required. In the short term this could be a spreadsheet where the next sequential number is assigned by an editor. Though this still has issues of number gaming.

If this were a high priority, one alternate path would be to split
1.) the editorial processes/board,
2.) the gitpages publication to two different URLs, and
3.) the offline processes, meetings, etc,
but power both from the single repo to keep the issue/PR numbering going as-is.

This would simplify the numbering, but make the double-CI a living nightmare for the poor souls who maintain it 😅