How do we address editors being overworked with a better governance method and what does it look like?

[kdenhartog]

@sbacha

Why cant the foundation provide a grant? Can it not offer ETH to stake to provide for self funding for this? It has done so with the client teams.

I generally think we will need to get to that point as well. Something interesting about the W3C is that they have a small team of full time staff and then for the rest of their team, they’ve got fellows which are paid by W3C members (who are their employers) but spend 80% of their time just doing W3C related work.

@sbacha

I think maybe a better volunteer application process would be beneficial. As it stands its kinda opaque and could benefit potentially by having open interviews during a special office hours session quarterly maybe?

For me I don’t think the answer is that we need more editors, but rather that we should distribute their responsibilities to more people. From a governance perspective this is also useful because it decentralizes the power placed in any one role within the standardization process.

@TimDaub

Having had conflicts with EIP editors, I think one problem is also that their job is to criticize a submitter’s proposal, and while this makes it eventually better (I appreciate all EIP editor’s critique), this giving of feedback will inevitably lead to feelings being hurt too. Do people see this as a real problem, or am I off here?

Personally, I think feedback is a feature not a bug (which I’d guess is your believe as well @TimDaub), but with that said I think the only real feedback within the process which has the power to affect the standard is the editors which is more of a bug than a feature. A standardization process is to meant to establish consensus, usually by way of controversy, and feedback is necessary to achieve that in my opinion. If there’s no one providing feedback then the specification probably isn’t well suited as a standard.

@TimDaub

We once practiced Holacracy, and one key tenant was that mediators must always focus on executing the process and not voicing their subject-matter opinion. E.g., I had EIP editor fights over ideas I brought to fruition as EIPs, but these could have been avoided if the EIP editor had strictly reviewed for form and not the proposal’s idea(ls).

In that way, an EIP editor would only help EIP submitters over the finish line towards getting things merged on GitHub (by criticizing form, e.g., “You must add a security section,” "you must use the form “ERC-XXX”), but all subject-matter critical feedback (e.g., “you shouldn’t propose this standard because it is immoral”) would actually come from other Ethereum community members. Dunno, just an idea.

I agree this is a problem. While I understand that all of the EIP editors today have good intentions and operate in good faith we can all find ourselves at times tied to a particular idea, solution, or way of doing things. I know I’ve encountered this numerous times when working on standards.

With that said, I think it’s important for editors themselves to recognize which “hat they’re wearing” when providing feedback. It should be OK for them to provide subject-matter opinions and feedback, but it’s not OK to use their editor capabilities in order to block proposals from moving through the process. That is a conflict of interest and a corruption of the role and I believe should be grounds for removal if it becomes a repeated issue. Unfortunately, while that is ideal and the way it’s handled in other standards organizations we’re not there yet with the EIP process because we lack in contributions from others in the Ethereum community these days on many EIPs. This is either an indication that some things just aren’t ready to be standardized or that the process has pushed people away from contributing. I believe it’s actually a bit of both. For this reason, the lines can become very blurry when the editors are the only ones commenting and providing feedback on EIPs. In nearly all the cases I’ve seen they’re doing this out of best interest of the community and to help start the discussion with thoughtful feedback. I don’t believe it always used to be editors guiding the discussions and being lead contributors in feedback though. For example, look at the liveliness of discussion that occurred around EIP-1098 with 25 different participants. Similarly there were some great discussions around EIP-1193 and I’m sure there was plenty round EIP-712.

This is all to say, I think that we’re at a point where it’s necessary for us to evaluate what’s the right way to split up the work that editors take on. Not only to help reduce the time and effort they have to spend in volunteering, but also because this will help get more people involved and decentralize the power to create a more robust process.

Proposal

In my opinion we should be splitting out the responsibilities into 3 separate roles. A WG to manage the governance process (EIP-1) and maintain the bots, a role I’m calling an “Area Director” which helps to establish whether a WG should be formed or a proposal should be tied into an already running WG, and a role which helps to manage a WG called a “WG chair” who’s there to maintain the WG and make sure work items and proposals are moving towards completion. We’d then also have EIP Authors which remain the people driving a proposal forward to completion.

With these new roles, I’d imagine the process for moving a proposal from draft to completion would look a bit like this.

1. Put forward a proposal to draw feedback and decide if it should be standards track or informational
   • preferably this step is actually done outside the EIP repository to increase the noise to signal ratio
   • it’s up to draft authors to gather enough attention to get a WG formed. This could be done via area directors helping to promote group on FEM or on twitter so they can determine if now is a good time to start the standards process for a particular item of work.
   • Things can sit in “idea” stage form indefinitely. These are essentially like internet drafts in IETF
2. Once the area director has determined a WG should be formed (or assigned a piece of work to a WG) then the idea is converted to the “draft” step and moved into a GH user (e-g EIP-Core or EIP-ERCs) focused on a particular area. It’s at this point that the iterative design process begins by forming a repository for the proposal, filing issues, and updating the spec. There should probably be re-occurring discussions or at least some way to separate feedback to make sure that all of the concerns are being addressed.
3. Once a draft is believed to be at a fairly stable state, it should enter a review period which should include a call for implementations and a test suite or reference implementation should be built ideally to make sure the spec is actually able to be implemented by multiple people and no interoperability concerns are left unaddressed.
4. Finally, once the authors, WG chair, and area director believe the spec is at a state where we’re close to consensus we can enter the “final call” period. At this point any last objections will be required to be lodged within a 2 week window and be addressed within a 4 week window from the point they’re addressed.
5. Once confirmed they’d be finalized and moved into the official EIP repository. At that point only errata can be filed to modify it which would need to be done via the WG that moved it forward (or a maintenance WG for that).