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, 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 9

  • 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

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

Previous KPIs

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

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

NA

Antioch KPIs

Antioch KPIs can be found here!