ethereum/pm is an issue tracker with a meeting attached to every agenda

Three call series, alternating weekly, and why that schedule matters

AllCoreDevs is a weekly meeting held by the Ethereum development community to discuss technical issues and coordinate work on the protocol, attended by core contributors from various organizations. During a call, participants discuss potential protocol changes, testing and related issues.

The schedule alternates by focus. On one week the call focuses on the consensus layer, meaning proof-of-stake, the Beacon Chain and similar; on alternate weeks it focuses on the execution layer, meaning the EVM, gas schedules and similar.

That alternation is the structural fact to hold onto. It means the repository has three separate call series rather than one: Execution, abbreviated ACDE; Consensus, abbreviated ACDC; and Testing, abbreviated ACDT. Anyone reading the meeting index is reading three interleaved sequences, and an item that looks stalled in one series may simply be waiting for the other half of the protocol.

On top of the three series there are breakout calls on specific core development topics, tracked through an `active-breakout-series.md` file in the `Breakout-Room-Meetings/` directory.

The call numbers in the README index show how established this is: ACDE is at 247, ACDC at 188, and ACDT at 100, with entries going back at least to September 2026.

Agendas are GitHub issues, and anyone may comment on them

The mechanism for participation is unusually low friction, and it is worth describing precisely because it is the part most people do not know.

Agendas live in the repository's Issues tab. To add an item to an agenda, you add a comment to one of the agenda issues. Anyone is welcome to do this, provided the item follows three guidelines.

The topic must be technical in nature. It must involve the Ethereum protocol at a low level, which means Ethereum applications and ERCs are generally not allowed as topics unless their mention relates to protocol changes. And it must not be philosophical: the core developer meetings are not meant to decide philosophical, contentious issues that should be decided by the community.

That third guideline is the interesting one, and the README explains the reasoning, noting that there are exceptions but that such topics distract from more productive technical discussions, and pointing to the Ethereum Magicians forum as a better venue for them. So the rule is not a silence policy; it is a routing decision.

In practice, the process means a public, time-boxed queue of protocol topics where anyone can add an item by commenting on an issue, with the meeting number and date fixing the deadline. There is no private agenda to be leaked later, because the agenda is the issue tracker.

A Google Calendar is also maintained that tracks upcoming protocol meetings, which is the practical way to know when a deadline is.

Where the actual content lands: forkcast, Magicians, video and transcripts

An agenda issue is where a discussion is scheduled, not where it is recorded. The README describes four destinations for what comes out of a call.

Discussions happen in the Ethereum R&D Discord server and on Ethereum Magicians. Upcoming and past call information, meaning transcripts, video links and summaries, can be found on Forkcast and on the table at the bottom of the README. Recordings are hosted on the EthereumProtocol YouTube channel.

So the repository is the index and the agenda, not the archive. That distinction matters if you are trying to find out what was decided about something: you follow the issue number from the README table to the Forkcast page, to the Magicians thread, and to the video.

The README's own table shows the columns, and the pattern in them is informative. Each row carries Date, Type, call number, Issue, Summary pointing at forkcast, Discussion pointing at an EthMag thread, and Logs pointing at a transcript directory. Recording is present for ACDE and ACDC rows and shown as a dash for ACDT rows, which tells you the testing calls are not recorded to video in the same way.

The Logs column points at a separate transcript repository rather than into this one. So a reader who wants the verbatim record leaves this repository entirely, and this repository is the durable table of contents.

The most recent entries listed are ACDT Call 100 on 12 Oct 2026, ACDE Call 247 on 08 Oct 2026, ACDT Call 99 on 05 Oct 2026 and ACDC Call 188 on 01 Oct 2026, which is consistent with the weekly alternation described above.

Facilitators and repo management are named, which makes the process legible

Governance of the meetings is documented with names and dates, which is unusual and useful.

The README lists current facilitators with the date they started. Execution has coleads Ansgar Dietrichs, from Oct '25, and Nixo, from Apr '26. Consensus has Alex Stokes, from Sep '24. Testing has coleads from the EF EthPandaOps team and the EF STEEL team, linked as organisations rather than individuals.

Past facilitators are listed too: Parithosh Jayanthi as interim ACDC, Tim Beiko for ACDE, Danny Ryan for ACDC, Hudson Jameson, Lane Rettig and George Hallam.

That list reads as a record of turnover, which is the honest read of open source governance at protocol scale. It also tells you something practical: if you want to influence how an agenda is run, you know who runs it and since when.

Breakout rooms are described as usually chaired by the expert or champion for the topic at hand, which is a sensible rule. A breakout on a specific topic chaired by the person who knows that topic is the difference between a working session and a status update.

Repository management sits with the Ethereum Foundation's Protocol Support team together with the ACD call facilitators, and the README also names a direct contact, Nixo, with a mailto address, for people who want to reach out about attending.

Attendance is by invitation to protocol developers, researchers and EIP authors, with regular attendees including Ethereum client developers, testing and security teams and independent contributors. Sometimes non-core contributors with particular expertise on a topic are invited to discuss a specific agenda item.

What sits in the repository beyond the meeting table

The top level directory listing shows more than meeting notes, and two entries stand out for anyone trying to find current protocol state rather than history.

There is `glamsterdam-mainnet-plan.md` and a `glamsterdam-pm.md`. Those are the working documents for a named network upgrade, which is the kind of file that answers the question "when does this change ship" in a way that meeting transcripts never will.

There is also a `Network-Upgrade-Archive/` directory, which by name is where previous upgrade material is retained.

Alongside those: `AllCoreDevs-EL-Meetings/` for execution layer meetings, `AllCoreDevs-CL-Meetings/` for consensus layer meetings, `Breakout-Room-Meetings/`, `Interop-Notes/`, and `processes/`. The last one is worth noting because the README describes no process documentation beyond the agenda guidelines, so `processes/` is likely where anything more formal lives.

There is also `all-forks.json` at the root. Given the name and the protocol context, that is fork data, and it is the kind of file that other tooling reads rather than humans.

The repository also carries a `.github/` directory, which is where issue templates and label configuration would live. The label structure is visible from the README's own links: issues are filtered with `label:ACD` combined with `label:Execution` for ACDE, `label:Consensus` for ACDC, and a combined `ACDT` label for testing calls, so the three series are distinguished by label rather than by repository.

A custom licence and a repository that is documentation, not code

Two classification notes that matter if you plan to reuse anything here.

The licence is recorded as Other, a custom licence GitHub cannot classify, with the LICENSE file as the authority. For a repository whose content is meeting agendas, transcript links and process notes, a custom licence is plausible, but you should read the LICENSE file yourself before mirroring, quoting or redistributing content. The README does not summarise the terms.

The second note is that this is not software. GitHub's language detection reports Python as the primary language, which reflects tooling or scripts rather than anything you would install. There is nothing to clone and run.

It also has effectively no release history. The single GitHub release listed is named `acd-video-bumper-v1`, described as an ACD video bumper and dated 2026-05-21, which is a video asset for the calls rather than a versioned software artefact. The last push was on 2026-10-15, so the repository is actively worked on; it is simply worked on as documents.

If you were looking for a tool, this is the wrong repository. If you were looking for the record of how Ethereum protocol decisions are proposed and discussed in public, it is exactly the right one, and the fact that it is boring infrastructure is the point.

Editorial conclusion

Adopt ethereum/pm if you are following or preparing Ethereum protocol work, since the agendas, the meeting index and the transcripts are the public record of how protocol decisions get made. Do not treat it as a technical artefact: there is no software here, and the primary language detected is Python only because of tooling directories. Verify first the licence before mirroring content, because the repository is marked with a custom licence rather than a standard one, and check `glamsterdam-mainnet-plan.md` and `processes/` if you need current network upgrade state rather than meeting history.

Frequently asked questions

Official sources

1. ethereum/pm on GitHub
2. Issues
3. README
4. Releases