Generally very supportive of the idea. The main issue acknowledged here is something that I resonate with, it is time to resolve it:
…These developers often find that their contributions are not recognized within the mandate of the Core Fellowship.
Drawing further on what you coined “Core Tooling”, to further clarify the scope, I suggest considering removing the following (see here) from the core fellowship, either now or later, and make it be solely part of the PoToC:
- user-interface code required to practically execute upgrades to the Polkadot (Main) Network; and
- code or technology required by, and utilised primarily for, any code or technology already included.
I think the definition of what is required to execute upgrade upgrades is fuzzy, and falls more reasonably in PoToC rather than core fellowship.
In the most extreme case, I could argue that all that is needed to do basic interaction with the Polkadot network and execute runtime upgrades is merely having a computer with curl and access to the internet to execute transactions.
Some tools in each category that come to my mind (personal opinion):
Core Tooling: Low level RPC/Chain APIs, such as PJS-API, SubXT, substrate-py-interface. PJS-Apps or an equivalent “developer console” UIs(see here), Metadata Portals, Block Explorers. (Hardware) Wallets/Dashboards that provide at least (cross chain)transfer functionality, and/or ability to interact with core Polkadot features, such as Staking and Governance, Multisigs and Proxies.
dApp Tooling: Faucets and Test networks. CLIs. Notification services. Portfolios. Analytics dashboards. High level libraries.
I think the main bottleneck is to come up with a definition of what counts as “Tooling” for either Core or dApp. The distinction between the two can be something that is later fleshed out by the collective itself. I hope my list above helps with that.