I’m not totally sure I understand what you are saying, but I think it’s something like: under the current system client developers can passively allow EIPs to come to them, while the SIG system would require more active engagement which would strain smaller teams.
I’ve been thinking more about what the structure of SIGs should be for Ethereum, and currently I think this is one case where copying directly from k8s would be misguided, because k8s infra is naturally modular, while Eth is both coupled and diffuse. For example, if there was a SIG State Management it would own ABI, SSZ, RLP, and different Tries, some of which are irrelevant to you as a consensus client developer. So SIGs for Ethereum should probably not be based on research categories.
Instead, I think each Special Interest Group should own and try to maximize one particular key performance indicator of Ethereum. One possible list with examples of who would own different parts of the current roadmap:
- Censorship Resistance (FOCIL)
- Decentralization* (SSF)
- Moneyness (Issuance Curve, Marketing)
- Network Stability* (State Expiry)
- Privacy
- Scaling (PeerDAS)
- Security* (Self-Destruct, Post-Quantum)
- Ship Speed (Process Design, Documentation, Devnets)
- UX Applications (EOF)
- UX End-users (Interop)
- UX Validators (Verkle)
Notably many of these groups already exist in some form or another. EthStaker could slot directly into the UX Validators SIG. Some exist bifurcated in highbrow and lowbrow versions, like RIG and ethfinance for Moneyness. Others exist more informally, for example I understand there is a customary step where EIPs are evaluated for DoS before consideration for inclusion, which could take place more transparently in a Network Stability SIG. But some don’t exist, even though they probably should.
(*those marked with an asterisk would probably be more defensive/veto oriented rather than focused on feature creation, with a dedicated consulting location where other SIGs can ask for advice on EIPs they are considering, as well as dedicated seats in any steering committee).
First off, I think it’s entirely possible for even small teams to have members in all SIGs, as this means that there won’t be very many of them. I think basically every Ethereum developer is here because they are ideologically aligned with at least one of these goals, and therefore naturally would want to be part of a group which is working towards them.
Secondly, you can see it’s not actually necessary to have a representative in every SIG. For example, consensus client developers probably don’t need to interact at all with SIG UX Applications.
Finally, it should be noted that the purpose of SIGs isn’t to coordinate development. That is what the fork coordinator (or ACD) is for. It’s to coordinate decision-making: SIGs provide entry points for people to get involved, places to build consensus and collaborate, and unified groups to lobby for features. The intention is that the only thing a client developer has to do for the fork itself is to implement and test. As a result, it should be entirely possible for client developers to tailor their degree of involvement, including an entirely passive or purely advisory role if that is what is desired.