---
tags: ACD
---

# ACD's Thoughts on ACD

Over the past 2 weeks, I've had conversations with various client teams and ACD participants to gather their feedback about AllCoreDevs. Here is a summary of the feedback I've received, along with some proposals based on it. Feedback is roughly ordered by frequency, but note that the sample size is quite small (<10 conversations total).

This first round of feedback focused mostly on core developers, given they are the main attendees of the calls. I'm planning on doing another round with a broader set of attendees (e.g. EIP champions) soon. If you'd like to be included in that, please ping me (`@timbeiko` on Discord & Twitter). Otherwise, I'll look at past attendee lists and pick out some people from there :eyes:

## TL;DR
* The general feeling about AllCoreDevs seems to be that "it's inefficient, but it works";
* While there was strong agreement that most hard/controversial decisions should be made on ACD, almost everyone would like the calls to spend more time on technical matters that client devs are concerned about;
* There was general agreement that it is "too easy" to bring up an EIP repeatedly on ACD;
* Most respondents would like a better view into the requirements for the Eth2 merge, and the longer term roadmap more generally.

## Proposed Next Steps

- [ ] As Berlin gets wrapped up, have 1-2 calls to discuss the Eth2 Merge and longer-term roadmap before starting to plan the next HF;
- [ ] Instead of having only the next call's agenda available, open the next ~3 months' agendas in advance. Schedule "important but not urgent" topics in advance, and identify calls on which we expect decisions to be made, so people can attend what matters the most to them.
- [ ] Discuss the following on ACD:
- [ ] The "bar" we require to discuss EIPs on the call, both for the first time, and repeat;
- [ ] ACD Code of Conduct ("Be Excellent to Each Other"?)
- [ ] ACD "Mission Statement" ("Ensure the Security & Long Term Sustainability/Viability/??? of Ethereum"?)

## Aggregated Feedback

*Note: "quotes" below are paraphrased, not verbatim quotes.* See the "Suggestions" section below for suggested improvements.

### ACD's Role

1. The goal of AllCoreDevs should be to improve Ethereum over the long term.
* "We should consider long-term benefits over short-term concerns."
1. AllCoreDevs should represent AllCoreDevs, and not the entire community. ACD should consider security risks to Ethereum first and foremost (and factor in the community's potential actions as part of that), but beyond that, the community should decide if they want to upgrade their nodes or not.
* "We need to set better expectations with regards to the importance of securing the network over generation of rewards for miners or stakers."

### General

1. It would be good to have more focused calls on specific topics (ex: snapshot sync, p2p, eth2 merge, etc.), and even to split the "technical" calls from "coordination" ones.
* "We're seeing ACD "splinter" which is a good thing. The scope has grown, and we can't manage everything in ACD directly."
* "Different people have different goals for the calls: some come wanting to discuss very technical topics, others politics, others just coasting along."
* "We do not discuss "existential threats" enough on the calls (state growth, MEV, etc.)."
* "We should be more aggressive about pushing things out to breakout rooms."
1. The calls are quite boring, especially compared to other calls in the ecosystem.
* Lots of repetition in meetings. Going over same topics over & over.
* The calls used to be more technical.
1. The calls are quite pleasant, especially compared to other calls in the ecosystem.
* "The calls feel more relaxed than Eth2 calls."
* "People are professional, nice, and funny."
1. We need to make it clear what the venue is to take a controversial decision.
* "The calls are stressful when controversial topics come up."
* "Lots of avoidance for controversial topics."
* "Breakout rooms are useuful to hash out technical details, but not to make controversial decisions."
1. We need to think about how to merge the Eth1 & Eth2 calls.
1. We should have a code of conduct for the calls, even if it is as simple as "Be Excellent to Each Other".
1. It would be good to have an alerting system to ping core developers when something very bad happens. Right now, some client teams only have access to `[e-mail]`.
1. We should find ways to improve intrapersonal relations between people on the call.

### Effectiveness
1. It is very hard to make forward progress on topics being discussed.
* "Unclear how we find consensus on issues that affect multiple stakeholders, especially when they have contradicting preferences."
* "We don't make much progress resolving fundamental disagreements about EIPs on ACD calls."
* "We need to stop 'lobbying by bikeshedding'."
* "AllCoreDevs manages to get the easy logistical stuff done, while not addressing the harder things."
1. On Eth1 calls, Hudson's role is closer to a moderator, while on Eth2 calls, Danny's role seems more focused on pushing things forward.
* "It would be good to have a more technical leader who shows the direction."
* "Hudson's approach is better, because it gives clients more flexibility in the roadmap."
1. We should make it clear in advance when a decision will be taken during a call. When a significant decision is to be taken, we should reach out to client developers in advance to make sure they are aware.
1. There is no good way for stakeholders to interface with core devs.
* "Some changes that made it into hard forks (e.g. `BLAKE2b` precompile) ended up not being used, and were pushed forward despite people on the calls raising objections to them, seemingly because they were "already in" a certain upgrade."
* "Mailing lists or better focused sections in Ethereum Magicians would help discuss things async."
* "Engagement is low on async channels like EthMagicians."
1. Not having a longer term roadmap makes it hard to assess priorities and progress.
* "We should consider our "existing backlog" of work more when judging new proposals."
* "It would be helpful to agree on and have a visualisation of a longer-term roadmap."
* "Unclear what is the order of precendence between various roadmap items."
* "We should have major features drive specific hard forks. For example, EIP-2929 drove Berlin, EIP-1559 likely to drive London, etc."
1. We have several mainnet clients now and we should think about how to incentivize delivery to avoid being slowed down by the slowest teams.
* "Not having that many EIPs to work on can be good: it allows clients to work on other important things on their roadmap."
* "We should get clients to provide more visibility about how long they expect various initiatives to take."
1. There is no accountability in the process. It is not clear who owns what and how they are accountable for it.

### EIPs Process

1. There should be a higher bar to discussing EIPs on ACD calls.
* "Only discuss them where there is an open PR for implementation."
* "We should require a prototype showing how the EIP will be useful that people can play with."
* "If EIPs don't have a prototype or something else people can play with, they should require the +1 from a core developer to be discussed on the call."
1. The EIPs process was not created at a time when there were several controversial EIPs.
* "Our current process is to not include things that are controversial, which most of the time doesn't cause harm."
* "We lack a mechanism to make controversial decisions."
1. "Accepted" is a bad term. We should change it to "Technically Sound" or something similar, to better reflect the type of evaluation that ACD does for EIPs.
1. It is hard to gauge how important some of the EIPs are. Aside from champions, it's not always clear that a large amount of users want these features.
* "If EIP-X is so important, why isn't anyone chasing us to ship it sooner?"
1. We need to proactively address "what happens if this breaks" when introducing new EIPs.
1. It is hard for core developers to comment on things they are not experts on, both from a technical and ecosystem perspective.

### Roadmap Priorities

Answers to "What should be our priority for the next 12-18 months?", ranked by frequency of mentions.

#### Multiple Mentions
* Eth2 Merge (5)
* Flat Database Support (2)
* Snapshot Sync (2)
* EIP-1559 (2)
* Statelessness (2)

#### Single Mention
* BLS support
* Difficulty Bomb
* EIP-2935
* Gas Prices
* Addressing MEV
* Improving network stack
* Making it easier to build a client from scratch
* Removing features from the protocol

## Full List of Suggestions

I've tried to map these to specific feedback points above. To be clear, I think "AllCoreDevs" should decide on which of these suggestions are worth implementing.

Feel free to leave comments with other suggestions and I will add them to the list!

### ACD's Role

1. Have an explicit "statement of purpose" for AllCoreDevs, making it clear what decision the group is comfortable or uncomfortable taking. Some thoughts:
* Security is the #1 consideration;
* Long term benefits over short term concerns;
* ACD package the software, but its up to the community to adopt it or not.

### General
1. Have ACD agendas planned for a longer time horizon (3 months?) and assign specific topics to calls in advance (ex: Eth2 merge, P2P, new EIPs, etc.).
2. Make it clear in advance, on the agenda, if a decision is expected to take place during a call. Ping client developers in advance.
3. Keep ACD as the place where hard decisions get finalized. Use breakout rooms to try and move things as close as possible to a decision, but have the final decision be made on ACD.
4. Have a simple code of conduct, "Be Excellent to Each Other", and remove people who don't follow it from calls/chat/etc.
5. Review security channels and make sure everyone is in the appropriate channels, create new ones if needed.
* Perhaps have a breakout room about this?
7. Set up casual chats between ACD participants, kind of like [Donut](https://www.donut.com/).

### Effectiveness
1. Keep having breakout rooms as soon as things end up taking a significant portion of ACD calls. Report back to ACD when a decision has been made.
2. Fund a "community liason" role within ACD, who is in charge of gathering feedback from the community for various EIPs and presenting it back to ACD.
3. Spend 1-2 ACD calls discussing the high level roadmap for the next ~12 months. Try and align on the big requirements, upgrade cadence, etc.
4. Spend 1 ACD call discussing what clients' biggest blockers to make progress are, and exploring how we can fix it.
5. Tim to reach out to client teams individually to discuss (4) instead of doing it on ACD.
6. Make it clear in the ethereum/pm repo who owns what, and how to contact them.

### EIPs Process
1. Require EIPs to either have (1) an open PR against a client implementation, (2) a prototype or (3) a +1 from a client developer to be added to the ACD agenda.
2. Have a specific subset of each call, or a subset of calls, where new EIPs get discussed, rather than being the default "first thing on the agenda."
3. For controversial EIPs, see (2) + (3) of the "General" section above.
4. Change "Accepted" to another term that better aligns with the type of review core developers do.
5. When adding EIPs to network upgrades, determine in advance how we will respond to different types of failure modes.
* Perhaps this should be part of the network upgrade process?

### Roadmap Priorities

1. Use the list above to help with the conversation mentioned in (3) of the "Effectiveness section": *"Spend 1-2 ACD calls discussing the high level roadmap for the next ~12 months. Try and align on the big requirements, upgrade cadence, etc."*