Clarify the scope of the Core Fellowship

[xlc]

We need to clarify the scope of the Core Fellowship so that new members can know in what area of work are considered in scope.

While we have manifesto as the source of truth, but it still leaves many rooms for interoperation and from recent discussions, it is clear the members do not have a consensus about this topic.

I am starting this issue in order trying to allow members to reach a consensus about this topic and then we will be able to produce a clear guideline for new members.

PS: I am not sure if this is the best place for such discussion, but at the same time this topic doesn't feel like in the scope of RFC. So I started this here for now and see if we can figure out the next step together.

Here is the quote from the manifesto for reference:

2.3.1. Specifics. Based on the above, we may conclude that expertise on the following technology and its strict descrip- tion(s) and/or implementation(s) would be considered a goal of the Fellowship: • the internals of all functional Polkadot node implementations; • cryptographic data-structures, algorithms, languages and apis required for the continued upkeep of the Polkadot (Main) Network; • consensus algorithms concerning the Relay-chain (babe & grandpa); • trust-free bridges relying on said consensus algorithms (planned to be) utilised by system chains; • parachain consensus; • cross-chain message passing (xcmp, hrmp, dmp & ump); • the Polkadot libp2p-based peer networking protocol; • the Polkadot topology strategies; • chain synchronisation strategies utilised by Polkadot; • the Polkadot business-logic (aka the “runtime”); • pallets utilised by the Polkadot (Main) Network and its system chains; • the internals of the frame pallet framework; • runtime and host apis; • the xcm specification and realisation; • standard rpcs; • 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. In short, if expertise on a technology (or a specific implementation of it) is required and primarily used for the Polkadot (Main) Network to continue operating and improving, then it is covered. If it is not then it is not. Notable examples of technologies/code which are not covered: • Rust language (required by realisations of the Polkadot Network, but not primarily used for them); • libp2p (required by the Polkadot Network but not primarily used for it); • ‘subxt‘ (useful tooling, but not required for Polkadot’s continued operation); and • ‘ink!’ (useful tooling, but not required for Polkadot’s continued operation).

This is the list of repo I believe that are in scope and everyone will agree:

• https://github.com/polkadot-fellows/runtimes
• https://github.com/polkadot-fellows/RFCs
• Everything under https://github.com/paritytech/polkadot-sdk/ that is also included in the runtime Cargo.lock file
• https://github.com/paritytech/xcm-format

This is the list of repo that are currently considered in scope but may require additional discussion:

• Everything under https://github.com/polkadot-js

This is a list of repo that I would like to seek for clarification that if they are under scope of the Core Fellowship

• Everything else under https://github.com/paritytech/polkadot-sdk/ that's not included in the runtime Cargo.lock file
• Tests related to Polkadot runtime. e.g. Acala's XCM tests, polkadot-integration-tests
• Testing tools powers the tests. e.g. Chopsticks, xcm-emulator, xcm-simulator
• Fuzzer. e.g. substrate-runtime-fuzzer

[xlc]

Also I would like to ask why subxt is considered out of scope but polkadot.js is. They are equivalent tool to my understanding.

[xlc]

I personally believe tests are in scope because it is not possible to develop the runtime properly without tests. It is an industry standard that tests are part of the software being developed.

In that case, the testing tools powers the tests should also be considered in scope if they are primarily used for the Polkadot (Main) Network. This means general testing framework like jest wouldn't be counted but Polkadot specific tool like Chopsticks, xcm-simulator etc should be counted. The same apply for the substrate-runtime-fuzzer as it is a required tool to improve the runtime.

[kianenigma]

Everything else under https://github.com/paritytech/polkadot-sdk/ that's not included in the runtime Cargo.lock file

Majority of the code under /substrate and /polkadot is also directly part of the node implementation of Polkadot.

Testing tools powers the tests. e.g. Chopsticks, xcm-emulator, xcm-simulator

I am leaning toward acknowledging that tools that the fellowship regularly uses to ensure basic correctness should be part of the duties of the same fellowship. In a very ideal world, there would have been a separation, but I think in it is beneficial to have them together for now. We also don't want to paint the picture of "micro-fellowships" :)

Also I would like to ask why subxt is considered out of scope but polkadot.js is. They are equivalent tool to my understanding.

I agree that the boundary there is a bit fuzzy. For this case, I prefer to see a separation rather than adding more topics to the corer fellowship: there should be a UI/Ecosystem Fellowship that contains such tools, and then the PJS apps/api can be removed from the core fellowship.

But admittedly it is hard to come up with the boundaries of such a new fellowship as well.

[chuacw]

There is a discussion feature on GitHub for every repo. If/When this is enabled, we can start the discussion there.

[gavofyork]

Also I would like to ask why subxt is considered out of scope but polkadot.js is. They are equivalent tool to my understanding.

polkadot.js was habitually by most used for a broad amount of on-chain interaction for the ongoing operation of the Polkadot network, especially regarding the numerous times we must craft specialist extrinsics for enacting certain upgrades, configurations or deployments.

Should subxt end up being a practical necessity for the ongoing operation of the Relay-chain and system chains, then I'd be fine with adding it.

[xlc]

Joe is using subxt to craft extrinsics for enacting upgrades https://github.com/joepetrowski/opengov-cli

[kianenigma]

Worth noting https://forum.polkadot.network/t/proposing-the-polkadot-tooling-collective-potoc/6915/3 here as it is a step forward in this conversation.