Post-mainnet idea: two overlapping councils

Idea: two overlapping councils

I watched the video that @robertneckelius recently shared (https://www.loom.com/share/6bce1f48dcd745d1b3684c5b2b3a69c9) and he mentioned the possible idea of having a second council very briefly. Maybe he had a similar idea to what I'm describing here, in any case I thought it would be an interesting idea to explore.

Current problems & observations

(it is unknown whether all of these will apply in later releases, not is it known whether the problems written about would actually apply in a mainnet scenario)

• It is relatively easy for the same council member to be elected repeatedly and hold the same amount of voting power whenever they do this.
  • This can result in community apathy towards the elections if there is not a sufficient mix of people participating.
  • This can result in less interest in the voting/governance process since you only get one election to vote in and only one election to announce your candidacy in. Due to there being only being one council it seems likely that the outcome of elections will only be slightly reactive to current platform issues or ideas.
  • It also means the likelihood of newer, relatively unknown members being able to realistically gain a foothold in the council is far less likely
  • Ideas of how to improve this situation is something I've written about a few times:
    • https://github.com/Joystream/joystream/issues/2488
    • https://github.com/Joystream/joystream/issues/2375
    • https://github.com/Joystream/joystream/issues/2845
    • https://github.com/Joystream/joystream/issues/2125
• Votes reset once a council ends
  • This creates a problem in that proposals submitted later in a council term are less likely to be voted on before the council expires and also that in the new council, these "orphaned" proposals may not get enough attention/votes to even pass. In reality, this means that not all proposals are created equally and timing can become a significant requirement when submitting a proposal.
  • This means that some core components of the proposal system may end up having to be timed particularly well so that they get enough votes.
    • This is impractical for a DAO which will presumably operate 24/7 with council members across the globe and also is required to make decisions at relative speed in order to remain effective. Having these low traffic spots at the end of elections can cause apathy for users wanting to submit proposals.
    • This can result in platform-wide issues, and if emergencies arise and the day to day business requirements from submitted proposals are not addressed in a timely manner it can reduce the DAOs effectiveness.
• Our platform is very distinct from other DAOs and we have already seen that just on our testnet the throughput of proposals is extremely high.
  • On mainnet, we will have 50 proposal types or more, this will increase the number of proposals submitted at any given time by a significant factor.
  • Proposal throughput is an issue I have mentioned in several other issues and coming up with possible ways of addressing this before it becomes an issue seems valuable.
    • https://github.com/Joystream/joystream/issues/2529
    • https://github.com/Joystream/joystream/issues/2869
    • https://github.com/Joystream/joystream/issues/2595
    • https://github.com/Joystream/joystream/issues/2589
    • https://github.com/Joystream/joystream/issues/2477
    • https://github.com/Joystream/joystream/issues/1958
    • https://github.com/Joystream/joystream/issues/1244
• Some users see the council as being all-powerful and perhaps having a hive minded attitude. Due to there only being one council, it is easy to see that CM's votes are heavily influenced by how their fellow CMs vote on proposals.
• If a few CMs on the council go AFK it is possible for proposals to be impossible to pass. Depending on the length of a council term, the likelihood of this possibly increases in the later days of the term.
• With the current KPI system (which is being changed and may not exist on mainnet) a lot of CMs end up being quite busy towards the end of the term, which results in less votes being cast.

Idea

The idea would be to have 2 councils but rather than both being elected simultaneously they would instead have terms that overlap. In the following example I am using an 8 day council term as it is easier to convey visually.

• This is a very basic idea so I am not addressing whether 3 elected councils would be able to vote on the same proposal and also not addressing election announce/vote/reveal cycles.

Requirements

• A member should be barred from serving on both councils at once
  • This means if member_23 submits a transaction to announce for Election 8 they should not be able to announce for Election 9 (this should be enforced through the runtime)
• The voting quorum requirements should require both Council A + Council B to vote in order for proposals to be approved/rejected/slashed.
  • in the current system, where we only have one council, the effective power of the council is 100%
  • with both Council A and Council B this would effectively mean that the power of each council is at 50:50
• Proposals may need to have some specified time limit so that 4 council's cannot vote on the same proposal (in this example that would be 8 days)
  • This may not be required since this system is intended to allow more voices on the same proposal.
• In some of the prior design files and GitHub issues it is shown that some expensive proposals (runtime upgrade, constitution) would require two distinct/subsequent councils to both approve the proposal in order for it to be approved.
  • This requirement for 2 subsequent councils could instead be removed and replaced with a far longer voting period on the proposal which would allow 2,3,4 or even more elected councils the ability to vote.
• I see no reason why voters should be restricted from participating in all elections (this would mean that they can vote on any candidate, in any election, without restriction)

Example

• Proposal 825 is submitted on Jan-8, even though this is when Council 8 only has one day left, it can also be voted on by Council 9 (and maybe council 10 also)

Benefits

• Can reduce low vote proposals that are submitted at the end of the council terms, which removes blind spots in when proposals "should" be submitted
• In the case of disenfranchisement with the current council, it provides a more immediate and a far more competitive means of both new people stepping up with specific goals they outline in their election announcements as well as a far better means for voters to direct their stake towards candidates they believe will solve issues that are currently occuring. This seems a lot less likely to happen with the current election system.
• Can hopefully make the DAO be able to fully operate 24/7 irrespective of different timezones/holidays/weekends.
• Can hopefully avoid situations where an elected council member goes AFK and a proposal subsequently doesn't reach quorum.
• Can increase diversity in council membership
• Can create some sense of competition between Council A + Council B
• Increase proposal throughput
• Remove votes being reset from proposals once a council term ends
• Can increase community interest in voting for council members, since there would hopefully be a better pool of candidates on both sides.
• Allows expensive proposals with a long voting period a better chance of getting a diversity of opinions.
• By distributing power to two council's it potentially makes attacks against the governance system more difficult.
• Potentially prevents a situation, where users see the council as being a single-minded entity composed of only the biggest bag holders

Disadvantages (and analysis)

• Makes the system more complex than it already is (:
• Could create a political party system
  • which in reality can already happen on the current system but doesn't have a remedy that the community can use as there is no opposing council to deal with
  • the only opposing council is the next council and if you're already a significant then you've already won
• Due to the division of power of each council, it could create conflicts between the groups and result in an unequal division.
• It may act as an unrealized weight on business critical proposals (such as hiring WG leads) and if there is significant back and forth between the opposing councils it may result in proposal stagnation/expiry or even a lack of quorum repeatedly.
• Due to the requirement of a member not being able to participate in two elections at the same time, it would significantly increase the value of sybil attacks (this problem already exists on the current system)

No files, tests, or concrete entry points are named. Start by locating the runtime governance and election implementation, then review the linked related issues and prior design files; done would require an agreed specification for overlapping councils, voting periods, quorum, eligibility, and proposal handling.