Proposal System: Final Major iteration

[bedeho]

Overview

We should refactor the proposal system, meaning the engine, the codex and discussion modules, to be in line with the functional description currently live in the Handbook: https://joystream.gitbook.io/joystream-handbook/governance/proposals

It's important to bear in mind that this is an integrated functional description that crosses many layers of abstraction, not only the multiple modules but even into what would be found in a query node. So it must be extracted from this how the modules should be organized to facilitate this. Some of the key points that pertain specifically to how to reorganize the runtime modules are therefore

• Drop all archival stuff, both in codex, engine, and discussion system.
• Use locks for staking, not staking module, recall
  • one account can be used per proposal
  • verify with runtime that account is bound to member
  • has sufficient free balance
  • verify with runtime that account is not already locked for purpose for which stake is not reusable: anything except voting
• Drop withdrawal/cancellation.
• Introduce block height triggering to lock in execution time.
• Discussion permissions: Proposal discussion permissioning #1227
• Add constitutionality: Idea: Constitutionality in the proposal engine #144
• Clearly separate creation and execution checks: Proposal Codex checks cleanup #1205, this requires going through each proposal creator one-by-one.
• Add rationales: Idea: Proposal vote reasoning #1157
• Bug: Proposal bug (between council sessions) #828
• Update budget: Integrated budget constraints #1487
• Update new proposals
  • Add constitution: Idea: Runtime Constitution #799
  • Add council blog
  • Comment out create_set_election_parameters_proposal proposal.
  • Update all proposals to
• Proposal parameters are constants Remove storage representation of immutable parameters in codex #862

Update Handbook

The current state of the handbook is quite complete, but the details of each proposal is not filled in, and as many proposals will change with this change, filling in the details has been postponed.

After completing this work, please update the signature and information for each active proposal, and update any incorrect claims about business logic and state management in general. There is no need to fill in all the missing constant values, this can be done by someone else

Implementation Path

Starting Point

Should build on a new council & election system & working group system that should be ready to go into production. Only work on the codex directly needs these most recent versions, hence work on the engine and discussion modules can still commence if these dependencies are still not fully completed.

Process

This is a complex set of changes, here are some ideas for how I think we can minimize confusion and false starts:

1. It should be bottom-up in terms of dependency graph:
   a. Engine module
   b. Discussion module
   c. Codex module
2. There should be a plan for how to tackle each module on its own, before we start.
3. Its worth having meetings that the plan for the module does not capture too much, as the handbook can easily mislead a spec, which it isn't.
4. Multiple early reviews on each module, avoiding one PR per module.

Anything else?