-
I would just use the existing tools in the Fellowship. Rank can be based on prior contributions and knowledge/experience, but to take a salary, one needs to defend their rank periodically. The default is demotion. If you know your impact will be low, then you can go off salary for your break to maintain your rank.
-
The Salary and Core Fellowship pallets. To prototype, probably fork the Collectives chain and launch a local network and tinker until you’ve set everything up.
-
Ideally, Collectives serve as a means for people with differing viewpoints to collaborate, even if they don’t agree all the time. I do see what you mean, but the system collectives chain is probably not the place for that (due to (4)). Perhaps something on a smart contract chain can facilitate these experimental groups and the Treasury should be lenient in funding them (e.g. just like accelerators have a “fixed deal” like X% equity for Y dollar investment that they offer uniformly). The Treasury could have a standard “Collective Experiment Funding Application” to help people get started.
-
Yes, there is. A runtime can only have 256 pallets (this is due to them being represented in an
enumdata type, which indexes its variants with au8). The first 50 are more-or-less reserved for system things (Session, Collators, Balances, XCM, etc). Also each collective is about 5 pallets (collective, referenda, treasury, origins, …). I think that for the collectives that make it there, there should be strong consensus about the mandate and that the membership criteria will find the best people/groups to fulfill it. That is not to say that experimentation/competition/tinkering is not valuable, it should just probably happen on something faster moving and more flexible. -
Ultimately Collectives need to manage their membership, that’s one of their features. I could imagine a change to the Ranked Collective pallet that allows people to place a deposit to become rank 0, but would need an existing member (or group of members) to admit them as rank 1.
To kick things off, I want to echo @joepetrowski’s insights shared in this discussion. It’s exciting to see the integration of Polkadot SDK #1333 in the Polkadot v1.3.0 update, expanding treasury allocations beyond just native assets. By the way, this is already live on Rococo and Westend.
The Multi-Asset Sub-Treasury initiative isn’t about diminishing voting rights or influence. As @joepetrowski pointed out, it’s primarily a first-level filter to cut down on irrelevant chatter. The concept is to have specialized groups manage specific, smaller proposals. This way, they can sift through the minor stuff and bring only substantial, combined proposals to the main Treasury for consideration. Since OpenGov came into play, we’ve seen a surge in Treasury proposals. With market trends suggesting an uptick in the bull market, it’s becoming increasingly challenging for the community to thoroughly review and vote on every single proposal, in my opinion.
Furthermore, it will still be possible for proposals to be brought directly to the wider community’s attention, allowing every user a chance to have their say on spending through the main treasury.
I don’t really see it that way, collectives should be able to approve proposals from their own treasuries. And if they are operating well, only good ones. Ideally the main Treasury is acting as the “Supreme Court”, the final appeal after proposals have been rejected by a collective.
I feel that the dynamic that’s likely to come out of this is - proposal to a collective → yes? good : no? immediately to main treasury with proposal. It won’t end up cleaning up the noise as much as just duplicating work.
And proponents may say ‘no because the collective will step in and say they rejected it already, saving mindshare’. The issue with is then we’re in a roundabout way back to the original idea where collectives essentially just act as technical committees who are paid to do their due diligence, create proposal templates, signal their intention to vote, etc. This is all solved more easily and naturally if we just nix the first class voters and go with the lighthouse model the fellowship is pursuing.
If we continue down the blocking-collectives path and stand staunchly behind it as our solve for the filtering issue we’re going to end up creating a court of appeals. And that’s just all unnecessary.
Also - somewhere along the way I messed up comms and now people think I’m against multi-asset subtreasuries. I’m for this. Everyone is for this. It’s an amazing idea. I’m speaking to blocking-collectives specifically.
What are blocking collectives?
Its shorthand for the model where only the collective can vote on a given subtreasury proposal.
What about this structure -
There’s the main treasury. It can vote in a subtreasury. At the creation of the multi-asset subtreasury a salaried collective is created as well (all the same up to here).
The only difference being subtreasuries allow for the setting of a weight parameter [0,1] by opengov. And this weight parameter dictates how much the general populations vote counts and how much the collectives vote counts.
This way we have balance of powers, we lean into the nice properties of continuous functions, and we can change it as the network evolves and grows. I assume initially it would be heavily weighted towards the collective as we need speed now. Then later find a nice middle ground.
It also allows the general population to signal how the vote would do in the main treasury, hopefully diminishing duplicate proposals.
I feel this is best of both worlds, not to mention flexible.
@sourabhniyogi I am taking our discussion from Polkadot Builder Collective. Before setting up individual Collectives we should focus on the general structure. I would personally really love to be involved when it comes to forming Collectives. I am a lawyer not a dev so if I can connect with someone who can show me how the collectives logic is set up on chain, it would be really helpful in understanding how can the social rules be set up around it. There is a long road ahead of us, collectives are a fundamental structures with high degree of importance so we shouldn´t rush it.
We should refrain from creating too many Collectives with overlapping goals. That would lead to dilution of ideas and discussion. It would also lead to a lot of administration and funding needed for these structures to run day to day. I would argue that forming few Collectives with quite broad areas of expertise that would be subdivided into smaller more agile groups around bounties is a better approach.
Right now main focus should be:
-
Analyze the current logic of the Fellowship and brainstorm if there should be any tweaks or improvements to the current structure before we start creating more collective. (I personally believe that collective members should have verified identity, especially if they will be receiving salary so the collectives can protect themselves through legal means if there is a bad actor.)
-
Analyze all current initiatives and communities to see what Collectives, it would make sense to create.
Right now I see three main areas where collectives would make sense.
- Technical Fellowship consisting of developers (Divided into subDAOs focused on core code and the ecosystem development. We should think about merging the Polkadot Alliance into it, because we have already many people in both so it only makes sense.
- Marketing Fellowship consisting of marketers, content creators, ambassadors. Divided into subDAOs/Councils focused on marketing strategy, events, onboarding, design, socials, etc.
- Governance Fellowship consisting of delegates. Divided into blocks focused on auditing, proposal template creation, proposal draft creation, etc. Similar to what is being proposed in the OpenCommunity Governance project by @CoinStudio mentioned in their comment.
Apologies about the poor phrasing. I definitely agree with your response!
The proposals I was referring to here are those which seek funding of the Collective’s treasury for a longer time period (i.e. quarterly, half-yearly, annually).
- Technical Fellowship consisting of developers (Divided into subDAOs focused on core code and the ecosystem development. We should think about merging the Polkadot Alliance into it, because we have already many people in both so it only makes sense.
- Marketing Fellowship consisting of marketers, content creators, ambassadors. Divided into subDAOs/Councils focused on marketing strategy, events, onboarding, design, socials, etc.
- Governance Fellowship consisting of delegates. Divided into blocks focused on auditing, proposal template creation, proposal draft creation, etc. Similar to what is being proposed in the OpenCommunity Governance project by @CoinStudio mentioned in their comment.
Personally, I agree with the Technical and Marketing. However, there should not be a specific Governance Collective. AFAICS, the idea is rather to reduce noise from verticals such as those two mentioned as well as others (e.g. Ambassador Programm, Anti-Scam Team, Parachain Fellowship, …). This enables the community to stay focused with proposals either not belonging to any existing Collective or seeking final appeal after being rejected by the corresponding Collective.
The idea of the governance collective is not to give it hard powers over the decisions making process, but rather have a place body with soft powers (use the power of argumentation and data) where delegates can share their expertise and provide oversight over what is happening in OpenGov. Then the Community can take their findings. The collective would inform holders about the decuision making process and support decentralization of delegates so there are not only big Delegates such as ChaosDAO, but also independent individual delegates for the voters to have more choice.
I think since you’re not a dev yet but are fascinated by collectives you probably should study the one collective that does exist and its manifesto before rushing to expand its charter. I strongly recommend you read 2.3 of the Polkadot Manifesto very closely. Gavin didn’t expand 2.3.1 to the entire Polkadot builder ecosystem for very good reasons, which you might not appreciate unless you actually follow the tech at the code level the way real Technical fellows do.
If you understand what all those terms are as a lawyer, that’s amazing – @joe may give you some friendly advice on the sanity of trying to recharter it to include something more expansive as you suggest. I should think only a senior fellow with experience in the fellowship would be able to expand its charter against its founders own very well thought design =). Good luck!
I have red the Manifesto few times and I understand the way it is set up. All I am saying is that the ecosystem devs and core devs are a very similar group of people.
So you can have either two collectives with very similar members each focused on a different thing or you can have a Technical Collective which is divided into sub Collectives (Fellowship and Alliance) where one si focused on building the core code and one is focused on the ecosystem around the core code.
The end goal is similar, but the structure around it is a bit different. In the first case you have 2 governance systems, 2 treasuries, 2 reward structures which comes with added costs. The other can share those which can safe a lot of resources.
Besides the fact that they are not, we should be quite cautious about scope creep and the mandates of particular collectives. The Ecosystem Tech Fellowship that I had in mind mentioning here is quite different to the Core Fellowship. There were a few meetings/forum threads about this but it never came to fruition (although would still like to see it).
You are basically saying, “the members of those two groups are developers, so let’s combine them into one group.” But they bring different knowledge, experience, and perspective. The Core Fellowship has experience in the core Polkadot protocol, why things were designed and implemented the way that they were (because they quite literally implemented large amounts of it themselves), and thus can understand the consequences of modifying certain parts of it.
A Parachain Technical Fellowship would bring experience more focused on running a parachain on Polkadot and the challenges associated with it. They might use their power to unbrick parachains (a matter in which the Core Fellowship would want to stay neutral) or their Treasury to fund block explorers for all parachains.
Comparison: You are a lawyer, so surely you can help me with {my problem} in {my jurisdiction}, right?
Yes, separate entities has added costs, but a collective’s mandate to the network should be clear, and not one of convenience. Things that are not within the mandate of any existing collective should go through public referenda, and a large number of similar proposals to public tracks would indicate that a collective dedicated to that area of expertise may be worth the cost in order to reduce the noise coming to public tracks.
Right before 2.3.1. the Fellowship Manifesto states:
The Fellowship is intended to be only the first of its kind. Should the concept (probably after some iteration) become proven effective, we might reasonably expect more instances of expertise-based organisation “fellowships” for other disciplines not covered by the present Fellowship.
So, to have a balanced approach, we could have multiple Fellowships with multiple collectives under them, and each Fellowship with their own sub-treasury.
This way people could focus on what they are most interested in and capable of. Naturally, a person could take part in multiple domains. Finally, these should not turn into unnecessary silos. The Fellowships should actively work together and share information for the common good and long-term success of the network.
That’s a very interesting to way to format 5 fellowships in an all encompassing way, are you going to put this through RFC-12 all at once or start with the “Collaboration Fellowship”?
Polkadot+Kusama have 2 functioning OpenGovs, a single function fellowship. Can we scale this by 5-10x this year through OpenGov itself?
This would be a great accomplishment and demonstration of liquid democracy =)!
Right now it feels a bit illiquid. What do you think of having the 100K DOT requirement (more than a house) be lowered to 1K DOT (less than a car) to stimulate many more actual collectives/fellowships and unleash the sheer power of OpenGov? A 100K DOT feels appropriately high for creation of a single Ministry of X (and is visibly empirically prohibitive), 10 DOT is probably more like creation of a many local sports clubs (and would immediately be spammed), 1K DOT feels just low enough to support a lot of much needed innovation and demonstration to get this 5-10x scale.
Thanks. I’m not personally going to advance this (no time) but if someone (maybe you?) finds it all-encompassing and inspiring enough, then go for it!
Here’s the entire framework around it:
Feel free to steal the idea and edit as you see fit. Also @six @Irina.Karagyaur and some other ambassadors might be interested in prodding it further.