Early and Aggressive Scope Freezes
We support a stronger commitment to early scope freezes. Scoping out fork N+1 while N is being shipped, and freezing N+1 when N is shipped sounds like a good framework. Although there should be rare exceptions for critically important features.
Governance and Call Structure
We think separating “scoping/roadmap” discussions from deep technical dives could streamline the process. This would work will with the parallelization of fork N+1 scoping and fork N development. The technical calls should probably still maintain the CL/EL division, but the scope/based calls probably should not. In this model, or even in the existing model, more forceful moderation on topic direction would help.
Steering committee
We’re cautious about adding bureaucracy and believe many of the benefits could be reaped by separating scoping from technicals calls, and harsher moderation.
Frequent Forks
Although each fork introduces process overhead, we hope we can make this more efficient. Parallelizing fork N+1 scope with fork N development reduces per-fork overhead. More frequent forks will also relieve pressure on getting EIPs in for fork N if N+1 doesn’t lag as far behind.
Finding a “North Star”
Without a unifying milestone like the Merge or Withdrawals, it’s not always clear what to prioritize. We see the next big push as PeerDAS. The “beam chain” is a bit further down the road. In between there is uncertainty about which EIPs or improvements should take precedence. A bottleneck here, is the huge amount of work it is to stay abreast of all research work, and with enough depth to have informed opinions. We believe more structured polling or active outreach to teams could help break this gridlock.
Slow-Client Delays
There is some threshold after which we must move forward without a client. This would have a major impact on users of this client and migration path for them should be made available. We will also need to weight the landscape of client diversity after this client is dropped. However when we’ve reached thresholds of “client diverse enough” with a low-enough impact on users, we should move forward.