Add Audience Review process to EIPs prior to Last Call

[fubuloubu]

This PR adds a "Key Stakeholder Review" process that all PRs go through, after a Draft is considered ready to Review, and prior to it entering Last Call (aka "public request for comment").

In the post-mortem for the aborted Constantinople fork that was set to occur on Jan 16, 2019, it was recommended to:

Create a more formalized process for reviewing and analyzing EIPs

This process change suggests "substantial internal review by relevant stakeholder groups" occur before a suggested change is brought to the wider community for final discovery of any issues with the proposal. During Draft, stakeholder groups are suggested by EIP editors and anyone else participating in the conversation. The list of stakeholder groups is TBD, but should be compiled from active discussion groups focused along a particular topic that meets on a regular basis such as FEM Rings. When moving from Draft to Review, the editor will contact and record meeting dates where the EIP is set to be discussed (if those stakeholder groups have not done so already).

During Review, stakeholder groups will discuss and provide feedback from that discussion, as well as the consensus recommendation of the group. When all groups have given their feedback, and the feedback is a GO, it will move to Last Call to solicit any final feedback the community might have. If a group chooses not to give feedback (or feels like they don't need to), they can leave "no comment". If a group forgets to or chooses not to give feedback, we can discuss what happens in that circumstance.

---

Stakeholder Group Requirements:

• a stakeholder group should have a clear summary of what types of issues they review
• a stakeholder group should have a regularly scheduled meeting, as well as participation information
• a stakeholder group should ideally have a main point of contact

This information should be displayed publicly so that community members are aware these groups exist (and can join them!). These groups should also be made available as tags, so that relevant stakeholders can easily filter on items with their particular tag in the right status for discovery in case the editor forgets to contact them.

---

The primary motivation behind this change is to ensure that a more focused review occurs on all EIPs, in order to solicit the most amount of feedback before bringing it to a Last Call review. This will prevent substantial wasted discussion or a lack of review from relying only on a general, public review (which may not occur to the level of risk present in the proposal).

Some relevant background material:

• https://ethereum-magicians.org/t/decentralizing-eip-workflow/1525/7
• https://ethereum-magicians.org/t/proposal-add-ring-tags-to-eips-solicit-comments-from-ring-s/1592
• Proposing a revised process for handling of EIP drafts #956
• Add new two-week review process to EIPs #1100
• https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d
• https://github.com/trailofbits/publications/blob/master/reviews/EIP-1283.pdf

[fubuloubu]

cc @GregTheGreek @siromivel

[fubuloubu]

Maybe call it "Audience" instead of "Stakeholders"

[Arachnid]

I like the premise of requiring explicit stakeholder groups to be included, and of open rules for defining what one is.

However, does this need to be a new status? Couldn't a requirement for entering 'last call' be that it's already been reviewed by a stakeholder group, and a requirement for 'final' be that the stakeholder group was given an opportunity to raise objections during 'last call'?

[fubuloubu]

That is an option. My idea behind the status was to reduce noise for the stakeholder groups by creating a more formal step to ask for their review. It's important for a proper review that the draft proposal be in a "finalized" state so that the intended audience doesn't have to waste cognitive energy on potential revisions without a reversion of status back to draft.

I'm definitely flexible on this however.

[GregTheGreek]

+1 to changing stakeholders -> Audiences

[siromivel]

I agree that garnering input from key stakeholders/audiences makes sense as a pre-requisite to entering the last call state - to my mind the last call should be a final firestop to catch unintentional side-effects or other oversights prior to inclusion in the protocol. I would place the onus on the authors to ensure that the proposal is fleshed out enough prior to submission for parties' impacted by that proposal to reasonably assess the impact on their domain and provide relevant input/revisions.

[fubuloubu]

There seems to be some consensus on defining this Audience feedback step to be a part of the Draft stage (prior to a move to Last Call). I agree that the Authors should be involved in garnering this feedback, reducing effort to EIP Editors. The subgroup information being made public is an important part of this process, to ensure that the relevant Audience subgroups remain accessible to Authors.

Does this make sense?

[GregTheGreek]

I brought this EIP up at ETHMagicians in Paris, I'm not sure who took notes but I think there was some good insight. Will look for it.

[bmann]

@GregTheGreek came up in the EIPs workshop. See https://ethereum-magicians.org/t/eips-ecosystem-standards/2835 — I’ll link back to this.

[GregTheGreek]

What happened to this?

[fubuloubu]

We discussed the path forward on this a bit in https://ethereum-magicians.org/t/definitions-of-governance-layers/3054/14

Seems like the next step is to qualify the need for this proposal by refining it through the Core Devs process and make sure we have alignment on the path forward.

[axic]

I think this looks like a good idea, just not sure it should be solely and editor's responsibility to steer the review period. @fubuloubu are you still pursuing this?

(Edit: typos)

[fubuloubu]

Loosely. In random conversations about the EIP process, especially around security review, I always end up touching on this. Some people even bring it up unprompted. It just always seem relevant, and everyone seems to like the concept (but not necessarily my execution specified here though).

Here's the latest example: https://ethereum-magicians.org/t/progpow-audit-delay-issue/3309/33

---

I do think it needs to be rewritten to better account for how the process could work more seemlessly.

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