From aeef43fa37a2dba085190b7cd3f17a654886b132 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Fri, 21 Jul 2023 08:41:56 +0200 Subject: [PATCH 1/4] create file --- ...Process-for-Introducing-New-Collectives.md | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 text/RFC-XXXX-Process-for-Introducing-New-Collectives.md diff --git a/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md b/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md new file mode 100644 index 00000000..e5086b97 --- /dev/null +++ b/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md @@ -0,0 +1,59 @@ +# RFC-0000: Feature Name Here + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | Date of initial proposal | +| **Description** | One-sentence description | +| **Authors** | | + +## Summary + +One paragraph summary of the RFC. + +## Motivation + +Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. + +## Stakeholders + +A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. + +## Explanation + +Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. + +## Drawbacks + +Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. + +## Testing, Security, and Privacy + +Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. + +## Performance, Ergonomics, and Compatibility + +Describe the impact of the proposal on the exposed functionality of Polkadot. + +### Performance + +Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? + +### Ergonomics + +If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? + +### Compatibility + +Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. + +## Prior Art and References + +Provide references to either prior art or other relevant research for the submitted design. + +## Unresolved Questions + +Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. + +## Future Directions and Related Material + +Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. From 0fd6cc4f81e95820bf5fee9edd10b611867b6b89 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 24 Jul 2023 10:45:48 +0200 Subject: [PATCH 2/4] draft RFC --- ...Process-for-Introducing-New-Collectives.md | 105 +++++++++++++----- 1 file changed, 77 insertions(+), 28 deletions(-) diff --git a/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md b/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md index e5086b97..7c9c4b79 100644 --- a/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md +++ b/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md @@ -1,59 +1,108 @@ -# RFC-0000: Feature Name Here +# RFC-0000: Process for Adding New System Collectives -| | | -| --------------- | ------------------------------------------------------------------------------------------- | -| **Start Date** | Date of initial proposal | -| **Description** | One-sentence description | -| **Authors** | | +| | | +| --------------- | ----------------------------------------------------------------------------- | +| **Start Date** | 24 July 2023 | +| **Description** | A process for adding new (and removing existing) system collectives. | +| **Authors** | Joe Petrowski | ## Summary -One paragraph summary of the RFC. +Since the introduction of the Collectives parachain, many groups have expressed interest in forming +new -- or migrating existing groups into -- on-chain collectives. While adding a new collective is +relatively simple from a technical standpoint, the Fellowship will need to merge new pallets into +the Collectives parachain for each new collective. This RFC proposes a means for the network to +ratify a new collective, thus instructing the Fellowship to instate it in the runtime. ## Motivation -Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. +Many groups have expressed interest in representing collectives on-chain. Some of these include: + +- Parachain technical fellowship (new) +- Fellowship(s) for media, education, and evangelism (new) +- Polkadot Ambassador Program (existing) +- Anti-Scam Team (existing) + +Collectives that form part of the core Polkadot protocol should have a mandate to serve the +Polkadot network. However, as part of the Polkadot protocol, the Fellowship, in its capacity of +maintaining system runtimes, will need to include modules and configurations for each collective. + +Once a group has developed a value proposition for the Polkadot network, it should have a clear +path to having its collective accepted on-chain as part of the protocol. Acceptance should direct +the Fellowship to include the new collective with a given initial configuration into the runtime. +However, the network, not the Fellowship, should ultimately decide which collectives are in the +interest of the network. ## Stakeholders -A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. +- Polkadot stakeholders who would like to organize on-chain. +- Technical Fellowship, in its role of maintaining system runtimes. ## Explanation -Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. +The group that wishes to operate an on-chain collective should publish the following information: -## Drawbacks +- Charter, including the collective's mandate and how it benefits Polkadot. This would be similar + to the + [Fellowship Manifesto](https://github.com/polkadot-fellows/manifesto/blob/0c3df46/manifesto.pdf). +- Seeding recommendation. +- Member types, i.e. should members be individuals or organizations. +- Member management strategy, i.e. how do members join and get promoted, if applicable. +- How much, if at all, members should get paid in salary. +- Any special origins this Collective should have outside its self. For example, the Fellowship + can whitelist calls for referenda via the `WhitelistOrigin`. -Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. +This information could all be in a single document or, for example, a GitHub repository. -## Testing, Security, and Privacy +After publication, members should seek feedback from the community and Technical Fellowship, and +make any revisions needed. When the collective believes the proposal is ready, they should bring a +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. -Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. +Note: There is no need for a `REJECT` referendum. Proposals that have not been approved are simply +not included in the runtime. -## Performance, Ergonomics, and Compatibility +### Removing Collectives -Describe the impact of the proposal on the exposed functionality of Polkadot. +If someone believes that an existing collective is not acting in the interest of the network or in +accordance with its charter, they should likewise have a means to instruct the Fellowship to +_remove_ that collective from Polkadot. -### Performance +An on-chain remark from the Root origin with the text +`REMOVE_COLLECTIVE("{collective name}, {para ID}, [{pallet indices}]")` would instruct the +Fellowship to remove the collective via the listed pallet indices on `paraId`. Should someone want +to construct such a remark, they should have a reasonable expectation that a member of the +Fellowship would help them identify the pallet indices associated with a given collective, whether +or not the Fellowship member agrees with removal. -Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? +Collective removal may also come with other governance calls, for example voiding any scheduled +Treasury spends that would fund the given collective. -### Ergonomics +## Drawbacks -If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? +Passing a Root origin referendum is slow. However, given the network's investment (in terms of code +maintenance and salaries) in a new collective, this is an appropriate step. -### Compatibility +## Testing, Security, and Privacy -Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. +No impacts. -## Prior Art and References +## Performance, Ergonomics, and Compatibility -Provide references to either prior art or other relevant research for the submitted design. +Generally all new collectives will be in the Collectives parachain. Thus, performance impacts +should strictly be limited to this parachain and not affect others. As the majority of logic for +collectives is generalized and reusable, we expect most collectives to be instances of similar +subsets of modules. That is, new collectives should generally be compatible with UIs and other +services that provide collective-related functionality, with little modifications to support new +ones. -## Unresolved Questions +## Prior Art and References -Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. +The launch of the Technical Fellowship, see the +[initial forum post](https://forum.polkadot.network/t/calling-polkadot-core-developers/506). -## Future Directions and Related Material +## Unresolved Questions -Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. +None at this time. From 30ad79125ebccc06c4b4d8fa0d51e085b7c40da3 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 24 Jul 2023 10:50:17 +0200 Subject: [PATCH 3/4] RFC-0012 --- ...s.md => RFC-0012-Process-for-Introducing-New-Collectives.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{RFC-XXXX-Process-for-Introducing-New-Collectives.md => RFC-0012-Process-for-Introducing-New-Collectives.md} (99%) diff --git a/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md b/text/RFC-0012-Process-for-Introducing-New-Collectives.md similarity index 99% rename from text/RFC-XXXX-Process-for-Introducing-New-Collectives.md rename to text/RFC-0012-Process-for-Introducing-New-Collectives.md index 7c9c4b79..95c701eb 100644 --- a/text/RFC-XXXX-Process-for-Introducing-New-Collectives.md +++ b/text/RFC-0012-Process-for-Introducing-New-Collectives.md @@ -1,4 +1,4 @@ -# RFC-0000: Process for Adding New System Collectives +# RFC-0012: Process for Adding New System Collectives | | | | --------------- | ----------------------------------------------------------------------------- | From 4a5361ac66e512073ff6651dce99a30997d4f54c Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 14 Aug 2023 19:44:34 +0200 Subject: [PATCH 4/4] rename file --- ...-Collectives.md => 0012-process-for-adding-new-collectives.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{RFC-0012-Process-for-Introducing-New-Collectives.md => 0012-process-for-adding-new-collectives.md} (100%) diff --git a/text/RFC-0012-Process-for-Introducing-New-Collectives.md b/text/0012-process-for-adding-new-collectives.md similarity index 100% rename from text/RFC-0012-Process-for-Introducing-New-Collectives.md rename to text/0012-process-for-adding-new-collectives.md