Hey @abcoathup,
Great timing, I was about to ping you to ask about Working Groups , except your acd & breakout there isn’t much activity there. IMO, they should go under Protocol Calls & happenings what do you think ?
Would also love to discuss further site feedback with you !
@nicocsgy can you bulk change the categories of acd & breakout to Protocol Calls & happenings (otherwise I can change each one manually).
These are my experiments in sharing call summaries and other info.
It would be good to experiment with using banners/pins for upcoming calls, but suggest we take this to a separate topic so as not to make this topic noisy.
@nicocsgy i’m in CET for the foreseeable future, happy to set up a 1:1 time. More urgently/consensually, I was wondering (apologies if this is already stated somewhere, I got lost in the sauce):
multiL1 or multiVM in Working Groups, or is it better for multichain stuff to live elsewhere entirely (say, a separate Discourse server for multi-chain DAOs and CASA and the like)?New homepage with category breakdown is great, btw, saw it only AFTER writing the above (I tend to skip homepage and go straight to notifs). It really begs the question where AllWalletDevs go, because if ERCs is its own category, having AllWalletDevs be the only WG in Working Groups seems a little odd…
Great, will DM 
Not really, I just had protocol calls in the sorcerer proposal. Because it’s clearer than “working groups” and not everyone that wants to attend an ACD or Breakout wants to be part of a working group. For independent calls like AllWalletDevs / AllERCDevs they seem like nice examples of working groups. When there is an AllWalletDevs call it’s totally fine to promote it in the Protocol Calls & happenings category IMO.
Which one is the most active I don’t see much about AllWalletDevs here (I only find an expired discord invite) ? I’d like to rework the current Working Groups category as it is inactive, I see two ways:
The goal to me is to have a bunch of tags that go well with the working groups / subcategories in order to have informations streamlined to the right group of person.
Nothing against the chain agnostic stuff, IMO it doesn’t fit with the ethereum-magicians discourse. They could have their own discourse or a dedicated subcategory somewhere but I’m definitely not in favour of having to maintain multiple categories and tags for those.
It’s a chicken-and-egg problem, and no quick-fix will solve the historical disequilibrium between protocol discussions and wallet/app-level discussions. Furthermore, I think this community more than any other I’ve seen in FOSS has a real cultural hostility against the concept of “working groups” and open design/standards processes, which everyone considers bureaucratic a priori and “unnecessary overhead”. As for how active “the working group” is, most of the current PR activity on ethereum/EIP addresses wallet EIPs, and all the people working on those show up for AllWalletDevs calls to promote their EIPs and gather input from wallet devs, so it’s less a matter of inactivity than a matter of no one bothering to wave a banner over the activity calling it “working group” activity. I wrote a blog post about how much value is left on the table by not calling what we already have “Working Groups,” but I’m basically an old man yelling at clouds at this point.
In any case, here is a non-expiring DiscoRD link for AWD, which is actually a pretty active Discord considering how non-cooperative the market for wallets is to date. SamWilsn runs a pretty tight ship over there.
Big +1 on the chat logs being made available at the same time as the recording. I am personally less bothered about the transcript as would probably still listen but the chat logs are often difficult to follow along with on the video and contain a lot of relevant discussion.
Before Devcon, client teams held an R&D workshop with a session about process improvements for ACD, here are the notes.
Three concrete ACD process improvements emerged:
Declined for Inclusion status to Network Upgrade Meta EIPs, allowing core devs to signal an EIP should not be included in the current fork (but could be considered for future forks). Draft PR: Update EIP-7723: Add "Declined for Inclusion" by timbeiko · Pull Request #9056 · ethereum/EIPs · GitHubTo expand on (3), there are currently two failure modes in our process: we risk committing to more EIPs than we can realistically implement, too early in the process or we risk including EIPs in network upgrades “just” because they are implemented.
+One solution could be to formalize the transition from CFI to SFI to mean “these EIPs will be included in the next fork devnet”. This would allow anyone to propose an EIP for inclusion, client devs can then “shortlist” EIPs in CFI, but the CFI → SFI transition would be bottlenecked by our actual devnet implementation capacity.
Additionally, we currently use “devnet” to mean two different things: the pre-testnet hard fork testing environment (e.g. pectra-devnet-x) and single EIP devnets for testing. We should consider having a clearer distinction between these two cases, either by using a different term than devnet for one of them, or by making it more explicit that $FORKNAME-devnet-x is qualitatively different from a “feature devnet”.
Thanks for sharing. 
DFI, non-consensus changes in upgrade Meta EIPs and formalizing upgrade-devnets PFI/CFI/SFI relationships are all great improvements.
It would be good to open these sessions up more, such as allowing written submissions from the community prior to the event (such as an open call to submit on Eth Magicians).
Some thoughts on additional improvements to ACD I’d be keen to see.
Thanks for the thoughtful reply! Here are a few comments 
That’s an interesting idea, will consider it for next time! The reason I haven’t done that in prior iterations is that ACD’s capacity for change is fairly limited and I wanted to ensure we focus on the things that are most valuable to client devs. That said, having a more public “suggestion box” that we then go through with participants seems reasonable!
I oscillate between thinking this is a good and bad idea…! In the abstract, it’s obvious why ACD planning for a longer time horizon is a good thing. That said, in practice there are a few challenges. First, when we make commitments for what goes >1 fork in the future, we often end up changing them when it actually comes time to work on that fork. So, the commitments almost give us a false sense of certainty, which can be very dissapointing if you thought the roadmap was settled and it changes. Second, it’s not clear to me that ACD is the best group/venue to unilaterally determine Ethereum’s long-term roadmap. We should make sure the community is involved in these discussions and so I’m weary of having ACD be the Official 
place for “roadmap discussions”.
I think I broadly agree with your suggestions around the PFI → CFI/DFI → SFI cycle, but in practice we have to mainain flexibility because not everything goes according to plan!
The one bit I’d disagree with is the short time window for CFI to overcome issues. In practice, this sometimes take several months. ACD should do the “best” thing, not necessarly the “quickest” thing and it’s fine if spending months/years iterating on an EIP is the highest value thing to do.
If you make the time box 15-20m rather than 5, I agree! Given ACD operates at a (bi)weekly cadence, IMO there’s often value in discussing something that can get resolved in 10-20m. We don’t do it every call, and it depends on the agenda, but I think it would be worse to optimize for the shortest possible call and then kick decisions out to other venues that won’t necessarily get as much engagement. In generally, after 10m if we aren’t getting closer to resolving the issue I’ll usually propose we move the topic to a breakout.
I actually really like EthMagicians being the spot where we have summaries and action items! If there wasn’t as much friction with Github, I’d actually want to move the agendas here, too While I think it’s fine for most Ethereum code to be hosted on Github (as several ppl have local .git copies), I’m uneasy with having our process depend on “Github artifacts” such as PRs, Issues, etc.
Right now, I still think the friction outweights the value of moving from Github, but I could be convinced otherwise.
How should we do this automagically? @nicocsgy @poojaranjan could we just have an AI notetaker on the call that posts the transcript to an EthMag thread?
@abcoathup Just want to highlight your community idea. I’ve proposed the idea of a non-binding feedback mechanism before because I think it’s an oversight that there is no way for the wider community to express what it wishes to see the focus on (e.g. ‘we should focus on UX, privacy, etc.’). It would also provide Core Devs with something like a basic barometer, ‘we’re interested in X but everyone else wishes we focused on Y.’
Probably this could be a simple website with a submission form since, for whatever reasons, people don’t feel confident posting on here or advocating for themselves through the more formal processes.
@polar there isn’t (currently) a specific place for community suggestions/discussion here on long term roadmap. It would be good to do something for this coming up to Fusaka upgrade planning.
There are discussion posts in Eth Magicians for each upgrade that anyone can post to:
EF Research AMA on Reddit is generally a great place to ask questions about the research vision.
https://www.reddit.com/r/ethereum/comments/1f81ntr/ama_we_are_ef_research_pt_12_05_september_2024/
Devcon had: Ethereum Magicians Infinite Endgames Session @ Devcon SEA
An Ethereum 2025+ survey/input from the community could be interesting. If you are interested we could create a discussions thread on Eth Magicians to flesh out what to ask.