EIPIP Meeting 19 Agenda

[poojaranjan]

Date and Time

Wednesday, Oct 21, 2020, at 15:00 UTC

Location

Zoom: TBA

YouTube Live Stream/Recording: TBA

Agenda

1. Onboarding EIP editors - expectation guidelines.

• Edson's Comment
• Also, refer an open issue Role of editors in EIP process

2. EIP repository scope and editor duties

3. EIP triaging permissions

4. Micah has too much power

5. Review action items from previous meeting

Next Call - Nov 04, 2020.

[MicahZoltu]

Preface for "EIP Repository Scope":

We currently have relatively few EIP editors and a relatively high volume of EIPs to "edit". Often, EIPs need a lot of assistance/hand holding to get through the process so the job of editor can be quite time consuming. Editors are all volunteers (no one is paid). Because of this, I think there is significant value in greatly constraining the scope of the EIP repository, and specifically the scope of what editors have to look at/sift through/edit/read. Along with all of this, we want editors to to remain politically agnostic in their duties, with a focus only on ensuring content is well formed and written and we do not want editors to become curators.

Informational EIPs currently are very open ended on what they can contain, and do not have a clear schelling fence with regards to their scope. Editors either need to become curators and decide what content is worthy of being in the EIPs repository and what isn't (a very political process) or they need to allow just about anything to be an informational EIP (ranging from core protocol best practices to someone wanting to document their Ethereum project in the EIPs repository instead of a docs site).

My preferred solution to this general problem is to assert that the EIPs repository is purely a technical standards repository which gives us a very clear schelling fence and greatly limits what is appropriate for the repository. This would mean Good Ideas need to live elsewhere, and only things that need to be standardized (many-to-many relationship) are appropriate for EIPs. Under such a policy, editors wouldn't have to engage in curation and their duties would be limited to making sure technical standards are well defined.

[MicahZoltu]

Agenda item: Micah has too much power.

Since I'm effectively the only one merging PRs, this gives me effective censorship power. There are a number of EIPs that I don't support (i.e., informational EIPs) and refuse to merge. Since these are valid EIPs per the rules, my refusal to merge should just result in someone else merging them if they are otherwise valid. However, I have noticed that in most cases (there are a couple exceptions) since no one else is merging PRs my refusal to merge effectively results in me completely blocking the EIPs, rather than just expressing my dissatisfaction.

One other possibility is that other editors agree with my sentiment and simply keep quiet on the matter to avoid getting into a political debate over merit or validity of the rules. If this is the case, we should adjust the rules to be more transparent.

This conversation should probably happen after the repository scope conversation, though I do worry about the amount of power I wield at the moment even if it turns out that editors agree with me on this specific point.

[gcolvin]

@MicahZoltu I think the active editors are down to me, you, @axic and sometime @Souptacular. For a while I was almost the only only one merging, and for now you are. I confess I'm not tracking them right now - my days and nights are more than full with paid work. If you find yourself in a bad position I suggest leaving a message on our Discord and contacting me directly at [email protected].

I'm a little bit more forgiving than you are for the first PR. There is plenty of time for cleaning up the draft later.

And of course we need more active editors.

[gcolvin]

The "Role of editors in EIP process" issue links to @ethernian's old Magicians thread https://ethereum-magicians.org/t/decentralizing-eip-workflow/1525, so a few comments on that.

Initially EIPs were mostly proposals for  CoreDev  community to make change into ethereum protocol.  Editors  are parts of  CoreDevs  and their mission was to pick technically sound EIPs with enough support from community.

Well, not really. I don't think even the original editors were all Core Devs, and the EIP Editors and the Core Devs are separate (non-)organizations - neither myself or Nick Johnson were Core Devs when we put current process in place by @Souptacular, @Arachnid, and myself.

Our mission was intentionally not to "pick technically sound EIPs with enough support from community." It was only to publish EIPs for the Core Devs and others to implement. Our intent was to model the IETF process (Internet Engineering Task Force) for maintaining the standards for internet protocols (including UDP and TCP/IP).

So for much of their life EIPs remain in Draft status. Core EIPs can considered by the Core Devs at any point they want and deployed (or not) via any process they want They go to Final status as part of being deployed on the mainnet. In the end it is the very fact of being deployed that makes a Core EIP Final - if it doesn't describe the actual consensus on the network an errata PR is needed.

I think the Last Call process got added later as a route to Final for non-core EIPs.

EIPs are not only about changes in ethereum protocol any more. Only few of EIPs require community consensus. Many of EIPs do not appeal to CoreDev and do not need to be reviewed by whole community before being implemented. Most of new EIPs are targeting some specific ethereum sub-community and not the whole ethereum community or only CoreDev’s.

EIPs never were only about protocol changes. EIP-20 dates to 2015.

@jpitts and I created the Ethereum Magicians in part as forum for reaching rough consensus on EIPs. At our second meeting Rings started to form around sub-communities, and more ad-hoc groups tend to form around some EIPs.

[gcolvin]

@poojaranjan -- your link to the Meeting 18 agenda is broken. Is it https://github.com/ethereum-cat-herders/EIPIP/issues/34?

So far as @edsonayllon comments on the Meeting 17 agenda:

Should EIP authors create a reference implementation in a client as a requirement?

It's not a requirement, but it's a good thing. "Rough consensus and working code" has long been an EITF motto. The code itself or references to it already have a place in the Implementation section.

Should a tagging system (maybe a header) be added to organize EIPs?

We are already using github labels on EIPs.

Should EIPs include a list of use cases?
Should EIPs include a list of pros and cons?

If these are needed they would already fit in the Motivation and Rationale sections.

[gcolvin]

Other discussion on the Meeting 17 Agenda includes some rather complex diagrams of EIP status.

• The EIP Editors being separate from the Core Devs, the Status field was not intended for tracking the Core Dev process. I would prefer an optional additional headers for this and any other such information.
• Looking at @MadeofTin's diagram I'd eliminate the Review and Living statuses. Draft EIPs can be reviewed at any time, and Drafts that don't get through Last Call to Final simply revert to Draft status until withdrawn by the author or otherwise moved.

[gcolvin]

As for the current agenda.

• I would not block a proposal for number squatting, but I'd scold the author. At the least there should be a summary of the intended EIP for that Issue. This should be made clear in EIP-1.
• I don't think we've ever enforced the policy that editors assign EIP numbers. It's common for authors to use the EIP Issue number - they are drawn from the same sequence as PR numbers. We should probably bless this practice in EIP-1.

[gcolvin]

And on @MicahZoltu's EIP repository scope.

Editors either need to become curators and decide what content is worthy of being in the EIPs repository and what isn't (a very political process) or they need to allow just about anything to be an informational EIP (ranging from core protocol best practices to someone wanting to document their Ethereum project in the EIPs repository instead of a docs site).

We chose way back not to be curators of the quality of a proposal, only whether it met our standards for correct form and technical substance. I don't know much about Schelling fences, but at this point I think we have enough experience to tighten up and clarify those standards.

I believe that Informational EIPs should be more open in form and substance, but still technical in nature. I think the reviews and discussion of the controversial EIP-2982: Serenity Phase 0 proposal can serve as an example.

[poojaranjan]

Closing in favor of #38