EIP-1 - add EIP Editor Criteria

[loredanacirstea]

This adds an EIP Editor Criteria section to EIP-1: a transparent process for appointing new EIP editors.

There have been discussions about adding more people as editors, but there is no PR with a process proposal in this repository, at this time.

My approach is:

• to make the requirements somewhat strict and based on merit. I think it is better to start with "strict" and see how the process works and how many new editors are still willing to meet requirements. Afterward, the process can be updated.
• start with a process that can be implemented in Github (because this is the current medium), but could eventually be decentralized

Discussions: #2173

Related: #2166

Disclaimer: I do not fit any editor category, not now and not in the near future.

[pi0neerpat]

LGTM just a few comments

[pi0neerpat]

If there are no current editors and no suitable editor applications for a category ...

Had to read this a few times before realizing both are required- maybe this would be more clear: "If there are 1) no current editors, and 2) no suitable editor applications for a category..."

... this rule can be restricted to:

relaxed rather than restricted is more clear.

[loredanacirstea]

Good point. Done in 2e7358a

[pi0neerpat]

This seems unnecessary and hard to enforce. Wondering what others think. Ain't we all supposed to be open and friendly?

[loredanacirstea]

I reworded in 2e7358a. Let me know if it is better now.

[pi0neerpat]

Is this the category for someone who approves/manages editors? Maybe change to "Editor Manager" or something similar

[loredanacirstea]

"Editor Manager" is more clear. Done in 2e7358a

[pi0neerpat]

Should be required

[loredanacirstea]

Done in 2e7358a.

[bmann]

My recommendation is that people just “do the work”.

If people consistently give feedback and monitor EIPs and work on them — they’re an editor! No barriers!

Giving someone commit access should happen after they’ve spent some time doing the work. But it can happen pretty quickly — because what is the downside of helping merge a PR? It can get reversed.

Editor should not be a power role, it should be a “do work” role.

[loredanacirstea]

@bmann ,

My recommendation is that people just “do the work”.

I think we fully agree on this.

If people consistently give feedback and monitor EIPs and work on them — they’re an editor! No barriers!

There is a matter of skill and quality of work to consider. People who do great work on some ERCs, may not be suited for Core. From personal experience: it is hard to assess quality. You have to really know your tech and think deeply about a problem. It is easy to comment and seem knowledgeable. This is why a vote from the current editors is necessary, and therefore a process.

But it can happen pretty quickly — because what is the downside of helping merge a PR? It can get reversed.

A thorn is harder to pluck then to pass through. We will soon need a process to revert that bad PR and lose another 2 weeks of arguing on Twitter.

Editor should not be a power role, it should be a “do work” role.

You have put the dot on the i.

[bmann]

Basically, I believe the issue is actually recruiting knowledgeable people and asking them to commit time to do the work — not handing someone a title.

If there were a line up of people begging for editor titles and/or tons of people consistently reviewing — this might be needed.

If it were me, I would put effort into recruiting more people rather than adding process that it’s unclear what it solves.

That’s my 2gwei. Good luck!

[ghost]

If it were me, I would put effort into recruiting more people rather than adding process that it’s unclear what it solves.

too much process (especially in form of text) is bad, agreeing here.

EIP process needs to be revised/simplified.

[Arachnid]

Given that the problem we have at the moment is not enough editor-hours, adding a large and bureaucratic process for approving editors and what they can work on seems like exactly the wrong direction to go to solve that problem. I don't think this PR solves a problem we actually have.

The requirement that editors be experts in the EIPs they're editing also reflects a misunderstanding of the role of editors, who are supposed to largely shepherd the process along, not to act as arbiters on the technical soundness of every detail of an EIP - that's what the last call phase is supposed to ensure.

[xinbenlv]

@Arachnid that is my (mis)understanding too. It's good that @loredanacirstea's attempt of adding a criteria for editor at least expose this misalignment of understanding.

[loredanacirstea]

@bmann , #2172 (comment)

If it were me, I would put effort into recruiting more people

Agreed. I would like to help such a campaign. It should be backed by current editors and maybe Ethereum Foundation. Are you in?

@lazaridiscom, #2172 (comment)

too much process (especially in form of text) is bad, agreeing here. EIP process needs to be revised/simplified.

Which parts are not needed? You can make a PR review.

@Arachnid, #2172 (comment)

seems like exactly the wrong direction to go to solve that problem. I don't think this PR solves a problem we actually have.

This is destructive criticism. What actually solves the problem?
I can give you a hint: organize a campaign for new editors to apply, involving the support of all current editors and maybe the Ethereum Foundation. Otherwise, demonstrate that you can carry the work with the numbers you have.
Then, you will find out that you need a process to approve new editors.

The requirement that editors be experts in the EIPs they're editing also reflects a misunderstanding of the role of editors, who are supposed to largely shepherd the process along, not to act as arbiters on the technical soundness of every detail of an EIP - that's what the last call phase is supposed to ensure.

The current EIP-1 editor responsibilities state: "Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status."

You know this very well. You are behaving like any politician: you know the current "law", but you want to change that law, so you deny the existence of that law. This behavior is very bad for the EIP process, which should be the heart of Ethereum 1.x.

[bmann]

@loredanacirstea I’ve added campaign ideas on EthMagicians https://ethereum-magicians.org/t/proposals-to-add-eip-editor-criteria-and-other-eip-process-improvements/3453/2

Also, I don’t think accusing @Arachnid is helpful?

Like this is pretty simple. A lot of the work is helping format their Markdown correctly. And giving them any feedback.

EIP editors do a first pass on technical soundness to weed out very low quality -/ but that mainly applies to ERCs.

Core EIPs getting from Draft to Accepted — and then actually into an HF — is the hard stuff.

It all starts with more people getting involved.

[loredanacirstea]

@bmann , thank you for continuing with the campaign ideas!

Also, I don’t think accusing @Arachnid is helpful?

If I am mistaken, I want to know exactly where. What is incorrect from my accusation? I can give step by step reasoning if needed.

I honestly respect @Arachnid for all the work he did and does in the space. But I never let slide unclear or incorrect affirmations - regardless of who makes them.

[ghost]

Which parts are not needed?

EIP process needs to be revised/simplified. - all of it, including its medium (github)

So, the current process/medium is the problem to solve first.

[xinbenlv]

@bmann. I like your constructive campaign proposal.

I'd like to say from a third pair of eyes of me, there is no bad-faith "accusation" nor bad-faith of pointing out the disagreement of direction. Actually such discussion is quite good. I don't take it for granted for your guys' spending time participating in the debate, and it already reveal some outcome.

@loredanacirstea communication-wise, I think a metaphor of saying some type of response sounds like a politician doesn't help the debate. Instead, the fact you pointing out that tech soundness WAS one of the existing expectation in thee EIP-1, or at least what the other side of argument doesn't seem to fully have the consensus, actually makes the strongest point.

Philosophical-wise, I agree with @Arachnid - if I understand it correctly - in that by not requiring a technical soundness approval by editors(which actually IS a defined group), it allows for decentralizing the technical contribution for whoever wants to help reviewing.

I believe what @loredanacirstea 's ask for: better editorial turn-around time and expectation of time to process, and what @Arachnid hope for: no one dictates a technical soundness approval, can be achieved by a combined solution, by improving the process and create a path to becoming editors

[xinbenlv]

I think it's important to include #956 as a context to this discussion (at least I miss that myself when participating this). @loredanacirstea do you want to append it to the first post of the thread?

[Arachnid]

@loredanacirstea This is destructive criticism. What actually solves the problem?

I don't know what will solve the problem, but that doesn't make my point - that this proposal doesn't solve it - invalid.

The current process does not expect editors to be experts on the EIPs they're editing - and the goal of the process isn't to do this, as it would put a large burden on editors to be final arbiters of every standard. Our goal instead is to use systems like Last Call to allow anyone to express technical concerns, meaning editors only need to be arbiters over whether there's consensus on an EIP.

Requiring editors to be experts, and imposing new restrictions on who can edit, will make it harder to recruit and retain editors and slow the EIPs process further - the opposite of what I think we are all trying to do here.

The PR you link to to EIP 1 is talking about lowering the requirements for getting a draft accepted; it doesn't refer to the process for getting an EIP to final status.

If you want to make a change to the EIPs process, I think it needs to meet a few criteria:

1. You need to demonstrate a sound understanding of how the current process functions, and how it's intended to function.
2. You need to articulate a problem that needs solving.
3. You need to demonstrate that the proposed solution works to solve the problem.

Right now I don't think this proposal meets any of these critieria.

[loredanacirstea]

@Arachnid

Your number 1. is irrelevant.
I do not need to know in detail how you are used to doing the process, in order to propose a better one. The only question here is: is my process better than the current one?

And up until this point, your only criticism was:
A) it is not how we do things!
B) this is too bureaucratic

A) Exactly.
B) EIP-1 has no process at all, the lack of clarity makes the editors a secret authoritative group with no clear way of getting in or knowing on which bases the current editors got in. A transparent process, however bureaucratic, is better than a closed-doors one. Help me improve it - what criteria don’t you like?

So, for your number 2.: the problem is my point B)
For your point 3.: I actually did the effort to write up a transparent process, when there was none.

You do not meet your own criteria, in order to judge my proposal:

1. You did not prove a sound understanding of my proposal
2. You did not articulate a bigger problem with my proposal than the problem solved by my proposal (bureaucracy is not worse than opaqueness)
3. You did not offer a better solution than my bureaucratic one, while demonstrating that it solves the problem

Since you did not demonstrate that my solution is worse than the current process or a solution of yours, and two different processes cannot be equal, we reach the temporary conclusion that my process is better than the old one.

Still, what I can do is split my proposal into two parts:

• Editor criteria with no mention of assigning editors to a PR
• Editor assignment proposal

Is that satisfactory?

[ghost]

Your number 1. is irrelevant.

Actually the whole issue here is irrelevant. And i explain:

@Arachnid states:

If you want to make a change to the EIPs process, I think it needs to meet a few criteria:

• You need to demonstrate a sound understanding of how the current process functions, and how it's intended to function.

I would say that this is "standard-procedure" (e.g. applicable to any process)

Now, if you start to understand the EIP process, the first weakness of it becomes nearly immediately clear:

• The current medium (github) does not meet the requirements for effective (technical) document collaboration.

Thus, before(!) extending the EIP process, one must take look for a better suited medium.

Moving the EIP to a new medium will eradicate several existent problems. There is a possibility that a new (and better suited medium) invites more contributor (editors).

[xinbenlv]

@lazaridiscom

The current medium (github) does not meet the requirements for effective (technical) document collaboration.

This is very good point. I'd like to dig deeper, could you provide if is there a link to doc/wiki/issue about what the known pain-points are about the github medium? Any discussion about improving EIP editorial procedure shall include that as reference. If one doesn't exist, can you start one?

[ghost]

@xinbenlv , here you go: #2187

(I'll add the github pain-points later at night when I need a break.)

[loredanacirstea]

@lazaridiscom , @xinbenlv can you please take this discussion to another PR/issue? Not on topic.

[edited]: ok, you did open a new issue before I posted, thanks.

[ghost]

Not on topic.

False.

[xinbenlv]

@lazaridiscom , @xinbenlv can you please take this discussion to another PR/issue? Not on topic.
[edited]: ok, you did open a new issue before I posted, thanks.

Agreed that this (tooling/medium of EIP editorial process) can take another issue that specialize in its own scope.

My impression is that overall there are consensus that editorial process needs a big improvement, including workflow, definition of roles, and tools. Some of the them are coupled to each other.

[ghost]

Agreed that this (tooling/medium of EIP editorial process) can take another issue that specialize in its own scope.

The thing is that "the process of spawning a related issue" is (naturally) always in-topic (or on topic).

Thus: "Not on topic" => False.

Thus: Intervention of @loredanacirstea => Irrelevant.

(Borg-Talk-Contest activated)

[Arachnid]

Your number 1. is irrelevant.
I do not need to know in detail how you are used to doing the process, in order to propose a better one. The only question here is: is my process better than the current one?

Of course you need to understand the existing process functions in order to propose changes to it. How else can you know if the changes you're proposing are helpful, or even coherent? How can you tell if your change is an improvement?

I honestly can't believe this is a point of contention.

B) EIP-1 has no process at all, the lack of clarity makes the editors a secret authoritative group with no clear way of getting in or knowing on which bases the current editors got in. A transparent process, however bureaucratic, is better than a closed-doors one. Help me improve it - what criteria don’t you like?

There's no 'secret group'. I agree, we could improve this with clear criteria for editorship, but for the reasons outlined above, your current suggestion is a long way from being useful for that. To try and solve the problem of "not enough editors", you propose a process that would make it very difficult to add new editors. Indeed, most existing editors would be either kicked out or restricted to only working on certain types of EIP if your proposal were adopted.

You do not meet your own criteria, in order to judge my proposal:

The criteria I proposed are for evaluating a proposed change to the EIPs process. I did not suggest they were universal principles.

However, I'm confident I did understand your proposal. I'm also confident that this change would make the editing process worse, not better. And what we're discussing on this PR thread is this PR, and whether it should go in; it's possible to reject a proposal as bad without being required to submit a better one for consideration.

Since you did not demonstrate that my solution is worse than the current process or a solution of yours, and two different processes cannot be equal, we reach the temporary conclusion that my process is better than the old one.

The proposal is absolutely worse than the status-quo, because it would make it almost impossible to appoint editors.

Still, what I can do is split my proposal into two parts:

Editor criteria with no mention of assigning editors to a PR
Editor assignment proposal
Is that satisfactory?

You're welcome to do so, but since I think both components are bad ideas that reflect a misunderstanding of how the EIP process works, I will not be in favor of either of them without substantial revisions.

Not on topic.

False.

Anything not related to the content of this PR is off-topic.

[ghost]

Not on topic.

False.

Anything not related to the content of this PR is off-topic.

Assessment rejected => #2172 (comment)

[Arachnid]

Your gnomic pronouncements about what you think is and isn't off-topic are also off-topic.

[ghost]

Your gnomic pronouncements about what you think is and isn't off-topic are also off-topic.

=> off-topic-loop detected

[xinbenlv]

Maybe off-topic, but I felt a bit heat in the debate. I'd like to remind everyone here regardless of sides of opinions or depths of understanding, these are all good-faith to make ethereum better together.

I also kindly suggest @loredanacirstea to make more efforts in trying to connect what you are proposing to the existing discussions of improving editorial procedure. These discussions exist and having more insights into them help you structure your proposal in a way easier clarifying yourself.

[pi0neerpat]

The current EIP editors are

• Nick Johnson (@Arachnid)

• Casey Detrio (@cdetrio)

• Hudson Jameson (@Souptacular)

• Vitalik Buterin (@vbuterin)

• Nick Savers (@nicksavers)

• Martin Becze (@wanderer)

• Greg Colvin (@gcolvin)

• Alex Beregszaszi (@axic)

This discussion is going is circles so I came in to say Can we please just get some editors up in this bitch Why isn't there a process for becoming an editor already? This shits supposed to be all open and decentralized, and yet here we are with only 8 gatekeepers. We don't need "clear criteria for editorship". Just start adding people when they make a PR to become an editor and get 3 editor votes. If people misbehave or aren't contributing in a positive manner then 5 votes you get kicked out. The fuck do I know though right? People just trying to contribute.

[ghost]

@pi0neerpat , you make it sound like it's really really big shit...

Though I understand your comment, it seems that the problem here starts with terminology.

"Editors" seem to be more something like "Judges", which need to have some deep knowledge and the brains (and an authority within the Ethereum Domain).

This shits supposed to be all open and decentralized, and yet here we are with only 8 gatekeepers.

To me it looks like the process is in the open. I could now start an EIP, get feedback, edit, get feedback, edit etc.

All seems quite fine.

(this my last response here. Github is simply the totally wrong medium for all this...)

Issue Template (here in the EIP repo)

https://github.com/ethereum/EIPs/issues/new

ATTENTION! If you would like to submit an EIP and it has already been written as a draft (see the template for an example), please submit it as a Pull Request.

If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive.

Keep in mind the following guidelines from EIP-1:

Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.

Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.

Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal.

[ghost]

(seriously, github is a joke, especially the issue-tracker... a pure tragedy)

[Arachnid]

"Editors" seem to be more something like "Judges", which need to have some deep knowledge and the brains (and an authority within the Ethereum Domain).

As I've been saying, this isn't how it works. Editors are not expected to have exhaustive technical knowledge of every proposed EIP; doing that is simply impractical.

[ghost]

I see.

I took the time to lookup the role:

Many EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
The editors don't pass judgment on EIPs. We merely do the administrative & editorial part.

source: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md#eip-editor-responsibilities

Thus, clearly, a simple process like #2172 (comment) describes should do it. Better yet: let people just do (e.g. do Editor work whilst filing PR's), reject/accept the PR's.

The folks that show talent in editing PR's gets invited to join the Editor club. This is more or less "standard-procedure" (OSS committers).

Zero need for complexity.

EDIT: still, i think the term "Editor" is a bit misleading, but that's another issue.

[pi0neerpat]

Zero need for complexity.

👍 Exactly

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.