Governance master issue - "build a governance system"

[mochet]

This issue is mainly a tracking issue, I am working on some areas of governance and exploring topics (which is not on GitHub or any public space just yet). This issue is for anyone interested to see the issues being researched currently. This isn't a part of incentives v3 unless otherwise specified.

Core Definition: "build a governance system"

This issue outlines the approach to taking all of the lessons learned from early testnets, combining it with other governance ideas that weren't explored and building a functional, regular, predictable system that heavily benefits all users and non-users of the Joystream DAO.

• governance system = These are a collection of organized documents, processes and paperwork that are created, refined and maintained to enable all core Joystream governance features to function reliably and to cut down on any potential wasted manhours.
• runtime = This is the underlying code that the Joystream DAO utilizes. It is lines of codes. It takes human input and does something. Best explained in this clip: https://www.youtube.com/watch?v=4s8Om0yjW9Q

Reasons for this initiative:

1. This initiative was taken as the olympia upgrade will wipe a lot of historical proposals. And whereas we had no system in place like this before, after having seen the chaotic nature of having to try and sort through 1000+ proposals and the tremendous difficulty in accessing relevant information now is the perfect time to try and build a forward thinking system.
2. For Olympia and Incentives v3: Build a system comprised of documents that acts as a good starting point due to the huge transition that will be taking place.
3. The KPI system is coming to an end. This previously helped to develop and define some aspects of governance.
4. incentives v3 has reports and some things however it is separate to this initiative. There is no intention to overlap or confuse incentives v3 therefore this will be a quiet/background approach.
5. No organized approach towards goverance has ever been taken by anyone so far. There are fragments and ideas that exist, but this is probably the first attempt to build a governance system undertaken for the Joystream project.

Goals:

1. Build a forward thinking system--do everything possible to create the initial building blocks for a governance system that can scale, be improved and delivers necessary information to platform participants. Everyone hates paperwork, but disorganized paperwork is even worse and paperwork is the foundation of how any governance system works.
2. Involve the community far more in the topic of governance and build discussion of the topic far more by giving all users initial organization system which they can then adapt, discuss and work with. Up until now interest in this topic has been limited and the lack of any organized system has likely been a huge aspect. There has been no table of contents nor any start or end point to governance and these need to be created because they have not organically developed so far.
3. For mainnet launch, this initiative should ideally be developed further and turn into a system that can help the platform, any elected council and any user or non-user of the platform benefit from a set of information that is organized, readily accessible and refined. Having this organized and accessible is critical (IMHO) to the launch of our platform on mainnet.
4. Drastically decrease wasted hours and disorganized use of the governance system. Regular proposals that are submitted are all created by different authors and the lack of standards has the compounding effect of reducing readability of the core governance processes. Some templates and some organization would greatly help with this (IMHO)
5. Make things easy - Make it far easier for new users to comprehend the governance system and make it far easier for them to participate. Joystream is already highly complex, and with no system for governance it doesn't matter how sophisticated the DAO is, at the end of the day a human has to read through the thousands of proposals and discussions to know what is happening and without structure that will eventually have a higher learning curve than what we think is difficult at this point in time (understanding how the runtime + its features work)
6. Things have to be written in consideration of the runtime - With the way Joystream is designed, anyone with sufficient tokens can submit a proposal at any time. Council members can vote however they want to on proposals. This is a fact. Templates, processes and documents are practically entirely optional. Fact is how many things should be approached and it doesn't make sense to try and pretend fact is optional.

Notes on included issues

• For the items that I have personally written, I attempt for these to be neutral but they are obviously my own ideas written based on my own interpretations.
• Nothing being listed here signals that any of these will or will not be proposed at some stage.
• Nothing is finalized at all--these are just topics and anything that may be introduced would follow the ordinary route that previous governance proposals have taken, including a discussion phase and including a phase where the active council can vote to approve, reject, abstain or slash anything proposed.
• If people want to create their own issues, or suggest additions to the list please make a comment or message me. I just happen to have had a heavy interest in governance since the project was started and so many of these issues are things I worked on.

Issues

• governance: token volatility (payment buffers) #709
• governance: cool off period #705
• governance: minimum stake requirements for WG leads + workers #711
• governance: periodic review of items #712
• governance: categorization of items #713
• governance: New Mint refill good practices #627
• governance: Reporting Standards #499
• governance: process for managing creative bounties + competitions #104
• governance: Complaints/Dispute presentation and resolution #566
• governance: report cycles #19
• governance: Council Secretary Role #715
• governance: Report manager #510
• governance: Proposal Guidelines #58
• governance: Standard Operating Procedure - Template #498
• governance: R&D system (mostly the R) #728