Key Performance Indicators (KPIs) define success metrics for the overall  testnet system, and will act as an incentive for the Council to do a  good job.

Starting with Antioch, KPI rewards will be distributed to Council Members based on their contributions. See Antioch KPIs here, and note that since it was "just" a runtime upgrade and not a new chain, the numbering continues.

Table of Contents

Overview

For each Council Term (or every other), a new set of KPIs will be released. These will  contain a mix of tasks, attempting to target different skills and  knowledge.

As soon as the Council is set, the Council Members CMs should try to agree on who is assigned what. If there are any disagreement,  Jsgenesis will use the individual "Term Summaries" (see below) and the  deliveries to set the individual rewards. This may lead to some "unfair"  rulings, but that is unfortunately how it must work.

Finally, as we have tried improving the KPI system, there will surely be some issues along the way. Please bear with us!

Current

KPI 22

  • KPIs: 15+3
  • Total Possible Rewards: $4075+650
  • Council Elected in Round: 24
  • Council Members: 16
  • KPI Length: 7 days / 100800 blocks
    • Start Block/Date: #2293200 / 15.09.21
    • End Block/Date: #2394000 / 21.09.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2422800 / 23.09.21

Notes

  1. As stated in the last round, we moved away from the fortnightly KPIs. We're keeping the notes below to avoid any further confusion.
  2. One thing we will keep from the failed attempt is that new KPIs may be added during the Term.
  3. A new introduction of this KPI is "permissions", in an attempt to reduce the occasional conflict of interest that may arise when you have a CM working on a (Council) KPI for a WG they are a part of. By default, all CMs can work on all Council KPIs (eg. all but the WG KPIs at the end), whereas for the WG KPIs, the Lead can assign anyone from their group.

Section I - Council work, Proposals and Bureaucracy

22.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

TBD

22.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

The Council appeared to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

After seeing this play out for a while, we still have mixed feelings about it. On one had, there is clearly more discussion, questioning and disagreeing. Whereas before, all proposals were basically approved, this is no longer the case.

On the flip-side, some (smaller) traces of fractioning has happened. To address this, we are doubling down on what was said last time:

We are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Finally, note that some of the SoW and reward requirements have changed.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

For all of the above, your comment should be precise, concise, polite, and if required, well sourced. A simple "no" will get you no where.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $200)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $150)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Further:

  • Only comments made in the proposal discussion will be evaluated. You can of course link to a longer post somewhere else there, but then you have to add a summary in the proposal discussion. Remember, having someones attention is not permanent.
  • Stay polite, even if you are replying to a personal comment, keep it civil.
  • You can only claim rewards for up to three proposals you dissented to.
  • Total Cap at $1000 per KPI, eg. $500 per Term

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

TBD

22.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

TBD

22.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

TBD

22.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

As the KPIs now cover 2 Council Terms, these reports must be generated for both terms. The naming convention should be 19A and 19B to refer to the two terms.

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2293200) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

TBD

22.6 - New Fiat Pool Scheme

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2293200
    • End Block: #2394000

Purpose

The community is taking a larger and more involved part of the Council voting, much to our pleasure. Let's make it more meaningful for them to do so!

An idea that's been discussed for some time now is the introduction of a way to increase the fiat pool based on the KPI performance. The exact structure of this has not been thought through, but here is one example of how it could work:

The current "baseline" for fiat pool replenishments is $1075 per week. Additionally, the fiat pool is increased at irregular intervals based on Bounty completions, and when minting new tokens as KPI rewards. Say the total achievable KPI (Council and WGs) rewards for a Term is $5000.

It must be assumed that if the all the KPIs are achieved, the Council did well (directly through Council KPIs, and indirectly for hiring good WG Leads). To reward the community for voting in a "good" Council, we could say that for every KPI dollar earned over $4000, 20% is added to the pool on a permanent basis.

On the other hand, if nothing is achieved, the Council did poorly. To punish the community for voting in a "bad" Council, we could say that for every KPI dollar under $2000, NOT earned, 20% is permanently removed from the pool.

Scope of Work

  1. Come up with a percentage based increase and/or decrease of the fiat pool based on the KPI performance. Use the results from KPI 21.10 to project what the current fiat pool would have been due to the past performance. The Council must approve your proposal in order for it to count.

  2. Propose other mechanism that could be used to decrease or fiat pool, based on either on-chain or off-chain events.

Reward Distribution

Grading is individual.

Weighting:

  1. $150
  2. $50

Grading

TBD

Section II - Community Management

22.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

    • Start Block: #2293200
    • End Block: #2394000

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

TBD

22.8 - Find All PRs/Issues That Require Jsgenesis

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a new list of actions required.

Scope of Work

  1. Find the last issue of this sort created in the community repo, review each of the items, reference it and create a new issue (in the same format) with the still unresolved items and reference the "old one".

  2. Go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, update the issue from 1. and add the new items.

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

  1. $50
  2. $100

Grading

TBD

22.9 - Create new KPIs

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

TBD

22.10 - KPIs Overview

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

The community has started voting as a unit, to ensure that a new Council is working well. As they have somewhat limited data to make that judgement, let's make it easier!

Note

SOW 1-3 was completed in KPI 21.10, but trying SOW 4 once more, with slightly higher rewards!

Scope of Work

  1. Get the stake for each CM for every Term. Note that unlike 1-3, this data must come from historical chain data. Should be separated in four datapoints:
  • Own stake
  • Other stake
  • If applicable, how much of the "other" stake was from JSG (5CJzTaCp5fuqG7NdJQ6oUCwdmFHKichew8w4RZ3zFHM8qSe6)
  • If applicable, how much of the "other" stake was themselves (eg. membership root and/or ctrl account)

Reward Distribution

Individual grading.

Grading

TBD

22.11 - Minting and Burning - Part 1

  • Reward: $700
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

The platform has taken a larger interest in the minting and burning of tokens recently. We believe this is good progress from previously, and it was a large part of the reason the dreaded "Council Dissent" KPI was introduced.

Although the "Tokenomics" and the status server combined gives a good idea of the mints and burns of Tokens, they do not provide the full picture.

Note

Bumping the reward a bit, after it's been unclaimed.

Scope of Work

The list below will hopefully cover all the sources of minting and burning of tokens on the platform, with some information on how to quantify it in (parentheses) from the historical chain data:

  • Minting:
    • Validator rewards (event)
    • Council rewards (from the Council Mint, which also funds proposals, refill is an event)
    • Other Worker and Lead rewards (from the respective mints, refill is an event)
    • Spending Proposals (event)
    • sudo 1 (event)
    • Other?
  • Burning:
    • Membership creation 2 (event)
    • Exchanges (when user sends to the exchange account, 5D5PhZQNJzcJXVBxwJxZcsutjKPqUPydrvpu6HeiBfMaeKQu, it makes a new transfer to itself with all tokens as fees)
    • Extrinsics/tx fees (must be set manually, see above)
    • Proposal fee (when not approved)
    • Proposal slashes
    • Worker and Lead slashes
      • Due to an issue with the current runtime, all stakes (both role and application) for the Operations group are/were burned
    • Other?
  1. Create a document with:
  • if applicable, the event, eg. sudo.setBalance for each mint/burn
  • what values from the chain state you need to compare for each block to calculate the mint/burn for that block
  • other sources of mints and burns.
    • if you find one, add the information requested above
  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

  2. Create a script that, at every block:

  • gets the totalIssuance
  • calculates what is minted and burned in the block
    • and compares the two amounts
    • if the they're not matching, return the block height(s)
  • for each "group" og mint and burn, sum up the total amounts

Use the script from block #717987 to #2091600 (or at least some intervals in that range), and whenever you see a discrepancy, check the particular block, and see if you can find the source, then update script and repeat.

The deliverable is the script (with comments), in PR to the Community Repo, alongside a list of blocks that you haven't been able to "understand", and some comments on what you have tried.

  • sudo always mints new tokens as KPI rewards, but on rare occasions for other purposes
  • when created through the Player onboarding, it's minted first

Reward Distribution

Individual grading.

  1. $250
  2. $250
  3. $200

Grading

TBD

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this section of KPIs.

22.12 - Follow up the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Note

Now that a Storage Lead has been hired, we're trying this one again. Note that anyone from the Storage Provider WG can not be the "primary" on this KPI.

Scope of Work

  1. Establishing the new OKR system for the SPs has unfortunately stalled. The technical part is more or less complete, and will be completed for the next Council Term, so we're going to cut through and propose something more specific. The work is to find out exactly what the numbers R_rec.L, R_okr.L, R_rec.W and R_okr.W should be:
  • The Lead currently earns ~$72 per week in recurring rewards
  • The Workers (ex JSG) all earn ~$30 per week in recurring rewards
  • Going forward, we propose all Workers (R_rec.W) earn either the break-even cost in terms of hardware, or slightly below.
  • Whether the recurring reward for the Lead (R_rec.L) should be higher or lower than this isn't clear.
    • The Lead has extra responsibilities to running their node, which has a value
    • The Lead will however potentially earn an extra income on this, as they will earn OKR rewards for the groups performance, and for Storage KPIs, which will cover most of their extra tasks
  • After establishing a benchmark value for OKRs, the OKR payout scheme will mean that of max OKR payout pool, equal to R_rec.L + R_rec.W, so that:
    • For the Group:
      • For each of the 7* KRs that exceeds the weekly target -> 1/7th of R_okr.W is shared between all the SPs that reached this individual KR.
      • If the group on average exceeds the target for 4/7 KRs, the Lead gets a bonus equal to R_okr.L/10
      • If the group on average exceeds the target for 5/7 KRs, the Lead gets a bonus equal to R_okr.L/5
      • If the group on average exceeds the target for 6/7 KRs, the Lead gets a bonus equal to R_okr.L/2
      • If the group on average exceeds the target for 7/7 KRs, the Lead gets a bonus equal to R_okr.L
  • Get these independent numbers approved by the Council, and provide specific examples of outcomes for the Workers and Lead with this schedule.
    • Note that half of the OKR rewards will come from minting of new tokens, so only half of the OKR rewards needs to be accounted for in the budget.
    • Further note that it's unlikely that the FULL OKR rewards (R_okr.W+R_okr.L) will actually be paid out each week, so the Council can assume the budget for the SP group won't have to pay all of R_rec.L + R_rec.W + (R_okr.W + R_okr.L)/2.

* Note that while the OKRs are being rolled out, the number will be lower than 7. The general process will still apply.

  1. Finally, as the OKRs will be tracked starting with the next Council Term, ensure that the Lead has set the new rewards for the workers before block #2091600.

  2. Assist the Lead with their other KPIs for the Term.

The CM addressing this task should familiarize themselves with the somehwat overlapping Storage KPIs.

Reward Distribution

Individual grading.

For 3. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $250
  • 2: $100
  • 3: $50

Grading

TBD

22.13 - Follow up the Content Curators Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Note

This was partially completed, but extending the whole thing for context. Grading will be delayed until after it's fully done.

Scope of Work

  1. After the closing of Bounty 10, the amount of uploads to the platform dropped substantially. Create a report containing information about content between blocks #717987 (first block with the current content directory) and #1998000 the following information, with charts where applicable:
  • Channel creation over time
  • Members with Channels over time
  • Uploads over time
  • Size of the dataDirectory over time
  • Curators (including Lead) over time
  • Curator rewards (including Lead), both in USD and tJOY.
  • Changes made to Channels and Videos over time
  • Curation/Censoring over time

Note that the information for the first 3 bullets above can be generated from the Hydra Playground, whereas the rest will require getting historical data from the chain. In the latter case, getting data for every 14400 blocks (eg. every day) is sufficient. The historical exchange rate can be derived from the status server.

  1. Use the data, and compare to the previous Curator Lead reports to get an estimate of the workload over time for the Curators, and compare the result to what was found in 1.

  2. Use the results as a baseline to review the current budget for the Curator group, keeping in mind that the workload is expected to go up (substantially) once the "new" content bounty is live.

  3. Assist the Curator Lead with their Curator KPI, KPI 19.CC-1.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $100
    1. $50
    1. $100

Grading

TBD

22.14 - Follow up the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Note

This was partially completed, but extending the whole thing for context. Grading will be delayed until after it's fully done.

Scope of Work

  1. The Operations group regularly presents interesting work that can enhance the platform. Get a an updated, and exhaustive list of what they want to achieve, and present it to the Council, in order to get a ranking of what the Council wants them to focus on. Note that this requires understanding not only what the end product is, but also insight about the complexity, value and time line for each of them.

  2. Once the results are in from the first Term, repeat the process for the second Council. Once the "final" results are in, co-operate with the Lead to get a firm timeline and manpower required for the top 3 items.

Reward Distribution

Grading is individual.

Grading

TBD

Section IV - Bounties

22.15 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

TBD

22.16 - Other Bounty Managers

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

We have lost track on the status of our bounties. Let's get back on track!

Scope of Work

For each of these open Bounties (#9, #16, #20, #21, #23), prepare a status update with the following information:

  • What has been started and completed? What is remaining?
    • Must include links to forum posts/github issues and PRs and proposals.
  • How much has been paid out by the Council? To whom?
    • Must include links to all spending proposals and PRs.
  • How much has been paid out by JSG?
  • Is there any action (review/payout/deploy/etc.) on JSG?
  • Is there a BM currently assigned?
  • Any other information to report?

Note that if you have participated OR is, or have been, a BM for one of the Bounties, please make that clear!

Reward Distribution

Individual.

Weighting:

  • 9 : $100

  • 16, #20, #21, #23 : $50

Grading

TBD

22.17 - Decentralized Domains Bounty

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2300400
    • End Block: #2386800

Purpose

We want to create a new Bounty for researching blockchain based decentralized domain name systems. To avoid having the Bounty require some of the success events being completed before we can move forward with the next ones, let's do some of the pre-work as bounties!

Scope of Work

Currently, there are at least a couple of projects focusing on blockchain based decentralized domains, such as:

We find this concept very interesting, and would love for the community to research these concepts further.

  1. Find Projects in the Substrate Space
    As we are building on substrate, it's easy to argue substrate based projects would be "best". Research if there are any actors in the space, and report back some "generic information":
  • Project Website
  • Project status (is it "live" and working?)
    • Supported blockchain(s)
    • Supported browser(s)
  • Is joystream.something available?
    • If yes, a 100$ bonus is added per project (not domain) IF:
    • Instructions to claim are added
    • This information is DM'ed to bwhm#6514 on discord, so that I can claim it before anyone else :)
  1. Find Other Projects in the Blockchain Space
    Research if there are any actors in the space, and report back some "generic information":
  • Project Website
  • Project status (is it "live" and working?)
    • Supported blockchain(s)
    • Supported browser(s)
  • Is joystream.something free?
    • If yes, a 50$ bonus is added per project (not domain) IF:
    • Instructions to claim are added
    • This information is DM'ed to bwhm#6514 on discord, so that I can claim it before anyone else :)

Reward Distribution

Individual grading.

If more than one person creates reports on this, the first one for each project earns the reward.

Weighting:

  • 1: $100 per project, capped at $300 (not including the joystream.something part)
  • 2: $25 per project, capped at $200 (not including the joystream.something part)

Grading

TBD

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • The Lead (if the position is occupied), must fill out the Term Summary and regardless if the task was assigned to a worker, or performed themselves.
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.

22.CC-1 - Bounty 18 Status Update

  • Reward: $200
    • Start Block: #2300400
    • End Block: #2386800

Purpose

See KPI 21.16!

Scope of Work

Same as KPI 21.16, but for Bounty 18.

22.OP-1 - Runtime Upgrade Verification

  • Reward: $300
    • Start Block: #2300400
    • End Block: #2386800

Purpose

With KPI 17.OP-1), the runtime upgrade was tested. However, the results weren't straight forward to parse. We need to verify exactly what happened, before we perform the upgrade on the real testnet!

Note that an updated version of pioneer can be found here, and that you can use the endpoint wss://staging-3.joystream.app/rpc for both pioneer and the API. Also note that the noteworthy fixes in this runtime upgrade was to:

  1. Fix the bug that caused all stakes when applying to the operations group caused the role and application stakes to get burned.
  2. Increase the max mint capacity increase through proposals from 5,000,000 to 50,000,000.

Note

Extended from last KPI round, with small reward increase.

Scope of Work

  1. After the proposed testing protocol was shared on Discord, I replied with some extra tasks. Although the tasks appear to have been performed, it's not easy to confirm from the results. Go through the list, and verify everything was done.

  2. Using the Member IDs, worker IDs, block heights, membership and worker accounts listed in the report, get the historical chain data from the applicable reports and test/verify for each opening and application:

  • What was the opening ID, opening parameters (max applicants, application/role stake, rewards and the various unstaking parameters)
  • Was the opening created before or after the runtime upgrade
  • What was the member ID, member handle, membership root/controller account, and role account
  • Was the application made before or after the runtime upgrade
  • What was the balance of each account, and the total issuance, on the block, and the block before, the member:
    • applied
    • was crowded out, not hired or hired
    • if hired:
      • fired or quit
    • note that if the unstaking parameter was >0, you need to check the block + the applicable unstaking value
    • note that if they were hired, they may have earned rewards that further complicates things
    • they may also have received tokens from other addresses/rewards in the window
    • also note that if the same member applied to multiple openings, you need to keep track of all stakes/values/rewards

After having generated all this information, create a report containing all the numbers above, an explanation of what you think happened, and whether the bug was fixed.

22.SP-1 - Storage OKRs

  • Reward: $300
  • Start Block: #2293200
  • End Block: #2394000

Note that this task is shared between the Operations Lead and the Storage Provider Lead. Ideally, they'll either co-operate, or delegate to workers in their respective groups to co-operate.

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established.

This has dragged out for far too long. Rewards increased again.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the proposed Key Results 1 - uptime, 5 - Rendering Time, and 6 - Upload Speed, and:
    • Are there any changes required to these?
    • What tools, not already available (eg. helios and joystreamstats.live has some helpful tools already) are needed to start measuring these right away?
    • Add examples, and improve the instructions and notations used so that the Council, Storage Providers and others understand exactly what and how is being measured, how it's going to be graded, and how frequently the should be measured
      Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. Deploy a script that measures the data you can, and share the script so that others can do so.
  2. Finally, review the proposed OKR system outlined in KPI 19.9, and the numbers that come out of it.

22.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #2293200
  • End Block: #2394000

Purpose

Although the OKR system will make it less profitable to be an underperforming SP on paper, the savings in costs by running a "cheap" node may break that assumption. Although we believe the Lead should have some subjective decision making power in deciding when the sanction a Worker, some objective data should be made available for the benefit of all parties. That doesn't mean that for long running SPs, with a great track record, some underperformance for some time is accepted.

Scope of Work

  1. Based on OKR related data, and/or other criteria, create a set of rules that could or should lead to the firing, slashing, or other sanctions agains an SP.

Previous KPIs

KPI 21

  • KPIs: 16+3
  • Total Possible Rewards: $4125+$350
  • Council Elected in Round: 23
  • Council Members: 16
  • KPI Length: 7 days / 100800 blocks
    • Start Block/Date: #2192400 / 07.09.21
    • End Block/Date: #2293200 / 14.09.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2293200 / 16.09.21

Notes

  1. After attempting moving to two terms per KPI set last time, we realized it wasn't really worth the confusion, and are moving back to the "old" way.
  2. One thing we will keep from the failed attempt is that new KPIs may be added during the Term.
  3. A new introduction of this KPI is "permissions", in an attempt to reduce the occasional conflict of interest that may arise when you have a CM working on a (Council) KPI for a WG they are a part of. By default, all CMs can work on all Council KPIs (eg. all but the WG KPIs at the end), whereas for the WG KPIs, the Lead can assign anyone from their group.

Section I - Council work, Proposals and Bureaucracy

21.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

TBD

21.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

The Council appeared to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

After seeing this play out for a while, we still have mixed feelings about it. On one had, there is clearly more discussion, questioning and disagreeing. Whereas before, all proposals were basically approved, this is no longer the case.

On the flip-side, some (smaller) traces of fractioning has happened. To address this, we are doubling down on what was said last time:

We are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Finally, note that some of the SoW and reward requirements have changed.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

For all of the above, your comment should be precise, concise, polite, and if required, well sourced. A simple "no" will get you no where.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $200)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $150)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Further:

  • Only comments made in the proposal discussion will be evaluated. You can of course link to a longer post somewhere else there, but then you have to add a summary in the proposal discussion. Remember, having someones attention is not permanent.
  • Stay polite, even if you are replying to a personal comment, keep it civil.
  • You can only claim rewards for up to three proposals you dissented to.
  • Total Cap at $1000 per KPI, eg. $500 per Term

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

TBD

21.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

TBD

21.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

TBD

21.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

As the KPIs now cover 2 Council Terms, these reports must be generated for both terms. The naming convention should be 19A and 19B to refer to the two terms.

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2192400) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

TBD

21.6 - FM Surveys

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. All CMs that does gets a $15 bonus.
  2. Have the Content Curators fill out this survey. At the time of writing, there are 6 workers + (1 the lead). For each CC after the 4th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers (no lead!). For each SP after the 5th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.

Reward Distribution

Grading is individual. Note that if you are elected for both terms, you still need to fill out the survey twice.

Grading

TBD

Section II - Community Management

21.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

    • Start Block: #2192400
    • End Block: #2293200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

TBD

21.8 - Clean up Community Repo - Part 2

  • Reward: $225+$150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

KPI 17.8 - Clean up Community Repo - Part 1, was partially completed, but it was nevertheless meant as a two-parter. Now it's time to finish it up!

Note that the @maxlevush, who submitted the work for Part 1, may be part of a team completing this task, but as the Scope of Work will reveal, they shouldn't complete it alone.

Extended from last KPI round.

Scope of Work

  1. Review the work already completed here, and consider the following:
  • Is the hierarchy proposed coherent and intiutive?
  • Are the conventions proposed both "good" enough, and not too difficult to adhere to?
  • What, if anything, is missing in the (now outdated) "preview" branch from the "original" SoW?
  1. Based on the findings in 1:
  • Draft up the "Contribution Guidelines", and for the purposes of the Council and the user of the repo, add some context about your choices.
  • Make a new, and updated*, branch on your fork showing how the repo would if all your proposed changes were included.
    • * the branch must not be based on a fork older than 48h.
  • Make a PR to the Joystream repo, so that all the changes are visible.
  • Make a Text Proposal to the Council with everything above.
  1. When the proposal is made, tag the Council Secretary and @bwhm#6514 on Discord, to participate in the discussion.

  2. While the proposal is being discussed, check in frequently, to participate in the discussion and ensure that any changes requested can be implemented quickly. In order to complete this task, all of the below must be done:

  • a (doesn't have to be the first one!) Text Proposal is approved by the Council
  • the format is accepted by @bwhm#6514
  • the PR must be updated to include any new PRs merged in the Joystream repo

Reward Distribution

As alluded to, this should KPI ideally be a collaborative effort. Unless 1-3 are all completed within the Term, the KPI will be extended and not graded before the next round.

Weighting:

  1. $50
  2. $150
  3. $25
  4. $150 *
    Note that this part is unlikely not to be completed before the end of the Term. If so, create a Spending Proposal that JSG will re-imburse after all the items in 4. is completed.

21.9 - Create new KPIs

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

TBD

21.10 - KPIs Overview

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

The community has started voting as a unit, to ensure that a new Council is working well. As they have somewhat limited data to make that judgement, let's make it easier!

Scope of Work

  1. Go through all the KPIs from Antioch and Sumer, and collect the following in a spreadsheet or json:
  • What was the total possible rewards for each Term
  • How much was paid out for each Term
  • Who where the CMs for each Term
  • How much did they earn in rewards
  1. Make sure the data is presented in such a way that it can be used to create tables ranking all past (and future) CMs by performance, both relatively and absolutely. Examples:
  • Rank all by total KPI earnings
  • Rank all by total KPI earnings per Term
  • Rank all by ratio of KPI earnings in a Term over total possible rewards for that Term
  • Rank all by ratio of KPI earnings in a Term over total paid rewards for that Term
  • etc.
  1. Make sure the data is presented in a way that allows creation of charts showing the performance over time for the both the entire Council and individual CMs. Examples:
  • Paid out per Term
  • Ratio of earned / total possible rewards
  • etc.
  1. Get the stake for each CM for every Term. Note that unlike 1-3, this data must come from historical chain data. Should be separated in four datapoints:
  • Own stake
  • Other stake
  • If applicable, how much of the "other" stake was from JSG (5CJzTaCp5fuqG7NdJQ6oUCwdmFHKichew8w4RZ3zFHM8qSe6)
  • If applicable, how much of the "other" stake was themselves (eg. membership root and/or ctrl account)

Reward Distribution

Individual grading.

  1. $150
  2. $50
  3. $50
  4. $150

Grading

TBD

21.11 - Minting and Burning - Part 1.

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

The platform has taken a larger interest in the minting and burning of tokens recently. We believe this is good progress from previously, and it was a large part of the reason the dreaded "Council Dissent" KPI was introduced.

Although the "Tokenomics" and the status server combined gives a good idea of the mints and burns of Tokens, they do not provide the full picture.

Scope of Work

The list below will hopefully cover all the sources of minting and burning of tokens on the platform, with some information on how to quantify it in (parentheses) from the historical chain data:

  • Minting:
    • Validator rewards (event)
    • Council rewards (from the Council Mint, which also funds proposals, refill is an event)
    • Other Worker and Lead rewards (from the respective mints, refill is an event)
    • Spending Proposals (event)
    • sudo 1 (event)
    • Other?
  • Burning:
    • Membership creation 2 (event)
    • Exchanges (when user sends to the exchange account, 5D5PhZQNJzcJXVBxwJxZcsutjKPqUPydrvpu6HeiBfMaeKQu, it makes a new transfer to itself with all tokens as fees)
    • Extrinsics/tx fees (must be set manually, see above)
    • Proposal fee (when not approved)
    • Proposal slashes
    • Worker and Lead slashes
      • Due to an issue with the current runtime, all stakes (both role and application) for the Operations group are/were burned
    • Other?
  1. Create a document with:
  • if applicable, the event, eg. sudo.setBalance for each mint/burn
  • what values from the chain state you need to compare for each block to calculate the mint/burn for that block
  • other sources of mints and burns.
    • if you find one, add the information requested above
  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

<body="19.16-1">sudo always mints new tokens as KPI rewards, but on rare occasions for other purposes>
<body="19.16-2">when created through the Player onboarding, it's minted first>

Reward Distribution

Individual grading.

  1. $150
  2. $150

Grading

TBD

  1. Create a script that, at every block:
  • gets the totalIssuance
  • calculates what is minted and burned in the block
    • and compares the two amounts
    • if the they're not matching, return the block height(s)
  • for each "group" og mint and burn, sum up the total amounts

Use the script from block #717987 to #2091600 (or at least some intervals in that range), and whenever you see a discrepancy, check the particular block, and see if you can find the source, then update script and repeat.

The deliverable is the script (with comments), in PR to the Community Repo, alongside a list of blocks that you haven't been able to "understand", and some comments on what you have tried.

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this section of KPIs.

21.12 - Follow up the Storage Working Group

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Hire a new Lead!

Reward Distribution

Individual grading.

Grading

TBD

21.13 - Follow up the Content Curators Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. After the closing of Bounty 10, the amount of uploads to the platform dropped substantially. Create a report containing information about content between blocks #717987 (first block with the current content directory) and #1998000 the following information, with charts where applicable:
  • Channel creation over time
  • Members with Channels over time
  • Uploads over time
  • Size of the dataDirectory over time
  • Curators (including Lead) over time
  • Curator rewards (including Lead), both in USD and tJOY.
  • Changes made to Channels and Videos over time
  • Curation/Censoring over time

Note that the information for the first 3 bullets above can be generated from the Hydra Playground, whereas the rest will require getting historical data from the chain. In the latter case, getting data for every 14400 blocks (eg. every day) is sufficient. The historical exchange rate can be derived from the status server.

  1. Use the data, and compare to the previous Curator Lead reports to get an estimate of the workload over time for the Curators, and compare the result to what was found in 1.

  2. Use the results as a baseline to review the current budget for the Curator group, keeping in mind that the workload is expected to go up (substantially) once the "new" content bounty is live.

  3. Assist the Curator Lead with their Curator KPI, KPI 19.CC-1.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $100
    1. $50
    1. $100

Grading

TBD

21.14 - Follow up the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2199600
    • End Block: #2286000

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Note: Extended from last week. Some work about this was submitted, but at the time of writing, it appears to be a little different than what was intended.

Scope of Work

  1. The Operations group regularly presents interesting work that can enhance the platform. Get a an updated, and exhaustive list of what they want to achieve, and present it to the Council, in order to get a ranking of what the Council wants them to focus on. Note that this requires understanding not only what the end product is, but also insight about the complexity, value and time line for each of them.

  2. Once the results are in from the first Term, repeat the process for the second Council. Once the "final" results are in, co-operate with the Lead to get a firm timeline and manpower required for the top 3 items.

Reward Distribution

Grading is individual.

Grading

TBD

Section IV - Bounties

21.15 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

TBD

21.16 - Other Bounty Managers

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2192400
    • End Block: #2293200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language
  1. The JSG "Specs" for Community Bounty #24 - "Upload Content", can be found here. From KPI 18.CC-3, these terms and conditions were presented. KPI 19.CC-2 will continue to focus on launching this Bounty.
  • Set a weekly reward for the BM, reflecting the expected workload of reviewing 100s of videos each week.
  • Find one or two BMs (ideally yourself) that:
    • Speaks English and Russian
    • Is interested in, and knowledge of, videos and old films
    • Is willing not to participate in the Bounty themselves
    • Has some understanding of the platform
    • Is not currently, or is willing to quit as, a Curator
    • Get the person approved by the Council
  • Push the BM, and the Curator Lead, to get the final Bounty text for the participants, and the workflow for the Curators and the BM(s) approved by JSG.
  • Ensure the BM sets a reward structure that rewards the best video(s) a little extra.
    Note that some extra information can be found in KPI 19.CC-2.

Reward Distribution

Grading is individual.

Weighting:

  • 1-2: $50
  • 3: $200 - Note that the BM(s) should get half of this, if it's not the same person(s) as the CM

Grading

TBD

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • The Lead (if the position is occupied), must fill out the Term Summary and regardless if the task was assigned to a worker, or performed themselves.
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.

21.CC-1 - TBD

  • Reward: $TBD
  • Start Block: #2192400
  • End Block: #2293200

21.CC-2 - New "Upload Content" Bounty

  • Reward: $100
  • Start Block: #1990800
  • End Block: #2192400

21.OP-1 - Runtime Upgrade Verification

  • Reward: $250
  • Start Block: #2192400
  • End Block: #2293200

Purpose

With KPI 17.OP-1), the runtime upgrade was tested. However, the results weren't straight forward to parse. We need to verify exactly what happened, before we perform the upgrade on the real testnet!

Note that an updated version of pioneer can be found here, and that you can use the endpoint wss://staging-3.joystream.app/rpc for both pioneer and the API. Also note that the noteworthy fixes in this runtime upgrade was to:

  1. Fix the bug that caused all stakes when applying to the operations group caused the role and application stakes to get burned.
  2. Increase the max mint capacity increase through proposals from 5,000,000 to 50,000,000.

Extended from last KPI round.

Scope of Work

  1. After the proposed testing protocol was shared on Discord, I replied with some extra tasks. Although the tasks appear to have been performed, it's not easy to confirm from the results. Go through the list, and verify everything was done.

  2. Using the Member IDs, worker IDs, block heights, membership and worker accounts listed in the report, get the historical chain data from the applicable reports and test/verify for each opening and application:

  • What was the opening ID, opening parameters (max applicants, application/role stake, rewards and the various unstaking parameters)
  • Was the opening created before or after the runtime upgrade
  • What was the member ID, member handle, membership root/controller account, and role account
  • Was the application made before or after the runtime upgrade
  • What was the balance of each account, and the total issuance, on the block, and the block before, the member:
    • applied
    • was crowded out, not hired or hired
    • if hired:
      • fired or quit
    • note that if the unstaking parameter was >0, you need to check the block + the applicable unstaking value
    • note that if they were hired, they may have earned rewards that further complicates things
    • they may also have received tokens from other addresses/rewards in the window
    • also note that if the same member applied to multiple openings, you need to keep track of all stakes/values/rewards

After having generated all this information, create a report containing all the numbers above, an explanation of what you think happened, and whether the bug was fixed.

21.SP-1 - Storage OKRs (Joint with 19.OP-2)

  • Reward: $250
  • Start Block: #2192400
  • End Block: #2293200

Note that this task is shared between the Operations Lead and the Storage Provider Lead. Ideally, they'll either co-operate, or delegate to workers in their respective groups to co-operate.

As there is no Lead at the moment, any Storage Provider can complete this task.

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, and the KPI 17.SP-1 wasn't completed last term, we'll give them one more chance, but with a shorter deadline.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the proposed Key Results 1 - uptime, 5 - Rendering Time, and 6 - Upload Speed, and:
    • Are there any changes required to these?
    • What tools, not already available (eg. helios and joystreamstats.live has some helpful tools already) are needed to start measuring these right away?
    • Add examples, and improve the instructions and notations used so that the Council, Storage Providers and others understand exactly what and how is being measured, how it's going to be graded, and how frequently the should be measured
      Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. Deploy a script that measures the data you can, and share the script so that others can do so.
  2. Finally, review the proposed OKR system outlined in KPI 19.9, and the numbers that come out of it.

KPI 19

  • KPIs: 16+7
  • Total Possible Rewards: $4550+$1125
  • Council Elected in Round: 21
  • Council Members: 16
  • KPI Length: 14 days / 201600 blocks
    • Start Block/Date: #1990800 / 24.08.21
    • End Block/Date: #2192400 / 07.09.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2221200 / 09.09.21
Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 33 1270701
2194 ilich 395 15209909
644 lkskrn 33 1270701
2098 0x2bc 208 8009269
635 xfactorus 16 616098
798 shtihmas 46 1771281
867 xandrell 70 2695427
1962 nkhlghbl 4 154024
439 fierydev 0 0
2 tomato 292 11243781
736 mmsaww 54 2079329
2329 laura 357 13746678
2130 maxlevush 598 23026648
1048 igrex 149 5737409
2435 zazik 16 616098
2182 isonar 17+50 654604+1925304
361 blackmass 6 231037
2096 svasilenko 87 3350031
321 freakstatic_council 517 19907654
2462 chiffah 51 1963811
790 ururu 12 462073
2148 controlla 11 423567
SUM 22 2972+50 114440130+1925304

Paid out at blocks #2,297,046 and #2,297,047.

Important Note

This set of KPIs extends across two weeks, which means it covers two Councils Terms. Some KPIs cover a single week. During the Terms, at least wWhen the 22nd council is elected (the second council), some new KPIs will be presented and extra scope may be added to existing ones.

The purpose of the change is two-fold:

  1. A lot of time is "lost" for the KPIs as they have been. We need to evaluate what has been done, and to what extent, meaning there's a delay in creating new ones. Then, the Council looks at, discusses and claims/distributes the tasks among themselves. Then, we need to slice some time off of the end to give room to evaluate.
  2. Grading, creating and publishing takes a lot of time. Although this change won't cut that in two, it will reduce some of the overhead.

For the individual CM, it means that if you are elected during the first Term, but not re-elected, you still have time to finish a KPI you started. You can however not start on the KPIs that was added/expanded upon. If you were elected in the second Term only, we hope the other CMs will be accommodating, and give you "priority" on the new tasks.

This was meant to follow a switch back to two week long Terms, but after giving it some thinking, we concluded the predictability of running for the Council every week is too important to give up.

If it doesn't work this way, we will revert back to the old system.


Added 19.8 on the 31st of August.

Added 19.14-19.16 on the 2nd of September.

Section I - Council work, Proposals and Bureaucracy

19.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: 2 council terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 36 134 18
2194 ilich 29 105 14
644 lkskrn 35 125 17
2098 0x2bc 6 24 3
635 xfactorus 34 117 16
798 shtihmas 34 120 16
867 xandrell 33 114 16
1962 nkhlghbl 7 30 4
439 fierydev 0 0 0
2 tomato 23 90 12
736 mmsaww 22 83 11
2329 laura 36 136 19
2130 maxlevush 30 119 16
1048 igrex 38 151 21
2435 zazik 21 76 10
2182 isonar 11 43 6
SUM 16 395 1467 200
Member ID Member Handle Voted Points Reward
1905 lyazufey1812 30 107 15
2194 ilich 21 75 11
644 lkskrn 30 110 16
361 blackmass 13 40 6
2098 0x2bc 10 34 5
2096 svasilenko 24 83 12
867 xandrell 34 118 17
321 freakstatic_council 30 120 17
2462 chiffah 25 93 13
2329 laura 30 129 18
790 ururu 23 83 12
2130 maxlevush 23 101 14
1048 igrex 33 129 18
2435 zazik 11 40 6
2148 controlla 19 76 11
2182 isonar 18 79 11
SUM 16 374 1417 200

19.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: 2 council terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

The Council appeared to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

After seeing this play out for a while, we still have mixed feelings about it. On one had, there is clearly more discussion, questioning and disagreeing. Whereas before, all proposals were basically approved, this is no longer the case.

On the flip-side, some (smaller) traces of fractioning has happened. To address this, we are doubling down on what was said last time:

We are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Finally, note that some of the SoW and reward requirements have changed.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

For all of the above, your comment should be precise, concise, polite, and if required, well sourced. A simple "no" will get you no where.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $200)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $150)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Further:

  • Only comments made in the proposal discussion will be evaluated. You can of course link to a longer post somewhere else there, but then you have to add a summary in the proposal discussion. Remember, having someones attention is not permanent.
  • Stay polite, even if you are replying to a personal comment, keep it civil.
  • You can only claim rewards for up to three proposals you dissented to.
  • Total Cap at $1000 per KPI, eg. $500 per Term

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

19.3 - Council Secretary

  • Reward: $300 per council term
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: (elected once per council term)
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • W1 - tomato - $280 - https://testnet.joystream.org/#/proposals/478
    • Managing PR's in community repo per rules: Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes
  • W2 - maxlevush - $280 - https://testnet.joystream.org/#/proposals/518
    • Managing PR's in community repo per rules: Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes

19.4 - Deputy Council Secretary

  • Reward: $150 per council term
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: (elected once per council term)
    • Start Block: #1990800
    • End Block: #2192400

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

19.5 - Council Minutes

  • Reward: $100 per council term
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term(s) + 1 day
    • Start Block: #1990800
    • End Blocks: #2091600, #2192400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

As the KPIs now cover 2 Council Terms, these reports must be generated for both terms. The naming convention should be 19A and 19B to refer to the two terms.

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2192400) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

19.6 - FM Surveys

  • Reward: $75 per term
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: 2 Full Terms
    • Start Block: #1990800
    • End Blocks: #2091600, #2192400

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others). These surveys must be completed each council term.
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + (1 the lead). For each CC after the 6th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 (the lead). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.

Reward Distribution

Grading is individual. Note that if you are elected for both terms, you still need to fill out the survey twice.

Grading

  • No claims

Section II - Community Management

19.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: 2x Full Terms

    • Start Block: #1990800
    • End Block: #2192400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

19.8 - Clean up Community Repo - Part 2

  • Reward: $225+$150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

KPI 17.8 - Clean up Community Repo - Part 1, was partially completed, but it was nevertheless meant as a two-parter. Now it's time to finish it up!

Note that the @maxlevush, who submitted the work for Part 1, may be part of a team completing this task, but as the Scope of Work will reveal, they shouldn't complete it alone.

Scope of Work

  1. Review the work already completed here, and consider the following:
  • Is the hierarchy proposed coherent and intiutive?
  • Are the conventions proposed both "good" enough, and not too difficult to adhere to?
  • What, if anything, is missing in the (now outdated) "preview" branch from the "original" SoW?
  1. Based on the findings in 1:
  • Draft up the "Contribution Guidelines", and for the purposes of the Council and the user of the repo, add some context about your choices.
  • Make a new, and updated*, branch on your fork showing how the repo would if all your proposed changes were included.
    • * the branch must not be based on a fork older than 48h.
  • Make a PR to the Joystream repo, so that all the changes are visible.
  • Make a Text Proposal to the Council with everything above.
  1. When the proposal is made, tag the Council Secretary and @bwhm#6514 on Discord, to participate in the discussion.

  2. While the proposal is being discussed, check in frequently, to participate in the discussion and ensure that any changes requested can be implemented quickly. In order to complete this task, all of the below must be done:

  • a (doesn't have to be the first one!) Text Proposal is approved by the Council
  • the format is accepted by @bwhm#6514
  • the PR must be updated to include any new PRs merged in the Joystream repo

Reward Distribution

As alluded to, this should KPI ideally be a collaborative effort. Unless 1-3 are all completed within the Term, the KPI will be extended and not graded before the next round.

Weighting:

  1. $50
  2. $150
  3. $25
  4. $150 *
    Note that this part is unlikely not to be completed before the end of the Term. If so, create a Spending Proposal that JSG will re-imburse after all the items in 4. is completed.

Grading

  • Continued in KPI 21

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this section of KPIs.

19.9 - Follow up the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Establishing the new OKR system for the SPs has unfortunately stalled. The technical part is more or less complete, and will be completed for the next Council Term, so we're going to cut through and propose something more specific. The work is to find out exactly what the numbers R_rec.L, R_okr.L, R_rec.W and R_okr.W should be:
  • The Lead currently earns ~$72 per week in recurring rewards
  • The Workers (ex JSG) all earn ~$30 per week in recurring rewards
  • Going forward, we propose all Workers (R_rec.W) earn either the break-even cost in terms of hardware, or slightly below.
  • Whether the recurring reward for the Lead (R_rec.L) should be higher or lower than this isn't clear.
    • The Lead has extra responsibilities to running their node, which has a value
    • The Lead will however potentially earn an extra income on this, as they will earn OKR rewards for the groups performance, and for Storage KPIs, which will cover most of their extra tasks
  • After establishing a benchmark value for OKRs, the OKR payout scheme will mean that of max OKR payout pool, equal to R_rec.L + R_rec.W, so that:
    • For the Group:
      • For each of the 7* KRs that exceeds the weekly target -> 1/7th of R_okr.W is shared between all the SPs that reached this individual KR.
      • If the group on average exceeds the target for 4/7 KRs, the Lead gets a bonus equal to R_okr.L/10
      • If the group on average exceeds the target for 5/7 KRs, the Lead gets a bonus equal to R_okr.L/5
      • If the group on average exceeds the target for 6/7 KRs, the Lead gets a bonus equal to R_okr.L/2
      • If the group on average exceeds the target for 7/7 KRs, the Lead gets a bonus equal to R_okr.L
  • Get these independent numbers approved by the Council, and provide specific examples of outcomes for the Workers and Lead with this schedule.
    • Note that half of the OKR rewards will come from minting of new tokens, so only half of the OKR rewards needs to be accounted for in the budget.
    • Further note that it's unlikely that the FULL OKR rewards (R_okr.W+R_okr.L) will actually be paid out each week, so the Council can assume the budget for the SP group won't have to pay all of R_rec.L + R_rec.W + (R_okr.W + R_okr.L)/2.

* Note that while the OKRs are being rolled out, the number will be lower than 7. The general process will still apply.

  1. Finally, as the OKRs will be tracked starting with the next Council Term, ensure that the Lead has set the new rewards for the workers before block #2091600.

  2. Assist the Lead with their other KPIs for the Term.

The CM addressing this task should familiarize themselves with the somehwat overlapping Storage KPIs.

Reward Distribution

Individual grading.

For 3. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $250
  • 2: $150

Grading

19.10 - Follow up the Content Curators Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. After the closing of Bounty 10, the amount of uploads to the platform dropped substantially. Create a report containing information about content between blocks #717987 (first block with the current content directory) and #1998000 the following information, with charts where applicable:
  • Channel creation over time
  • Members with Channels over time
  • Uploads over time
  • Size of the dataDirectory over time
  • Curators (including Lead) over time
  • Curator rewards (including Lead), both in USD and tJOY.
  • Changes made to Channels and Videos over time
  • Curation/Censoring over time

Note that the information for the first 3 bullets above can be generated from the Hydra Playground, whereas the rest will require getting historical data from the chain. In the latter case, getting data for every 14400 blocks (eg. every day) is sufficient. The historical exchange rate can be derived from the status server.

  1. Use the data, and compare to the previous Curator Lead reports to get an estimate of the workload over time for the Curators, and compare the result to what was found in 1.

  2. Use the results as a baseline to review the current budget for the Curator group, keeping in mind that the workload is expected to go up (substantially) once the "new" content bounty is live.

  3. Assist the Curator Lead with their Curator KPI, KPI 19.CC-1.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $100
    1. $50
    1. $100

Grading

  • SOW 1 (Bounty 10 report) - $150
  • SOW 2 (Estimate curator workload) - $100
    • No work submitted/completed
  • SOW 3 (Review the budget) - $50
    • No work submitted/completed
  • SOW 4 (Assist lead wth Curator KPI) - $100
    • No work submitted/completed

19.11 - Follow up the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1998000
    • End Block: #2192400

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. The Operations group regularly presents interesting work that can enhance the platform. Get a an updated, and exhaustive list of what they want to achieve, and present it to the Council, in order to get a ranking of what the Council wants them to focus on. Note that this requires understanding not only what the end product is, but also insight about the complexity, value and time line for each of them.

  2. Once the results are in from the first Term, repeat the process for the second Council. Once the "final" results are in, co-operate with the Lead to get a firm timeline and manpower required for the top 3 items.

Reward Distribution

Grading is individual.

Grading

  • SOW 1 (Get a list of what Operations wants to achieve)
  • SOW 2 (Get a firm timeline)
    • No work submitted/completed

Section IV - Bounties

19.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per term
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms + 1 day
    • Start Block: #1990800
    • End Block: #2106000 (denote as 19-12.A)
    • End Block: #2192400 (denote as 19-12.B)

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

19.13 - Other Bounty Managers

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day (single term)
    • Start Block: #1990800
    • End Block: #2106000 (denote as 19-12.A)
    • End Block: #2192400 (denote as 19-12.B)

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language
  1. The JSG "Specs" for Community Bounty #24 - "Upload Content", can be found here. From KPI 18.CC-3, these terms and conditions were presented. KPI 19.CC-2 will continue to focus on launching this Bounty.
  • Set a weekly reward for the BM, reflecting the expected workload of reviewing 100s of videos each week.
  • Find one or two BMs (ideally yourself) that:
    • Speaks English and Russian
    • Is interested in, and knowledge of, videos and old films
    • Is willing not to participate in the Bounty themselves
    • Has some understanding of the platform
    • Is not currently, or is willing to quit as, a Curator
    • Get the person approved by the Council
  • Push the BM, and the Curator Lead, to get the final Bounty text for the participants, and the workflow for the Curators and the BM(s) approved by JSG.
  • Ensure the BM sets a reward structure that rewards the best video(s) a little extra.
    Note that some extra information can be found in KPI 19.CC-2.

Reward Distribution

Grading is individual.

Weighting:

  • 1-2: $50
  • 3: $200 - Note that the BM(s) should get half of this, if it's not the same person(s) as the CM

Grading

Section V - Interim KPIs

Due to the numbering system, these are added here. Note that [KPI 19.8](#19.8) was also added after the "first" Term, but the ones below at an even later stage. (We'll go back to weekly KPIs starting next Term)

19.14 - Create new KPIs

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

19.15 - KPIs Overview

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

The community has started voting as a unit, to ensure that a new Council is working well. As they have somewhat limited data to make that judgement, let's make it easier!

Scope of Work

  1. Go through all the KPIs from Antioch and Sumer, and collect the following in a spreadsheet or json:
  • What was the total possible rewards for each Term
  • How much was paid out for each Term
  • Who where the CMs for each Term
  • How much did they earn in rewards
  1. Make sure the data is presented in such a way that it can be used to create tables ranking all past (and future) CMs by performance, both relatively and absolutely. Examples:
  • Rank all by total KPI earnings
  • Rank all by total KPI earnings per Term
  • Rank all by ratio of KPI earnings in a Term over total possible rewards for that Term
  • Rank all by ratio of KPI earnings in a Term over total paid rewards for that Term
  • etc.
  1. Make sure the data is presented in a way that allows creation of charts showing the performance over time for the both the entire Council and individual CMs. Examples:
  • Paid out per Term
  • Ratio of earned / total possible rewards
  • etc.
  1. Get the stake for each CM for every Term. Note that unlike 1-3, this data must come from historical chain data. Should be separated in four datapoints:
  • Own stake
  • Other stake
  • If applicable, how much of the "other" stake was from JSG (5CJzTaCp5fuqG7NdJQ6oUCwdmFHKichew8w4RZ3zFHM8qSe6)
  • If applicable, how much of the "other" stake was themselves (eg. membership root and/or ctrl account)

Reward Distribution

Individual grading.

  1. $150
  2. $50
  3. $50
  4. $150

Grading

19.16 - Minting and Burning - Part 1

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

The platform has taken a larger interest in the minting and burning of tokens recently. We believe this is good progress from previously, and it was a large part of the reason the dreaded "Council Dissent" KPI was introduced.

Although the "Tokenomics" and the status server combined gives a good idea of the mints and burns of Tokens, they do not provide the full picture.

Scope of Work

The list below will hopefully cover all the sources of minting and burning of tokens on the platform, with some information on how to quantify it in (parentheses) from the historical chain data:

  • Minting:
    • Validator rewards (event)
    • Council rewards (from the Council Mint, which also funds proposals, refill is an event)
    • Other Worker and Lead rewards (from the respective mints, refill is an event)
    • Spending Proposals (event)
    • sudo 1 (event)
    • Other?
  • Burning:
    • Membership creation 2 (event)
    • Exchanges (when user sends to the exchange account, 5D5PhZQNJzcJXVBxwJxZcsutjKPqUPydrvpu6HeiBfMaeKQu, it makes a new transfer to itself with all tokens as fees)
    • Extrinsics/tx fees (must be set manually, see above)
    • Proposal fee (when not approved)
    • Proposal slashes
    • Worker and Lead slashes
      • Due to an issue with the current runtime, all stakes (both role and application) for the Operations group are/were burned
    • Other?
  1. Create a document with:
  • if applicable, the event, eg. sudo.setBalance for each mint/burn
  • what values from the chain state you need to compare for each block to calculate the mint/burn for that block
  • other sources of mints and burns.
    • if you find one, add the information requested above
  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.
  • sudo always mints new tokens as KPI rewards, but on rare occasions for other purposes
  • when created through the Player onboarding, it's minted first

Reward Distribution

Individual grading.

  1. $150
  2. $150

Grading

  • Continued in KPI 21

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.

19.CC-1 - Update Featured Video Rules

  • Reward: $75
  • Start Block: #1990800
  • End Block: #2192400

The "Main" featured video for the Joystream Player was just changed, but the rules are still missing!

Some notes:

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Notes:
  • JSG reserves the right to veto this choice, for any reason.
  • Certain metadata is required, including a cover cut.
  • The community should keep in mind the featured video slot should be reserved for the absolute best ones in terms of production value etc.
    Remember that the featured video is the first thing any new user will see when opening the Joystream Player, and it autoplays the "cover cut" by default. That means that this video has to be standout, and the cover cut needs to be interesting. The main goal of this video (in the future) is to get the person opening the Joystream Player buy a subscription to the platform!
  1. Decide on frequency for how often the video should be changed.

Grading

19.CC-2 - New "Upload Content" Bounty

  • Reward: $100
  • Start Block: #1990800
  • End Block: #2192400

Purpose

We have been working on finalizing this for a while, and now it's time to finish!

The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here.
Last week, the Curators presented a set of terms and conditions here.

Scope of Work

  1. The terms contained some good additions to the rules, but some elements requested in the "Specs" and KPI 18.CC-3 was not included:
  • The BM, ie. the person that grades the "quality" and thus reward distribution must not be a (current) Curator.
  • The exact format that participants should post in the forum (making it easier for all)
  • A template for the Curators "approval" spreadsheet
  • The workflow and timeline
    As the first to act at the end of each week, this must be settled!
Grading

19.OP-1 - Runtime Upgrade Verification

  • Reward: $250
  • Start Block: #1998000
  • End Block: #2192400

Purpose

With KPI 17.OP-1), the runtime upgrade was tested. However, the results weren't straight forward to parse. We need to verify exactly what happened, before we perform the upgrade on the real testnet!

Note that an updated version of pioneer can be found here, and that you can use the endpoint wss://staging-3.joystream.app/rpc for both pioneer and the API. Also note that the noteworthy fixes in this runtime upgrade was to:

  1. Fix the bug that caused all stakes when applying to the operations group caused the role and application stakes to get burned.
  2. Increase the max mint capacity increase through proposals from 5,000,000 to 50,000,000.

Scope of Work

  1. After the proposed testing protocol was shared on Discord, I replied with some extra tasks. Although the tasks appear to have been performed, it's not easy to confirm from the results. Go through the list, and verify everything was done.

  2. Using the Member IDs, worker IDs, block heights, membership and worker accounts listed in the report, get the historical chain data from the applicable reports and test/verify for each opening and application:

  • What was the opening ID, opening parameters (max applicants, application/role stake, rewards and the various unstaking parameters)
  • Was the opening created before or after the runtime upgrade
  • What was the member ID, member handle, membership root/controller account, and role account
  • Was the application made before or after the runtime upgrade
  • What was the balance of each account, and the total issuance, on the block, and the block before, the member:
    • applied
    • was crowded out, not hired or hired
    • if hired:
      • fired or quit
    • note that if the unstaking parameter was >0, you need to check the block + the applicable unstaking value
    • note that if they were hired, they may have earned rewards that further complicates things
    • they may also have received tokens from other addresses/rewards in the window
    • also note that if the same member applied to multiple openings, you need to keep track of all stakes/values/rewards

After having generated all this information, create a report containing all the numbers above, an explanation of what you think happened, and whether the bug was fixed.

Grading
  • No work submitted/completed

19.SP-1 - Storage OKRs (Joint with 19.OP-2)

  • Reward: $250
  • Start Block: #1998000
  • End Block: #2192400

Note that this task is shared between the Operations Lead and the Storage Provider Lead. Ideally, they'll either co-operate, or delegate to workers in their respective groups to co-operate.

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, and the KPI 17.SP-1 wasn't completed last term, we'll give them one more chance, but with a shorter deadline.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the proposed Key Results 1 - uptime, 5 - Rendering Time, and 6 - Upload Speed, and:
    • Are there any changes required to these?
    • What tools, not already available (eg. helios and joystreamstats.live has some helpful tools already) are needed to start measuring these right away?
    • Add examples, and improve the instructions and notations used so that the Council, Storage Providers and others understand exactly what and how is being measured, how it's going to be graded, and how frequently the should be measured
      Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. Deploy a script that measures the data you can, and share the script so that others can do so.
  2. Finally, review the proposed OKR system outlined in KPI 19.9, and the numbers that come out of it.
Grading
  • No progress.

19.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #1998000
  • End Block: #2192400

Purpose

Although the OKR system will make it less profitable to be an underperforming SP on paper, the savings in costs by running a "cheap" node may break that assumption. Although we believe the Lead should have some subjective decision making power in deciding when the sanction a Worker, some objective data should be made available for the benefit of all parties. That doesn't mean that for long running SPs, with a great track record, some underperformance for some time is accepted.

Scope of Work

  1. Based on OKR related data, and/or other criteria, create a set of rules that could or should lead to the firing, slashing, or other sanctions agains an SP.
Grading
  • No work submitted/completed

19.SP-3 - Test Storage Node Upgrade

  • Reward: $400
  • Start Block: #1998000
  • End Block: #2192400

Purpose

A PR with another upgrade to the storage node was made a while back. This has been testet quite well, and seems to improve the performance further, with some improvements added to helios as well that should be helpful for the OKRs.

Scope of Work

  1. Fire up two new storage nodes at the same time, where one runs the current master branch, and the other the branch with the upgrade. Log which commit they are built from. Configure them as such:
  • both in the same datacenter
  • with the same specs
  • run as --anonymous
  • set --max-sync 50
  • ensure they have enough storage (at least 300GB) to reduce randomness.
  1. Check the amount of storage they have available at regular intervals (say every 1h), and compare the time it takes for each to complete, and whether they have any issues.

  2. Deploy them (don't think you need to actually hire them, but you need a URL at least) to test downloading and playing 20-30 videos both have to a third computer, and compare the the download speed.

  3. Test the new helios functionalities.

  4. Report the results.

Grading

KPI 18

  • KPIs: 13+7
  • Total Possible Rewards: $2450+$1075
  • Council Elected in Round: 20
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1890000 / 17.08.21
    • End Block/Date: #1990800 / 24.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2019600 / 26.08.21

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 51 1798036
2124 julysake 10 352556
361 blackmass 9 317300
515 l1dev 164 5781919
635 xfactorus 19 669857
867 xandrell 57 2009570
318 supunssw 7 246789
2039 doppelganger23 9 317300
321 freakstatic_council 117 4124906
957 leet_joy 6 211534
439 fierydev 2 70511
2462 chiffah 68 2397381
4 nexusfallout 10 352556
2 tomato 348 12268951
2435 zazik 75 2644170
2182 isonar 215 7579955
2329 laura 480 16922691
SUM 17 1647 58065982

Note that some of the CMs shouldn't have gotten rewards, as they forgot to fill out the CM/FM survey. Fortunately for them, we forgot to annihilate them :)

Payouts made on block #2049149.

Section I - Council work, Proposals and Bureaucracy

18.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 39 147 21
2124 julysake 21 69 10
361 blackmass 16 61 9
515 l1dev 25 95 14
635 xfactorus 37 134 19
867 xandrell 39 132 19
318 supunssw 12 48 7
2039 doppelganger23 18 60 9
321 freakstatic_council 32 118 17
957 leet_joy 14 40 6
439 fierydev 4 16 2
2462 chiffah 28 106 15
4 nexusfallout 18 67 10
2 tomato 22 90 13
2435 zazik 27 106 15
2182 isonar 28 103 15
SUM 16 380 1392 200

18.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

As we have yet to conclude the second "round" of these, we will give it a little more time. Note however that the grading will require far better arguments (when in disagreement), and more precise questions (when information is required) for qualifying for rewards. A simple "no.", or "why?" will not command anything. Finally, we are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Total Cap at $500

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

  • @lyazufey1812 ($30)
    • https://testnet.joystream.org/#/proposals/463
      • Cost: Unknown
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No
      • Reward: $35
        • The comment raised some important small mistakes with the written proposal
  • @chiffah ($15)
    • https://testnet.joystream.org/#/proposals/449
      • Cost: Up to $400
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and there was no comment made.
      • Reward: $15
    • https://testnet.joystream.org/#/proposals/438
      • Cost: Up to $10
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and the comment didn't provide any dissent.
      • Reward: $0
    • https://testnet.joystream.org/#/proposals/437
      • Cost: Up to $10
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and the comment didn't provide any dissent.
      • Reward: $0
  • @tomato ($50)

18.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

18.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

18.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 19th "official" Council (#1890000-#1990800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

18.6 - FM Surveys

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others).
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + (1 the lead). For each CC after the 6th one, $25 will be awarded to the CM(s) in charge.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 (the lead). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge.

Reward Distribution

Grading is individual.

Grading

Section II - Community Management

18.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1897200
    • End Block: #1983600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

18.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it needs to be "re-orged".

Note

Extended from KPI 16 and 17. Note that this is final extension!

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds contribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

18.9 - Follow up the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Establishing the new OKR system for the SPs has unfortunately stalled. The technical part is more or less complete, and will be completed for the next Council Term, so we're going to cut through and propose something more specific. The work is to find out exactly what the numbers R_rec.L, R_okr.L, R_rec.W and R_okr.W should be:
  • The Lead currently earns $72 per week in recurring rewards
  • The Workers (ex JSG) all earn $27 per week in recurring rewards
  • Going forward, we propose all Workers (R_rec.W) earn either the break-even cost in terms of hardware, or slightly below.
  • Whether the recurring reward for the Lead (R_rec.L) should be higher or lower than this isn't clear.
    • The Lead has extra responsibilities to running their node, which has a value
    • The Lead will however potentially earn an extra income on this, as they will earn OKR rewards for the groups performance, and for Storage KPIs, which will cover most of their extra tasks
  • After establishing a benchmark value for OKRs, the OKR payout scheme will mean that of max OKR payout pool, equal to R_rec.L + R_rec.W, so that:
    • For the Group:
      • For each of the 7(?) KRs that exceeds the weekly target -> 1/7th of R_okr.W is shared between all the SPs that reached this individual KR.
      • If the group on average exceeds the target for 4/7 KRs, the Lead gets a bonus equal to R_okr.L/10
      • If the group on average exceeds the target for 5/7 KRs, the Lead gets a bonus equal to R_okr.L/5
      • If the group on average exceeds the target for 6/7 KRs, the Lead gets a bonus equal to R_okr.L/2
      • If the group on average exceeds the target for 7/7 KRs, the Lead gets a bonus equal to R_okr.L
  • Get these independent numbers approved by the Council, and provide specific examples of outcomes for the Workers and Lead with this schedule.
    • Note that half of the OKR rewards will come from minting of new tokens, so only half of the OKR rewards needs to be accounted for in the budget.
    • Further note that it's unlikely that the FULL OKR rewards (R_okr.W+R_okr.L) will actually be paid out each week, so the Council can assume the budget for the SP group won't have to pay all of R_rec.L + R_rec.W + (R_okr.W + R_okr.L)/2.
  1. Finally, as the OKRs will be tracked starting with the next Council Term, ensure that the Lead has set the new rewards for the workers within that time. (Also a Storage KPI).

  2. Assist the Lead with their other KPIs for the Term.

Reward Distribution

Individual grading.

For 3. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $200
  • 2: $100

Grading

  • SOW 1 (OKRs + payouts) - ($200)
    • No work submitted. No rewards.
  • SOW 2 (set new rewards) - ($100)
    • No work submitted. No rewards.
  • SOW 3 (assist lead with their KPIs)
    • No work submitted. No rewards.

18.10 - Follow up the Content Curators Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. With the new "Upload Content" Bounty being presented, ensure we get a good start. Act as the Council's arm, to ensure that all the tasks outlined in KPI 18.13-3 and KPI 18.CC-3 are not only done, but in a satisfactory manner.

  2. Assist the Curator Lead with their other Curators KPIs, KPI 18.CC-1 and KPI 18.CC-2.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1-3: $50

Grading

  • SOW 1 (Public domain videos + KPI 18.CC-3) - ($75)
    • No work submitted. No rewards.
  • SOW (assist with KPI 18.CC-1 + 2) ($75)
    • No work submitted. No rewards.

18.11 - Follow up the Operations Working Group

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Assist the Lead in achieving their Operations KPIs, 18.OP-1 and 18.OP-2.

Reward Distribution

Grading is individual.

Grading

  • SOW 1 (assist lead in achieving their KPIs) - ($100)
    • No work submitted. No rewards.

h2 id="section-iv">Section IV - Bounties

18.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No work submitted. No rewards.

18.13 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language
  1. The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • ensure a BM, or a small team is hired, for the scope of grading the "value" of the videos
      • these people should NOT be Curators, to avoid overlap
    • ensure the Curators are deploying resources to validate/approve the videos
    • ensure a good workflow is established between them, with precise timelines
    • officially open the Bounty through a forum post, before the end of the Term

Reward Distribution

Grading is individual.

Weighting:

  • 1-2: $50
  • 3: $100

Grading

  • Bounty 20 ($50)
  • Bounty 21 - Website Translation ($50)
    • No work submitted. No rewards.
  • Bounty 22/24 - Upload Content ($100)
    • No work submitted. No rewards.

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.
    • Example: If the Operations Group performs the Update Featured Video, but fails to test anything and/or take notes, they will not be rewarded at all.

Note that there were some incorrect block heights for the End Block for all of these. It was meant to be the end of the term, but it's not clear exactly if it was understood to be a typo, so they'll be extended (mostly).

18.CC-1 - Update Featured Video

  • Reward: $75
  • Start Block: #1897200
  • End Block: #1983600

The "Main" featured video for the Joystream Player has been the same for a while now. It's time to change it!

Last week, the same KPI was made, with these results:

  1. A proposal to establish the rules was made, with a link to the mechanism on github.
  2. ?
  3. Video

Some notes:

  1. This mechanism certainly rules out a number of videos, but it doesn't establish a mechanism, unless one accepts that the Lead and curators agree offchain. Further, one has to remember that the featured video is the first thing any new user will see when opening the Joystream Player, and it autoplays the "cover cut" by default. That means that this video has to be standout, and the cover cut needs to be interesting.

  2. Nothing provided.

  3. Continuing from 1, although this particular video was indeed well made, it's rather short.

  • No cover cut was provided, as the link doesn't work

It has to be mentioned that:

  • The link provided in the KPI (by me) was not correct, as the file name had been changed.
  • The Council approved the "faulty" mechanism.

To summarize, we'll try again!

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Notes:
  • JSG reserves the right to veto this choice, for any reason.
  • Certain metadata is required, including a cover cut.
  • The community should keep in mind the featured video slot should be reserved for the absolute best ones in terms of production value etc. The main goal of this video (in the future) is to get the person opening the Joystream Player buy a subscription to the platform!
  1. Following 1., use said mechanism to select the video.

  2. Propose one (or more if needed) videos to Jsgenesis - @kdembler(koalva#6880) and @bedeho(bedeho#0275) on Discord for approval.

  3. After one has been approved, follow the steps here, and share the json with @kdembler(koalva#6880) on Discord.

Grading

18.CC-2 - Bounty 10 Cleanup

  • Reward: $150
  • Start Block: #1897200
  • End Block: #1933200

Purpose

The post-mortem of Bounty 10 still hasn't been completed. However, with the "old" Lead having left, and "new blood" on the way in, we can't expect them to fix it for free.

Although some work may have been done on this last Term, nothing has been shared as far as we know. We'll give the Curator Lead one more go. (Note the early End Block).

Scope of Work

  1. Familiarize yourself with the task defined in KPI 15.8 and KPI 16.10, and the WIP delivery. Get an overview of what is done AND correct, what is done but not correct, and what is missing.
  2. Create a realistic timeline, with milestones, for when the task is completed for all the videos, assuming the entire team will divert their full attention to it.
  3. Share the work that has been done thus far, with emphasis on the format of what will be delivered when the Cleanup is done.

Grading

@laura ($450)
* As mentioned when grading the last term, the Curators basically finished the work instead of following the KPI rigorously.
* The "issue" with that, is that the rewards for completing hadn't been defined.
* Furthermore, the task in 1. and 2. were graded last week.
* The actual work submitted was great, and spot checks uncovered only a couple minor errors. The only real problem one could find is that it appears not to have been clear to the Curators why this was a KPI - namely identifying incorrect and/or dishonest licensing. In the future, it would be nice to highlight which videos needs curation, and why.
* The reward for this KPI is going to be higher than the reward stated, as it completes KPI 16.10 only double. The reward for those would have been $400.
* Adding another $50 from this brings the total to $450.

18.CC-3 - New "Upload Content" Bounty

  • Reward: $100
  • Start Block: #1897200
  • End Block: #1983600

Purpose

As we sincerely wants to have a lot of uploads on our platform, we're planning to re-open a similar Bounty to #10, but with more strict and precise rules for all parties. The Curators will verify/approve each video, before the BM will do the actual grading.

The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here.

Scope of Work

  1. Review the issue, and in collaboration with the Council and the BM that gets assigned, agree on the exact:
  • Scope of Work for the Curator group
  • Workflow
  • Weekly deadlines
  • The format of the validation performed by the Curators
  1. Allocate resources from the Curator Group and "train" them, to ensure what was agreed in 1. is upheld.

Grading

18.OP-1 - KPI JSON

  • Reward: $300
  • Start Block: #1897200
  • End Block: #1983600

Purpose

As many have pointed out, using this blog post to read the KPIs is cumbersome at best. The Operations group has proposed a new format for this, under the assumption we still used a JSON to present the data. As this is, sadly, not the case anymore, we need to make it happen!

Note that the Operations Lead proposed using YAML instead of a JSON, but I prefer the latter for the simple fact that it's used in so many other parts of the Joystream Platform, making it easier for most to grasp (if not master).

Scope of Work

  1. Based on the structure of this, and previous KPIs, come up with a JSON Schema for presenting the data in the KPIs.

  2. Find a "clever" standard of presenting tables, line changes, bullet points (and numbered/lettered) presented.

  3. Create a script that parses a markdown and creates a nice looking JSON, OR vice-versa.

Weighing:

  1. $150
  2. $50
  3. $100

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. or 3. is not completed.

Grading

  • SOW 1 (JSON schema) ($150)
  • SOW 2 (standard for presenting tables/bullet points) ($50)
    • No work submitted. No rewards.
  • SOW 3 (create a script) ($100)
    • No work submitted. No rewards.

18.OP-2 - CLI Integration in Pioneer

  • Reward: $200
  • Start Block: #1897200
  • End Block: #1983600

Purpose

Some amount users has issues accessing the CLI, mostly due to the slightly cumbersome installation process, but for others, even opening the terminal is a little scary. Is there a way we could integrate the CLI in to Pioneer? Ideally, it would be similar to how the current JS integration works, but allow you to choose between the keys you have in your local storage.

This was not done last week, but I'm giving it one more Term. I'll also bump the reward, as it seems it may be underpaid a bit.

Scope of Work

  1. Do some research, and research if this is feasible. If yes, outline the challenges associated with the making this, create an estimate of the time needed and the expected costs.
  • It can be used in the browser, similar to how the current JS integration works
  • It can use the keys you have in your local storage
    Make a PR with the findings to the Community Repo
  1. Write the draft for making this a Bounty.

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. is not completed.

Grading

  • SOW 1 (Research)
    • This was already completed in KPI 17.x and paid out $75/$100 to isonar.
  • SOW 2 (Write Bounty Draft)
    • The KPI 17.x grading notes that this was impractical, no work was reported, so no rewards have been given.

18.SP-1 - Storage OKRs

  • Reward: $200
  • Start Block: #1897200
  • End Block: #1962000

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, and the KPI 17.SP-1 wasn't completed last term, we'll give them one more chance, but with a shorter deadline.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the metrics, and propose what:
    • changes
    • removals, or;
    • additions are in order, and;
    • why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
    Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. For the Storage OKRs that CAN be measured without new tools, start getting numbers as a benchmark value for the OKRs. In addition to the "final" numbers, the data sources must be provided.
  2. Finally, review the proposed OKR system outlined in KPI 18.9, and the numbers that come out of it.

Grading

  • SOW 1 (Review Storage OKRs)
    • No work submitted. No rewards.
  • SOW 2 (Start measurements)
    • No work submitted. No rewards.
  • SOW 3 (Review proposed OKR system)
    • No work submitted. No rewards.

18.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #1897200
  • End Block: #1983600

Purpose

Although the OKR system will make it less profitable to be an underperforming SP on paper, the savings in costs by running a "cheap" node may break that assumption. Although we believe the Lead should have some subjective decision making power in deciding when the sanction a Worker, some objective data should be made available for the benefit of all parties. That doesn't mean that for long running SPs, with a great track record, some underperformance for some time is accepted.

Scope of Work

  1. Based on OKR related data, and/or other criteria, create a set of rules that could or should lead to the firing, slashing, or other sanctions agains an SP.

Grading

  • SOW 1 (set of rules for firing/slashing/sanctions against SPs)
    • No work submitted. No rewards.

KPI 17

  • KPIs: 13+5
  • Total Possible Rewards: $2825+$725
  • Council Elected in Round: 18
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1789200 / 10.08.21
    • End Block/Date: #1890000 / 17.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1918800 / 19.08.21
Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 19+45 639959+1515692
2124 julysake 6 202092
361 blackmass 6 202092
515 l1dev 11 370502
982 drmarkovi 9 303138
867 xandrell 17 572594
321 freakstatic_council 124 4176571
439 fierydev 8 269456
4 nexusfallout 12 404184
2 tomato 329 11081387
736 mmsaww 56 1886193
2329 laura 141 4749166
705 flakes9776 10 336820
2130 maxlevush 663 22331184
1048 igrex 126 4243935
2182 isonar 282 9498331
SUM 16 1819 61267604
  • due to an error, lyazufey1812 didn't get credit for 17.2 in the initial transfer.

Paid out on block #1,963,066 and block #1,963,067.

Section I - Council work, Proposals and Bureaucracy

17.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 34 127 19
2124 julysake 12 36 6
361 blackmass 11 38 6
515 l1dev 18 72 11
982 drmarkovi 17 59 9
867 xandrell 31 109 17
321 freakstatic_council 24 93 14
439 fierydev 14 50 8
4 nexusfallout 21 79 12
2 tomato 18 70 11
736 mmsaww 21 83 13
2329 laura 26 104 16
705 flakes9776 21 66 10
2130 maxlevush 31 135 21
1048 igrex 34 140 21
2182 isonar 14 47 7
SUM 16 347 1308 200

17.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

As we have yet to conclude the second "round" of these, we will give it a little more time. Note however that the grading will require far better arguments (when in disagreement), and more precise questions (when information is required) for qualifying for rewards. A simple "no.", or "why?" will not command anything. Finally, we are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Total Cap at $500

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

  • @laura $0
    • https://testnet.joystream.org/#/proposals/424
      • Cost (Claimed): $100
      • Was it a malicious, or objectively bad proposal: No
        • Did the vote/comment affect the outcome: No, comment was made after 5/9 votes were in.
        • "Cost" of proposal: unknown
        • Reward: $0
  • @igrex $55
    • https://testnet.joystream.org/#/proposals/408
      • Cost: unknown, but presumably some non-trivial amount
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Yes, likely
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $50
    • https://testnet.joystream.org/#/proposals/416
      • Proposal was an improvement to the above.
      • Cost: $25
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Possibly
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $5 (shared)
  • @isonar $0
    • "I really hate this KPI, frankly, but this week there was a case which I couldn't help but reporting as anything else but my dissent."
    • https://testnet.joystream.org/#/proposals/423
      • Proposal ongoing, will be graded next term
    • https://testnet.joystream.org/#/proposals/417
      • Cost: $450 (text proposal, so inferred)
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No
      • No comment was made to the actual voters. Discord comments are fine and well, but unless the voters can see them...
      • Reward: $0
  • @lyazufey1812 $45
  • @mmsaww $5
    • https://testnet.joystream.org/#/proposals/416
      • Cost: $25
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Possibly
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $5 (shared)
  • @maxlevush $22
  • @freakstatic_council $10
    • https://testnet.joystream.org/#/proposals/417
      • Cost: $450 (text proposal, so inferred)
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No.
      • Reasonable objection, but a more helpful one would be to link to alternatives.
      • Reward: $10

17.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

17.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

17.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 2 days
    • Start Block: #1789200
    • End Block: #1918800

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 18th "official" Council (#1789200-#1890000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

17.6 - FM Surveys

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others).
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + but no lead. For each CC after the 6th one, $25 will be awarded to the CM(s) in charge.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 the lead - soon(tm). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge.

Reward Distribution

Grading is individual.

Grading

  1. CMs completed in time: julysake, mmsaww, igrex, Nexusfallout, flakes9776, freakstatic_council, maxlevush, tomato, lyazufey1812, isonar
    • Technically, @laure should be DQ'd, but it's assumed to be a misunderstanding this time, as the curator survey was completed.
  2. CCs completed in time: 4/10 -> no reward.
  3. SPs completed in time: 9/10 -> $75.

Section II - Community Management

17.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1796400
    • End Block: #1983600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

17.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it needs to be "re-orged".

Note

Extended from KPI 16

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds constribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

17.9 - Follow up the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Assist the Lead with their KPI for the Term.

  2. Assuming:

  • There will, on average, be ~$200 available as KPI rewards (minted by JSG, not part of the budget) for the Storage Group (KPIs managed by the Lead)
  • There will be weekly grading of the OKRs, where the Lead is rewarded if the group performs well, and the workers are rewarded if they perform well individually.

Propose on an exact reward structure for the SPs:

  • How much should simply occupying the role award, for both workers and Lead?
    • What is the assumed break-even point for one SP?
    • Why so much/little?
  • How much should the individual SP earn for running good nodes through the OKR system?
    • Should the OKR system pay for their internal rank, ie. relative grading or should it be absolute?
  • How much should the SP Lead earn for managing a team that gets "good" scores?
  • How does the KPIs play in here?
    • Should we assume the Lead always assigns themselves?

Based on numbers found, and the current budget, how many SPs should the platform have?

Reward Distribution

Individual grading.

For 1. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $200
  • 2: $100

Grading

  1. Assist the Lead with their KPI for the term ($200)
    • No claims for this KPI.
  2. Propose exact reward structure for SPs + KPIs ($100)
    • No claims for this KPI.

17.10 - Follow up the Content Curators Working Group

  • Reward: $350
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Hire a new Lead. It needs be made abundantly clear to the applicant what is expected of them from the get go, as they will be "under fire" immediately.

  2. The platform needs a well defined curation policy for the Curators. Although some examples have been made in the helpdesk, both for the Lead and Workers, the Council should improve and update these based on the experiences thus far. This is not to say that there can't be any degrees of freedom for the Curators, but some basic rules should be prepared, and presented in a comprehensible way. Prepare a PR to the community repo, and get it approved by the rest of the Council. Ensure the new Lead is on board with these rules, keeping in mind the reward they will earn. Finally, present the rules to JSG for approval.

  3. Ensure the Lead immediately addresses their KPIs for the Term. If they are hired before block #1947600, ie. three or more full days before the end of the term, but is unable to complete the tasks outlined in their KPIs, a warning should be issued.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $200
  • 3: $50

Grading

  1. Hire a new lead ($100)
  2. Curation Policy ($200)
  3. Ensure the lead immediately addresses their KPIs ($50)

17.11 - Follow up the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. As for the other Working Groups, we are considering switching the Operations Working Group's rewards scheme to a combination of specific Operations KPIs, and perhaps at a later stage OKRs. Review KPI 15.9-1, adapt it to the Operations Working Group, and propose a scheme. An important thing that is unique to this group is that some of it's Workers are hosting infrastructure out of pocket. It's not entirely clear exactly what that is, who is doing it, how it's being compensated, and whether these tasks are tied to individuals who happens to be part of the Operations WG, or whether these are tasks that are tied to the WG itself.
  2. Assist the Lead in achieving their Runtime Upgrade Test KPI.

Reward Distribution

Grading is individual.

For 2. If the KPI is graded as complete, the Operations Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $150
  • 2: $100

Grading

  1. Reward Scheme ($150)
    • No claims for this KPI.
  2. Assist the lead in achieving their Runtime Upgrade Test KPI ($100)

h2 id="section-iv">Section IV - Bounties

17.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • Bounty 9 ($25/$50 per week)
    • No claims for this KPI.

17.13 - Other Bounty Managers

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.
    • Example: If the Operations Group performs the runtime upgrade, but fails to test anything and/or take notes, they will not be rewarded at all.

17.CC-1 - Update Featured Video

  • Reward: $75
  • Start Block: #1796400
  • End Block: #1983600

Purpose

The "Main" featured video for the Joystream Player has been the same for a while now. It's time to change it!

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Note that:
  • JSG reserves the right to veto this choice
  • Certain metadata is required.
  1. Following 1., use said mechanism to select the video.
  2. Follow the steps here, and share the json with @kdembler(koalva#6880) on Discord.

Grading

17.CC-2 - Bounty 10 Cleanup

  • Reward: $150
  • Start Block: #1796400
  • End Block: #1983600

Purpose

The post-mortem of Bounty 10 still hasn't been completed. However, with the "old" Lead having left, and "new blood" on the way in, we can't expect them to fix it for free.

Scope of Work

  1. Familiarize yourself with the task defined in KPI 15.8 and KPI 16.10, and the WIP delivery. Get an overview of what is done AND correct, what is done but not correct, and what is missing.
  2. Create a realistic timeline for when the task is completed for all the videos, assuming the entire team will divert their full attention to it.

Grading

  • @laura (lead) - $125/$150
    • https://testnet.joystream.org/#/forum/threads/545?replyIdx=2
      1. Presumably done
      2. Estimation not provided during council term, but instead, it seems like the actual work was close to being done.
        • This leads to a quite awkward situation, as the next CC KPI was supposed to set a reward for doing the work based on this.
        • The final, "human, readable" version of the cleanup was presented formally after the deadline for this term.
        • Therefore, the grading of the actual work will be done for the next term, this grading (and reward) covers only what was stated in 17.CC-1.
        • In summary, it feels harsh to deduct in this case, but the Lead should expect the next grading to more accurately reflect the work that's been done.

17.OP-1 - Runtime Upgrade Test

  • Reward: $200
  • Start Block: #1796400
  • End Block: #1983600

Purpose

Looking at the progress for KPI 16.11-3, it seems unlikely that the full test, plus report can be completed before the end of the Term.

Scope of Work

  1. Finish the test, per the testing protocol.
  2. Prepare a step by step by step report, with all the relevant information needed to verify the findings. This includes:
  • For all the mint proposal testing:
    • Proposal IDs
    • Results
  • Blockheights of every transaction of importance
  • For all Operations Group stake testing:
    • The addresses and memberships for all applicants
    • The blockheights for each "event" and the balances of the relevant accounts before and after each of them.
    • Results
  • For all "random" tests performed:
    • What was tested
    • Results

Grading

  • @isonar $100/$200
    • https://github.com/Joystream/community-repo/pull/294
      1. Test was finished
      2. It seems as though the major parts were actually done, but there were many issues with the report:
        • The structure of the report makes it very difficult to read.
        • The same accounts have been used for multiple openings, and the naming (mix of memberId, memberHandle, workerId)
        • It's impossible to tell (from the report notes alone) whether the Operations WG applicants that applied before the upgrade got their stake(s) back or not.
    • In @isonars defense, the instructions could have been made more clear, but in general (eg. not just in this case), I think it's important for users to try and think what is actually being done. In this particular case, it means that in order to verify the runtime works as intended, one has to get lots of historical state in order to parse the results.
    • Furthermore, Pioneer was not upgraded.
  • @l1dev

17.OP-2 - CLI Integration in Pioneer

  • Reward: $100
  • Start Block: #1796400
  • End Block: #1983600

Purpose

Some amount users has issues accessing the CLI, mostly due to the slightly cumbersome installation process, but for others, even opening the terminal is a little scary. Is there a way we could integrate the CLI in to Pioneer? Ideally, it would be similar to how the current JS integration works, but allow you to choose between the keys you have in your local storage.

Scope of Work

  1. Do some research, and research if this is feasible. If yes, outline the challenges associated with the making this, create an estimate of the time needed and the expected costs.
  • It can be used in the browser, similar to how the current JS integration works
  • It can use the keys you have in your local storage
    Make a PR with the findings to the Community Repo
  1. Write the draft for making this a Bounty.

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. is not completed.

Grading

17.SP-1 - Storage OKRs

  • Reward: $200
  • Start Block: #1796400
  • End Block: #1983600

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, this will be assigned to the group itself.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the metrics, and propose what:
    • changes
    • removals, or;
    • additions are in order, and;
    • why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
    Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. For the Storage OKRs that CAN be measured without new tools, start getting numbers as a benchmark value for the OKRs. In addition to the "final" numbers, the data sources must be provided.

Grading

KPI 16

  • KPIs: 13
  • Total Possible Rewards: $3600
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1688400 / 03.08.21
    • End Block/Date: #1789200 / 10.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1818000 / 12.08.21
Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 44 1473131
2124 julysake 7 234362
361 blackmass 6 200882
515 l1dev 11 368283
635 xfactorus 16 535684
867 xandrell 55 1841414
1962 nkhlghbl 2 66961
2039 doppelganger23 7 234362
321 freakstatic_council 130 4352433
439 fierydev 5 167401
4 nexusfallout 13 435243
2 tomato 645 21594765
2130 maxlevush 473 15836161
2148 controlla 11 368283
1027 stavr 17 569164
2182 isonar 428 14329550
SUM 16 1870 62608079

Paid out at block #1,849,466.

Section I - Council work, Proposals and Bureaucracy

16.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 36 139 19
2124 julysake 15 53 7
361 blackmass 13 46 6
515 l1dev 21 81 11
635 xfactorus 30 118 16
867 xandrell 35 125 17
1962 nkhlghbl 4 13 2
2039 doppelganger23 14 50 7
321 freakstatic_council 32 121 17
439 fierydev 12 36 5
4 nexusfallout 26 97 13
2 tomato 26 109 15
2130 maxlevush 41 154 21
2148 controlla 20 77 11
1027 stavr 34 126 17
2182 isonar 27 97 13
SUM 16 386 1442 200

16.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

16.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $280/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: N/A
    • Council wrangling in #council channel - Yes

16.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

16.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 17th "official" Council (#1688400-#1789200) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

16.6 - Council Term Length and Size

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

We have had one week Council Terms and 16 CMs for a while now, giving everyone time to get used to it. Are these the "right" numbers?

Scope of Work

  1. Discuss the benefits and drawbacks of increasing and decreasing both numbers. Then propose new numbers, and back them up with data and/or arguments.

Reward Distribution

Ideally however, this should be a collaborative effort, but the organizer(s) will earn the rewards. They can however split as they like.

Grading

Section II - Community Management

16.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1688400
    • End Block: #1789200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

16.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it to be organized logically.

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds constribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

  • Work submitted, but incomplete. Grading deffered as this KPI is repeated in KPI 17

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

16.9 - Follow up the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

All tasks can be performed by the Council, but some co-ordination with the Lead seems prudent.

  1. We are considering switching the Storage Working Group's rewards scheme to a combination of Specific Storage KPIs, and OKRs. Propose a new compensation strategy based on all the information below.
Recurring Rewards

Some amount of their compensation should still come from recurring rewards. This could either be meant to:

  • Cover the actual running costs of operating a storage node
  • Cover the running costs, plus a small bonus for the work of bootstrapping, upgrading and maintaining
  • Cover less than the costs, assuming there are secondary incentivizes tied to extraordinary tasks and/or performance
KPIs
  • For extraordinary tasks, such as co-ordinated upgrades, testing new software, and debugging or researching errors, the Lead (and workers) have seen little to no incentives (eg. financial rewards) of doing so. Performing these tasks have only (directly) rewarded the Council through their KPIs. This can be fixed in multiple ways:
    • The Council could simply pay them extra through spending proposals, thus having "everyone" pay
    • The Council could increase their rewards temporarily to pay for it
    • The Council could increase their rewards permanently, while also be more "vigilant" in firing/slashing the Leads, thus having a more effective carrot and stick
      • All these will in some way affect the budget, complicating the financial side of the equation. Although this has some secondary benefits, it appears as though the Council(s) hasn't thought about it, or discarded it for some reason.
    • The Council could pay them directly out of their own pockets (and claimed the KPI rewards themselves).
      • This would make backroom deals more profitable. Unclear if this is good or bad.
    • We could add Storage Working KPIs to address these.
      • This approach would reduce the pressure on the Council, but add to Jsgenesis power and workload.

Assuming introducing Storage KPIs is the starting point for discussion:

  • The extraordinary these tasks would be irregular, but important.
    • Should they be for the Lead only?
    • Is it reasonable at all for the Lead to receive these, or should they be expected to perform "these sort of tasks" anyway?
    • What should the Leads recurring rewards be, if the only thing that distinguishes from the Workers is managing the Workers, (eg. hiring, firing and setting rewards) and reporting?
OKRs

Having objective and numeric metrics to evaluate the performance of the group has been long wanted, and used to some extent for a while. A formal system of measuring it, as outlined in #2 could be used to either:

  • Give the Council better data to evaluate the performance of the Storage group, or
  • Have the OKR system account for some percentage of the Leads, and potentially groups, overall rewards

Assuming we opt for the OKRs tied to rewards is the starting point for discussion. JSG proposes a system where:

  • The Council either assigns someone to perform the measuring and grading, or it's done by JSG.
    • The metrics and tools needed are provided through a group effort (JSG, the Operations group, and potentially others)
  • The "official" OKRs only measures and rewards the Lead.
    • The Lead gets the data measured, and uses it to measure and reward the individual Workers.
  • They are measured each Council term.
    Questions:
  • Does the above make sense? If not, propose improvements
  • How much of the Leads, and potentially Workers, should be tied to the OKRs?
  • Should the rewards come from budget, or some other source?
  • How should they be paid out.
  • Should there be a stick in addition to the carrot?
  1. Review the Storage OKRs.

An issue outlining the storage OKRs will be posted no later than block #1723000.

  • Review the metrics, and propose what changes, removals or additions are in order, and why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
  1. Time permitting, start measuring what the values of each Key Result is right now, to create a benchmark.

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Weighting:

  1. $150
  2. $100
  3. $150

Grading

  1. Propose a KPI/OKR rewards scheme
  2. Review the Storage OKRs
  3. Start measuring to create a benckmark
    • No work completed

16.10 - Follow up the Content Curators Working Group

  • Reward: $600
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Note

Scope of Work

Task 1. is expected to be performed/coordinated by the Curator group. The Council, or a Council Member's job is to push them into doing so. The first half should have been completed during the last term.

Tasks 2-4 can be performed by the Council, but some co-ordination with the Lead seems prudent.

  1. Bounty #10 was cancelled, mainly because a quick spotcheck revealed that the Bounty meant to reward publishing videos in the Public Domain ("PD") (to be fair, other permissive licenses was also allowed, if the license was "valid" - eg. attribution included, no derivates, etc.), was mostly rewarding copying videos from YouTube (YT). After we announced this, a concern that not only was most of the videos taken from, but not all videos was even properly licensed from there.
    The Curators must perform a "post mortem", going through ALL videos that submitted a claim to Bounty #10 (even if they weren't rewarded), and provide a spreadsheet with the following columns:
  • Video Id
  • Channel ID
  • Owner Id
  • On-chain License
    • The on-chain license ID can be mapped to the name - see helpdesk for Curators
  • On-chain Attribution
  • Whether other licensing requirements are upheld
    • Only applicable to certain CC licenses, eg. CC BY-ND - "No derivates"
  • Information Provided
    • If the forum post with Bounty claim contained extra info about the source
  • Original YT link
    • If available with a quick search
  • Actual license of original source
    • What license the media is actually licensed as
    • On YT, any video that doesn't explicitly say License - Creative Commons Attribution license (reuse allowed), is NOT free to share by anyone else than the owner.

Before the end of the Term, the Curators must have completed the FULL report, and shared it with me @bwhm#6514 on Discord.

  1. The platform needs a well defined curation policy for the Curators. Although some examples have been made in the helpdesk, both for the Lead and [Workers]](https://github.com/Joystream/helpdesk/tree/master/roles/content-curators), the Council should improve and update these based on the experiences thus far. This is not to say that there can't be any degrees of freedom for the Curators, but some basic rules should be prepared, and presented in a comprehensible way. Prepare a PR to the community repo, and get it approved by the rest of the Council.

  2. At the time of writing, it's not clear whether task 4. and 5. from KPIs 15.8 were completed. These are loosely related to task 2. above.

  3. As for the Storage Working Group, we are considering switching the Curators Working Group's rewards scheme to a combination of specific Curator KPIs, and perhaps at a later stage OKRs. Review KPI 16.9-1, adapt it to the Curator Working Group, and propose a scheme.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $200
  • 2: $100
  • 3-4: $150

Grading

  1. Bounty 10 report
  2. Curation Policy
    • No work completed.
  3. KPI 15.8 follow up
    • No work completed.
  4. Propose a KPI/OKR rewards scheme
    • No work completed.

16.11 - Follow up the Operations Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

Task 1 and 2 needs to be performed with assistance, if not by, the Operations group. Tasks 3 and 4 are open for the Council.

  1. A runtime upgrade has been prepared quite some time ago, but haven't been properly tested yet. The PR can be found here, and building should return a .wasm file with the blake2 checksum:
(0x)d6a5f19b0a9834921a2e778676f2c8255d56e1a792bdfcd31dd29263b52c1021416adc126c152d1a425afd859f45f167a17847ec5e3288a75cfb2bfa74172ad2 joystream_runtime.wasm

If you get a different hash, ask us for the wasm.

As there is a staging network mirroring the current network, this can be used for testing. All that is needed is to ask us for the chain_spec.json, sync a node (or two), and host the version of pioneer in the PR above. At least the main tester must have access to this node, so they can check the logs when/if needed.

  1. Prepare a testing protocol, which includes:
  • Where to access the old, and new, pioneer
  • What needs to be done BEFORE performing the runtime upgrade?
    • a step by step list of the transactions that should be made, and
    • what should be documented along the way
  • What is going to be tested AFTER the runtime upgrade?
    • a step by step list of the transactions that should be made, and
    • what should be documented along the way

What is needed from JSG to perform the test? When (if at all) is the sudo key needed?

  • Set the Council?
  • Provide tokens for the runtime upgrade proposals? (your keys should have the same amount of tokens as at launch)
  • Sudo in the runtime ugprade? (if you don't have time to wait the full two days)
  • Provide keys to the current occupants of roles?

The test protocol must be approved by @bwhm#6514 on Discord or github.

  1. Perform the test.

  2. As for the other Working Groups, we are considering switching the Operations Working Group's rewards scheme to a combination of specific Operations KPIs, and perhaps at a later stage OKRs. Review KPI 16.9-1, adapt it to the Operations Working Group, and propose a scheme. An important thing that is unique to this group is that some of it's Workers are hosting infrastructure out of pocket. It's not entirely clear exactly what that is, who is doing it, how it's being compensated, and whether these tasks are tied to individuals who happens to be part of the Operations WG, or whether these are tasks that are tied to the WG itself.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-4: $150

Grading

  1. Runtime Upgrade
    • This has not been completed yet, grading deferred as this KPI is repeated in KPI 17
  2. Prepare a testing protocol
  3. Perform the test
  4. Propose a KPI/OKR rewards scheme

Section IV - Bounties

16.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No reports submitted covering Bounty 9

16.13 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

  • Community Bounty #20 - "Github Bounty Guide"
    • @isonar $100/$200 - Managed Bounty 20
  • Community Bounty #21 - "Website Translation"
    • No claims for this bounty

KPI 15

  • KPIs: 11
  • Total Possible Rewards: $3600
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1587600 / 27.07.21
    • End Block/Date: #1688400 / 03.08.21
  • Term Summaries Forum Thread: link
  • Deadline to Submit Summary: #1717200 / 04.08.21

Annihilation

As is explained further here, there were strong arguments for simply annihilating this entire KPI, as 15.8-1 was not handled at the level expected. Instead, we opted to reduce the payments by 50%. Some points that lead to this (final) decision:

  • The workload, as described, may have been too much to expect
  • The Curators did eventually start producing what seems like an honest attempt (although late AND lacking)
  • The Council did try some last minute save, and a firing proposal is at least scary, although it won't pass.
    • Note again that this is not Jsgenesis saying the Lead should be fired.
    • The Council could, and should also have considered both carrots and sticks:
      • Providing better incentives (temporary budget increase, spending proposals, etc)
      • Slashing some amount
      • Formal warning
      • Assisted
  • Finally, a lot of excellent work would not have been rewarded.

In summary, future annihilation conditions will be better and/or more realistically constructed. If they fail however, it will be 100%.

Grading

Member ID Member Handle Reward* [USD] Reward** [USD] Reward [tJOY]
361 blackmass 12 6 207168
515 l1dev 12 6 207168
982 drmarkovi 8 4 138112
867 xandrell 70 35 1208481
318 supunssw 2 1 34528
1316 andybut 102 51 1760929
2039 doppelganger23 6 3 103584
321 freakstatic_council 246 123 4246947
957 leet_joy 0 0 0
439 fierydev 6 3 103584
4 nexusfallout 12 6 207168
2 tomato 1078 539 18610603
736 mmsaww 118 59 2037153
2329 laura 90 45 1553761
2130 maxlevush 838 419 14467241
1048 igrex 22 11 379808
SUM 16 2613 1307 45266235

* denotes the grading value
** denotes the actual amount paid, after discounting for the "annihilation"

Payouts were made at block #1748912.

Notes

This set of KPIs will have two "major" changes from the usual:

  • A primary focus in KPIs 15.7 and 15.8 (see also Annihilation Modes)
  • Stricter submissions rules:
    • if your contributions aren't added to the Term Summaries forum thread in time, or
    • doesn't include the context needed to grade (not applicable to 15.6), or
    • lacks all links needed for a reviewer
      Your work will NOT be graded.
  • Stricter grading
    • if your work lacks key components, or
    • is presented in a poor way
      Your reward will be deducted more heavily than before

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 16th (confusingly listed as "Election round 17" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.
  2. For 15.7:
  • If conditions 1-3 isn't met AND no actions are taken, or
  • If the Council isn't posting daily status updates said conditions, or
  • Nothing is submitted, or the quality of work is really poor for conditions 4-5
  1. For 15.8:
  • If condition 1 isn't met AND no actions are taken, or
  • Nothing is submitted, or the quality of work is really poor for conditions 2-3

All KPI rewards will be forfeited.

Section I - Council work, Proposals and Bureaucracy

15.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 22 85 11
515 l1dev 22 80 11
982 drmarkovi 14 50 7
867 xandrell 39 149 20
318 supunssw 2 8 1
1316 andybut 39 161 21
2039 doppelganger23 12 48 6
321 freakstatic_council 32 123 16
957 leet_joy 0 0 0
439 fierydev 10 40 5
4 nexusfallout 24 92 12
2 tomato 21 85 11
736 mmsaww 33 128 17
2329 laura 39 149 20
2130 maxlevush 37 160 21
1048 igrex 38 165 22
SUM 16 384 1523 200

15.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before.
Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

15.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1587600
    • End Block: #1702800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $275/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: N/A
    • Council wrangling in #council channel - Yes

15.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1587600
    • End Block: #1702800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

15.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 16th "official" Council (#1486800-#1587600) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading


Section II - Community Management

15.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1587600
    • End Block: #1688400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Section III - Working Groups

15.7 - Follow up the Storage Working Group

  • Reward: $900
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

For this Term, the Storage and Curation working groups will be the focal point of the KPIs.

Scope of Work

Task 1-3 are expected to be performed/coordinated by the Storage Lead. The Council, or a Council Member's job is to

  • track the results continuously
  • report the progress to the Council
  • update/notify/warn/slash/fire the SP

Task 4 and 5 can be performed by one or more CMs.

  1. A new version of the Storage Node is expected on the 28th of July (expect an @everyone in the #storage-provider room on Discord). As restarting a Storage Node takes is offline for ~1h, the rollout needs to be coordinated. As there are 10 nodes not operated by Jsgenesis, the rollout should be something like:
  • Within 1h of the release, 2-3 Storage Providers has STARTED upgrading. This can be monitored by the version number when running the new helios.
  • At all times, there should be NO less than 5 Storage Nodes Operational (eg. running with a URL set).
    • This means the Lead must ensure that nodes are following their "orders"
  • Within 24h of the release, max one Storage Node is still Operating the "old" version.
  • Within 36h of the release, no Storage Node is still Operating the "old" version.
    • The Operational, ie. URL set, part is to ensure the Storage Lead can make arrangements with good Storage Providers that, for some reason or other, is unable to make the changes in time.
  • At no point during the 36h is more than one "new" Storage Node Operational, without having all files stored locally
  1. After 72h of the release:
  • All SPs Operational (must be at least 7) have ALL files available locally.
  • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.06s/file and 0.06s/unique_size [GB]
    • Where unique_size refers to ACCEPTED files, with non-duplicate ipfs hashes.
  1. By the end of the term:
  • All SPs Operational (must be at least 9) have ALL files available locally.
  • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.05s/file and 0.05s/unique_size [GB]
    • Where unique_size refers to ACCEPTED files, with non-duplicate ipfs hashes.
  1. Deploy a script, or manually perform a check of the Joystream Player landing page asset loading time. A brief explanation of how to do so manually in the browser is outlined below:
  • Open the landing page, with the web developer tools open in the network tab, with images and media enabled.
    • Make sure you use incognito mode and/or disable/clear caching.
  • Scroll down the page, to request more and more assets (video thumbnails and channel avatars are fetched once "visible").
  • The SP the asset is getting fetched from, the size of the asset, and the time it takes to complete.
  • Log the results
    This should be done at least once a day, following the same "procedure" (eg. scrolling speed, etc.) each time.
  • Use the data to get the average speed for each provider each day.
  • Track the data throughout the Term.

Publish a TL;DR of the results every time in #storage-provider room on Discord, and at the end of the Term, deliver a report of your results, presented in a readable way.

  1. The Council must go through All reports delivered by the current Storage Lead (4/nexusfallout) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the Workers Lead in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.

Reward Distribution

Grading is individual.
For 1-3: The CM that reports on these results will get the reward regardless of the actual results, on the condition that "appropriate action" is taken if the results are "bad".
For 4: If one or more publishes a report, the reward will be split based on the quality of the report and results.

Weighting:

  • 1: $200
  • 2: $100
  • 3: $100
  • 4: $300
  • 5: $200

Grading

  1. First 36h
  • Within 1h of the release, 2-3 Storage Providers has STARTED upgrading. This can be monitored by the version number when running the new helios. - OK
  • Within 24h of the release, max one Storage Node is still Operating the "old" version. - OK
  • At all times, there should be NO less than 5 Storage Nodes Operational (eg. running with a URL set). - OK
  • Within 24h of the release, max one Storage Node is still Operating the "old" version. - OK
  • Within 36h of the release, no Storage Node is still Operating the "old" version. - OK
  • At no point during the 36h is more than one "new" Storage Node Operational, without having all files stored locally - OK
    • SP 4 and 16 had many failed for a brief period, but corrective actions were taken quickly. A few nodes had 1 or 2 missing, but that is sync issue and no fault of their own.
  1. @tomato - $100 (no one else took credit) https://testnet.joystream.org/#/forum/threads/522?replyIdx=5
    • After 72h of the release:
      • All SPs Operational (must be at least 7) have ALL files available locally. - OK
      • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.06s/file and 0.06s/unique_size [GB] - OK
        • 0.021s/file
  2. @tomato - $50 (no one else took credit) https://testnet.joystream.org/#/forum/threads/522?replyIdx=5
    • By the end of the term:
      • All SPs Operational (must be at least 9) have ALL files available locally. - OK
        • It was in fact only 8, but:
        • the "final" SP with ID 4 was operational withing 24h.
        • SP 6 was live within 26h
        • SP 16 was live within 48h
      • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.05s/file and 0.05s/unique_size [GB] - OK
        • 0.018s/file
  3. @tomato - $150
  4. @maxlevush - $200

15.8 - Follow up the Content Curators Working Group

  • Reward: $700
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

For this Term, the Storage and Curation working groups will be the focal point of the KPIs.

Scope of Work

Task 1 is expected to be performed/coordinated by the Curator group. The Council, or a Council Member's job is to push them into doing so.

Tasks 2-4 can be performed by one or more CMs.

  1. Bounty #10 was cancelled, mainly because a quick spotcheck revealed that the Bounty meant to reward publishing videos in the Public Domain ("PD") (to be fair, other permissive licenses was also allowed, if the license was "valid" - eg. attribution included, no derivates, etc.), was mostly rewarding copying videos from YouTube (YT). After we announced this, a concern that not only was most of the videos taken from, but not all videos was even properly licensed from there.
    The Curators must perform a "post mortem", going through ALL videos that submitted a claim to Bounty #10 (even if they weren't rewarded), and provide a spreadsheet with the following columns:
  • Video Id

  • Channel ID

  • Owner Id

  • On-chain License

    • The on-chain license ID can be mapped to the name - see helpdesk for Curators
  • On-chain Attribution

  • Whether other licensing requirements are upheld

    • Only applicable to certain CC licenses, eg. CC BY-ND - "No derivates"
  • Information Provided

    • If the forum post with Bounty claim contained extra info about the source
  • Original YT link

    • If available with a quick search
  • Actual license of original source

    • What license the media is actually licensed as
    • On YT, any video that doesn't explicitly say License - Creative Commons Attribution license (reuse allowed), is NOT free to share by anyone else than the owner.

    Before the end of the Term, the Curators must have made the first half of the report (eg. half the items), and shared it with me @bwhm#6514 on Discord.

Note:
It's been pointed out that this is quite a time consuming task. Will try to clarify some points:

  • There are currently close to no videos getting published, with the cancellation of Bounty #10.
    • That means the curator group, 9 people, have a lot of "free" time.
    • Although the Lead is responsible, they are not expected to do it alone!
  • One you have the videoIds, getting the channelId, (owners)memberId, (on-chain)license, and (on-chain)attribution, is something that takes 5 min, using hydra playgroun.
  • All the posts where users post their videos for claiming bounty rewards should be in the same thread (or at least only a couple)
    • All payout proposals should have that info, and/or links.
    • The "Information Provided" from the claimant should be there
  • If there's no link to the original source neither in attribution nor in the "Information Provided", try a YT search of the title (and check the video thumbnail, it may also show the YT title)
  • "Only" half of the videos covered in the Bounty must be completed to avoid annihilation.

This should be the top, and ONLY priority for the Curators this term - the time is ticking :)

  1. Create a draft for a new version of said Bounty, that takes the "lessons learned" in to account.
  • What should the workflow look like?
    • What should be required of the participants? What information should they be forced to provide?
    • What should be required of the BMs? How much time and effort will this cause?
    • What should be required of the Curators? Should it be a separate role to approve the submitted material, and another to set the reward based on quality?
  • What is a reasonable reward structure?
    • The previous version seemed to reward YT copypaste "too high", even after setting a budget
    • The previous version may have been "too low", to get curated and more desirable content
  • What can be done to improve the incentives for all parties?
  • What should the conditions be?
  1. The Council must go through All reports delivered by the current Curator Lead (1048/igrex) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the Workers Lead in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.
  1. Time permitting, use the results from 3. to draft a new Scope of Work. This should be approved by the Council first, then sent forward to JSG for another round of approval.

  2. Time permitting, use the results from 3 and 4. to propose get an idea of how many Workers are needed in the group, assuming they work x hours a week.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $200
  • 2: $100
  • 3: $250
  • 4-5: $75

Grading

  1. No one took credit/blame
    Failure here, unless an action was taken, was listed as a cause for annihilation.
    • Some work has been done, but there are some concerns:
      • It's not clear whether all the videos in the list were in fact rewarded by bounty 10
      • There are some unaddressed questions about the work here
      • It appears to have been too late (even if we're kind and assume 03.08 was withing the term)
      • It was not sent to me
    • Which raises the question if there was any consequences:
      • A proposal was opened to fire the lead here
      • It appears as if it won't pass, but it's certainly a consequence.
        • Note that this is not Jsgenesis saying the Lead should be/have been fired.
      • Conclusion can be found here
  2. @tomato - $100
  3. @maxlevush - $200
  4. NA
  5. NA

15.9 - Follow up the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

Task 1 is expected to be performed/coordinated by the Operations lead. The Council, or a Council Member's job is to push them into doing so.

Tasks 2 can be performed by one or more CMs.

  1. The Operations group current list of assigned tasks (by the Council), and what they are actually doing, appears to not be 100% synced. It appears a trello board has been created (good initiative!), but I didn't not have credentials to view it when I tried.
  • Make sure the trello (or similar) kanban board is open for all to view (best to keep write access contained :D), and find a way to highlight it
  • Share a list containing all infrastructure, with links to the service AND source code, hosted by the group
  • Elaborate on the trello board, and share short and long term plans for the group
  1. The Council must go through All reports delivered by the current Operations Lead (515/l1dev) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the group in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $200

Grading

Section IV - Bounties

15.10 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1594800
    • End Block: #1702800

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No summaries submitted for this.

15.11 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 14

  • KPIs: 14
  • Total Possible Rewards: $3100
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1486800 / 20.07.21
    • End Block/Date: #1587600 / 20.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1515600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 15 473465
515 l1dev 32 1010059
635 xfactorus 21 662851
982 drmarkovi 18 568158
867 xandrell 102-75 3219563
1316 andybut 25+75 789108
2039 doppelganger23 15 473465
957 leet_joy 0 0
439 fierydev 10 315643
4 nexusfallout 40 1262574
2 tomato 1 31564
525 oiclid 216 6817897
2130 maxlevush 767 24209848
1048 igrex 76 2398890
1027 stavr 26 820673
2182 isonar 96 3030177
SUM 16 1460 46083935

The rewards were paid out at block #1664236.

Notes

As the Council Secretary has been absent, it has been a little difficult to get a perfect overview of the performance last week, and thus creating new KPIs for this term. As a consequence, the current KPI set will be a little smaller than usual, and there may be some overlap of tasks that was completed last term.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 13th (confusingly listed as "Election round 15" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.


Section I - Council work, Proposals and Bureaucracy

14.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1486800
    • End Block: #1587600

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 13 49 15
515 l1dev 11 46 14
635 xfactorus 18 69 21
982 drmarkovi 15 59 18
867 xandrell 23 91 27
1316 andybut 20 83 25
2039 doppelganger23 14 50 15
957 leet_joy 0 0 0
439 fierydev 9 33 10
4 nexusfallout 19 75 22
2 tomato 1 4 1
525 oiclid 24 102 30
2130 maxlevush 21 89 26
1048 igrex 23 105 31
1027 stavr 23 89 26
2182 isonar 16 65 19
SUM 16 250 1009 300

14.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

14.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @oiclid - $150/$150
    • Assigned all relevant PRs to the secretary:

14.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 16th "official" Council (#1486800-#1587600) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

https://testnet.joystream.org/#/forum/threads/512?replyIdx=5

14.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1486800
    • End Block: #1587600

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 2 2 18
635 xfactorus 0 0 0
982 drmarkovi 0 0 0
867 xandrell 0 0 0
1316 andybut 0 0 0
2039 doppelganger23 0 0 0
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 2 18
2 tomato 0 0 0
525 oiclid 7 4 36
2130 maxlevush 2 2 18
1048 igrex 5 5 45
1027 stavr 0 0 0
2182 isonar 3 3 27
SUM 16 22 18 164

Section II - Community Management

14.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1486800
    • End Block: #1602000

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Section III - Working Groups

14.7 - Self Managed Budgets

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Working Group budgets are currently replenished irregularly, when the Leads notice their mints are close to empty (or worse). This makes it hard to track spending and there is also no way for Leads to justify or request their budgets in advance due to the mint refill restrictions.

Identify a way of handling budgets that would allow for a once-per-Council refill and involve some system of request and accountability (the upcoming runtime upgrade will include a greatly increased working group mint capacity).

Scope of Work

Note: All tasks should be performed in a cooperative manner with the respective Leads.

  1. Prepare some "sample" budgets for each working group that:
  • provides a reusable format (if not an actual template)
  • shows the level of details/granularity required
  • shows what each worker make, and contains a narrow range of workers expected to be part of the WG for the Term
  • if applicable (eg. for Storage and Curators), takes the OKR system in to account
    • as the OKR rewards are paid from the Council mint, these should be included in the budget, but not the Proposal
  • other?
  1. Establish some rules:
  • should extraordinary mint replenished for a WG not be allowed at all, or something that is expected to occur rather frequently?
    • should mint replenishes require that the Lead has submitted their pending reports?
    • if yes, what happens to the workers that (supposedly) did their jobs?
  • other?
  1. Set a deadline to move to the new system.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $75 for each of the three WGs
  • 2: $75
  • 3: $0

Grading

  • Scope of Work 1 (Prepare sample budgets for each WG)
    • Not completed - $/$75
  • Scope of Work 2 (Establish some rules)
    • Not completed - $/$75
  • Scope of Work 3 (Set a deadline)
    • Not completed - $/$0

14.8 - Follow up the Storage Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. It has been discovered that when a Storage Provider is down, for a variety of reasons, the Joystream Player is struggling heavily to load all the assets. Especially if the Worker in question was the liaison (ie. the SP that first received the assets). A solution for this has been established, and outlined in the #storage-provider discord. Tasks:

  • Update the helpdesk, for both the Lead and the Workers, explaining how this should be done.
  • Revise the criteria for a Storage Provider to be fired for downtime, depending on how quickly they perform this fix themselves (which doesn't require actually running the storage-node)
  • Update the workflow after getting hired for the role, so that these workers aren't negatively impacting the system while syncing the data, and aren't selected for uploads during this time.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $150

Grading

14.9 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

  • Design an OKR system
    • Already completed and paid during a previous council term.

14.10 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

  • Scope of Work 1 (Curator Lead tasks on community repo)
    • Not completed - $/$150
  • Scope of Work 2 (Follow up with leads, perform checks and sign off on reports)
  • Scope of Work 3 (Create a list of problems with the current curator workflow)
    • Not reported - $0/$37.5

14.11 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 14.9 for more information.

Reward Distribution

Grading is individual.

Grading

  • Already completed and paid during a previous council term.

14.12 - Follow up the Operations Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Ensure the Working Group updates the Joystream api examples in the community repo:
  • Updates the package.json file with correct types
  • Updates/ensures all the applicable examples work
  • Remove the examples that no longer applies
    • Ideally also adds new ones, but that will be added to the next set of KPIs.
  1. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50
  • 3: $50

Grading

  • Scope of Work 1 (Create a budget based on current tasks)
    • Not completed/reported
  • Scope of Work 2 (Ensure API examples are updated)
  • Scope of Work 3 (Follow up and sign off on lead's reports)

Section IV - Bounties

14.13 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

14.14 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. For Bounty #20:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. For Bounty #21:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 13

  • KPIs: 16
  • Total Possible Rewards: $3850
  • Council Elected in Round: 15
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1386000 / 13.07.21
    • End Block/Date: #1486800 / 20.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1515600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 27 786112
361 blackmass 13 378498
635 xfactorus 18 524075
867 xandrell 28 815227
1962 nkhlghbl 6 174692
318 supunssw 3 87346
1316 andybut 294 8559886
2039 doppelganger23 9 262037
321 freakstatic_council 171 4978709
439 fierydev 16 465844
4 nexusfallout 43 1251956
2 tomato 40 1164610
1989 2themoon 8 232922
2130 maxlevush 188 5473668
1048 igrex 111 3231794
2182 isonar 220 6405357
SUM 16 1195 34792733

Payouts done at block #1562012.

Small Changes

Starting with the last KPI round, a few changes are made:

  • The deadlines for KPIs that requires submitting a report, will be set to 12h (7200 blocks) BEFORE the end of the Term
  • All KPIs become active 12h (7200 blocks) AFTER a new Council is elected
    • These two are to make it easier to create new KPIs, as it's sometimes hard to know whether something should be included for the next term or not.
  • KPIs are broken into smaller pieces when possible, even if there is some overlap

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 13th (confusingly listed as "Election round 15" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.


Section I - Council work, Proposals and Bureaucracy

13.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1386000
    • End Block: #1486800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 28 118 27
361 blackmass 14 56 13
635 xfactorus 20 77 18
867 xandrell 30 120 28
1962 nkhlghbl 6 24 6
318 supunssw 3 12 3
1316 andybut 30 119 27
2039 doppelganger23 11 41 9
321 freakstatic_council 22 90 21
439 fierydev 17 68 16
4 nexusfallout 20 80 18
2 tomato 24 102 23
1989 2themoon 9 36 8
2130 maxlevush 29 130 30
1048 igrex 32 159 36
2182 isonar 19 76 17
SUM 16 314 1308 300

13.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

@tomato (0/$300)

  • No summary submitted

13.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @maxlevush ($75/150)
    • All relevant PRs merged (presumably meant handled)
    • Adjustet Lead rewards

13.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 15th "official" Council (#1386000-#1486800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

13.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1386000
    • End Block: #1486800

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
1905 lyazufey1812 0 0 0
361 blackmass 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
1316 andybut 2 2 17
2039 doppelganger23 0 0 0
321 freakstatic_council 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 3 25
2 tomato 2 2 17
1989 2themoon 0 0 0
2130 maxlevush 7 7 58
1048 igrex 9 9 75
2182 isonar 1 1 8
SUM 16 24 24 200

Section II - Community Management

13.6 - Founding Member Statistics

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400 *
    • End Block: #1479600

* extended from round 12.
AFAICT, No one has attempted this. Will be made into a bounty next Council Term, if no one starts. It's a good way to learn more about the Joystream API (as well)!

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!
Further note that there is some overlap with KPI 13.7. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

Some statistics:

  • Total platform Memberships: 2434
  • Member that have submitted scores (including up to Scoring Period 9 only): 736
  • Total >0 submissions: 1819
  • Members that have earned >0 for every Scoring Period: 37
  • Members that have earned >0 for all but two or fewer Scoring Periods : 34+47
  • Graded submissions per Scoring Period: [15,562,287,122,143,139,144,140,144,123]
  • Direct scores per Scoring Period: [9550,90420,35190,18840,21080,34645,31245,28145,33035,25660]
  • Referral scores per Scoring Period: [0,6442,2679,1590,1812,2403,2055,1458,1458,1747]
  • Average direct scores pr submission by Scoring Period: [637,161,123,154,147,249,217,201,229,209]

Some worrying signs:

  • There are fewer submissions per Scoring Period
  • There are fewer points awarded per Scoring Period
    • This is partially due to re-calibration, but shouldn't be the case for the last 6 or so rounds, and it's still crashing
  • Our statistics indicate that very few of both CMs and workers are reporting their activities

Although there are some known reasons for this development, we want to know more!

Scope of Work

For all of the above:

  • Getting the verbose FM points data needed can be found here
  • ctrl+f of cmd+f the memberId or memberHandle to find that person (you may have to download the file)
  • What you need is the directScores for each round
    • they are indexed from Scoring Period 0 and upwards
  1. Assemble more data for CMs:
  • Doing work on the Council is supposed to be the best/most efficient way of earning FM points
    • Use the KPI grading results, available for Sumer and Antioch to find out the memberId and memberHandle of the CMs was for Council Term.
    • Take advantage of the fact that each Scoring Period, starting from round 1 lasted two weeks, and figure out which Scoring Period each Council Term "belongs" in
    • Find out how many points all the CMs earned per Scoring Period (even if 0), and whether they were CMs in "both" Terms or not, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their CM KPI work
      • the CMS that reports their Council KPI rewards, should earn a (roughly) "fixed" amount of FM points pr KPI $ earned
  1. Assemble more data for workers:
  • Being part of a WG is supposed to be another key way of earning FM points:
  • You can ignore rounds from before the release of Antioch - 7th April 2021 (eg. start from Scoring Period 5)
    • Using on-chain data, find the memberId and memberHandle that was active in a role at the end of each Scoring Period
    • Hints:
      • Use the KPI gradings to find an approximate blockHeight corresponding to that date (will be <14400 off - good enough!)
      • Create a script, or use the javascript playground to find the active workers for each of the WGs (the operations WG didn't exist before #717987)
    • Once you know who was hired as worker for each group during each Scoring Period, find out how many points each of them earned per Period, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their WG work
  1. Assemble data for bounties:
  • Bounties are another great way of earning large "chunks" of FM points, although not as recurring as the other two
    • Use this json to get the "closedDate" and the corresponding github issue to figure out who was paid out for each bounty completed after the FM program launch.
    • You can also ask the Council Secretary for more info
    • Find out whether points the bounty solver earned points for their work, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their Bounty work
      • much like for CMs, the FM points awarded should be roughly proportional to the $ earned on a bounty
  1. Combine the data:
  • At this point, you should be able to identify roughly whether the user reported their work from 1, 2 or 3
    • If you need more information, you can ask the user themselves for "full" information (if they kept it), or blrhc#0162 / bwhm#6514 on discord for some more information on specific summaries on Discord
    • Knowing that some will have reported other activities as well, try to estimate what was earned from what
  • You have now separated the source of points, and can produce a report with:
    • the raw data gathered, in MS excel/google sheets/mac number/open office or json format
CMs

For CMs, knowing that CMS that reported their Council KPI rewards, should earn a roughly "fixed" amount of FM points per KPI $ earned, estimate which CMs submitted their CM KPI work in their scores:

  • From all the Councils: how many out of all reported their work?
  • How many FM points (estimate) is a CM awarded per KPI $ earned?
  • How many KPI $ was earned?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual CMs?
Workers

For workers, it may not always be the case that they earn points solely for being in the WG. They may be awarded extra for actual activity, but assume they're not

  • For all the WGs: how many out of all reported their work per Scoring Period?
  • How many FM points (estimate) is awarded per week of being hired in each WG (if they reported)?
  • How many FM points are the Leads awarded?
  • How many of the workers, for each WG, submitted their scores in each Scoring Period out of the total possible?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual Workers?
Bounties

For Bounties, knowing that you earn a roughly "fixed" amount of FM points per Bounty:

  • How many FM points (estimate) is bounty $ worth?
  • How many FM points was awarded from bounties?
  • How many FM points was "lost" - both in total and for the individual bounty solver?

Reward Distribution

If multiple reports are made, the KPI reward may be increased so the total reward paid may exceed the "promised" amount.

Grading

  • No work completed
    • Will become a bounty

13.7 - Founding Member Survey

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400 *
    • End Block: #1479600

* extended from round 12.
We hope to get close to a 100 submissions here. Help @andybut spread the word :)

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!

Further note that there is some overlap with KPI 13.6. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

See KPI 13.6 for more information.

Scope of Work

Create a Questionnaire, targeting:

  • Everyone that has submitted a scoring summary for a Scoring Period
  • Everyone that has been on the Council on the latest network (eg. Antioch/ joy_testnet_5)
  • Everyone that has been part of a Working Group on the latest network (eg. Antioch/ joy_testnet_5)
Information Wanted

Most of the information wanted can be deduced by reading KPI 13.6, but some examples are added. Multiple choice questions should be used when possible:

  • Are you in one or more of the groups above?
    • Which one(s)?
  • How many times have you submitted a summary?
  • Why/why not more/some?
    • What do you typically include in your summaries?
  • How many times have you x Council/WG/Bounties?
    • Have you reported these activities?
    • Why not?
  • Did you know Council/WG/Bounties awards lots of points?
  • Did you know Council/Bounty $ earns is roughly proportional to FM points awarded?
  • Knowing this, would you (re-)submit your summaries for "older" Scoring Periods?
  • What can be done to make it "easier" for you to submit in the future?
  • etc.

At the bottom of the survey, include a "free text" field where users should paste in the signature of the message:

I am member <ID>, signing with key <rootAccount OR controllerAccount>

So for me, member 1 and root account 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx:

message:
"I am member 1, signing with key 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx"
signature:
"0xc218c9fab03783c10ee94f27b4c353f3d3a234ea98816ae6abd5e0d446957c78f91efd9a8f4824875bdc1d824f4b51fb3a5a5534461d65e44d1d6b7021aff384"
Reporting the Results

Everyone (with a memberId < 2434) that participates earns $5 worth of JOY, IF they include said signed message. Their individual responses should be anonymized, but respondents that don't supply a signature should not be included in the results.

Present the report with the results as a PR to the Community Repo

  • in markdown format
  • all questions and answer statistics, with numbers and pie charts
  • short summary with interpretation of the results

All messages and signatures must be sent to me through:

  • @bwhm #6514 (discord)
    or
  • @bwhm (keybase)

The respondents will be rewarded when the KPI is graded.

Reward Distribution

If multiple reports are made, the KPI reward will go the to the "best" one.

Grading

13.8 - Runtime Upgrade Parameters Discussion

  • Reward: $100++
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1508400 *

* extended two more days (only), as we need to finalize this.

Purpose

As there was a bug with the stakes for the Operations Working Group, we are planning to perform a runtime upgrade that fixes this. As we prefer not to do these regularly (as it requires extensive testing), it makes sense to see what else could be addressed!

Scope of Work

  1. Invite the Community at large to participate, and propose which parameters could be changed to improve the "quality of life" for the Council, WGs and the Community.
  2. Create proposals for each specific parameter change. Then discuss and vote on them.
  3. Present the results in a short report.

Reward Distribution

The writer of the report can earn up to $50.

  • Each member that proposed a change (that gets approved by the Council) earns between $25
  • If the value gets approved by Jsgenesis, a further $25 is awarded, even if it isn't included in the upgrade

Grading

  • Nothing submitted

13.9 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1386000
    • End Block: #1501200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

  • @andybut ($100)
  • @isonar (25$)
  • @mexlevush (25$)

Section III - Working Groups

13.10 - Self Managed Budgets

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Working Group budgets are currently replenished irregularly, when the Leads notice their mints are close to empty (or worse). This makes it hard to track spending and there is also no way for Leads to justify or request their budgets in advance due to the mint refill restrictions.

Identify a way of handling budgets that would allow for a once-per-Council refill and involve some system of request and accountability (the upcoming runtime upgrade will include a greatly increased working group mint capacity).

Scope of Work

Note: All tasks should be performed in a cooperative manner with the respective Leads.

  1. Prepare some "sample" budgets for each working group that:
  • provides a reusable format (if not an actual template)
  • shows the level of details/granularity required
  • shows what each worker make, and contains a narrow range of workers expected to be part of the WG for the Term
  • if applicable (eg. for Storage and Curators), takes the OKR system in to account
    • as the OKR rewards are paid from the Council mint, these should be included in the budget, but not the Proposal
  • other?
  1. Establish some rules:
  • should extraordinary mint replenished for a WG not be allowed at all, or something that is expected to occur rather frequently?
    • should mint replenishes require that the Lead has submitted their pending reports?
    • if yes, what happens to the workers that (supposedly) did their jobs?
  • other?
  1. Set a deadline to move to the new system.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $75 for each of the three WGs
  • 2: $75
  • 3: $0

Grading

  • Nothing submitted

13.11 - Follow up the Storage Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.

  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $100

Grading

  • Nothing submitted

13.12 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

  • Nothing submitted

13.13 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

  • Nothing submitted

13.14 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 13.12 for more information.

Reward Distribution

Grading is individual.

Grading

TBD

13.15 - Follow up the Operations Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Ensure the Working Group updates the Joystream api examples in the community repo:
  • Updates the package.json file with correct types
  • Updates/ensures all the applicable examples work
  • Remove the examples that no longer applies
    • Ideally also adds new ones, but that will be added to the next set of KPIs.
  1. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50
  • 3: $50

Grading

  • @isonar ($50/$150)
    • Set up a trello board (I don't have access)
    • Conflict of interest makes it hard to see what is done as a Role occupant, vs CM

Section IV - Bounties

13.16 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • Nothing submitted

13.17 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. For Bounty #20:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. For Bounty #21:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 12

  • KPIs: 16
  • Total Possible Rewards: $3800
  • Council Elected in Round: 13
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1285200 / 06.07.21
    • End Block/Date: #1386000 / 13.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1414800

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 13 385032
515 l1dev 0 0
635 xfactorus 19 562740
867 xandrell 78 2310194
318 supunssw 11 325797
1316 andybut 132 3909560
2039 doppelganger23 8 236943
321 freakstatic_council 105 3109877
957 leet_joy 1 29618
439 fierydev 13 385032
4 nexusfallout 39 1155097
2 tomato 610 18066905
525 oiclid 75 2221341
2130 maxlevush 658 19488563
1048 igrex 60 1777073
2182 isonar 14 414650
SUM 16 1836 54378422

Paid out at block 1446734.

Small Changes

Starting with this KPI, a few changes are made:

  • The deadlines for KPIs that requires submitting a report, will be set to 12h (7200 blocks) BEFORE the end of the Term
  • All KPIs become active 12h (7200 blocks) AFTER a new Council is elected
    • These two are to make it easier to create new KPIs, as it's sometimes hard to know whether something should be included for the next term or not.
  • KPIs are broken into smaller pieces when possible, even if there is some overlap

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.


Section I - Council work, Proposals and Bureaucracy

12.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1285200
    • End Block: #1386000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 16 64 13
515 l1dev 0 0 0
635 xfactorus 29 92 19
867 xandrell 40 136 28
318 supunssw 13 52 11
1316 andybut 40 144 30
2039 doppelganger23 10 40 8
321 freakstatic_council 34 116 24
957 leet_joy 1 4 1
439 fierydev 16 61 13
4 nexusfallout 29 102 21
2 tomato 26 115 24
525 oiclid 39 155 32
2130 maxlevush 39 145 30
1048 igrex 38 149 31
2182 isonar 18 68 14
SUM 16 388 1443 300

12.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $275/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 65%
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes

12.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

12.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1285200
    • End Block: #1400400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 12th "official" Council (#1285200-#1386000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

12.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1292400
    • End Block: #1386000

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
318 supunssw 0 0 0
1316 andybut 2 1 6
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 6
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 3 18
2 tomato 7 7 41
525 oiclid 7 3 18
2130 maxlevush 6 6 35
1048 igrex 7 5 29
2182 isonar 1 0 0
SUM 16 34 26 153

Section II - Community Management

12.6 - Founding Member Statistics

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!
Further note that there is some overlap with KPI 12.7. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

Some statistics:

  • Total platform Memberships: 2434
  • Member that have submitted scores (including up to Scoring Period 9 only): 736
  • Total >0 submissions: 1819
  • Members that have earned >0 for every Scoring Period: 37
  • Members that have earned >0 for all but two or fewer Scoring Periods : 34+47
  • Graded submissions per Scoring Period: [15,562,287,122,143,139,144,140,144,123]
  • Direct scores per Scoring Period: [9550,90420,35190,18840,21080,34645,31245,28145,33035,25660]
  • Referral scores per Scoring Period: [0,6442,2679,1590,1812,2403,2055,1458,1458,1747]
  • Average direct scores pr submission by Scoring Period: [637,161,123,154,147,249,217,201,229,209]

Some worrying signs:

  • There are fewer submissions per Scoring Period
  • There are fewer points awarded per Scoring Period
    • This is partially due to re-calibration, but shouldn't be the case for the last 6 or so rounds, and it's still crashing
  • Our statistics indicate that very few of both CMs and workers are reporting their activities

Although there are some known reasons for this development, we want to know more!

Scope of Work

For all of the above:

  • Getting the verbose FM points data needed can be found here
  • ctrl+f of cmd+f the memberId or memberHandle to find that person (you may have to download the file)
  • What you need is the directScores for each round
    • they are indexed from Scoring Period 0 and upwards
  1. Assemble more data for CMs:
  • Doing work on the Council is supposed to be the best/most efficient way of earning FM points
    • Use the KPI grading results, available for Sumer and Antioch to find out the memberId and memberHandle of the CMs was for Council Term.
    • Take advantage of the fact that each Scoring Period, starting from round 1 lasted two weeks, and figure out which Scoring Period each Council Term "belongs" in
    • Find out how many points all the CMs earned per Scoring Period (even if 0), and whether they were CMs in "both" Terms or not, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their CM KPI work
      • the CMS that reports their Council KPI rewards, should earn a (roughly) "fixed" amount of FM points pr KPI $ earned
  1. Assemble more data for workers:
  • Being part of a WG is supposed to be another key way of earning FM points:
  • You can ignore rounds from before the release of Antioch - 7th April 2021 (eg. start from Scoring Period 5)
    • Using on-chain data, find the memberId and memberHandle that was active in a role at the end of each Scoring Period
    • Hints:
      • Use the KPI gradings to find an approximate blockHeight corresponding to that date (will be <14400 off - good enough!)
      • Create a script, or use the javascript playground to find the active workers for each of the WGs (the operations WG didn't exist before #717987)
    • Once you know who was hired as worker for each group during each Scoring Period, find out how many points each of them earned per Period, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their WG work
  1. Assemble data for bounties:
  • Bounties are another great way of earning large "chunks" of FM points, although not as recurring as the other two
    • Use this json to get the "closedDate" and the corresponding github issue to figure out who was paid out for each bounty completed after the FM program launch.
    • You can also ask the Council Secretary for more info
    • Find out whether points the bounty solver earned points for their work, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their Bounty work
      • much like for CMs, the FM points awarded should be roughly proportional to the $ earned on a bounty
  1. Combine the data:
  • At this point, you should be able to identify roughly whether the user reported their work from 1, 2 or 3
    • If you need more information, you can ask the user themselves for "full" information (if they kept it), or blrhc#0162 / bwhm#6514 on discord for some more information on specific summaries on Discord
    • Knowing that some will have reported other activities as well, try to estimate what was earned from what
  • You have now separated the source of points, and can produce a report with:
    • the raw data gathered, in MS excel/google sheets/mac number/open office or json format
CMs

For CMs, knowing that CMS that reported their Council KPI rewards, should earn a roughly "fixed" amount of FM points per KPI $ earned, estimate which CMs submitted their CM KPI work in their scores:

  • From all the Councils: how many out of all reported their work?
  • How many FM points (estimate) is a CM awarded per KPI $ earned?
  • How many KPI $ was earned?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual CMs?
Workers

For workers, it may not always be the case that they earn points solely for being in the WG. They may be awarded extra for actual activity, but assume they're not

  • For all the WGs: how many out of all reported their work per Scoring Period?
  • How many FM points (estimate) is awarded per week of being hired in each WG (if they reported)?
  • How many FM points are the Leads awarded?
  • How many of the workers, for each WG, submitted their scores in each Scoring Period out of the total possible?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual Workers?
Bounties

For Bounties, knowing that you earn a roughly "fixed" amount of FM points per Bounty:

  • How many FM points (estimate) is bounty $ worth?
  • How many FM points was awarded from bounties?
  • How many FM points was "lost" - both in total and for the individual bounty solver?

Reward Distribution

If multiple reports are made, the KPI reward may be increased so the total reward paid may exceed the "promised" amount.

Grading

  • No work completed

12.7 - Founding Member Survey

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!

Further note that there is some overlap with KPI 12.6. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

See KPI 12.6 for more information.

Scope of Work

Create a Questionnaire, targeting:

  • Everyone that has submitted a scoring summary for a Scoring Period
  • Everyone that has been on the Council on the latest network (eg. Antioch/ joy_testnet_5)
  • Everyone that has been part of a Working Group on the latest network (eg. Antioch/ joy_testnet_5)
Information Wanted

Most of the information wanted can be deduced by reading KPI 12.6, but some examples are added. Multiple choice questions should be used when possible:

  • Are you in one or more of the groups above?
    • Which one(s)?
  • How many times have you submitted a summary?
  • Why/why not more/some?
    • What do you typically include in your summaries?
  • How many times have you x Council/WG/Bounties?
    • Have you reported these activities?
    • Why not?
  • Did you know Council/WG/Bounties awards lots of points?
  • Did you know Council/Bounty $ earns is roughly proportional to FM points awarded?
  • Knowing this, would you (re-)submit your summaries for "older" Scoring Periods?
  • What can be done to make it "easier" for you to submit in the future?
  • etc.

At the bottom of the survey, include a "free text" field where users should paste in the signature of the message:

I am member <ID>, signing with key <rootAccount OR controllerAccount>

So for me, member 1 and root account 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx:

message:
"I am member 1, signing with key 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx"
signature:
"0xc218c9fab03783c10ee94f27b4c353f3d3a234ea98816ae6abd5e0d446957c78f91efd9a8f4824875bdc1d824f4b51fb3a5a5534461d65e44d1d6b7021aff384"
Reporting the Results

Everyone (with a memberId < 2434) that participates earns $5 worth of JOY, IF they include said signed message. Their individual responses should be anonymized, but respondents that don't supply a signature should not be included in the results.

Present the report with the results as a PR to the Community Repo

  • in markdown format
  • all questions and answer statistics, with numbers and pie charts
  • short summary with interpretation of the results

All messages and signatures must be sent to me through:

  • @bwhm #6514 (discord)
    or
  • @bwhm (keybase)

The respondents will be rewarded when the KPI is graded.

Reward Distribution

If multiple reports are made, the KPI reward will go the to the "best" one.

Grading

12.8 - Runtime Upgrade Parameters Discussion

  • Reward: $100++
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

As there was a bug with the stakes for the Operations Working Group, we are planning to perform a runtime upgrade that fixes this. As we prefer not to do these regularly (as it requires extensive testing), it makes sense to see what else could be addressed!

Scope of Work

  1. Invite the Community at large to participate, and propose which parameters could be changed to improve the "quality of life" for the Council, WGs and the Community.
  2. Create proposals for each specific parameter change. Then discuss and vote on them.
  3. Present the results in a short report.

Reward Distribution

The writer of the report can earn up to $50.

  • Each member that proposed a change (that gets approved by the Council) earns between $25
  • If the value gets approved by Jsgenesis, a further $25 is awarded, even if it isn't included in the upgrade

Grading

12.9 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1292400
    • End Block: #1400400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

12.10 - Update Membership Profiles

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Being able to reach a member through their address and/or their memberId is sometimes needed. Both for our own benefit, and for the Community as a whole, adding contact info in the profile would be a great help.

Scope of Work

Reach out to the community, and ask them to add contact information and avatars in their membership profiles.

Make sure they are aware of the potential doxxing risk, and only share information they are "comfortable" with.

Contact Info

For the contact information, one or more of the below "counts":

  • Discord (full ID)
  • Keybase
  • Telegram
  • Twitter
    Optionally, GitHub handle is also a "nice to have".
Avatar

Any avatar other than the default is nice :)

Reward Distribution

The rewards will be split between those that tries to reach the Community.

For each user, that in between the start block and end block:

  • adds at least one contact info grants: ¢50
  • adds three or more (including GitHub) and HAS an avatar: $1

Capped at $300!

Grading

Section III - Working Groups

12.11 - Follow up the Storage Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.

  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $100

Grading

12.12 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

12.13 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

12.14 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 12.12 for more information.

Reward Distribution

Grading is individual.

Grading

12.15 - Follow up the Operations Working Group

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50

Grading

Section IV - Bounties

12.16 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $100 to finalize all submissions
    • Bounty 19: $25/100 per week
    • Bounty 20: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

  • #9
  • #14
    • The grading appears too generous - contact Council Secretary for more info
  • #19
  • #20
    • Should be opened by 08.07.21

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 11

  • KPIs: 11
  • Total Possible Rewards: $2775
  • Council Elected in Round: 11
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1184400 / 29.06.21
    • End Block/Date: #1285200 / 6.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1314000

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 10 282818
515 l1dev 4 113127
635 xfactorus 34 961581
867 xandrell 63 1781753
1962 nkhlghbl 3 84845
318 supunssw 2 56564
1316 andybut 111 3139279
2039 doppelganger23 20 565636
321 freakstatic_council 146 4129141
957 leet_joy 12 339381
439 fierydev 24 678763
4 nexusfallout 50 1414090
2 tomato 592 16742820
525 oiclid 108 3054433
2130 maxlevush 568 16064057
1048 igrex 110 3110997
SUM 16 1857 52519285

Paid out at block #1333558.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

11.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 6 24 10
515 l1dev 3 9 4
635 xfactorus 21 84 34
867 xandrell 23 86 35
1962 nkhlghbl 2 8 3
318 supunssw 3 6 2
1316 andybut 24 92 37
2039 doppelganger23 12 48 20
321 freakstatic_council 21 84 34
957 leet_joy 7 30 12
439 fierydev 15 60 24
4 nexusfallout 19 78 32
2 tomato 24 101 41
525 oiclid 16 60 24
2130 maxlevush 25 100 41
1048 igrex 24 112 46
SUM 16 245 982 400

11.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

11.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

11.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 11th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

11.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1270800
    • End Block: #1285200

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

11.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1184400
    • End Block: #1299600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

11.7 - Manage the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $200
  • 3: $100

Grading

11.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 11.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

11.9 - Manage the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $50

Grading

11.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
1316 andybut 1 1 9
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 9
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 2 2 18
2 tomato 3 3 27
525 oiclid 1 1 9
2130 maxlevush 6 5 45
1048 igrex 8 7 64
SUM 16 22 20 182

11.11 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $150 to finalize all submissions
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 10

  • KPIs: 12
  • Total Possible Rewards: $3025
  • Council Elected in Round: 12
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1083600 / 22.06.21
    • End Block/Date: #1184400 / 29.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1213200

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 32 941327
635 xfactorus 35 1029577
867 xandrell 111 3265230
1962 nkhlghbl 15 441247
318 supunssw 5 147082
2039 doppelganger23 27 794245
321 freakstatic_council 133 3912392
957 leet_joy 4 117666
439 fierydev 24 705996
4 nexusfallout 41 1206076
2 tomato 652 19179548
1989 2themoon 12 352998
2130 maxlevush 661 19444296
1048 igrex 122 3588811
355 manipal 0 0
2182 isonar 22 647163
SUM 16 1896 55773654

Payouts on block #1236226.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

10.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 19 76 32
635 xfactorus 22 82 35
867 xandrell 23 86 36
1962 nkhlghbl 9 36 15
318 supunssw 4 13 5
2039 doppelganger23 17 65 27
321 freakstatic_council 19 76 32
957 leet_joy 4 10 4
439 fierydev 14 56 24
4 nexusfallout 19 76 32
2 tomato 21 90 38
1989 2themoon 7 28 12
2130 maxlevush 24 108 46
1048 igrex 22 93 39
355 manipal 0 0 0
2182 isonar 13 52 22
SUM 16 237 947 400

10.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

10.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

10.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 9th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

10.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1170000
    • End Block: #1184400

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

10.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1083600
    • End Block: #1198800

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

10.7 - Manage the Storage Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Storage Lead role is scattered across the Helpdesk, proposal(s) and forum post(s). This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other SPs) must be available and helpful in Discord and the forum.
  • The Storage Lead should be conducting:
    • frequent spotchecks
    • general "system health" checks
    • asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.

This should be accompanied by a set of rules defining some terms under which the Storage Lead should be:

  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. In collaboration with the Lead, create a budget that allows the hiring of 4 more SPs, to a total of 10 (including the Lead). This should include

  • Estimates of costs for different VPS providers
  • A reasonable profit for the workers, taking their time in to account.
  • At which point(s) the SPs needs a payment increase to account for increased costs, eg. growth of the data directory.
  • Note that this budget should take any OKR compensations in to account, when those are ready.
  1. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:
  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-3: $75
  • 4-5: $150

Grading

10.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
    This should be accompanied by a set of rules defining some terms under which the Curator Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 10.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

10.9 - Manage the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Hire a team of at least 3 (more) people.
  3. Follow up and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-4: $50

Grading

10.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 3 3 26
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 1 1 9
2 tomato 8 7 61
1989 2themoon 0 0 0
2130 maxlevush 6 4 35
1048 igrex 5 5 43
355 manipal 0 0 0
2182 isonar 0 0 0
SUM 16 23 20 174

10.11 - Working Group Term Limits

  • Reward: $150
  • Reward Distribution: Shared
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Unlike the Council, where there are (currently) 16 spots every week, the Working Groups naturally sees less turnover. Especially the Lead. On the positive side, this should mean a long standing Lead gets significant insight to what the job entails. It does also mean that potentially only a single person knows how the system works.

Especially as it has also proven to be very rare for the Lead to be fired, even if they are not performing as instructed.

Scope of Work

  1. Discuss the merits for term limits for each of the Working Group Leads.
  2. If considered useful, set a reasonable length, and agree on some process for doing the handover.
  • Should the former Lead stay on as a Worker, to ease the transition?
  • Under what circumstances should this apply?
  • Should they receive extra compensation for this?
    • If so, how long?
    • Is a single bonus payout better?

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

10.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 9

  • KPIs: 11
  • Total Possible Rewards: $2875
  • Council Elected in Round: 11
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #982800 / 15.06.21
    • End Block/Date: #1083600 / 22.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #112400

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 12 328081
515 l1dev 0 0
635 xfactorus 28 765522
867 xandrell 153 4183033
1962 nkhlghbl 27 738182
318 supunssw 6 164041
321 freakstatic_council 123 3362831
957 leet_joy 24 656162
439 fierydev 13 355421
4 nexusfallout 24 656162
552 cheomsk 30 820203
2 tomato 791 21626008
1323 kakashi 14 382761
2130 maxlevush 51 1394344
1048 igrex 61 1667745
2182 isonar 18 492122
SUM 16 1375 37592618

Payouts were done on block #1153461.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 9th (confusingly listed as "Election round 11" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

9.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 6 24 12
515 l1dev 0 0 0
635 xfactorus 15 54 28
867 xandrell 20 74 38
1962 nkhlghbl 13 52 27
318 supunssw 3 12 6
321 freakstatic_council 19 72 37
957 leet_joy 11 46 24
439 fierydev 8 26 13
4 nexusfallout 13 46 24
552 cheomsk 16 58 30
2 tomato 20 98 50
1323 kakashi 7 28 14
2130 maxlevush 20 77 40
1048 igrex 19 76 39
2182 isonar 9 36 18
SUM 16 199 779 400

9.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $270/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 75%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/203)
    • Council wrangling in #council channel - Yes

9.3 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No one claimed referral commissions.
  • Bounty 9
    • @ - $0/$25
      • No new submissions, no payments
      • Still requires structure improvement due to merge/review delays
  • Bounty 19
    • @ - $0/$25
      • No submissions, no applications, no payments.

9.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 9th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

9.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1069200
    • End Block: #1083600

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

9.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel
  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #982800
    • End Block: #1098000

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

9.7 - Manage the Storage Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Storage Lead role is scattered across the Helpdesk, proposal(s) and forum post(s). This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other SPs) must be available and helpful in Discord and the forum.
  • The Storage Lead should be conducting:
    • frequent spotchecks
    • general "system health" checks
    • asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.

This should be accompanied by a set of rules defining some terms under which the Storage Lead should be:

  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. In collaboration with the Lead, create a budget that allows the hiring of 4 more SPs, to a total of 10 (including the Lead). This should include

  • Estimates of costs for different VPS providers
  • A reasonable profit for the workers, taking their time in to account.
  • At which point(s) the SPs needs a payment increase to account for increased costs, eg. growth of the data directory.
  • Note that this budget should take any OKR compensations in to account, when those are ready.
  1. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:
  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads are (still) failing at an alarming frequency - at the time of writing, close to 10% are pending vs accepted (133 - 1538).
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-3: $75
  • 4-5: $150

Grading

9.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
    This should be accompanied by a set of rules defining some terms under which the Curator Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 9.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

9.9 - Manage the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1098000

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Currently, the specific tasks associated with the Operations Lead role was agreed in proposals:
  • 127
  • 128
  • 155
  • 160
    In addition, some tasks are outlined in the helpdesk. This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Operations group always has assigned one/some of their own to act as Bounty Managers for all technical and research bounties, such as:
  • Reporting requirements and frequency
    This should be accompanied by a set of rules defining some terms under which the Operations Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Hire a team of at least 3 (more) people.
  3. Follow up and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-4: $50

Grading

9.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
321 freakstatic_council 1 1 11
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 0 0 0
552 cheomsk 0 0 0
2 tomato 14 12 133
1323 kakashi 0 0 0
2130 maxlevush 1 1 11
1048 igrex 2 2 22
2182 isonar 0 0 0
SUM 16 18 16 178

9.11 - Working Group Term Limits

  • Reward: $150
  • Reward Distribution: Shared
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Unlike the Council, where there are (currently) 16 spots every week, the Working Groups naturally sees less turnover. Especially the Lead. On the positive side, this should mean a long standing Lead gets significant insight to what the job entails. It does also mean that potentially only a single person knows how the system works.

Especially as it has also proven to be very rare for the Lead to be fired, even if they are not performing as instructed.

Scope of Work

  1. Discuss the merits for term limits for each of the Working Group Leads.
  2. If considered useful, set a reasonable length, and agree on some process for doing the handover.
  • Should the former Lead stay on as a Worker, to ease the transition?
  • Under what circumstances should this apply?
  • Should they receive extra compensation for this?
    • If so, how long?
    • Is a single bonus payout better?

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

  • Not completed ($0/$150)

KPI 8

  • KPIs: 10
  • Total Possible Rewards: $2375
  • Council Elected in Round: 10
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #882000 / 08.06.21
    • End Block/Date: #982000 / 15.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1011600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 9 249816
515 l1dev 16 444117
635 xfactorus 30 832719
867 xandrell 170 4718742
1962 nkhlghbl 124 3441906
318 supunssw 9 249816
2039 doppelganger23 14 388602
321 freakstatic_council 133 3691722
957 leet_joy 48 1332351
4 nexusfallout 28 777205
552 cheomsk 39 1082535
631 xantis 14 388602
2 tomato 798 22150331
319 sparky 0 0
2130 maxlevush 187 5190616
2182 isonar 34 943748
SUM 16 1653 45882828

Paid out at block #1,034,470.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 9th (confusingly listed as "Election round 11" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

8.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #88200
    • End Block: #982800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 4 16 9
515 l1dev 7 28 16
635 xfactorus 16 52 30
867 xandrell 19 61 35
1962 nkhlghbl 8 33 19
318 supunssw 4 16 9
2039 doppelganger23 7 25 14
321 freakstatic_council 19 75 43
957 leet_joy 15 58 33
4 nexusfallout 15 50 28
552 cheomsk 19 68 39
631 xantis 7 25 14
2 tomato 17 73 41
319 sparky 0 0 0
2130 maxlevush 19 65 37
2182 isonar 18 60 34
SUM 16 194 705 400

8.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $280/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 75%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/203)
    • Council wrangling in #council channel - Yes

8.3 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $25/50 per week
    • Bounty 15: $25/100 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty with this format, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

8.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 8th "official" Council on Babylon (#882000-#997200) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

8.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #968400
    • End Block: #982800

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

8.6 - Discord Channel Management

  • Reward: $50 Per Channel Group
    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    1. Governance
    • #council
    • #proposal
    • #bounties
    1. Newcomers
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups (1-3):
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

8.7 - Manage the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.
This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Uploads are failing at an alarming frequency - at the time of writing, close to 10% are pending vs accepted (90 - 964). Ensure the Storage Lead finds out which SP(s) are the source of these failures, and takes appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • This task requires some research from the SP lead, but by using the query-node playground, and the examples, it can be done.
  • The Lead is free to ask questions in Discord if assistance is needed
  1. Ensure the Lead (and/or other SPs) are available and helpful in Discord and the forum
  2. Ensure the Storage Lead is doing frequent spotchecks, performs general "system health" checks, and asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  3. Currently, the reporting requirements are stated here and here. The Council needs to nail down a specific reporting system. See this issue for some suggestions.
  4. Ensure the Lead performs the actions required by them, and any other agreed upon deliverables.
  5. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.
  6. Ensure the Lead adjusts the workers rewards if required due to rate changes
  7. Propose a draft for an OKR system used to measure the quality of service provided by the working group (this subtask commands $100/$300 of the possible rewards)
  • Who should be respnsible for making, and grading, the OKRs?
    • eg. Council creates, Lead measured
    • Lead creates, workers measured?
    • Both?
  • What sort of metrics should be measured?
    • What are those metrics now?
    • What should those metrics be?
  • How frequently should the results be measured?
  • What should the incentives be?
    • Should part of the Leads compensation be tied to the results?
  • etc.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.8 - Manage the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

In no particular order:

  1. The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  1. With the new content directory, the reporting requirements for the group and Lead should be revisited. Previously, the Council agreed on these requirements.
  • This seems a little lightweight, and should be expanded. Now that examples for using the query node playground has been added here, more thorough reporting should be required:
    • the suggested format for "regular checks" can be found here
    • the suggested format for "council reports" can be found here
    • not that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Agree on the frequency and format of the reporting.
  • The results, as agreed in a text proposal, should then be added to the Community Repo.
  1. As stated in KPI 8.4, some content statistics should be included in the Council Minutes. This should include information about categories, channels, duration statistics and upload statistics, available from the Query Node Playground.
  2. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  3. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  4. Ensure the Lead adjusts the workers rewards if required due to rate changes
  5. Propose a draft for an OKR system used to measure the quality of service provided by the working group (this subtask commands $100/$300 of the possible rewards). This means:
  • Who should be respnsible for making, and grading, the OKRs?
    • eg. Council creates, Lead measured
    • Lead creates, workers measured?
    • Both?
  • What sort of metrics should be measured?
    • What are those metrics now?
    • What should those metrics be?
  • How frequently should the results be measured?
  • What should the incentives be?
    • Should part of the Leads compensation be tied to the results?
  • etc.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.9 - Manage the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Ensure the group immediately addresses the defined tasks listed in the groups helpdesk section.
  2. Create a list of reasonable tasks the group could be tasked with right away, or in the future once more workers are hired. Examples from last KPI (some overlap with 1.):
  • Manage/maintain the api-examples in community repo
    • update when new types are issued (urgent)
    • eg. create new/better examples (high priority)
  • Technical bounties:
    • Act as BMs
    • Suggest new ones
    • Provide guidance and assistance?
    • Decide whether they (not the BM themselves ofc) can also apply/contribute?
  • Maintain (and pay for) some server infrastructure:
    • Backup servers (pioneer, API)
    • Leeching storage nodes (as backups when needed)
    • Provide API for getting data from "old" testnets
    • Non-critical/sensitive stuff created by the community (UNO)
    • Discord/telegram bots
    • Faucets (funds to be requested in spending props)
    • Deploy mirror of QN/Atlas?
  • Make minor (unsolicited and/or solicited) improvements to CLI and Pioneer
  • Manage #tech-support (Discord)
  • Offload Council?
  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Create the initial reporting requirements for the group.
  3. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 2 1 15
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 15
957 leet_joy 1 1 15
4 nexusfallout 0 0 0
552 cheomsk 0 0 0
631 xantis 0 0 0
2 tomato 8 5 77
319 sparky 0 0 0
2130 maxlevush 1 1 15
2182 isonar 0 0 0
SUM 16 13 9 138

KPI 7

  • KPIs: 11
  • Total Possible Rewards: $2625
  • Council Elected in Round: 9
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #781200 / 01.06.21
    • End Block/Date: #882000 / 08.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #925200

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 8 214297
515 l1dev 6 160723
635 xfactorus 37 991124
867 xandrell 87 2330481
1962 nkhlghbl 313 8384374
318 supunssw 12 321446
2039 doppelganger23 33 883976
321 freakstatic_council 141 3776987
957 leet_joy 39 1044698
439 fierydev 21 562530
4 nexusfallout 33 883976
2 tomato 636 17036620
2183 dapplooker 0 0
319 sparky 0 0
2130 maxlevush 198 5303854
1746 ogpetya 4 107149
SUM 16 1568 42002235

Paid out at block #934,190.

Notes

After having the KPI system operational for 5 weeks, we've had time to monitor the rewards, and have made some adjustments. Long story short:

  • Some of the KPIs that are always completed in full, that we suspect have been particularly well paid, will see small adjustments downward.
  • Some of the KPIs that has been repeatedly issued, but not completed, has been removed (to be made into a bounty), or will pay more.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 7th Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 4 16 8
515 l1dev 3 12 6
635 xfactorus 18 72 37
867 xandrell 18 72 37
1962 nkhlghbl 19 75 39
318 supunssw 6 24 12
2039 doppelganger23 16 64 33
321 freakstatic_council 19 81 42
957 leet_joy 17 76 39
439 fierydev 10 40 21
4 nexusfallout 16 64 33
2 tomato 18 82 43
2183 dapplooker 0 0 0
319 sparky 0 0 0
2130 maxlevush 18 84 44
1746 ogpetya 2 8 4
SUM 16 184 770 400

Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 2.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $250/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 50%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/197)
    • Council wrangling in #council channel - Yes

Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 15: $25/100 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty with this format, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 7th "official" Council on Babylon (#680400-#694800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #781200
    • End Block: #882000

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

Discord Channel Management

  • Reward: $50 Per Channel Group
    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    1. Governance
    • #council
    • #proposal
    • #bounties
    1. Newcomers
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups (1-3):
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Manage the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

As the runtime upgrade is completed, the Storage Provider will see a lot more load coming their way, as they are no longer only responsible for uploads, but also all playback and downloads.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. At an alarming frequency, uploads are failing. Ensure the Storage Lead finds out which SP(s) are the source of these failures, and takes appropriate actions depending on their findings.
  2. Ensure the Lead (and/or other SPs) are available and helpful in Discord and the forum
  3. Ensure the Storage Lead is doing frequent spotchecks, performs general "system health" checks, and asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  4. Ensure the lead delivers frequent reports of the matters above, and other agreed upon deliverables.
  5. Follow up (including performing some checks of their own) and sign off on the Leads reports.
  6. Ensure the Lead adjusts the workers rewards weekly (as the rate changes)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Manage the Content Curators Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

In no particular order:

  1. The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  1. Ensure the Lead adjusts the workers rewards weekly (as the rate changes)
  2. With the new content directory, the reporting requirements for the group and Lead should be revisited. See helpdesk for details.
  • The results, as agreed in a text proposal, should then be added to the Community Repo
  1. Follow up (including performing some checks of their own) and sign off on the Leads reports.
  2. Some issues have arisen after the sumer upgrade such as channel categories being missing, work with the Curator Lead to create a list of these issues and submit them on the Joystream GitHub repo: https://github.com/Joystream/joystream/issues
  3. New "helpers" for the content curators will be posted to the helpdesk some time the 2nd of June 2021. Ensure they learn to use these tools.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Manage the Operations Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Create an opening for the operations group Lead, with:
  • A non-trivial (role) stake, and a temporary reward (see 4 and 5).
  • Reasonable hiring criteria
  • Promote the opening on Discord and the forum, with estimates on workload and future reward
  • Hire the best candidate as Lead
  1. Agree on a scope of work for the Operations for this term. Some examples of long term tasks below:
  • Manage/maintain the api-examples in community repo
    • update when new types are issued (urgent)
    • eg. create new/better examples (high priority)
  • Technical bounties:
    • Act as BMs
    • Suggest new ones
    • Provide guidance and assistance?
    • Decide whether they (not the BM themselves ofc) can also apply/contribute?
  • Maintain (and pay for) some server infrastructure:
    • Backup servers (pioneer, API)
    • Leeching storage nodes (as backups when needed)
    • Provide API for getting data from "old" testnets
    • Non-critical/sensitive stuff created by the community (UNO)
    • Discord/telegram bots
    • Faucets (funds to be requested in spending props)
    • Deploy mirror of QN/Atlas?
  • Make minor (unsolicited and/or solicited) improvements to CLI and Pioneer
  • Manage #tech-support (Discord)
  • Offload Council?
  1. Agree on a standard for weekly reporting.
  • The results, as agreed in a text proposal, should then be added to the Community Repo
  1. Based on 2 and 3, decide on a new budget, with reasonable rewards for the Lead, and n workers to be hired during the term.
  2. Set a new reward for the Lead
  3. Follow up and sign off on the Leads reports.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 2 2 24
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 3 2 24
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 0 0 0
2 tomato 10 10 118
2183 dapplooker 0 0 0
319 sparky 0 0 0
2130 maxlevush 2 2 24
1746 ogpetya 0 0 0
SUM 16 17 16 188.23529411764704

Content Migration

  • Reward: $200
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

As KPI 6.11 wasn't fully completed, nor delivered on time, we have an unresolved problem with migrating videos and channels.

Scope of Work

Come up with a plan for getting all the "good" content uploaded to the previous testnet migrated.
This plan should consider:

  • Ideally, the owner performs all uploads themselves.
    • Provide incentives based on quality first and foremost, but quantity should also matter due to the workload for the owner.
  • When a plan has been discussed and approved, promote it both on Discord and the Forum.
  • The Council will be given a budget of $300 to compensate the owners/uploaders.

Note that Jsgenesis has a backup of the "old" content directory, and can, with inputs such as memberId, assist with:

  • getting the required content for screening and/or re-uploading
  • verifying interested parties did indeed have n channels/videos
  • other

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Antioch KPIs

Antioch KPIs can be found here!