Calling Polkadot Core Developers

I’m glad to see that we’re slowly building the initial cohort of members of the Fellowship. There has been a little confusion around what actions and expertise the Fellowship membership is designed to recognise; I’d like to clarify that a little.

Firstly, like the Technical Committee, this is a technical collective. Members are expected to have rich technical knowledge and in software this pretty much means code (non-executable symbolic/formal languages may also suffice). This expertise should be enough to debug and fix faults in at least one area of the protocol. For Fellows, the expertise should run to actually designing and implementing substantial components. Communication is a element of membership, but being an educator or mentor is not nearly sufficient.

Secondly, this is about expertise which is required by and primarily utilised for the Polkadot (Main) Network. Not Kusama. Not the parachain community. Not ecosystem participants such as exchanges.

Technology and code utilised by the wider Polkadot community (some of which is developed by Parity or sponsored by the Web3 Foundation) is no doubt important for the success of Polkadot. But it is not the intention of the Fellowship to address the continued maintenance and development of this code. This is, mostly, a matter of practicality and pragmatism. It’s easier to define smaller, more constrained sets.

Also, there’s a little confusion over what rank is appropriate. There is some pretty comprehensive guidance in the Manifesto, but here’s a quick overview:

  • I Dan: Contributors to core code who have made several small but non-trivial PRs (e.g. bug fixes, minor features) and who “get” what Polkadot’s about. I expect there will be quite a few community members in this category. There are no specific time requirements for this rank.
  • II Dan: Those who have been focusing on Polkadot and contributing for a full-time equivalent of 1 year or more. An article from them on Polkadot’s technology as well as making a contribution to the realisation of a major component (e.g. a pallet or crate). I’d expect there’s a few community members at this level, but not so many (yet!).
  • III Dan: Those who have played a primary (or sole) role in implementing a substantial core component (think a mid-sized pallet or crate) which is required by Polkadot and have been making non-trivial contributions to Polkadot for 2 years FTE. We’d expect a near-continuous level of availability to maintain the network (with extended periods of absence to be made known in advance). We’d also expect a few articles by them and at least one presentation on core Polkadot matters. There are very few community members at this stage and it’s really meant as a watershed threshold.
  • IV Dan and above: At this point you’re proposing, designing and realising core components yourself and writing long-form articles about it. Being the primary person to design and realise SASSAFRAS, XCM v4, FRAME v2 would be a great argument for getting this level of rank. You’d be mentoring new fellows and guiding core development and prioritisations. You’d also have to be working on the Polkadot core technology for over 3 years FTE. I don’t personally know of any non-Parity members at this level, but hopefully the Fellowship will facilitate this!

As the Manifesto mentions, the Fellowship is not intended to be entirely unique. Once proven as a concept then I, for one, would back additional Fellowship-like constitutional ranked member organisations for a number of other fields. The trick is in adequately defining the scope and rank requirements, and here I think a wider community discussion could be useful.

Expert-base collectives (“additional Fellowship instances”) I see being potentially useful:

  • Ecosystem technology (similar to the Fellowship but designed to cover a much broader base of technological expertise not strictly required by the Polkadot (Main) Network). Could include technology in typical use across the ecosystem including e.g. ORML, validator tooling, infrastructure tooling, wallets, contracts, Ink!, UI toolkits and off-chain integrations.
  • Pure research and, perhaps, specification - pure research is explicitly not covered by the Fellowship.
  • Community development, adoption, outreach and technical education.
  • …?
10 Likes