EIP-1 - addition to "EIP Editor Responsibilities"

[loredanacirstea]

This is an addition to EIP-1, regarding the EIP Editor Responsibilities, to avoid editors being a bottleneck for merging EIP Draft proposals, that can even be due to lack of time.

It mentions a process of appointing another editor to continue the job if the current one is unable to do so. It adds a maximum period of time that can pass between opening an EIP PR and a first editor review. If this is passed, it is a clear sign of a bottleneck. The editors' composition should be reevaluated and new editors must be added if lack of time is the cause.

30 days has been chosen because it is the default period for most government processes. Other suggestions are welcomed.

This proposal also signals the need for an EIP Editor Criteria section, to add more transparency to the process used to appoint new editors. This is covered in #2172

[pi0neerpat]

Would setting a deadline have the unintended consequence of increasing the average time to merge? If the deadline is 30 days, then would all PR reviews take 30 days?

[loredanacirstea]

@pi0neerpat , the intention is to not let PRs stay for months without any review from editors. I mentioned a maximum amount of time, so this should not affect the minimum limit of how fast PRs get reviewed or merged. Let me know if I was unclear in the proposal phrasing & you can suggest improvements.

[Arachnid]

I think this reflects a misunderstanding of the EIP process. Drafts do not have assigned editors; editors are volunteers and pick up tasks as they can.

Also, unless you're going to start paying us, I don't think it's exactly reasonable to try and demand am SLA.

[pi0neerpat]

No need for pay. Instead add reviewers to reduce the burden and speed things up.

But also a good point- why aren't reviewers being paid? Everyone should be getting compensated 💰

[Arachnid]

No need for pay. Instead add reviewers to reduce the burden and speed things up.

Who adds these editors? How are they selected? Do you need a second rule that adds more editors if it takes too long to add editors as a result of the first rule? How is this rule enforced?

[xinbenlv]

I think both sides have reasonable arguments.

I'd like to add some hopefully relevant input to provide (maybe?) useful context.

• Status of Abandon is created here in ethereum/EIPs Introduced Abandoned status in EIP-1 #2051
• FYI: BIP-0002 says 3 year.

BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.

• An interesting case: an editor tries to reject BIP-0047 and response was "we have adoption, so we don't care if BIP-0047 makes into BIP or not." (Reject BIP-0047 (no progress in three years) bitcoin/bips#790).

[loredanacirstea]

@Arachnid ,

I think this reflects a misunderstanding of the EIP process. Drafts do not have assigned editors; editors are volunteers and pick up tasks as they can. - #2166 (comment)

I understand the current EIP process documents. I do not agree with your interpretation of them.
I quote from EIP-1:

For each new EIP that comes in, an editor does the following:

What does “each” mean to you in this context? For me, it means: every single one should be caught by the review process at any moment in time.

Volunteering must provide at least the same quality of service as a for-profit (I have > 4 years of volunteering experience tech/non-tech). Volunteering is the basis of open source.

Also, unless you're going to start paying us, I don't think it's exactly reasonable to try and demand am SLA. - #2166 (comment)

If needed, I will pay. What is the rate?

Who adds these editors? How are they selected? Do you need a second rule that adds more editors if it takes too long to add editors as a result of the first rule? How is this rule enforced? - #2166 (comment)

It seems that you are asking: "How did I become an editor?".

But now I have an answer to your question: #2172. I think you meet the criteria to be an editor through your technical achievements.

Feedback appreciated from current editors & community.

@xinbenlv ,

Status of Abandon - #2166 (comment)

Yes, the above focuses more on the author's responsibilities, which are very important. My proposal focuses on EIPs left unreviewed by editors, without a clear priority queue or deadline.

[Arachnid]

I understand the current EIP process documents. I do not agree with your interpretation of them.
I quote from EIP-1:

For each new EIP that comes in, an editor does the following:

What does “each” mean to you in this context? For me, it means: every single one should be caught by the review process at any moment in time.

Yes, every EIP should be processed. That doesn't mean each EIP is assigned a dedicated editor.

Volunteering must provide at least the same quality of service as a for-profit (I have > 4 years of volunteering experience tech/non-tech). Volunteering is the basis of open source.

That's a nice aspiration to have, but we don't actually have any mechanism to achieve that.

It seems that you are asking: "How did I become an editor?".

No, I'm saying you are proposing a change that says "an editor shall be added", but doesn't explain how we find, vet, or add these editors. If we had a list of would-be editors waiting, we'd add them now. Why would we wait until a crisis occurs?

[loredanacirstea]

@Arachnid ,

Yes, every EIP should be processed. That doesn't mean each EIP is assigned a dedicated editor.

How else can you ensure that every EIP is processed if no one feels responsible for it?

No, I'm saying you are proposing a change that says "an editor shall be added", but doesn't explain how we find, vet, or add these editors.

In my previous post I linked a process for adding new editors: EIP-1 - add EIP Editor Criteria, so now, I do explain. If you have objections/suggestions, please comment on that PR.

If we had a list of would-be editors waiting, we'd add them now.

There is a PR made by someone who wanted to become and editor: #1558. It was left unanswered for months. I understand why that might be: there is no current process to add editors and no one wants to assume personal responsibility.

Why would we wait until a crisis occurs?

I agree. We shouldn’t. The deadline acts as a signal to action and action should start now.

[Arachnid]

How else can you ensure that every EIP is processed if no one feels responsible for it?

It's volunteer work, and people pick it up as they have time. EIPs do not have assigned editors. You may think they should, but that's not currently the case, and your proposed change seems to assume it is.

I agree. We shouldn’t. The deadline acts as a signal to action and action should start now.

The 'consequences' of missing the deadline in your proposed change are to add an editor - but there's no plausible situation in which we'd have an editor waiting to be added that we don't just add immediately, regardless of deadlines.

[xinbenlv]

Agree with @Arachnid that it's volunteer work and a SLA will be hard to impose.
I also totally agree with the OP and @loredanacirstea etc the need of a set expectation of time of processing EIPs. It benefits the Ethereum community as a whole.

To start a constructive discussion, may I propose several potential solutions to the problem:

1. Curate a process of admitting new editors.

For example,

• allow contributors to this repository to start self-nominate or nominate people who have provided valuable feedback, to apply to be editor-candidate.
• publish in the EIP-1 of what's expected criteria to become an editor.
• whoever are editor-candidate can get to work in pair with editors in reviewing new EIPs. The editors group set a goal of periodic (maybe monthly) review the readiness of new Editor-candidates and admit them into the editors group.

2. Curate a process of reviewing EIPs before editor review
   For EIPs at Last Call or getting close to Last Call, suggest a voluntary signup of contributors to review their EIPs before recommending to an editor review. The benefit is if the EIPs amount is large, it helps editors to prioritize those more ready for review.

3. Setting a rotating role of Editor-on-Duty and triage incoming EIPs of different stages to Editors or Editor-candidate.

I'd also suggest we start to motivate people to contribute to reviewing EIPs by encouraging authors to acknowledge the help they received from editors or other volunteer reviewers they think valuable in their EIPs.

My 2 cents.

[loredanacirstea]

@Arachnid , #2166 (comment)

EIPs do not have assigned editors. You may think they should, but that's not currently the case, and your proposed change seems to assume it is.

The current EIP-1 says: "For each new EIP that comes in, an editor does the following: [...] Once the EIP is ready for the repository, the EIP editor will: [...]"

It details a process that the editor has to follow. It says "an editor", "the editor", which means the editor who chooses to review that EIP. If you understand that multiple EIP editors can mix in over one another and review / merge an EIP, you should make a PR to change the EIP-1 wording.

The 'consequences' of missing the deadline in your proposed change are to add an editor - but there's no plausible situation in which we'd have an editor waiting to be added that we don't just add immediately, regardless of deadlines.

It means that editors, EF, community should do public calls that editors are needed. And I am showing that they are. If there are no public calls, it means that you do not want new editors.

There is now a plausible situation: have you forgotten about #1558? You have not answered.

@xinbenlv, I have started a process for admitting new editors: #2172. Let me know what you think.

[Arachnid]

@xinbenlv I think these are good ideas. For #2, I would love to see this work devolve to Ethereum Magicians rings. If that were the case, while EIPs outside rings could still be accepted, editors could push people to seek adoption by a Ring first, rather than doing direct to the editors. This is again similar to how the IETF handles things.

Last Call is also supposed to make review more of a community effort; by requiring authors to seek and integrate feedback, it makes the editors' task the simpler one of checking if feedback was solicited and responded to properly, rather than exhaustively reviewing the EIP themselves.

The current EIP-1 says: "For each new EIP that comes in, an editor does the following: [...] Once the EIP is ready for the repository, the EIP editor will: [...]"

It details a process that the editor has to follow. It says "an editor", "the editor", which means the editor who chooses to review that EIP. If you understand that multiple EIP editors can mix in over one another and review / merge an EIP, you should make a PR to change the EIP-1 wording.

I don't think the text says what you think it does here. There's clearly no assigned editor for an EIP; that's not said anywhere in the text, and it's not how things operate. Editors pick up PRs as they're able. I don't need to propose a change to EIP 1 because that's already how it works.

I'm also not sure how you think having assigned editors would help here.

It means that editors, EF, community should do public calls that editors are needed. And I am showing that they are. If there are no public calls, it means that you do not want new editors.

Then you should detail in your PR what it is you think should happen in this case.

[xinbenlv]

@Arachnid

For '#'2, I would love to see this work....

At first I think you refer to issue #2 which confuses me a bit. And then I realize you probably mean my suggestion.

2. Curate a process of reviewing EIPs before editor review

I'd suggest you to use (2) instead of #2 because Github will pick it up.

Content-wise, I am convinced by your argument. In particular, I quite like the idea

Last Call is also supposed to make review more of a community effort; by requiring authors to seek and integrate feedback, it makes the editors' task the simpler one of checking if feedback was solicited and responded to properly, rather than exhaustively reviewing the EIP themselves.

[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.