Process for Adding New System Collectives #12
Conversation
|
ChaosDAO would also like to explore this space. |
| remark with the text `APPROVE_COLLECTIVE("{collective name}, {commitment}")` to a Root origin | ||
| referendum. The proposer should provide instructions for generating `commitment`. The passing of | ||
| this referendum would be unequivocal direction to the Fellowship that this collective should be | ||
| part of the Polkadot runtime. |
There was a problem hiding this comment.
Who is expected to work on introducing an approved collective to the runtime/code base?
Should we clarify it in this RFC?
There was a problem hiding this comment.
Not exact but similar to: #2 (comment)
If the Fellowship is being paid by the network and they agree to a process to signal network desire for some code in a runtime that is within the Fellowship GitHub org, then someone in the Fellowship should take responsibility to make sure it gets done. The PR will need approval from high-ranking Fellows even if someone outside the Fellowship implements it.
|
Looks Ok to me :) in general I think the approach of creating new instances of the different pallets that make up a collective like the fellowship is not very approachable nor scalable but I think this works as a start, at least the community will know there's a processes. To make the process easier/automatable for the fellowship I would be more strict about the format used for the submission and include some form of machine readable format that tools can use to auto generate the instantiation code and auto-submit a PR for the new collective. Markdown for the manifesto annotated with a "front matter" section has a good balance of being simple enough for the proposers(even if they don't use a tool) and still machine parsable. ---
collective: Great Collective
type: ranked
member_types: individuals
has_treasury: yes
ranks:
- name: simpletons # used to generate origin and track
track: # overrides for the associated track default config
decision_period: 5 days
- name: smarty-pants
salary: 1 DOT
seeding:
- rank: 1
account: 1universe1ruLer11111111111111111111111111111G91
---
# The Great Collective Manifesto
...Later on as demand for collectives increases the fellowship might find worth it investing some dev hours creating a permission-less collectives system where new collectives are incubated continuously and every now and then one such collective might apply to become a "system collective" like the technical fellowship. |
As a new feature/chain this could be valuable, but this is not at all the purpose of system collectives. System collectives are meant to be permissioned; namely they need buy-in ("permission") from the network to be considered part of the Polkadot system, and as such need to justify their reason for existing and the powers they wish to acquire and get explicit approval from stakeholders. The process is not meant to be scalable (although adding/configuring a few pallets is hardly a huge lift), it is meant to ensure that people have an accepted process to demonstrate that buy-in and a reasonable expectation that this group (the Fellowship) will honor that signal. |
|
/rfc propose |
|
Hey @ggwpez, here is a link you can use to create the referendum aiming to approve this RFC number 0012. Instructions
It is based on commit hash 4a5361ac66e512073ff6651dce99a30997d4f54c. The proposed remark text is: |
|
/rfc process 0x4b54385ffd3ef633aa021d7c56d06de833071380f4ced0e747705dce1838f622 |
|
The on-chain referendum has approved the RFC. |
This RFC proposes a means for Polkadot stakeholders to ratify a new collective. The Fellowship should agree to add new collectives to the Collectives parachain runtime that pass the given process.