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?
There are quite a lot of people from the ecosystem that will get a decent ranking. Over time this will also more and more grow, as the knowledge spreads
After the first wave these people will also be able to vouch for others and to onboard them into the fellowhsip.
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?
At the moment the criteria are very tightly focused on core code, so contributions to things built on top of Substrate or Polkadot donāt explicitly count.
@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
Candidates require a deposit and I am not sure if we would record them as well in the seeding phase. Probably best to submit your interest in this rank as soon as the onchain fellowship is live.
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 got interested if thatās the case here, so I coded up a little program to try and project the Fellowshipās political decentralisation over time: Fellowship Voting Power Scenario Simulator
Sorry to make you click a link to reach my analysis and results. Hereās a very short summary:
Hypothesis: the Fellowship thatās described after page 3 in the manifesto, as well as in the forum thread, risk becoming heavily politically centralised,
Method: To test this and facilitate objective discussion, I coded a simple simulation of how
the voting power of the seed group might develop compared to the collective voting power of everyone else.
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.
