Thank you for the thoughtful post, @philknows!
I agree with your overall assessment that we need to be better at coordinating “external stakeholders” within the ACD process, and what the overall goals should be. Once we have a clear outline for the process, we should add it to ethereum/pm. The repo is very much due for an overhaul which I’ve failed at prioritizing.
A few thoughts on your specific questions:
Where should contributors coordinate their support?
IMO it’s ~impossible to mandate that a distributed community like ours would coordinate on a single place to voice support. That said, I think we can put the onus on an EIP champion to aggregate all of it in a single place.
Previously, I tried doing this on EthMagicians by using $fork-candidate tags (shanghai, cancun).
While some good came out of it, such as the EIP-1153 proposal thread, it wasn’t used consistently enough for EthMag to be the canonical place to track all proposals.
I had to maintain a separate list, which lived outside the hard fork meta EIP, resulting in three places where this information lived. As a minor improvement to this, I proposed adding PFI to Meta EIPs. For future forks, I think it’s reasonable to ask EIP champions to open a PR against the HF Meta to propose their EIP be PFI’d.
To simplify things, my proposal here would be that when someone PFI’s an EIP, they add a link in their PR to an EthMagicians thread that tracks support, adoption, etc. for the EIP in the first post. By default, this should be the discussion-to thread, but in cases where the champion does not have access to the original thread (because they weren’t the main author), it could be a new one, like in the case of 1153.
Assuming people are on board with this, we could update EIP-7723 to describe this process, and/or link that in ethereum/pm.
I disagree with a few of your priorities here, namely:
- Encouraging updates: this can be done in large part async. I think we should only briefly cover “updates” on the call and reserve more of it for discussion that has to happen synchronously.
- Encouraging summaries: again, I’d lean towards async summaries and having the call go into some questions/comments on those.
- Discouraging technical debates or PR/EIPs discussion: I think, when done well, this is actually one of the most valuable functions of ACD. Sometimes, spending an extra 5-10m debating things live on the call can save us a 2 week async iteration cycle. It’s a hard balance to get right, but overall I think we’ve gotten better at moving things to breakout rooms when they digress too much.
That said, one thing we can probably do better to maximize signal is be clear on the agenda what the expectation is for each conversation point (e.g. Introduce vs. Discuss/Debate vs. Decide).
Agreed with everything here, and one thing I’d make explicit is that anyone running breakouts or working on an initiative that affects network upgrades or the short term L1 R&D roadmap should attend ACD by default.