Title: AllCoreDevs__Network_Upgrade___EthMagicians_Proces
Category: Magicians

Author: timbeiko
Date: 2024-05-29T15:38:44.043Z

ACD & Process Improvements
June 19 update

NUP Proposal 1: PFI, CFI, SFI: drafted EIP-7723
NUP Proposal 2: EIP Review Tracker: proposed a discussion-to template

Original Post
Following from the Nyota ACD Process Breakout, here are some specific proposals to improve AllCoreDevs, the Network Upgrade Process and Ethereum Magicians. Each of these are the result of several individual and group conversations, but everything below was authored by me and should not be assumed to already be endorsed by anyone else as-is.
ACD Calls
Given the relatively short duration and large attendance of ACD calls, we want to prioritize high-context conversations that are relevant to L1 client & testing teams working on protocol changes. That said, ACD is also one of the most visible forums for the broader community to engage with “core devs”, and we should ensure it remains open to them.
ACD Proposal 1: EIP Review Requests
Today, it isn’t uncommon for someone to bring up a topic on ACD which very few people have previously reviewed, leading to people “getting up to speed” live on the call. Here is an example from ACD#188.
To improve on this, we could introduce “Review Requests” on the ACD agenda, where instead of discussing a topic on the call by default, it is flagged to core teams for review. Once the item has been reviewed by at least one client team asynchronously, it could then be discussed more thoroughly on the next call, if needed.
These latter synchronous discussions could potentially be gated by client teams proposing the topic be discussed on a call.
ACD Proposal 2: Breakout Room Templates
Breakout rooms are broadly appreciated as a way to have deeper discussions on specific topics, and as the best place to bring in experts from outside client teams to discuss specific topics. So far, they haven’t been very “templatized”. Adding a common structure across them could help better dessiminate information from breakouts back to ACD.
Going forward, breakout rooms could require:

A moderator, who will run the call and report progress back to ACD
A public agenda in ethereum/pm/issues
A written summary of discussions/decisions (by default, done by moderator)
A recording, uploaded to the @EthereumProtocol YouTube
A transcript (autogenerated OK) posted to ethereum/pm
A notice on Ethereum Magicians (see “EthMag Proposal 1” below)

Breakouts do a mix of some/most/all of this already, but having a common template (explained in ethereum/pm?) would help both preserve records and efficiently communicate the takeaways in AllCoreDevs calls.
ACD Proposal 3: Async Team Updates
While planning Pectra, some teams started voicing their preferences for specific EIPs asynchronously ahead of ACD calls. There is broad agreement that this is valuable to keep doing, with the caveat that we want to ensure the governance process remains anchored to “rough consensus” (rather than formal voting or unanimity), and that we allow for individuals to keep voicing their opinions, even if it is different from their team’s majority view.
In the spirit of “rough consensus”, this feels like something we should encourage but not formalize. Teams sharing their views on important topics ahead of time (ideally >24h before the call) enables all participants to have a higher context discussion. That said, we should allow each team to do this in the format/medium they prefer. Similarly, we should leave ample room for qualitative discussion rather than simply trying to quantify support/objections for proposals.
Network Upgrade Process
NUP Proposal 1: PFI, CFI, SFI
Note: an EIP has been drafted to formally propose this. See the discussion here.
A few years ago, Ethereum’s execution layer started using the “Considered for Inclusion” status to highlight EIPs that client teams were seriously considering for a network upgrade but didn’t want to make a full commitment to include yet. The term was inspired from “Concept ACK” in Bitcoin Core.
While teams still feel CFI is a valuable status (CL teams have now started using it!), it is far from perfect: there’s a lack of clarity around when something should be CFI’d, some EIPs go from being
proposed" (which is not a formal status) to “Included” (which is), leading to confusion, etc.
Today, the rough pipeline for EIPs is as follows:

The EIP is “proposed” for a network upgrade, either on Ethereum Magicians, or a Github issue. For the past couple forks, I’ve kept a list of these proposals on Ethereum Magicians.
Some EIPs are formally Considered for Inclusion, which gets recorded in the Meta EIP for the network upgrade, see e.g. EIP-7600.
Some EIPs then get formally Included in the network upgrade, which is also recorded in the Meta EIP. Note that EIPs do not necessarily have to be CFI’d before being Included.
When a network upgrade goes live, the Meta EIP only retains the Included EIPs. In other words, the CFI status is only applied to EIPs on a per-fork basis.

To improve on this, I propose introducing a new status, Proposed for Inclusion, and renaming Included to Scheduled for Inclusion.
Proposed for Inclusion would be used by an EIP author to signal they want their EIP to be considered for a network upgrade. To formally propose an EIP for inclusion, one would simply need to open a PR to a network upgrade’s Meta EIP and list it there. This removes the need for someone (usually me!) to track proposals across multiple places, and provides EIP authors an “artifact proof” of the proposal, the PR to the Meta EIP.
Considered for Inclusion would remain mostly used as it is today, a way for client developers to signal which EIP they would like potentially see included in a network upgrade.
Again, there has been confusion about when something should be CFI’d. If we wanted a formal threshold for this status, I would propose “>1 client team affected thinks this is worth considering for the network upgrade”.
We currently have a soft rule to “not CFI something on the first ACD it is presented on”. If PFI was a formal status, this could potentially be relaxed to “don’t CFI something that hasn’t been PFI'd for 7+ days”.
Scheduled for Inclusion would replace Included to highlight EIPs that client teams have committed to implement and include in the network upgrade barring significant unexpected technical issues. Historically, a handful of Included EIPs have been removed during the implementation and testing phases because of technical issues. SFI better conveys that this may happen.
Optionally, once a network upgrade has gone live, SFI EIPs could be categorized as Included.
NUP Proposal 2: EIP Review Tracker
Note: a template for EIPs’ discussion-to threads has been proposed to address this.
Something that would make EIP Review Requests better is the ability to collect and keep track of reviews on an EIP. EIPs currently have discussions-to links which direct towards a single forum thread that can be hard to follow and “hide” important but unaddressed concerns.
Having a way for EIP authors and reviewers to solicit/highlight/track more formal “reviews” on an EIP could help make the async process more efficient.
An easy way to do this would be to create default templates for EthMagicians discussion-to threads which make it easy for the EIP authors to keep track of various reviews, audits, critcisms, etc. in a single place.
One example of this being done informally is the EIP-1153 shanghai/cancun thread. A possible sections for the template could be:

Client Implementations
Expert Reviews
Open Questions & Risks
Objections & Concerns

NUP Proposal 3: Align EIP and NUP Processes
With the split of the EIP and ERC repositories, there is an opportunity to modify the EIP process to better suit the needs of Ethereum network upgrades. For example, PFI, CFI, SFI could be added to the header of EIPs, and lists of EIPs in each status could be exposed on eips.ethereum.org.
The biggest blocker here is bandwidth: there are only a handful of EIP/ERC editors and they struggle to do more than the bare minimum to keep the process moving.
NUP Proposal 3.1: Client Team EIP Editors by Default
One idea to address this would be for every L1 client team who participates in the Network Upgrade Process to volunteer a part time EIP editor to help with the process.
Ethereum Magicians
EthMag Proposal 1: Breakout Room Highlights
One of the biggest issues for the broader Ethereum community is knowing if and when they should pay attention to AllCoreDevs. While EIP champions typically try and reach out to stakeholders affected by their proposals, historically this has often resulted in many relevant teams being unaware of a proposal until fairly late in the network upgrade process.
A good proxy for proposals which require deeper discussion and community engagemment are “proposals that lead to breakout rooms”. A simple improvement could then be to advertise past and upcomming breakouts on Ethereum Magicians, potentially with a way for users to subscribe to these posts exclusively.
For example, the website could display a banner with upcomming breakout rooms and their topics, or a weekly/forthnightly/monthly post could link all the recent breakouts and where follow-up conversation is happening.
EthMag Proposal 2: Revamped Categories
The Ethereum Magicians Post Categories need some love. While many are used regularly and well understood (e.g. EIPs, last-call, etc.), several of them are outdated (Working Groups, Ethereum 1.x, etc.), vague (Primordial Soup), or simply unused (Sharding, Address Space Extension).
Creating a net set of categories which both regular and more casual users of Ethereum Magicians find useful would help make Ethereum Magicians a central hub for both types of users. Ideally, users could also “follow” these categories in various ways, e.g. via per-category email notifications/digets or even things like custom Lens/Farcaster channels or Twitter bots that share new activity in them.
EthMag Proposal 3: Onboarding New Admins
Similarly to the EIP process, maintainer bandwidth is the main blocker to making Ethereum Magicians much better. To reflect that Ethereum Magicians is a resource for both the broader Ethereum community and core L1 R&D contributors, we should consider having an open process to add maintainers who can represent these different stakeholder groups.

Author: derek
Date: 2024-05-30T00:46:49.561Z

Really appreciate your work Tim.  I’m very new to the ACD process (having only been participating since 3074 was approved), but given my experience with 3074/7702 I think your proposals make a lot of sense.



 timbeiko:

NUP Proposal 1: PFI, CFI, SFI


Regarding this proposal, I’m not sure about tracking PFI/CFI/SFI in a meta EIP.  To me, the core devs already have a lot of visibility into what’s being considered.  The primary purpose of the PFI/CFI/SFI system would be to increase visibility for the community at large, but I’m not sure if listing them on a meta EIP that changes for every network upgrade is the best way to accomplish that.
To me, I think it would be preferable to simply introduce PFI/CFI/SFI as new statuses to EIPs themselves.  That way, when a EIP is considered for inclusion, it’s reflected on the EIP itself.
Furthermore, we should also update the EIP website to highlight the EIPs that are currently in PFI/CFI status, ideally on the homepage.  That way community members can always go to the EIP website and immediately find out which EIPs are being proposed/considered for inclusion, without first having to find the “currently active meta EIP.”

Author: abcoathup
Date: 2024-05-30T01:39:49.591Z

Thanks for detailed improvement proposals.  Feedback & additional improvement proposals below:
ACD Proposal 1: EIP Review Requests
Other than the moderator calling out the list of EIP review requests, there shouldn’t be a need to discuss non-CFId EIPs on ACD outside of Network Upgrade scoping discussions.
ACD Proposal 2: Breakout Room Templates
Recordings should include a view of the participants (to easily see who was there) and the chat.  The chat often contains a large amount of context.
Created an example as a wiki page for Future of EOA/AA Breakout Room #3
ACD Proposal 4: ACD Templates
ACD calls should also follow a similar template to Breakout Room Templates
A summary of decisions and actions should be shared on Eth Magicians (a topic per ACD)
Tim currently shares an ACDE summary on Eth R&D Discord and more detailed notes on Twitter
Alex has started sharing an ACDC summary on Eth R&D Discord.
Independently Christine Kim does a write up of ACD calls, with WiEN doing a summary.
Decisions/action summaries should be consistent, durable and easy to find e.g. on Eth Magicians rather than a Discord or Twitter.
A transcript, including the chat should also be shared on Eth Magicians alongside the summary.
Created an example as a wiki page: All Core Devs - Consensus (ACDC) call #134
ACD Proposal 3: Async Team Updates
It would be great if client teams could include a TLDR (ideally in a similar format) with a list of EIPs that they support (recommend CFI) and EIPs they don’t support for specific upgrades, along with any caveats.  So it is easy to see which EIPs have support for a particular upgrade.
Non-client teams & individuals could also do writeups with what they support.
ACD Proposal 4: Fortnightly ACD calls
Outside of Network upgrade scoping & during public testnet testing/upgrade/retro, ACD calls could be fortnightly (every two weeks) or even monthly.
If CFI/SFI EIPs need detailed discussion then this can be in a breakout room.
More async discussion allows wider participation (for those who are normally asleep during ACD).
Network Upgrade Process
Network upgrade process needs a major overhaul.  It is the end of May, and the scope for Pectra is still not finalized, when formal discussions started in January.  Pectra was originally envisaged as a small fork targeting late 2024.
NUP Proposal 1: PFI, CFI, SFI
Ideally we would be able to remove EIPs from Considered for Inclusion where the EIP definitely won’t be included in the upgrade.  This reduces the CFI list to only possible EIPs.
e.g. EIP7547 inclusion lists had issues with EIP3074 which couldn’t be resolved for Electra, but remains CFId.
NUP Proposal 2: EIP Review Tracker
This would be of huge benefit if EIP authors and/or Eth Magicians mods maintained this for the discussion topic.
The topic could be a Discourse wiki that could be updated over time.
NUP Proposal 3.1: Client Team EIP Editors by Default
 Each client team should nominate their editor.
Though editors should not assign their own EIP numbers (to avoid any perception of number sniping).
NUP Proposal 4: Multi-upgrade roadmap
Define a multi-upgrade roadmap of key major features.  The next 3 upgrades should be named.
This would allow EIPs to be PFId for the most suitable upgrade in the next few years.
NUP Proposal 5: Defined upgrade phases


Upgrade breakout for PFI EIPs (beauty parade)
Each PFI EIP gets a ten minute slot to present (using a preshared presentation) showing what their EIP does, who/how it benefits Ethereum, which client teams support it and estimated effort.  Ideally presentations would have a template they could follow.  Have multiple breakouts until all PFI EIPs presented.


Scoping
Client teams propose which PFI EIPs they support (along with other teams/independents), then a week later after all proposals are shared meet at ACD to finalize scope, with the aim to SFI EIPs.  Any CFId EIPs which have caveats on being SFId should have a limited window (e.g. a month) to be SFId (caveats removed) or they should be removed from CFI.  We should avoid having a situation where an EIP is CFId for a long period of time.
New EIPs should not be added into scope after this phase, without support of a large number of client teams.  This should be extraordinary circumstances.


Implementation
An EIP implementation tracker should be used.  e.g.  pectra-devnet-0 specs - HackMD
ACD should be used to report on issues blocking/delaying implementation.  Any detailed discussions should be done async or in a breakout room.
ACD should be used for moving EIPs from CFI to SFI, removing EIPs from CFI and deciding if a major change in an EIP scope means it should be removed.


Testing
We should have a defined period of time and order to public testnets after devnets & shadow forks.
e.g. Holešky first, 3 week gap, then Sepolia, 4 week gap, then mainnet


Upgrade


Retro
Public retro with written input from teams of what went well/what didn’t and how we improve the process


EthMag Proposal 2: Revamped Categories
Categories should be templated.  To encourage topic authors to use the same format.
EthMag Proposal 3: Onboarding New Admins
Currently there are only 3 admins, no moderators and only 4 non-admin regulars (who can recategorize and rename topics).  This may need to be part of someones paid role, or find a way to fund efforts (either grant or retroactively).

Author: abcoathup
Date: 2024-05-31T00:26:46.309Z

ACD Proposal 5: Separate moderator and streaming responsibilities
We should employ people focused on streaming/recording and not burden moderators with streaming responsibilities.
Moderators already have enough to do.

Author: timbeiko
Date: 2024-06-04T18:09:49.113Z

@derek ty for your comment! A few follow up thoughts:



 derek:

The primary purpose of the PFI/CFI/SFI system would be to increase visibility for the community at large, but I’m not sure if listing them on a meta EIP that changes for every network upgrade is the best way to accomplish that.


I wouldn’t say the primary purpose is to increase visibility for the community: having more granular status helps make the process clearer to everyone involved, including the client teams who have to make a decision about including things. This includes them being aware of everything that has been proposed, and reduces the amount of places one must look for this info to a single one.



 derek:

To me, I think it would be preferable to simply introduce PFI/CFI/SFI as new statuses to EIPs themselves. That way, when a EIP is considered for inclusion, it’s reflected on the EIP itself.
Furthermore, we should also update the EIP website  to highlight the EIPs that are currently in PFI/CFI status, ideally on the homepage.


I agree all of this would be nice, but given the limited bandwidth of EIP editors, it seems unlikely to happen in the short term. Having the info in the Meta EIP requires no additional work from EIP editors.

Author: timbeiko
Date: 2024-06-04T18:44:57.325Z

Thank you for the thoughtful comment! Some thoughts:
ACD Proposals

Re “Breakout Room & ACD Templates”, what do you think is the right breakdown between EthMagicians and ethereum/pm, @abcoathup? The latter currently keeps track of agendas, transcripts and recordings. Ideally, I’d want to avoid duplicating “canonical” sources of info. That said, I realize a lot of the valuable context (e.g. Christine Kim’s notes) is more of a natural fit on EthMag than /pm. It’s also a bit awkward that the README currently links out to my Twitter recaps but nothing else. This started being done when I was the only one doing other summaries along with the transcripts, but today there are clearly more options 
Re: ACD “decision tracking”, we did this in the past (some older ACD transcripts have many decisions/action items). We stopped because it felt too rigid/bureaucratic. Today, I try and document which ACD call a specific change to a Meta EIP was agreed to on. Perhaps there’s a low-overhead middle ground to track important action items but not be too rigid about it?
Re: Forthnighly ACD calls, I actually asked client teams about that recently and people still like having calls often! I’m inclined to follow their preferences here, but would also like us to eventually move to a slower cadence of sync calls.

Network Upgrade Proposals



 abcoathup:

Ideally we would be able to remove EIPs from Considered for Inclusion where the EIP definitely won’t be included in the upgrade. This reduces the CFI list to only possible EIPs.
e.g. EIP7547 inclusion lists had issues with EIP3074 which couldn’t be resolved for Electra, but remains CFId.


This is a nice to have, agreed. By default, it happens when the fork ships (hence why I’m against “CFI” being a status that transitions to the next fork by default), but we could remove things more aggressively.



 abcoathup:

NUP Proposal 4: Multi-upgrade roadmap
Define a multi-upgrade roadmap of key major features. The next 3 upgrades should be named.
This would allow EIPs to be PFId for the most suitable upgrade in the next few years.


I think we need to be very careful with this. Ethereum’s roadmap is extremely volatile and network upgrades take a long time to ship. Talking about what we’ll do 3 upgrades from now means talking about our priorities in 3-5 years, which we should recognize will at best be educated guesses. We shouldn’t create a false sense of certainty / sunk cost that “EIP X with be in Upgrade A because ACD decided it 2.5 years ago”.
If you wanted to “expose” the next three forks, my proposal would be something like:

Only PFI EIPs in the third next fork
PFI or CFI EIPs in the second next fork
PFI, CFI, SFI EIPs in the current fork




 abcoathup:

NUP Proposal 5: Defined upgrade phases


I’m relatively strongly against overly formalized phases like this. Protocol development is full of unknown unknowns, Ethereum is ~impossible to deprecate features on, and we want to balance process efficiency and openness. These three constraints are already huge and, somewhat miraculously, Ethereum manages to deliver on it. A big part of this is due, I think, to our willingness to be iterative in our processes and not overly formalize things. At best, formalizing things too much leads to outdated documentation (e.g. this). At worse, it leads to working on things that are “easy to fit in the process” vs. changing the process to fit the work.
Not against the idea of doing retros by default, though!



 abcoathup:

ACD Proposal 5: Separate moderator and streaming responsibilities


On one hand, I’d love this! I often (half) joke that OBS is the hardest part of my job  OTOH, part of the value in having many people “struggle” with it is that we don’t rely on a single person to be able to stream. But that can probably be addressed in other ways!

Author: bumblefudge
Date: 2024-06-05T19:38:20.188Z

Hey Tim!  I love all of this, and I will zoom in on the Eth-Mag stuff for now because I’m not experienced enough with ACD calls (aside from a few breakouts!) to have useful input on those just yet.  I’ll actually address them in reverse order, which will make sense after I’ve done them.



 timbeiko:

EthMag Proposal 3: Onboarding New Admins
Similarly to the EIP process, maintainer bandwidth is the main blocker to making Ethereum Magicians much better. To reflect that Ethereum Magicians is a resource for both the broader Ethereum community and core L1 R&D contributors, we should consider having an open process to add maintainers who can represent these different stakeholder groups.


Every Discourse I’ve ever seen that is HALF this big or this complex has LOTS of janitors and admins, often in tiers of privilege or focus. Maybe site-level things like escalating/removing admin permissions from other users and configuring the whole site and such shouild be reserved for a top-level admin deputized by the multisig (someone committed to that kind of role), but purely “editorial” privileges (just triaging posts, in a public way that can always be called out by anyone if abuse is noticed) should probably be distributed as widely as possible. Let’s call these “Editors”, since they don’t necessarily have conventional admin powers, or “Janitors”, cuz they keep things clean and efficient without necesssarily having power or authority in any conventional sense.
Furthermore, SamWilsn and I have been socialising around in various places the idea of “Standing Working Groups” modeled on ACD for other permanent topic-areas (by rough analogy to standing working groups in IETF), at least for ERC/Dapp devs and for Wallet/Interfaces devs.  I think ACD (and every other “standing working group”, however that’s defined) should have at least one person at a time who can (and knows how to) do those editorial things. From the point of view of synergy between the eth-mag discussions and the WG, imagine an ACD member-and-editor who was authorized to:

tag and untag threads as ACD-relevant (currently only OP and admins can change tags and categories, I believe)
split threads (this helps a lot when people are email-subscribed to specific tags or categories, and threads broken out have different tags or categories)
quickly remove spam or help triage sitewide issues, even if they’re only placing close attention to their WG’s threads/categories/tags




 timbeiko:

EthMag Proposal 2: Revamped Categories
The Ethereum Magicians Post Categories need some love. While many are used regularly and well understood (e.g. EIPs, last-call, etc.), several of them are outdated (Working Groups, Ethereum 1.x, etc.), vague (Primordial Soup), or simply unused (Sharding, Address Space Extension).
Creating a net set of categories which both regular and more casual users of Ethereum Magicians find useful would help make Ethereum Magicians a central hub for both types of users. Ideally, users could also “follow” these categories in various ways, e.g. via per-category email notifications/digets or even things like custom Lens/Farcaster channels or Twitter bots that share new activity in them.


+1  Maybe Categories should be reserved for standing working groups, and tags for topics that can cross-cut them?



 timbeiko:

EthMag Proposal 1: Breakout Room Highlights
One of the biggest issues for the broader Ethereum community is knowing if and when they should pay attention to AllCoreDevs. While EIP champions typically try and reach out to stakeholders affected by their proposals, historically this has often resulted in many relevant teams being unaware of a proposal until fairly late in the network upgrade process.
A good proxy for proposals which require deeper discussion and community engagemment are “proposals that lead to breakout rooms”. A simple improvement could then be to advertise past and upcoming breakouts on Ethereum Magicians, potentially with a way for users to subscribe to these posts exclusively.
For example, the website could display a banner with upcomming breakout rooms and their topics, or a weekly/forthnightly/monthly post could link all the recent breakouts and where follow-up conversation is happening.


I haven’t dug too far into the plugin topic, but I’m pretty sure the plugin maintained by Discourse itself would probably be the default option for calendaring:


Discourse Meta – 6 Dec 24




Discourse Calendar (and Event)




Plugin






official
calendar-and-event





:discourse2: Summary  Discourse Calendar and Event adds dynamic and interactive calendar and event features to your Discourse site.   🛠 Repository Link https://github.com/discourse/discourse-calendar   📖 Install Guide How to install plugins in...

Reading time: 8 mins 🕑
Likes: 185 ❤






Perhaps Editor/Janitor types (or the subset of those working with standing working groups) could be given permissions to add to that calendar? Not sure how fine-grained the permissioning is for plugins but I’d assume from how seriously Discourse takes privileges and user-classes it’s pretty easy to set up and copy-paste into the future.

Author: abcoathup
Date: 2024-06-06T01:39:48.922Z

ACD Proposals



 timbeiko:


Re “Breakout Room & ACD Templates”, what do you think is the right breakdown between EthMagicians and ethereum/pm



Speed, access, visibility & accuracy are important for me.
I don’t think I knew that transcripts were stored in ethereum/pm, which is bad as that suggests they aren’t being shared and not relevant in a timely manner to the weekly news.  To add value to community understanding (rather than just being receipts) we need transcripts, chat logs & recordings soon after the calls as possible (e.g. within 24 hours) rather than days or even weeks later.  Ideally from Zoom we can get chat logs and transcripts quickly.  We also want to make it easy for anyone to correct typos.  This could continue to happen on GitHub but it needs to be much much faster. (Happy to help if I can).
As for notes, Eth Magicians seems the best place to include a summary, even if this is a copy of what is posted in Eth R&D Discord.  This also allows for other sources such as Christine’s writeup to be included.



 timbeiko:


Re: ACD “decision tracking”



Current ACD summaries in Eth R&D Discord are pretty close to what I am after: decisions on upgrade roadmap, EIPs included/CFId/removed from CFI, EIP scope change, devnet/testnet/mainnet upgrade dates, with callouts for upcoming breakouts and any PFId EIPs for teams to review.
Meta EIP tracking which ACD calls EIPs were included/CFId is great.  Might be good to make this more visible such as Eth Magicians discussion topic.  Could try turning the Eth Magicians discussion topic into a wiki post.



 timbeiko:


Re: Forthnighly ACD call



Increasing async comms would be good.  I really like that teams are doing writeups of their priorities and sharing prior to calls.
If teams are happy with the frequency, then great.  Hopefully then calls could be shorter (closer to 45 minutes outside of scoping).
NUP Proposal 4: Multi-upgrade roadmap
For upgrades 2 & 3 general priorities at a high level would be sufficient rather than specific EIPs e.g. censorship resistance, L2 scaling, UX, DX.  Definitely need to avoid EIP authors feeling like they were promised a specific upgrade, priorities will change & many EIPs will never be included in an upgrade.
NUP Proposal 5: Defined upgrade phases
Discussions on Pectra scope started in December for a 2024 upgrade and we are now June with the scope hopefully to be finalized at the next ACDE & ACDC.
Maybe there is a middle ground.  ACD would ideally focus on upgrade scope until the list of included & CFId EIPs is finalized.  New EIPs would only be added to an ACD agenda prior to scoping or with support of multiple client teams (async).

Author: jpitts
Date: 2024-06-06T16:33:41.031Z

EthMag Proposal 1: Breakout Room Highlights
A good proxy for proposals which require deeper discussion and community engagemment are “proposals that lead to breakout rooms”. A simple improvement could then be to advertise past and upcomming breakouts on Ethereum Magicians, potentially with a way for users to subscribe to these posts exclusively.
For example, the website could display a banner with upcomming breakout rooms and their topics, or a weekly/forthnightly/monthly post could link all the recent breakouts and where follow-up conversation is happening.

This is a really good idea, I can help w/ setting up the discourse plugin or other means to highlight “breakout rooms” or simply “breakouts”. Anything that happens in person or in calls (notes, etc.) should be incorporated as well.

EthMag Proposal 2: Revamped Categories
The Ethereum Magicians Post Categories need some love. While many are used regularly and well understood (e.g. EIPs, last-call, etc.), several of them are outdated (Working Groups, Ethereum 1.x, etc.), vague (Primordial Soup), or simply unused (Sharding, Address Space Extension).

Definitely 1.x needs to be changed, or find a way to deprecate these kinds of categories that are dated to the understandings of a different era.
Are there new categories we should immediately add? Removing the less-used ones is a good idea, recategorizing the content more broadly.
If we are to keep some of the old ones like “primordial soup” I probably need to write an explainer.

Creating a net set of categories which both regular and more casual users of Ethereum Magicians find useful would help make Ethereum Magicians a central hub for both types of users. Ideally, users could also “follow” these categories in various ways, e.g. via per-category email notifications/digets or even things like custom Lens/Farcaster channels or Twitter bots that share new activity in them.

Unfortunately categories are only one per topic. Perhaps the tags would help here more, and highlight how to use them for new users. Certain tags can target more casual users, or users having a special interest e.g. “governance-acd”, and applied wherever a governance issue seems to be bubbling up (even if in the middle of a discussion about a specific EIP).

EthMag Proposal 3: Onboarding New Admins
Similarly to the EIP process, maintainer bandwidth is the main blocker to making Ethereum Magicians much better. To reflect that Ethereum Magicians is a resource for both the broader Ethereum community and core L1 R&D contributors, we should consider having an open process to add maintainers who can represent these different stakeholder groups.

I am definitely on board for helping make this happen. The Forum is successful for very technical discussions but I think that it can be broadened and made more resilient with more help!

Author: vshvsh
Date: 2024-06-07T13:25:47.043Z

What do y’all think about separating hardfork date targets from hardfork composition? E.g. - next hardfork to be targeted to Q42025 and what is ready and is scheduled for inclusion goes in; what’s not ready doesn’t. That would make scheduling testnets, conferences, node software upgrades easier and give concrete deadlines for implementers, and would simplify many decisions around hardfork composition.

Author: shemnon
Date: 2024-06-07T13:50:26.436Z

It’s been proposed, and attempted.  Hasn’t worked out.

Author: bumblefudge
Date: 2024-06-07T15:15:29.735Z

jpitts:

Are there new categories we should immediately add? Removing the less-used ones is a good idea, recategorizing the content more broadly.


See my response above!  I’ve been trying to get AllWalletDevs and AllERCDevs a Category (and editorial rights thereto) for a year.

Author: jpitts
Date: 2024-06-11T17:25:46.443Z

Thanks, and I’m in support of adding!
For the WG type of categories, it is important to have a good and up-to-date “About” topic describing the WG, link, contacts, call times, etc. These are not used nearly enough on the Forum. Each category has one and it can serve as a pinned message. We can position it better here as well.
Realizing it is hard to search for it, we may need to tag it.
Searching for “about the tokens category”, here is a sample: About the Tokens category

Author: jpitts
Date: 2024-06-11T17:29:11.720Z

General comments about WGs:
As with anything relating to organizing, it is a lot work to keep a WG going. Magicians early-on were trying to accomplish this w/ “rings” but only a few kept running. One issue was setting up WGs before a person was solidly committed to running it for a period of time. It needs messaging and herding  . They may need support too, perhaps this can be accomplished by this emerging group to improve the process.

Author: jpitts
Date: 2024-06-11T18:10:43.579Z

bumblefudge:

+1 Maybe Categories should be reserved for standing working groups, and tags for topics that can cross-cut them?


One way to go may be to retire most of the subject-oriented categories like “Tokens” and use tags instead, with the exception of Process Improvement, EIPs, ERCs, etc. These categories can be considered to be a kind of “taking an idea to production WG”.
But I should emphasize that, for new users, the subject-oriented categories are helpful. We need to address what they solve. @timbeiko’s expansion of these did clean things up considerably though. Perhaps what we can do is create a nice, organizing page w/ a link in the navigation for this handful of very popular tags which group related topics (often redundantly, as in the case of a topic categorized under “Tokens” having a tag “tokens)”.

Author: bumblefudge
Date: 2024-06-12T14:14:52.616Z

jpitts:

As with anything relating to organizing, it is a lot work to keep a WG going. Magicians early-on were trying to accomplish this w/ “rings” but only a few kept running. One issue was setting up WGs before a person was solidly committed to running it for a period of time.


Actually, my proposal is that each Category map not to “working groups” in the aspiration sense of a “semi-official group that people hope and assume will keep meeting regularly” but rather to “working groups” in the banal administrative sense of “group of people that hold public meetings and have nominated a representative who has committed to at least curating the Category on Eth-mag and finding their own replacement after the year they committed to”  .  I think I have such volunteer co-editors from the AllWalletDevs and AllERCDevs committees (that already hold meetings and publish notes from them), and any other WGs should be considered “at-risk”/“in-process” until volunteers as awesome as those two materialize!  I also AM that person for ChainAgnostic[StandardsAlliance], if that’s a category people want (I could also stand up a separate discourse if that’s preferred for whatever reason-- there are pros and cons to having a separate-but-equal discourse for Categories that are a little adjacent or orthogonal to eth design debates, like ENSDAO or SnapsDAO).
IMHO, the best definition of a Category should be an ongoing and manual/subject curational grouping representing a community (whether that’s a Discord server, frequent or sporadic public meetings, etc), rather than some permanent or self-evident logical category like “protocol-level” or “dapp development”.  In the most extreme form of this definition, having 1 or more curators chosen/supported by the group would be an ongoing hard requirement for having a category, and when one steps down without a replacement, that category would be paused/archived/etc.
Anyways, not sure this kind of detailed governance talk lends itself to longform Discourse, so if there’s a meeting about this at a time i could reasonably attend from Berlin (vampire hours are fine), invite me! I have been taking notes and talking to people about gradually ratcheting up and formalizing the concept of working groups for a while, so I have notes to share on communities that may or may not qualify as such and be interested in a “Category” as defined above as well.

Author: timbeiko
Date: 2024-06-12T22:25:43.592Z

Thanks for all the suggestions, @bumblefudge  !
Agreed on having more “Janitors” across EthMag would be really valuable. That seems like an easy win we’ve sorted out the broader structure.
At a higher level, one thing I want to be mindful of is not creating more confusion in the community by having too many “things”. If, for example “Breakout Rooms”, “Working Groups”, “Rings” and “EIP Working Groups” all refer to roughly the same thing, maybe we should try and harmonize them better?
For example, if we think the thematic split should be L1 | L2 | Wallets | Applications, then “Tokens” shouldn’t have its own category but just fall under Applications. L1, L2s and Applications are the easiest to map to standards, with EIPs/RIPs/ERCs. Wallets definitely feel like the hardest ones here (and the one I have least context on ), but maybe it’s fine for that one to not map as cleanly to a spec category?
@jpitts I do also like the idea of combining IRL events with all of this, but given online calls and remote collaborations are far more frequent, I think we should design the process to work well for that and then see if it can also be used for in-person gatherings, rather than the other way around.

Author: timbeiko
Date: 2024-06-12T22:26:19.329Z

Also, here’s an EIP draft to introduce PFI/CFI/SFI: EIP-XXXX: Network Upgrade Inclusion Stages
Let’s move discussion of that proposal to the thread linked above.

Author: bomanaps
Date: 2024-06-13T16:49:07.288Z

@bumblefudge, @jpitts, thank you both for your valuable insights.
I agree with your perspective on the need for more “Janitors” across EthMag. This could indeed be a valuable addition once we’ve sorted out the broader structure. Your point about avoiding confusion in the community by harmonizing similar elements is well-taken. It’s crucial to ensure that our terminology and structures are clear and consistent to avoid any misunderstandings.
Harmonizing Terms and Reducing Confusion
I completely agree with the need to minimize confusion by harmonizing terms. Having multiple labels like “Breakout Rooms,” “Working Groups,” “Rings,” and “EIP Working Groups” can definitely be confusing if they all essentially refer to the same type of grouping.
Proposed Solution:

Unified Terminology: We could adopt a single, clear term for these groups. For example, we could refer to all of them simply as “Working Groups” or another suitable term that resonates with the community.
Clear Definitions: Each term we use should have a clear and distinct definition to avoid overlap. This can be documented and communicated clearly within EthMag.

Thematic Categories
Your idea to have thematic splits such as L1, L2, Wallets, and Applications makes sense and could streamline categorization.
Regarding “Tokens”:

I agree that “Tokens” can fall under “Applications” since they are a type of application built on top of Ethereum.

Specific Challenges with Wallets
Wallets do seem to be a unique category that doesn’t map as cleanly to standards like EIPs/RIPs/ERCs.
Proposed Approach:

Special Category: It might be beneficial to treat “Wallets” as a special category with its own curators and standards, recognizing its unique nature and importance within the ecosystem.
Flexible Mapping: Accept that not all categories will map perfectly to EIP/RIP/ERC specifications, and that’s okay. The primary goal is to ensure each category has clear, active curators and a well-defined scope.

Moving Forward
I am open to further discussions to refine these ideas and ensure we implement a structure that is both efficient and easy for the community to understand. Let’s schedule a meeting to discuss this in detail. I’m flexible with timing.
Thanks for raising these important points. Looking forward to working together on this!

Author: bumblefudge
Date: 2024-06-17T11:57:09.100Z

@timbeiko @jpitts @shemnon @abcoathup @xinbenlv @SamWilsn Speaking of IRL events, is there a session planned for eth-mags and/or EIPIP topics at EthCC? Some of the stuff discussed above might be easier to hash out IRL in a timeboxed, advertised governance-scrum kinda format.
If no other sessions/venues get put on the official calendar, all this could be discussed at the otherwise mostly off-topic CASA meetup on Wednesday afternoon, a few blocks off-site. But my preference would be for something on the calendar that more people come to.

Author: timbeiko
Date: 2024-06-19T23:15:15.008Z

I won’t be at EthCC unfortunately, but I’ve just shared this with some folks trying to organize more technical protocol-related sessions.

Author: timbeiko
Date: 2024-06-19T23:20:13.727Z

timbeiko:

NUP Proposal 2: EIP Review Tracker


Here’s a proposal for this: Template for `discussion-to` threads

Author: nicocsgy
Date: 2024-06-24T10:49:55.571Z

Ethereum Magicians improvement proposal
Hello Magicians,
I’ve often heard that the current structure of the forum can be overwhelming and difficult to navigate. To address this, I’d like to propose a reorganization of the categories. After a few iteration on the forum  organisation, I agree with @jpitts , the best approach would be to organize the forum with tags: Categories > Subcategories and Tags. This will not only make searching for information more efficient but also reduce duplicates and open the door to more fine-grained features (e.g., category summaries and bridged messages).
I’ve experimented with this structure on a “test discourse” instance, Ethereum-sorcerers. Please note, this instance is purely for testing features and is not an active forum, feel free to join and try. Your feedback on these changes would be invaluable, and I’d love to see other contributors participate in the forum improvement process.
Proposed Changes & Features

Categories & Tags Organization: Aligning with EIP-1, to ensure consistency and clarity.
Light & Dark Mode: Introducing a Solar / Lunar theme to enhance visual comfort.
Design Enhancements: Utilizing Ethereum.org assets for category icons & banners to create a cohesive and appealing design.
Discourse Native’s Topic Template: Implementing templates that align with @timbeiko 's proposal for the EIPs category, ensuring structured and consistent discussions.

Proposed Categories & Tags




Category
Description


EIPs
Ethereum Improvement Proposals, an EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature.


RIPs
Rollup Improvement Proposals, standardizing and providing high-quality documentation for Rollups in the Ethereum ecosystem, tracked through Rollup Improvement Proposals (RIPs).


ERCs
Ethereum Request for Comments, proposing standards for Ethereum applications.


Protocol Call
Discussions and updates about Ethereum protocol development and upgrades.


Café
A place for casual discussions about Ethereum, site feedback, and topics that don't fit into other categories.


General
Introduction page and the big 'introduce yourself' thread.







Subcategory
Parent Category
Description


EIPs Standards Track
EIPs
A Standards Track EIP describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. When creating a topic you have to chose one of the following tagcore; networking; interface


EIPs Meta
EIPs
Proposals describing processes surrounding Ethereum or proposing changes to processes. These often require community consensus and do not affect the Ethereum codebase.


EIPs Informational
EIPs
Informational EIPs describe design issues or provide guidelines to the community without proposing new features.







Tags Group:
Tags



Café Category


introduction
feedback
irl
user-experience




EIP Category


wallet
consensus-layer
execution-layer
opcode
staking
account-abstraction
cryptography
economics
precompile




EIP Standards Track Category


core
interface
p2p
networking




EIP Status


idea
draft
final
living
review
stagnant
withdrawn




Working Group


breakout-room
acdc
acde
client-team
ethcatherders
peepaneip
rollcall





Proposed Meta Improvement Process
Each category will have a subcategory dedicated to process improvements. The Café category could include a dedicated thread for site feedback and improvement proposals. This thread would allow anyone to request the addition of a tag, category, or subcategory or suggest changes. We can repurpose this very thread for that purpose.
Transition Path
We can follow this tutorial from the Discourse team to bulk move topics. I volunteer to manually reorganize the remaining topics and tags that wouldn’t fit in the bulk moves.
Proposed Timeline
I propose a two-week discussion period to assess these changes. If agreed upon, we can implement them promptly to have those changes presented during Execution Layer Meeting 191 & IRL in the upcoming EthCC sessions.

Author: matt
Date: 2024-06-24T15:45:54.691Z

Thanks @nicocsgy! Some suggestions

Should “protocol call” category be “governance” instead? Seems much clearer about what is actually happening in the category.
I would change the subcategories for eips to be: core, networking, interface, meta, and informational
It isn’t super clear what “cafe” is for. I think something more descriptive like “community”, “magicians”, or “AllCoreMagicians” could help.
For EIP tags, I would change “opcode” to “vm”.
I think we can remove the tags for “EIP Standards Track Category” because the will be denoted via subcategory?
EIP status tags seems like a nice idea, but I think the odds of them becoming stale are super high and then they become confusing. I would probably omit them at the start.
I think we could rename “working group” tag category to “Governance” or something of the like. I don’t really think “breakout-room” makes as much sense in a “working group” category, but might make a lot of sense in a governance one.

Author: nicocsgy
Date: 2024-06-24T16:53:55.165Z

Hey @matt ,
Thanks for the feedback, much appreciated !


Should “protocol call” category be “governance” instead?


I have no strong opinion on this one. But some of the calls aren’t really governance process like “peep an EIP”


I would change the subcategories for eips to be: core, networking, interface, meta, and informational


Yes, I think this might be a better organisation as it relies less on the tags, I’ll try it.


It isn’t super clear what “cafe” is for. I think something more descriptive like “community”, “magicians”, or “AllCoreMagicians” could help.


Yes, I am up for suggestions “community” seems a bit vague, “AllCoreMagicians” reminds me a bit of ACD so I’d prefer “magicians”. I also think “café” is good because welcoming.


For EIP tags, I would change “opcode” to “vm”.


Yes, sounds good.


I think we can remove the tags for “EIP Standards Track Category” because the will be denoted via subcategory?


Yep, agreed.


EIP status tags seems like a nice idea, but I think the odds of them becoming stale are super high and then they become confusing. I would probably omit them at the start.


So we can “enforce” the selection of an “EIP status tags” for every new topic I think it’s reasonable to expect this from authors considering that new posts are very likely going to be " idea / draft ". The hard work would be to tag correctly all the existing posts. We can add or remove them easily anyway if they become too much.


I think we could rename “working group” tag category to “Governance” or something of the like. I don’t really think “breakout-room” makes as much sense in a “working group” category, but might make a lot of sense in a governance one.


So “working group” isn’t a tag it’s actually just the tag group name it’s not shown anywhere it’s just to name the group. I think it’s fine to leave it as is.

Author: caspar
Date: 2024-06-24T17:13:17.497Z

Thank you @nicocsgy!



 matt:

It isn’t super clear what “cafe” is for. I think something more descriptive like “community”, “magicians”, or “AllCoreMagicians” could help.


+1



 nicocsgy:

So “working group” isn’t a tag it’s actually just the tag group name it’s not shown anywhere it’s just to name the group. I think it’s fine to leave it as is.


Does this mean the naming of the “Cafe Category” also doesn’t matter, because it’s not shown anywhere?
fwiw “cafe” is more unclear/ambiguous to me than “magicians community” or something along those lines.



 nicocsgy:


Light & Dark Mode: Introducing a Solar / Lunar theme to enhance visual comfort.
Design Enhancements: Utilizing Ethereum.org assets for category icons & banners to create a cohesive and appealing design.



I like light/dark mode! But I would keep design choices generally very neutral and minimal, also wrt to ethereum.org assets etc.

Author: nicocsgy
Date: 2024-06-24T19:31:17.684Z

Hello @caspar, thanks for the feedback

Does this mean the naming of the “Cafe Category” also doesn’t matter, because it’s not shown anywhere?

Yes “Cafe category” is the name of the group of tags related to the “Café” category. The name of the tag group is hidden but the Café category is there.

fwiw “cafe” is more unclear/ambiguous to me than “magicians community” or something along those lines.

Alright, probably worth a renaming and a better description then.

I would keep design choices generally very neutral and minimal, also wrt to ethereum.org assets etc.

The icons / banner could be an optional theme not on the default one. But I generally think a little touch of design (maybe not the ethereum.org assets indeed) would do good and align with the different websites across the ethereum ecosystem.

Author: bumblefudge
Date: 2024-06-26T19:24:53.613Z

I like this as a starting point but I’m more interested in [bottom-up] curation over time than [top-down] curation upfront.  If this is a community venue it shouldn’t need centralized curation or maintenance.
My proposal was that instead of “Working Group” being one more permanent category full of things that can go stale or need a top-down refresh every year, each category only exist as long as there is a Working Group actively curating it (tagging/untagging, splitting threads, etc). Heck, I’m sure there’s a discourse plugin that trigger actions when none of a given category’s designated curators have logged in to check their moderator inboxes for 30 days…
As someone else (seemingly with ChatGPT’s help) put it:

The primary goal is to ensure each category has clear, active curators

Author: nicocsgy
Date: 2024-06-27T01:20:23.640Z

Hey @bumblefudge,
I don’t think the changes proposed introduce the need for curation or maintenance. The idea was indeed to propose something light enough so that it introduces no maintenance. The only actions required would be a few changes in the settings, some commands for the bulk moves and about 20 lines of CSS/HTML styling.
The changes would ensure that new topics in certain categories use the right tags (e.g. you open a topic in EIPs and you have to select the right subcategories and tags). Those categories and tags would be defined to best fit the current EIP process as described in EIP-1 and other finalized Meta EIPs.
I think it’s ok to expect from EIP authors that they follow those rules as ultimately their task to champion their proposal outweighs the few clicks to select the right category and status. As for the rest of the users, they remain free to reply and to create a new topic of their choice and to suggest a new category, as they are today. And the subcategories improvement process would stimulate meta discussion as this one.
The only thing that would change is that one would have to reply to propose tags in a meta thread rather than being able to create tag by himself (that might be modified if creating tags doesn’t mess with “tag groups”).



 bumblefudge:

My proposal was that instead of “Working Group” being one more permanent category full of things that can go stale or need a top-down refresh every year, each category only exist as long as there is a Working Group actively curating it (tagging/untagging, splitting threads, etc).


What you’re proposing is actually introducing maintenance. I am not against the idea, but I am not sure how to articulate it or if enough volunteers would show up. So I’d like to start with a lighter version that can work as proposed and build from there.
I’m also not convinced about the structure having a working group category full of things that can go stale so there would be one main category and people that are part of those “working groups” are assigned to the moderate the other categories ? IMHO for the protocol related categories we simply need a clear structure that mirrors the Meta EIPs (as this leaves less room for interpretation) and a few open categories for the community forum.



 bumblefudge:

Working Group actively curating it (tagging/untagging, splitting threads, etc). Heck, I’m sure there’s a discourse plugin that trigger actions when none of a given category’s designated curators have logged in to check their moderator inboxes for 30 days…


I do agree that more moderation would do good. But I don’t think there is a need for a plugin linked to moderators activity.

Author: nicocsgy
Date: 2024-06-27T15:28:46.429Z

Re @caspar, @matt
I applied the suggested changes to the sorcerer test discourse.

Reorganised category to mirror Standard tracks EIPs with subcategories rather than a Standard category group tag
Bulk moved topics
Renamed category Café to Magicians
Changed tags opcode to EVM and group tags EIP category to Topic category, Café category to Magicians category
Removed Ethereum.org assets as category banners
Removed Ethereum.org assets as category icons
Enforced the EIP template in the corresponding EIP categories




 caspar:

I like light/dark mode! But I would keep design choices generally very neutral and minimal, also wrt to ethereum.org  assets etc.


To keep the design minimal I removed all the ethereum.org assets but I’d like to see some assets for EthMag as I think this forum could use some cool logos / icons. This would align with the overall ethereum vibe across websites, even tho I agree that EthMag’s doesn’t require a lot of assets as it’s a technical forum. I think we could agree to design a few good logo / icons, e.g the ethresear.ch logo is nice.
I suggest to keep doge-computer from William Tempest as a “small icon” which is displayed on the top left when you read a topic. Currently on EthMag the “small logo” is just stars. But IMO the “doge-computer” is an amazing small logo to represent the “reading EthMag” activity and it will be hard to design a better one.
image1676×579 51.8 KB
vs
image1632×599 60.5 KB
“doge-computer” from William Tempest :
doge-computer.482265f82850×2040 610 KB

Author: bumblefudge
Date: 2024-06-27T15:37:25.427Z

nicocsgy:

I don’t think the changes proposed introduce the need for curation or maintenance. The idea was indeed to propose something light enough so that it introduces no maintenance


Sorry, I didn’t mean to imply that your one-time update to the categories introduces MORE need for curation, I think the need for deputized curation has been a constant since inception and shuffling around the categories would give the false sense of having solved the problem for as long as it takes for them to go out of sync with where the humans are talking over time.
To put it another way, what the available categories are at a given point in time is orthogonal to how usefully they are curated over time, and no amount of tweaking the signage is good enough to do away with the need for humans to direct traffic in a context this noisey and emergent. Getting and retaining humans to direct traffic is, IMHO, the higher priority, and one classic way to retain volunteers is to give them ownership over their labor (i.e. the application of tags and categories, and the list of available tags and categories). Like reddit mods, a little bit of [highly local] authority and recognition goes a long way.
Letting them choose a category-specific icon might also help

Author: nicocsgy
Date: 2024-06-27T22:49:53.571Z

No worries, I agree on the need for more curation and that human effort is needed at some point. I think that with an organised forum it reduces a bit the need for manual work hence the changes. But yes it will require some people to help as this is growing.
Cool ideas, I do agree recognition goes a long way and there are a lot of cool titles with the magician theme.

Author: bumblefudge
Date: 2024-06-30T11:10:07.508Z

nicocsgy:

Cool ideas, I do agree recognition goes a long way and there are a lot of cool titles with the magician theme.


I am but a humble Pageboy, your liege, content to carry the wand in its protective travel hard-case where wizards conjure and invoke the spirits

Author: abcoathup
Date: 2024-07-11T10:45:21.123Z

timbeiko:

ACD Proposal 2: Breakout Room Templates


@poojaranjan as agreed, moving discussion from Eth R&D Discord regarding ACD & breakout meetings.
I am a heavy consumer of post call artifacts (where available) and create my own summaries to share based on moderator summaries/notes and/or watching recordings
Artifacts:
Agenda: GitHub issues on ethereum/pm
Summary (of discussions/decisions): some are on Eth R&D Discord
Notes: moderator specific location & format (Twitter thread, HackMD, Google Docs etc)
Recording: YouTube
Transcript: File in ethereum/pm
Notice: proposed for Eth Magicians
Historic record: links in README on ethereum/pm
Feedback:
Agenda mostly working, though a standard template would be helpful with some instructions on how to add things to the agenda (and what would/wouldn’t be added e.g. new EIPs should be proposed async first)
Long term having a dependency on GitHub is bad and need backups of these.
Summary: these are moderator dependent, so location and format vary greatly (Tim  & Alex use Eth R&D Discord for ACD).
A template and a standard location is important to agree on.
The summary is the key output for a meeting (otherwise if there are no agreed decisions, what was the point of the meeting).  As well as being used by the participants, this is used by the community (including news) to understand what has been decided.
Moderator created summaries are not currently linked to from ethereum/pm README.
Using Eth R&D Discord makes sharing difficult (I have shared screenshots on Twitter/Reddit with a copy of the text and experimented with Mirror & more recently Eth Magicians), are hard to find and has a dependency on Discord.  At the very least copying/mirroring to a more permanent home would be preferred.
Summaries need to be timely (within 24 hours) otherwise alternate summaries will be used which may be different than those recorded by the moderator.
Summaries in ethereum/pm are not moderator created and are not available in a timely manner, so are only useful for historic record purposes only. (the latest merged notes for ACD are from May)
Notes
These are moderator dependent, so location and format vary greatly.  They give more context to the summary, often the why a decision (in the summary) was made.
They should sit along side summaries.
There should also be a way to link independent writeups e.g. @Christine_dkim writes notes for ACD calls.
Recording: recordings should show participants and chat (for context) with subtitles (for accessibility).
Currently only ACD recordings include participants and chat, other calls lose this context.
Recordings should be available within 24 hours (at the latest) and ideally trimmed to the start of the call.
YouTube is great for sharing, but backups are required for the long term.
Transcripts (including & Chat logs)
Ideally these would be auto generated and available at the same time of the call recording (for news purposes).
Chat logs are needed as a lot of context of discussions is done in the chat rather than on audio.
Ideally both could be easily corrected (auto generated is not great for technical terms currently) such as in a wiki.
Notice
Notices could be pinned/banner topics in Eth Magicians with a link to the agenda.  Essentially these are for promotion with pre call information all being in the Agenda.
I have been experimenting creating these as wiki posts in Eth Magicians, and then adding the summary, notes, recording etc.  Though don’t have permissions to pin/banner.

ethereum/pm for post call artifacts is fine for historic record but is not timely enough for other purposes.  As an example the README shows the latest calls from May.
Using ethereum/pm agenda issues to link to post call artifacts puts the responsibility on the creator (generally the moderator) and may not be timely enough.
Using Eth Magicians wiki posts allows more people to edit in a timely manner but risks vandalization and is a dependency on Discourse.  It also duplicates effort.
TLDR:
Need summaries/recordings/transcripts/chat logs available in a timely manner (ideally within 24 hours of a call), with templates/locations for moderators to easily do this and easy ways for community to update transcripts/chat logs.

Author: timbeiko
Date: 2024-07-12T16:27:04.673Z

@abcoathup I agree with a lot of your suggestions in the last post! In short:

Big +1 on summaries being valuable but not visible enough. I’m going to focus on shifting that, and make EthMag summaries my #1 artifacts, which gets crossposted to Twitter/Discord/Farcaster/etc.
The /pm repo is due for a refresh, and I’d rather wait a bit longer until more stuff around EthMag is figured out. It still feels like the right medium-term place for agendas and transcripts to live.
I think it’s fine to not focus on “notes” too much if we have good summaries and transcripts. Another artifact I’d like to have is good audio-only recordings.


More detailed responses:



 abcoathup:

Agenda mostly working, though a standard template would be helpful


Agreed here. Our “standard template” is currently on the /pm README. I’ve been meaning to revamp it a bit, but want to do so in the context of the other changes discussed in this thread.



 abcoathup:

Long term having a dependency on GitHub is bad and need backups of these.


I agree with this too. I’ve considered moving them to EthMag a few times, but Github is valuable in that it is “closer” to where a lot of the technical work discussed on ACD happens.



 abcoathup:

Summary: these are moderator dependent, so location and format vary greatly (Tim & Alex use Eth R&D Discord for ACD).


Agree these are really important, timeliness matters, and discord isn’t the best place for them. Starting with the next ACDE, I will try making EthMag summaries my #1 artifacts, effectively replacing both the Twitter threads and Discord summaries. I’ll cross-post them there, and see what the reaction is 



 abcoathup:

Notes
These are moderator dependent, so location and format vary greatly. They give more context to the summary, often the why a decision (in the summary) was made.


Notes are a bit of an awkward “level of resolution” IMO. I’d rather we focus on a good summary + transcript and treat notes as a “nice to have”.



 abcoathup:

There should also be a way to link independent writeups e.g. @Christine_dkim writes notes for ACD calls.


I agree these are really valuable and should be better highlighted! So maybe Summary / Transcript / Writeups are the right artifacts?



 abcoathup:

Recording: recordings should show participants and chat (for context) with subtitles (for accessibility).
Currently only ACD recordings include participants and chat, other calls lose this context.
Recordings should be available within 24 hours (at the latest) and ideally trimmed to the start of the call.
YouTube is great for sharing, but backups are required for the long term.


Agreed with all this, and I’d even go further. It would be nice to have audio-only versions of the calls broadly available, like a podcast subscription or something. The only times I have to watch a call I missed, I go to a “Youtube to mp3 conversion” site and download the audio only 



 abcoathup:

Transcripts (including & Chat logs)
Ideally these would be auto generated and available at the same time of the call recording (for news purposes).


I agree with the “ideally” here, but as @poojaranjan pointed out on Discord, auto-generated transcripts are far from perfect. Chat logs can likely be made available at the same time as videos, but for transcripts, I think it’s fine to wait a bit longer if it means the output has been sanity-checked.

Author: poojaranjan
Date: 2024-07-12T17:04:39.014Z

timbeiko:

Big +1 on summaries being valuable but not visible enough. I’m going to focus on shifting that, and make EthMag summaries my #1 artifacts, which gets crossposted to Twitter/Discord/Farcaster/etc.


Agree that summaries are super valuable and would like to encourage the meeting facilitator to keep it as the comment on the Agenda at ethereum/pm Issue like this or this. It can be crossposted on Discord and other social media.
The benefit I see it is that a particular GitHub Issue is the canonical source of truth for a specific meeting to collect all info.The Breakout Room Folders will be helpful to get additional transcripts along with Zoom chat files.



 timbeiko:


The /pm repo is due for a refresh, and I’d rather wait a bit longer until more stuff around EthMag is figured out. It still feels like the right medium-term place for agendas and transcripts to live.



Absolutely in favor of keeping /pm repo as a placeholder.



 timbeiko:


I think it’s fine to not focus on “notes” too much if we have good summaries and transcripts. Another artifact I’d like to have is good audio-only recordings.



I think the mp3 or wav version can be made available via Zoom. I can suggest ECH Podcast to upload the Meetings audio version if there is enough interest.

Author: nicocsgy
Date: 2024-07-18T13:23:22.411Z

Hey magicians,
We should probably have a bigger poll / vote for the logos to be added to Ethereum Magicians. This could be a nice way to gather the community. It should come at a later stage we could make a new thread inviting contributors to propose logos / assets. But it shouldn’t be a blocker to the organisational changes described above.
Applying the changes would also unlock a refresh on /pm repo, and more fine grained summary for working groups.



 timbeiko:

The /pm repo is due for a refresh, and I’d rather wait a bit longer until more stuff around EthMag is figured out. It still feels like the right medium-term place for agendas and transcripts to live.


@jpitts, I think we have some consensus around minor changes that would help the forum. Let me know, if that sounds good to you or if you’d like any further details.

Author: bumblefudge
Date: 2024-07-26T12:16:53.104Z

More generally, “where” does one “go” for an update on eth-mags admin, delegation, janitorial volunteering, etc etc?  I am trying to sort out visa stuff to go to DevCon, perhaps it’s worth having some kind of catherders/EIPIP/ethmag minisummit and talk about all this in sync-time? I would move mountains to attend a zoom call on this, I have felt a little blocked and a lot motivated on this topic for like 3 years.

Author: nicocsgy
Date: 2024-08-02T12:52:44.827Z

Hey hey,
Glad you asked, I just reorganised some categories as per the above proposal. I’d love to discuss with you further involvement in the eth-mag website and I hope we can collectively “unblock” this situation.



 bumblefudge:

More generally, “where” does one “go” for an update on eth-mags admin, delegation, janitorial volunteering, etc etc?


IMO it would be nice to launch a call to contributors to discuss this further, as you said above even with an organised forum some human curation will help a lot !
So now the Magicians category contains Site Feedback - Fellowship of Ethereum Magicians and Process Improvement - Fellowship of Ethereum Magicians (which might be a bit of a duplicate still thinking about it) the process improvement should be more general meta discussion on the Magicians category while the Site Feedback is pure Eth-mag feedback.

Author: abcoathup
Date: 2024-08-02T23:01:20.105Z

@nicocsgy
I want a home for acd  & breakout.  I’ve been putting them in Working Groups
Would also like to see upcoming calls as banners/pins.
Would be great to have templates for each category.

Author: nicocsgy
Date: 2024-08-02T23:26:58.715Z

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 !

Author: abcoathup
Date: 2024-08-03T01:54:55.277Z

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

Author: bumblefudge
Date: 2024-08-05T09:29:22.819Z

@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):



 nicocsgy:

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 ?



Is the distinction that “Protocol Calls” is for projects on the EF calendar (ACD, Breakout, RIPs), and “Working Groups” are independent things like AllWalletDevs, AllERCDevs, etc? This seems fine to me, and reflects a kind of organic grouping (modulo the slight “pecking order” it could be taken as reinforcing.)

If so, I would recommend Victor and Sam both be given curatorial rights over the WG category so they can split threads tag/retag/detag threads within that purview. I’m glad to help out but they run calls and have better visibility, seems like they


Should CAIP/CASA topics like in a tag like 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)?

Author: bumblefudge
Date: 2024-08-06T08:33:43.254Z

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…

Author: nicocsgy
Date: 2024-08-06T11:58:51.572Z

bumblefudge:

CET for the foreseeable future


Great, will DM  



 bumblefudge:

Is the distinction that “Protocol Calls” is for projects on the EF calendar (ACD, Breakout, RIPs), and “Working Groups” are independent things like AllWalletDevs, AllERCDevs, etc?


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:

We could push the “old rings” topics under one subcategory with tags for each ring and create new subcategories for the active working groups like AllWalletDevs
We could rename / create a new category for the active “working groups”

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.



 bumblefudge:

Should CAIP/CASA topics like in a tag like 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)?


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.

Author: bumblefudge
Date: 2024-08-07T09:00:17.488Z

nicocsgy:

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:


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.

Author: siladu
Date: 2024-10-11T03:13:57.803Z

abcoathup:

Transcripts (including & Chat logs)
Ideally these would be auto generated and available at the same time of the call recording (for news purposes).


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.

Author: timbeiko
Date: 2024-11-25T21:59:55.721Z

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:

Add a 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 · GitHub
Include non-consensus changes in Meta EIPs, to signal their importance and give client teams a hard deadline for implementation.

Note: this has already proven valuable with PeerDAS (a Networking EIP) being SFI’d for Fusaka. While it’s unclear where to explicitly formalize this, we should discuss whether to similarly “include” EIP-4444 in Pectra or Fusaka.


Formalize the relationship between EIPs being added to devnets and the PFI → CFI → SFI statuses.

To 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”.

Author: abcoathup
Date: 2024-11-26T10:12:13.417Z

timbeiko:

session about process improvements for ACD


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.
ACD’s should be themed/have a main focus (around the phases of the development cycle).

Prior to upgrade planning, ACD’s should focus on long term planning.
Once there is rough consensus on the long term planning (which is subject to change each upgrade cycle) then ACD’s should focus on upgrade planning
Upgrade planning should start with reviewing all the PFI (but not CFI/DFI until all reviewed).  PFI champions should provide written submissions and be given timeboxed slots to present (slides are good) and answer questions (e.g. 5 minutes to present, 5 minutes questions)
Once PFI have all been reviewed, then they should be moved to CFI or DFI.  (Pectra’s window for discussing PFI appeared to be ~6 months).  Written submissions from teams and the community could be done async.  Async rough consensus can be used to then make a decision on ACD which to CFI/DFI.
CFI can then have a short window (ideally 2 weeks) to overcome any major blocking research/implementation tasks
CFI should then be reviewed again (similar to PFI with presentations by champions and written submissions from teams) and moved to SFI or DFI.  The default should be DFI.
Unfortunately due to the overhead of upgrades (2 months of public testnets before mainnet), upgrades are more waterfall model (6-9 months minimum cycles)
PFI being discussed outside of upgrade planning should be the exception, and mostly should wait until the next upgrade planning.

ACD’s should focus on decisions rather than discussions

ACD should be 30-60 minutes to focus on decisions (long term planning & upgrade planning maybe the exceptions) (also shorter calls are less painful for AUS/NZ, unfortunately I don’t see us moving from Eth o’clock)
Any discussions should be timeboxed (5 minutes presentation, 5 minutes discussion/Q&A), if more time is needed then it should be done async or if required move to a breakout and only come back to ACD when a decision is needed.
No new items should be discussed that haven’t already been raised async.  Ideally they should only be raised at ACD if a decision is needed.

ACD transparency

Summary of actions & decisions from ACD within 24 hours (generally hours) is fantastic.  For the last ~6 months we have been storing these on Eth Magicians.  I am not convinced that this is the best location but at least is better than Twitter, Discord or GitHub issues.  They could be stored in GitHub but need to be available within 24 hours.
AI generated transcripts (clearly marked as such) & chat logs should be made available to the community within 24 hours of ACD.  Ideally this happens automagically.

Author: timbeiko
Date: 2024-11-26T15:02:50.601Z

Thanks for the thoughtful reply! Here are a few comments 



 abcoathup:

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


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!



 abcoathup:


Prior to upgrade planning, ACD’s should focus on long term planning.



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.



 abcoathup:

ACD’s should focus on decisions rather than discussions


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.



 abcoathup:

ACD transparency


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.



 abcoathup:


AI generated transcripts (clearly marked as such) & chat logs should be made available to the community within 24 hours of ACD. Ideally this happens automagically.



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?

Author: polar
Date: 2024-11-30T09:32:35.740Z

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

Author: abcoathup
Date: 2024-12-01T00:10:22.636Z

polar:

there is no way for the wider community to express what it wishes to see the focus on


@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:

Pectra Network Upgrade Meta Thread
EIP-7607: Fusaka Meta EIP

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



 polar:

Probably this could be a simple website with a submission form since


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.

Author: nicocsgy
Date: 2024-12-05T22:48:35.287Z

timbeiko:




 abcoathup:


AI generated transcripts (clearly marked as such) & chat logs should be made available to the community within 24 hours of ACD. Ideally this happens automagically.



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?


I like the idea! We could do it easily I’ll make that happen for next ACD. And link it to the corresponding thread in Protocol Calls & happenings. I could probably set that up with a bot account I’ll figure out the details.

Author: poojaranjan
Date: 2024-12-06T18:56:07.926Z

I’m not sure how accurate the Zoom transcript will be, but I can share it with @nicocsgy if that would be helpful!

Author: poojaranjan
Date: 2024-12-06T19:02:43.380Z

abcoathup:

chat logs should be made available to the community within 24 hours of ACD.


The chat log is roughly 14 pages long (in Google Docs). Not all of the conversations are relevant. ECH notes aim to filter out useful links mentioned during the call and include them in the notes. However, if the suggestion is to gather the raw file, do you have a specific placeholder in mind?

Author: abcoathup
Date: 2024-12-07T02:35:46.396Z

I have created a wiki post (that anyone should be able to edit) to discuss protocol call artifacts.
We can discuss the details there, feel free to edit/reply on the wiki post.




Protocol call artifacts Process Improvement


Protocol call artifacts

agenda
transcripts (AI generated)
chat logs
summary of actions/decisions
video recording
third party writeups

Goals

Record of actions/decisions (ideally by the moderator) of each call
Quick access to artifacts by the community
Long term storage of artifacts

Long term storage
Where possible artifacts (other than third party writeups & perhaps recordings) should be permanently stored as files in GitHub - ethereum/pm: Project Management: Meeting notes and agenda items.  …

Author: nicocsgy
Date: 2024-12-07T17:27:47.817Z

Hey Pooja,
I think we’re going to go for a fancier tool than the native zoom transcript. I’m yet to figure out which  one is the most appropriate. If anyone has recommendation, I’m all ears.
I’ll be iterating on this next week