Ethereum Core Dev process
Apart from technical details of the protocol, it's important to understand how the whole upgrade process and core development works to be able to follow it. This page provides some context and resources with more details about its current structure.
The ethereum/pm repository is used for Ethereum project management purposes. It serves as a coordination for planning developer calls and archiving their recordings. Core developers across all teams meet weekly at All Core Devs calls. These are dedicated specifically to Consensus (ACDC), Execution (ACDE) and Testing (ACDT). When learning about the protocol, it might be useful to follow these and explore what are current efforts in the protocol work. Apart from ACD calls, there are Breakouts dedicated to more specific topics like implementation work of a specific EIP. Follow these if any of current breakouts fall in your area of interest.
The ACD is part of a larger process that helps to upgrade Ethereum constantly, bring more features, security, scalability etc. These upgrades are versions of Ethereum you are familiar with from other presentations, Devcon city names in execution like Prague, Osaka, and their consensus counterparts carrying names of stars, e.g. Electra, Fulu. Both CL and EL devs need to coordinate to delivery a hard fork that brings new features but is not compatible with previous version of the network.
This requires lot of coordination and testing as detailed in other lectures. The overall process starts with EIPs being created and proposed for specific upgrades, either as major often complex features carrying the headliner title or smaller improvements alongside. The process to accept these EIPs into following hard fork requires consensus across developers and community, sometimes making it hard to plan further into the future.
EIPs get prioritized into those considered for inclusion (CFId) and declined. CFI EIPs are then more deeply discussed to choose those fitting the implementation scope and moved to Scheduled (SFId). These EIPs are then finally implemented across clients, first individually and then becoming part of iterating public devnets. These are ephemeral networks only meant to test the interop of current implementation step (only part of SFId EIPs are implemented). With all of the development done and testing passed, hard fork gets scheduled to be deployed on public testnets. These are regular testnets used by app developers so they provide more realistic testing ground for the new upgrade. After all of this, the mainnet is scheduled with enough room for the community to get ready and upgrade their nodes.
Following chart explains the whole process in detail. The best resource for up to day tracking of current development is https://forkcast.org/
Check the presentation by Tim Beiko with his overview and examples of the development process: