AllCoreDevs, Network Upgrade & EthMagicians Process Improvements

Process Improvement
1

ACD & Process Improvements

June 19 update

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.

13 Likes
2

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.

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

2 Likes
3

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

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

3 Likes
4

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.

5

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

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.

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.

6

Thank you for the thoughtful comment! Some thoughts:

ACD Proposals

  1. 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 :smile:
  2. 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?
  3. 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

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.

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

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!

On one hand, I’d love this! I often (half) joke that OBS is the hardest part of my job :smile: 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!

1 Like
7

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.

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

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

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:

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.

2 Likes
8

ACD Proposals

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.

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.

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

1 Like
9

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!

1 Like
10

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.

11

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

1 Like
12

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

14

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

1 Like
15

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 :slight_smile: . They may need support too, perhaps this can be accomplished by this emerging group to improve the process.

1 Like
16

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

2 Likes
17

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” :sweat_smile: . 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.

2 Likes
18

Thanks for all the suggestions, @bumblefudge :pray: !

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 :smile:), 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.

3 Likes
19

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.

1 Like
20

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

21

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