Governance version 2, and with it the Polkadot Fellowship, is about to launch. For those who do not know, the Polkadot Fellowship is an on-chain body designed to represent the voice of the technical experts on the Polkadot Network and its protocol. In a loose sense, it takes over from the Technical Committee and is substantially more decentralised, designed to have as many members as there are core developers/designers of the protocol.
The Polkadot Fellowship Manifesto, a document explaining the background to its creation, its purpose, goals and rules is available in the Manifesto repository. In this document you’ll find a description of the subjects of knowledge which are relevant for membership of the Fellowship as well as the expectations and requirements for each rank within the Fellowship.
As part of the rollout, the existing Technical Committee will be given the ability to seed the initial members of the Fellowship. To help optimise the Technical Committee’s work, if you have a substantial technical knowledge of the Polkadot protocol please make yourself known by creating a pull request in the seeding repository.
The pull request should:
be titled “Member Request”.
be made by your regular Github username.
include in the content a single change to README.md which is one additional row to the table in which you add the rank you believe best represents your contributions, Kusama Account ID and Github ID.
include in the description the range of ranks you believe would be reasonable given your contributions.
include in the description a reference to the earliest non-trivial pull request to a core Polkadot code repository.
include in the description a reference to the most substantial pull request to a core Polkadot code repository.
Please also ensure that your public Kusama network address is included in your Github bio.
Please keep an eye on the pull request as the TC may review and ask for clarifications on contributions.
I am extremely interested in the developments of the fellowship, this is truly an exciting new age of governance for Polkadot!
I would like to know how open the fellowship will be towards mostly parachain engineers.
Since the idea is to decouple from Parity developers, this presents a conflict of interest if the acceptance criterias revolve around the codebases that are mostly managed and worked on by Parity developers, so I would believe that not only acceptance but also decent ranking of ecosystem developers should be a big priority, right?
I see, well, from the descriptions of the ranks in the manifesto I placed myself in rank 1, so that’s where it gets confusing for me. I have written extensive code for parachains and even have 2 completely unique parachains connected to Kusama which I have led the development of, so the question that I come out with is: Should I keep my rank as 1 in the request, or should I take other criteria besides the ones described in the manifesto and request for a higher rank?
@gavofyork The manifesto mentioned benefits for the members (which is a good incentive in general), but I didn’t see any reference to how it gets financed (I might have missed it)?
Also, I’m a bit confused if I should ask my team to participate or not.
I’m in favor of having more knowledge/participation into the technical part of the relay/ecosystem, but I’m also worried of the impact it would have on their work (Specifically if they receive benefits for their participation). My (first) understanding of the manifesto seems to imply some responsibilities, but I’m not sure to which extend those go.
I would expect that the Polkadot Treasury be the benefactor of the pool of expertise crucial to its own existence, however of course, this is a decision for the wider Polkadot governance.
Members of the Fellowship in receipt of funds will generally not be working full time on other projects, even projects building on top of Polkadot. As the Manifesto states, their focus is expected to be very much on the Polkadot core code and technologies - those required for Polkadot to operate. While there is a lot of excellent technology built on or around Polkadot, this is explicitly not covered by the Fellowship Manifesto.
So it is not meant to actually gather knowledge and expertise around Polkadot development, but more to create a team of developers to contribute/maintain/evolve the Polkadot “base” (around Substrate mostly), is that correct ?
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.
There’s certain quite a bit of the Substrate codebase which is covered as “core”, yes. Also, all of the Polkadot codebase, Smoldot, Cumulus, several parts of Polkadot-js, bridges and quite a bit of lower-level technology which these rely on. There are additional realisations of Polkadot - not yet able to sync - which I would argue should also be covered once they are able to practically help maintain the network (i.e. once they can function as a node).
I initially thought, mostly from previous previous talks, that it was intended more for a larger audience and was hoping this would serve parachains (Moonbeam included) to have access to a “collective” of experts helping with technical decisions/progress.
I would have loved to replace our Technical Committee by the Fellowship (which we could finance through our Treasury too). Not only because those from the Fellowship would have the technical abilities to understand the details but also because they would have a wider view (if you include other parachain experts too) of the ecosystem and the implications of those changes.
I guess that it might be one of the next steps of the Fellowship
The Polkadot Fellowship is intended to be only the first of its kind. It focusses
on the sustenance and enrichment of technical expertise relevant to the Polkadot network primarily concerning the core
protocol and its implementation
We should, as a community, devise other similar ‘Fellowships’ or associations for different key types of contribution to the network once the initial fellowship is off the ground and running
Having many members is not the same as being politically decentralised. Some members will have substantially more voting power than others, so the number of powerful members might stay very small for many years.
I’m sure I made mistakes along the way towards producing that plot. I would be very interested in a plot that reflect Gavin’s or other top contributors’ assumptions about how the Fellowship will work and develop.
As well as facilitating discussion, a projection/simulation can be used to track where we’re heading, once real data about voting and participation becomes available.
I’m not a Polkadot Core Developer, so I my input here might be a bit… uncalled for, but friends at Parity suggested I discussed this here. I hope it finds you well, anyways.
Thanks for the detailed analysis, @tobbelobb . Ultimately, the fellowship is only one of many paths towards political decentralization. Its decision-making power is highly limited to growing its own ranks, and approval & whitelisting of protocol upgrades which can be easily overridden by the rest of the governance system. These bodies form checks-and-balances on each other. In the worst case, where all early fellowship members form an internal cartel against all new fellowship members, it would be easiest to remain ‘centralized’ by simply not accepting any new members. That said, the seeding group already consists of developers from several different organizations: Parity, Acala, Gear, Composable, InvArch, and others - each with their own viewpoints of how technical progress should be made.
Qualitatively, I don’t believe such a degenerate case to be a likely outcome, and any similar degenerate case can be overridden by other governance entities to replace or restructure the fellowship if it’s not doing its job.
That already makes the scenario in the plot above very unlikely indeed. My guessed seed group is way off. Will I find all members here: Pull requests · polkadot-fellows/seeding · GitHub ? I think I see most people I’d expect, except Gavin there.
Ah, yes the possibility of a proper referendum to override or fix a dysfunctional Fellowship was actually a big gap in my analysis when I posted.
This is interesting because the Fellowship could be on track to decentralise quite quickly then, which opens up for new scenarios. The same mechanisms that could have enabled a degenerate case (which now seems unlikely) will could eventually preserve already established decentralisation and make it harder to reverse.
I tried making assumptions based on top members really trying to decentralise. See for example that Parity’s combined voting power reduces between year 0 and year 1. The main uncertainty I see is associated with how many more fellows will appear from outside Parity compared to inside of Parity per year. This number was guesstimated to 15, which might be way off in either direction.