Joystream Stats fcbd88a006 merge archived helpdesk | преди 2 години | |
---|---|---|
.. | ||
img | преди 2 години | |
README.md | преди 2 години |
This page contains a detailed guide about how the governance system works on the current Joystream testnet, and how you can participate. This page is intended primarily for those wanting to become, or who already are Council Members ("CMs").
Nonetheless, if you are interested in the Joystream project more generally and/or want to become a part of the community now or in the future, there is lots of information in here that will help you understand the project and the governance of the platform at a higher level.
Starting with the launch of the Antioch
network, some changes to the Council Member incentive scheme will take effect. There are two main reasons for this:
With the last "iteration" of the KPI rewards scheme, we saw a marked improvement in the achievement of sometimes difficult KPIs. Despite the individual KPI rewards for the Council Members being independent of their actual contribution, the CMs solved the problem by creating spending proposals for the reward of that KPI - effectively granting themselves rewards. Although this is a relatively good solution, it still creates a strong incentive for a "whale" to vote themselves in each term and earn the associated rewards with no further effort.
This last point overlaps neatly with the second point - namely the difficulty for new users to earn their slot on the Council. Jsgenesis countered this by voting themselves, and making sure at least some newcomers got their opportunity, but we are now targeting a more "aggressive" rotation. At launch, we will be targeting a healthy mix of newcomers and more seasoned Council Members.
The new structure can be summarized as follows:
More details about the KPI rewards can be found here.
As the governance system is arguably the most important component of the platform on mainnet, we are relying on testnets to train and build up an experienced and highly competent group of initial community members that can diligently perform the tasks required of them once we reach the mainnet stage.
A "good" Council needs CMs that all have a strong understanding of both the platform's token economics ("tokenomics") and each of the individual Working Groups and the roles each of these play in making the platform function. Additionally, the composition of each Council should ensure that the group has expertise in every domain, and some CMs with low-level technical understanding will likely be required to provide guidance on other aspects of the project (marketing, legal, strategy etc.).
During the Constantinople testnet, Jsgenesis realized we need to put a lot more effort in to attracting, training and retaining these high-quality people. CMs will on a mainnet exclusively earn recurring rewards, similar to other roles. On our testnets however, where there are little incentives for users to diligently scrutinize each applicant and place votes, we have tried to mimic this through use of KPIs.
Jsgenesis will also take an active role in the elections. More information on how to apply, and increase your chances of getting elected can be found here.
A newly elected Council could be assigned a recurring reward that automatically pays out tokens every n
th block. The magnitude of this reward may change over time, but can be monitored on the Tokenomics page.
In the current Sumer testnet the recurring rewards are absent.
The KPI rewards will depend on the Council's performance. Jsgenesis will provide a new set of Council KPIs for each new term, with some variability in terms of scope and maximum rewards.
Each individual KPI will be have a reward assigned to it, which can be achieved if the task is fully completed, and graded as such by Jsgenesis. If the task is considered 20% completed, the reward will be set to 20% of this (unless something else is specified in the KPI).
Unlike previous versions of the KPI reward scheme, these will not be shared (equally) by all CMs, and no rewards will be distributed to the Voters. The reward can be awarded to a single CM, or divided by a group of CMs. This means the Council is incentivized to co-operate, and distribute tasks between them based on whatever metric they choose.
If they are able to agree on a distribution up front, this should be posted in a new thread on the forum, which the individual CMs will (at the end of the term) use to outline what they did during the term. This information will then be public, and used for three different purposes:
Below we will expand further on that first point.
In general, Jsgenesis will only use what is included in the forum post, and results/deliveries when grading KPIs. This means that any agreement made between two CMs in other channels will not be considered in case of disputes.
Before the grading deadline, Jsgenesis will not only grade the KPIs for quality, but also decide on who gets what portion of the rewards.
Unlike most of the other current and future roles on the Joystream Platform, most of the information and actions required by participants in the governance system is available in our UI - named Pioneer. For elected CMs, some familiarity with GitHub is required, and at any time, a subset of the CMs must be able to use git, and basic coding review skills. As the project grows, new skills and more advanced skills may be required.
If you want to get elected as a CM or vote on the platform, you need to be a Member. Instructions for registration can be found here.
Note
After introducing Memberships
to the platform, we found it to be confusing to have a concept of both Accounts
and Memberships
. We are in the process of renaming the Accounts
to the Keys
, but there are still traces of Accounts
showing up.
A new Council of CMs are elected at regular intervals. The election is decided by selecting the applicants that has the highest total "stake" backing them. Staking here means "locking" up your tokens, making them unusable for transfers or staking in other ways, thus forcing participants to put "skin in the game". The total stake is the sum of the applicant's own stake required to put themselves up for election, and the stake of any voters voting for them.
The terms of these elections are defined by some parameters. Although these can be changed either by the Proposal system, or by sudo
, the parameter changes should be both infrequent and small.
The current set of parameters, as well as the status and stage of the Council/election cycle can be found here.
In addition to the length (and definitions) of the election stages described below, the most important parameters are:
Council Size
Candidacy Limit
Minimum Council Stake
Minimum Voting Stake
The full details of the election cycle will also expand upon these parameters.
The election cycle consists of four stages. Currently, the length of each one is:
During the entire Announcing
stage, anyone that is a Member and can stake a greater number of tokens than the Minimum Council Stake
, can apply to become a CM.
With your membership key:
Important Notes
Candidacy Limit
, which limits the number of applicants that goes through to the votingAt the end of the stage, there are three outcomes depending on:
Applicants
Council Size
Candidacy Limit
If: Council Size <= Applicants <= Candidacy Limit
. I.e. the number of applicants is between the Council Size
and Candidacy Limit
.
The Announcing
stage ends, with all the applicants proceeding to the Voting
stage.
If: Candidacy Limit < Applicants
. I.e. the number of applicants is greater than the Candidacy Limit
.
All of the applicants are sorted and ranked by their stake. The Announcing
stage ends, and only those with a rank better than, or equal to, the Candidacy Limit
will proceed to the Voting
stage.
The applicants that did not make it to the Voting
stage get their stake back right away.
If: Applicants < Council Size
. I.e. the number of applicants is smaller than the Council Size
.
There are not enough applicants to fill the Council slots, and a new Announcing
stage begins, with all the applicants automatically re-entered.
As soon as the Announcing
stage closes, anyone that is a Member and can stake more than the Minimum Voting Stake
, can vote for any of the applicants for the entire duration of this stage.
With your membership key:
You can vote as many times as you like, for any Applicant (including yourself).
Important Notes
When you submit a Vote, a Random salt
will be generated for you, and only a Hash
of the vote will be broadcast and stored on chain. This means:
Random salt
somewhere, you will only be able to "reveal" your vote if:
Random salt
, you only need the keyAs soon as the Voting
stage closes, the Revealing
stage begins. As stated before, only when a vote is "revealed" will it become public, and count.
With your membership key (used to vote on the candidates):
At the end of the Revealing
stage, the applicants are sorted and ranked by their total stake, i.e. the sum of the stake(s) they bonded during the Announcing
stage, and the sum of all "revealed" votes.
The applicants ranked within the number equal to the Council Size
will become CMs.
The applicants that did not get elected will get their stake back immediately. The same goes for those that voted for them, and those that did not reveal their votes.
On the block that marks the end of the Revealing
stage, the elected CMs will automatically be given their new privileges. Namely, the right to vote on Proposals, and be assigned an on-chain Recurring Reward.
The CMs' stakes will be not only be held until the Term Duration
expires, but until a new Council is elected. The same applies to those that voted for them.
The Recurring Rewards however, will only be paid during the Term Duration
.
Note that the next Announcing
stage will start at the exact block the Term Duration
expires.
Unless you have sufficient tokens to get (re-)elected without any extra voters, you are unlikely to get any votes without making an effort to do so. As Jsgenesis represents a large proportion of the voting power, and community members are unlikely to vote for unknown actors without a proven track record, there are some steps you can take to greatly increase your probability of getting votes:
Before a new Announcing
stage begins, a new thread will be made on the on-chain forum. Regardless of whether you are a new to the project, have been following it from a distance, are an active member or an experienced CM, make a post or two explaining why you deserve to be voted in. Some suggestions of what to include are:
As you are likely to get some follow up questions, it is a good idea to check in at regular intervals to answer these.
The CMs have a variety of tasks. Some are pro-active, others are re-active. Some are recurring and predictable, others will require on the spot problem solving.
To some extent, the same applies to their rewards. They could receive a fixed (in tJOY) Recurring Reward, which will be handled automatically by the chain. The other relies on their ability to solve the tasks and challenges they face through the Council KPIs.
A CM that is slacking off, or for other reasons unable or unwilling to perform their tasks will still receive their rewards for the term, but are unlikely to get re-elected in the near future.
The list below contains a high-level overview of their responsibilities:
Although only the Council KPIs will qualify for extra rewards in that particular term, other tasks will be rewarded through Founding Member points and increased probability of re-election.
For each Council Term, a set of Council KPIs will be released. These will contain tasks that the Council, or individual CMs acting on behalf of the Council, should try to complete. Although the tasks and actions required by the Council will vary, the structure of the Council KPIs are fixed.
An example of the structure for a single Council KPI is outlined below. Note that the number of KPIs, success events, individual and sum of the rewards, and complexity of the KPIs per term will vary.
Council KPI - Term X
id:
- The unique identifier (e.g. X.1
)Title:
- The titleReward:
- The maximum reward paid, assuming all Success Events
are delivered and graded completeDescription:
- A description of the problem solved if all Success Events
are completeSuccess Events:
1.
- A precise definition of subtask 1.
2.
- A precise definition of subtask 2.
n.
- A precise definition of subtask n.
Annihilation:
- A precise definition of something that, if it occurs, would result in the entire KPI Reward
getting lost, even in the event all the Success Events
are fully completed.Grading date:
- A (loose) deadline for when Jsgenesis will grade the KPIs, and if applicable, pay the CMs their rewards.In addition to these, there are some other information that may or may not be included:
Starting at:
- The exact block height (and approx. date/time) from which the KPI is "Active"Ends at:
- The exact block height (and approx. date/time) from which the KPI is no longer "Active"Measurement period:
- Similar to the aboveThe reason these may not always be present is because the intention is that a Council KPI will be active from the block the Council is elected, until the block a new one replaces them.
The Council KPIs will emphasize tasks that the Council would be expected to handle or directly delegate once the project is live on mainnet. Instead of partially repeating what is listed here, this section will instead focus on some examples of specific Success Events
, and workflow.
Most KPIs will be graded based on one of two things:
For a deliverable to qualify, it must, unless noted otherwise:
Unless these conditions are met, Jsgenesis reserves the right to consider a deliverable invalid. However, exemptions can be made depending on the circumstances.
It is irrelevant whether the Council collaborates in producing the deliverable, if it is made by a single CM, or procured from another Member or outsider. The only exceptions are if the deliverable:
The KPI will define whether the value in question shall be:
Each Council will be prompted to submit deliverables reporting on things like:
The Council Secretary is an informal role, where the Council themselves are given some flexibility in deciding on compensation and extending their Scope of Work, outside of what is defined in the Council KPI.
The following bullet points should be expected as the Success Events
for the KPI:
Currently, there are two Working Groups on the network:
The role of the Council is not to control these directly, but rather ensure they are being well-run by their respective Leads. What is considered "well-run" is of course open to a wide interpretation, so specific quantitive and qualitative targets would be defined in the Council KPIs.
However, to understand what these targets could entail, how to monitor them, and perhaps even stay ahead of the curve, one should be familiar with some indicators of what to look for.
Finally, a CM must understand what the Council's options are for dealing with a Working Group that is underperforming.
How the Council chooses to approach this is up to them. It is up to the Lead of each group to create Proposals for replenishing the Working Groups mint, but it's up to the Council to approve or reject these requests.
A good approach could be to agree on weekly budgets, and revise them on an as-needed basis. How to set these budgets would depend on a variety of factors such as:
dataDirectory
dataDirectory
In addition to the bottom-line costs, there are some nuances to the distribution of said costs, and the general quality of the service each Working Group Provides.
Storage Providers
Content Curators
verified
Lead Actions Are the Leads doing their jobs, in terms of:
In some cases, the Council may wish to take some action in relation to the Lead of a Working Group.
If a Working Group is not performing adequately, the first course of action may simply be to give an informal warning to the Lead in question.
The main way of dealing with Leads is through the proposal system. Unfortunately, there are currently limited ways of dealing with the Curator Lead. For the Storage Lead, there are more options, but only one that is not a punishment: Content Curator Lead
The concept and some examples of (Community) Bounties (previously referred to as "Community KPIs") are explained here, so this section will rather focus on the Council's role in these as Project Managers. What this entails exactly will vary depending on the type, complexity, and stage of the active Bounties themselves, but "good" Project Management will be rewarded through the Council KPIs.
A Community Bounty will in general be graded based on deliverables, with conditions similar to what is described here.
Unlike the Council KPIs, the rewards for fulfilling them will not go directly to the CMs, but rather increase the Fiat Pool, thus increasing the value of all the token holders. However, it's assumed that most, if not all, of these rewards will be directed at the group or individual that made the deliverable.
This section contains examples with suggestions for the step-by-step workflow some "common" formats for Bounties - namely "Open", "Free For All" and "Closed" formats. The format should try to optimize for the time, quality, risk and cost, associated with each Bounty.
Note that the target audience for this is not the participants themselves, but rather the Council Members.
bwhm
or blrhc
of Jsgenesis in the Community RepoAs seen in below, the amount of work managing a Bounty will in some cases be substantial. Previously, it was intended that the Council should perform this work as group, but it has become clear that hiring a single (or small group) to act as Bounty Manager(s), either for all open Bounties, or individual ones, is needed for the system to work.
Although the idea of forcing the Council to communicate and co-operate their way through this was noble, it leads to an example of the tragedy of the commons.
As managing the Bounties will be a significant part of their (potential) KPI rewards, they have some excess resources and incentives to hire the "right" people. They can either pay for this out of pocket, request funding for this through spending proposals, reserve some part of the Bounty reward for this purpose or by asking Jsgenesis for designated funding.
In the end, the Council will still be responsible for the work the BM does, so they should still verify the spending and/or text proposals made, and seek feedback of the BM's performance (e.g. responsiveness and communication) from participants.
Jsgenesis creates a Bounty Issue in the Community Repo with a new Bounty. This Bounty Issue is meant for the Council first and foremost, and ideally, the person(s) attempting, or successfully manages, to solve the Bounty should not even need to read this.
In this Bounty Issue, Jsgenesis will explain/outline:
After this, the BM, parses the Bounty Issue, and starts drafting what will be the original post(s) in the Forum thread. In this post, the following should be made clear:
If the BM needs clarity or more information than what is covered in the Bounty Issue, reply to it for clarity.
Once the draft is completed, the BM creates a text or spending proposal (if funding is needed for their tasks) presenting a draft of the Forum post that will be made for the bounty. If the text is too long to fit in the proposal, a link to the text is shared in its place.
If the proposal is approved, with or without any agreed corrections, the Forum thread is created with the agreed content.
Finally, the BM replies with the content in the Bounty Issue, and makes a PR to the Community Repo, updating the information required.
If the Bounty Issue doesn't include, or just suggests a format, the Council is free to choose.
If a format is specified, there is still some freedom to choose within that realm. What is listed below are simply examples.
An example of the "Open" format is Bounty #10 - "Upload Public Domain Content".
Anyone (with a membership) can participate in this bounty, it has a fairly low barrier to entry, and will run indefinitely.
However, managing this bounty is not as straightforward, as one would expect a large number of entries, from many different users.
Involved parties, and their responsibilities:
$n
(length, resolution, encoding, etc.)channelId
(s)videoId
(s)An example of the "Open" format is Bounty #11 - "Design Community Repo Banner".
Similar to the Open format, anyone (with a membership) can participate in this bounty, but it requires a little more specialized skills. It's similar to a competition in many ways, as there can be unlimited entrant, but only a few winners.
Involved parties, and their responsibilities:
In Bounties that requires significant time and/or other resources to complete, and with only one "winner" in practice, Jsgenesis considers it fair to all parties to have an application process culminating in a single Community Member being assigned the Bounty for some agreed time.
Most coding
and research
Bounties fits equally well as examples, but #8 - "Ledger for Joystream" seems most suitable due to its extensive scope.
Involved parties, and their responsibilities:
n
, say 2 weeks from now.n+43200
, say within three days of the Application stage endingn+43200+72000
(five days) and fully accepted. If not submitted, a new Applicant may be Assigned, unless an agreement is made.n+43200+72000+72000
(ten days) and fully accepted. If not submitted, a new Applicant may be chosen, unless an agreement is made.n+43200+72000+72000+72000
(fifteen days) and fully accepted. If not submitted, a new Applicant may be chosen, unless an agreement is made.In addition to the varieties outlined, other formats can be defined and chosen if they are more appropriate for a specific Bounty.
A "new" Council must honor any agreements and rules set by their predecessors, for as long as the rules say so.
The workflow will depend both on the Reward Distribution and the Format, and must be established beforehand.
Constantinople introduced a number of important changes to the governance structure of the platform. The most important of these was the enhancement of the platform's proposal system. You can read descriptions of each of the proposal types on the helpdesk article here.
Most of the proposals are meant to allow the Council to allocate the platforms resources as efficiently as possible. In order to do so, a tokenomics spreadsheet has been made to assist in the decision making.
As a Member (CM or not) you are able to make proposals to be voted on by the Council.
The types of proposals available include:
To make a proposal:
/proposals
).active
proposals, you can click the New Proposal
button at the top of the page.Create Proposal
and fill in the required fields, Title
, Rationale
and Description
.Submit Proposal
and sign the transaction.active
on the proposals page.While any member can make a proposal, only Council Members can vote!
The voting process is rather simple. The first step is to navigate to the proposals (/proposals
) page and view the currently active proposals. Select the proposal you would like to vote on and simply click the button corresponding to your decision (based on discussion with other council members) on the merits of the proposal.
You can choose:
Approve
- approving the proposed actionReject
- reject the proposed actionSlash
- reject the proposed action, and slash the stake of the proposerAbstain
- abstain from votingMore information on how council votes are processed can be read here.