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.

The "old" page was apparently too large for ghost to handle - the old page has been moved to https://blog.joystream.org/sumer-kpis-old/ :)

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

Current

KPI 40

  • KPIs: 11+5
  • Total Possible Rewards: $2050+$1030
  • Max Fiat Pool Difference: $10
  • Council Elected in Round: 42
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3992400 / 19.01.22
    • End Block/Date: #4093200 / 26.01.22
  • Deadline to Submit Summary: #4122000 / 28.01.22

Notes

Runtime upgrade incoming!

Section I - Council work, Proposals and Bureaucracy

40.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

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

40.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

40.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3999600
    • End Block: #4086000

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

40.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #4093200
    • End Block: #4208400

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.

Scope of Work

  1. The Council 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

40.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3999600
    • End Block: #4086000

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

No weighting will apply here*, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.
* If 6. isn't done within 12h of Term end, $50 will be forfeited.

Section II - Community Management

40.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #distributor
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

  1. we may perform spotchecks
  2. the manager can split the rewards across multiple CMs.

Grading

TBD

40.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3999600
    • End Block: #4086000

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

40.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #4093200
    • End Block: #4222800

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

TBD

Section III - Working Groups

40.III-1 - Follow up the Storage Working Group

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

Purpose

As Giza is going live at block #4124518 (this Friday ~19:30 GMT), we need to ensure the transition goes over as smoothly as possible!

Getting the storage system up and running is a critical task, that needs follow up.

Scope of Work

  1. Consider revising the budget. If reasonable and required, Jsgenesis will increase the recurring reward to bridge the gap until the new incentives are live. Keep in mind that:
  • The size of the content directory will go down a lot
  • Storage nodes will no longer be required to store ALL data
  • Storage nodes will no longer serve content, only receive, store and share with distributors
  • The Lead will need to learn a lot quickly
  • The Lead will have a fair amount of maintanance to do, after the above
  1. Monitor, and assist the Lead is performing their tasks in 40.SP-1 - Maintain Storage System.

Reward Distribution

1/2 $50

Grading

TBD

40.III-2 - Follow up the Distributor Working Group

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

Purpose

As Giza is going live at block #4124518 (this Friday ~19:30 GMT), we need to ensure the transition goes over as smoothly as possible!

Getting the storage and distribution system up and running is a critical task, that needs follow up.

Scope of Work

  1. Hire a Lead! Jsgenesis will make themselves Lead to get "started", but a new Lead must take our place within the end of the Term. (Remember to fire "us" before the "Fill Opening" proposal is approved). Note that the outcome of SoW 3 of KPI 40.DT-2 should be considered in choosing one!

  2. Set a budget for the group. If reasonable and required, Jsgenesis will increase the recurring reward to bridge the gap until the new incentives are live.
    Keep in mind that:

  • The size of the content directory will go down a lot
  • Distributor nodes does not need to store all data
  • Disitrubot nodes must have great bandwidht
  • The Lead will need to learn a lot quickly
  • The Lead will have a fair amount of maintanance to do
  1. Monitor, and assist the "test" Leads are performing their tasks in KPI 40.DT-2.

Reward Distribution

1-3: $50

Grading

TBD

Section IV - Bounties

40.IV-1 - Bounty Managers

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3992400
    • End Block: #4093200

Not clear if completed

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.

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

Some general information can be found here.

Scope of Work

  1. For all "Official" Jsgenesis created/endorsed bounties: what is the current status of the grading/payment? Is there an action on JSG?

  2. What is the status of Bounty 27? Note that OP isn't the offical text.

  3. What is the status of Bounty 21? We have heard whispers that it's completed, but would like to know more specifics.

Reward Distribution

Weighting:

  1. $20
  2. $40
  3. $40

Grading

TBD

Working Group KPIs

40.SP-1 - Maintain Storage System

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #3992400
    • End Block: #4194000

Purpose

As Giza is going live at block #4124518 (this Friday ~19:30 GMT), we need to ensure the transition goes over as smoothly as possible!

Scope of Work

  1. Ensure all the workers you want to continue in the role, prepares for the new system. This means:
  • After the upgrade, they can stop their old storage nodes
  • They can either use the current giza branch, OR wait until we merge to master (after the upgrade) to update their software
  • If they have very costly storage volumes, these can be downgraded. The amount of capacity needed can be derived from further tasks.
  1. If available, the Lead will need to perform a fair amount of transaction very quickly after the upgrade. This means you should have a built the giza branch, and be ready.

After the first bucket (operated by Jsgenesis) has been created, and the migration is "complete", the Lead will need to create buckets for the other workers. Then, there will be a lot of moving of bags and changing the configs to find a good balance.

  1. Every 24h after launch, Jsgenesis will check which SPs are up. We expect (excluding Worker ID 10):
  • 24h: > 40%
  • 48h: > 80%
  • 72h: > 100%
    • The Lead is free to fire to keep this ratio (firing 19 would be smart :D)

As soon as Atlas is "up", and migration is completed:

  1. Keep the amount of failed uploads below 10

  2. If an issue occurs that is blocking uploads, identify the problem and fix it within 2h. You may want to share the Leads role key with a delegated Worker whom you trust.

Jsgenesis will do spotchecks starting approximately 24h after lanch, and continuing throughout the term.

  1. Avoid having any asset at less than 2x replication (excluding the Jsgenesis operated node).

  2. Avoid having a single node being at more than...

  • 70% of capacity if "acceptingNewBags" = true
  • 85% of capacity if "acceptingNewBags" = false
    ...for more than 12h.

Grading

TBD

40.DT-2 - Maintain Distributor System

  • Reward: $600
  • Fiat Pool Factor: 0
    • Start Block: #3992400
    • End Block: #4194000

Purpose

As Giza is going live at block #4124518 (this Friday ~19:30 GMT), we need to ensure the transition goes over as smoothly as possible!

As there won't (yet) be a real Lead for the role, the three that seems to be the most interested and/or qualified will share the responsibilities. They will be given the role key of the Lead to make the transaction needed, once they have their nodes up and running.

Scope of Work

  1. Have all three nodes operational, and serving content within 24h of the release.

  2. After they're up, take screenshots of the contents of the directory you use to store the files, and:

  • ls -al
  • du -sh
    At least once every 24h.
  1. Plan how you would, if hired as the Lead, perform your hiring and configure the system knowing:
  • The budged from 40.III-2
    • How many workers?
    • Minimum hardware requirements?
  • Although not utilized right away, we want to spread out distribution across at multiple regions, to reduce latency. This is a large part of what will make this system great.
    • How many regions are reasonable given:
      • The amount of workers (ref budget)?
      • Where does the requests come from?
      • Where should the workers create their nodes?
      • What coverage and replication can be reached given all of this?
  • Which commands do you have to make to make your system the way you want?
  • Given the content directory at 12:00 GMT, this Sunday, create a spreadsheet outlining what bags are in which buckets, including the number of assets and total size of each bag. Include the bucketId (family:index) for each bucket.

This will be a hard one, but do your best!

Reward Distribution

For each of the three workers (they will not earn any rewards while Jsgenesis is the Lead):

  1. $25
  2. $25
  3. Up to $150 (high bar here)

Grading

TBD

40.OP-1 - Frontend Onboarding

  • Reward: $30
  • Fiat Pool Factor: 0
    • Start Block: #3992400
    • End Block: #4395600

Purpose

The purpose, and a loosely defined overview of tasks can be found here. This has not been created, or reviewed by the people writing this, so:

Scope of Work

  1. As far as we know, the Lead is starting the work. Pay is $30

Grading

TBD

40.OP-2 - Community Repo

  • Reward: $150
  • Fiat Pool Factor: 0
    • Start Block: #3992400
    • End Block: #4194000

Purpose

With a new runtime comes new types!

Scope of Work

  1. Fix all the examples in the community repo, with new types.

Grading

TBD

40.CC-1 - Finalizing Content Migration

  • Reward: $50
  • Fiat Pool Factor: 0
    • Start Block: #3992400
    • End Block: #4194000

Purpose

TBD

Previous KPIs

Section I - Council work, Proposals and Bureaucracy

39.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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

39.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

39.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

39.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3992400
    • End Block: #4107600

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.

Scope of Work

  1. The Council 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

39.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

No weighting will apply here*, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.
* If 6. isn't done within 12h of Term end, $50 will be forfeited.

Grading

TBD

Section II - Community Management

39.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

  1. we may perform spotchecks
  2. the manager can split the rewards across multiple CMs.

Grading

TBD

39.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

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

39.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3992400
    • End Block: #4122000

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

TBD

39.II-4 - Investigate Validators - Part II

  • Reward: $0
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

TBD
Part I has apparently been completed, but not yet graded. Assuming it goes well, AND we find time, this will be added.

39.II-5 - Content Migration for Giza

  • Reward: $150
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Real (:D) Final Call

Purpose

As the new storage system introduced for Giza also makes some smaller changes to the Content Directory, migration is manual. That means we need to find out what to migrate!

Hint: Using the query node playground will make your life easier.

Scope of Work

  1. Perform a review of all the channels, and sort them in a table, with the following information:
  • Channel: channelId, title, number of assets, size of all the assets (in GB)
  • Channel owner: memberId, memberHandle
  • Video stats: number of videos, [videoId]
    • does the channel have any censored or hidden videos? If yes - add notes.
      Finally, place them in one of three buckets:
  • Should be migrated (A)
  • May be worth migrating (B)
  • Shouldn't be migrated (C)
    • Regardless of why, a quick "one-liner" as to WHY you suggest this.
  1. Ask the owners if they want their channel migrated. Prioritize those in bucket (B).
    Update the table with the replies as: "yes/no/noreply,notIdentified"
    Include a link to the discord/forum post where they replied, and the discord handle of the owner (or tlgrm, etc. if that's where you reached them.)
    Note They will (still) be the owner of the channel, but the channelId/videoIds will change.

  2. When you are done, make sure the Curator Lead gets the sheet, so they can perform their KPI.

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

  1. $200 (assumes ALL channels )
  2. For each reply, link:
    A - $0.5
    B - $1.5
    C - $1

39.II-6 - User Friendly API Guides

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

This KPI is inspired by this "Create New KPIs" suggestion by @laura.

Purpose

In order to figure out a lot of things on our testnet, some usage of either:

  1. the chain state in Pioneer
  2. the Javascript console in Pioneer
  3. creating your own script in typescript, using our API

is needed. Although there is some tools for this in the Community Repo, it's not very well documented.

Scope of Work

  1. The Community Repo now looks great, but finding out and using the API is not straight forward. Consider renaming, and/or moving the "Scripts" directory. (eg. /joystream-api). The downside is that some people will try to make code PRs to /contributions, so not clear if this is best. In any event:
  • Add a small note in the main, eg. /README.md about how to find this section.
  • From the looks of the current setup, adding a new directory to the current /contributions/tech, will not build as intended, as the /contributions/tech/joystream-api is the root directory. Fix this!
  1. How to use the chain state in pioneer (including enabling it!) Examples:
  • Finding the balance of an account
  • Getting a membershipId from a membershipHandle and vice versa.
  • Getting the membershipRootAccount (and, if they differ the membershipControllerAccount) from either of the above, and vice versa.
  • How much a worker has staked by workerId.
  • More?
  1. How to use the Javascript in pioneer (including enabling it!) Examples:
  • Finding the balance of an account currently, and on block n
  • Finding the total issuance of an account currently, and on block n
  • How to get all balance changes for an account between block n and block m
  • More?
  1. Create a new README.md in the whatever path chosen above, equivalent to the current /contributions/tech, outlining:
  • How to use the API (similar to what is found here, but more n00b friendly).
  • How to create a new "Council Tokenomics" report step-by-step.
  • Add an example of how to get historical data.
  • How and where to ask for help!

Reward Distribution

1-3 $60 each
4 $120

Grading

TBD

Section III - Working Groups

Section IV - Bounties

39.IV-1 - Bounty Managers

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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.

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

Some general information can be found here.

Scope of Work

  1. For all "Official" Jsgenesis created/endorsed bounties: what is the current status of the grading/payment? Is there an action on JSG?

  2. What is the status of Bounty 27? Note that OP isn't the offical text.

  3. What is the status of Bounty 21? We have heard whispers that it's completed, but would like to know more specifics.

Reward Distribution

Weighting:

  1. $20
  2. $40
  3. $40

Grading

TBD

Working Group KPIs

39.CC-1 - Content Migration

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #3891600
    • End Block: #4194000

Purpose

Once KPI 38.II-6 is completed, we need to make sure we're not migrating any bad files.

Scope of Work

  1. Review all videos in bucket A, B and whatever channels in bucket C that the channel owner wants to migrate.
  • If you find a video in clear violation of the ToS - censor, and ask the user to delete the video if they want to have their channel migrated. Log the channelId and videoId, and the reason for your action (to the table).
  • If you find videos that are simply distasteful, add a note of the channelId and videoId (to the table), and why.
  • If you find channels that are pure copypasta from YT, especially if not all YT videos have the correct license, add a note of the channelId and videoId (to the table), and why.

Grading

TBD

Grading

TBD

39.SP-1 - Content Directory Status

  • Reward: $100
  • Fiat Pool Factor: 0.2
    • Start Block: #3862800
    • End Block: #4093200

Purpose

Perform a quick check of the current content directory, and storage usage.

Hint: Requires using the query node playground.

Scope of Work

  1. How many assets have been uploaded?
  2. What is the current size of the content directory, considering:
  • all uploads, no filtering
  • all uploads that was accepted by the liaison
  • same as above, but remove duplicate ipfsContentId (they are only stored once in IPFS)
  • how much is the ipfs repo storing for each of the SPs?
  1. What is the reason for the discrepancies?

Grading

TBD

39.OP-1 - Frontend Onboarding

  • Reward: $30
  • Fiat Pool Factor: 0
    • Start Block: #3891600
    • End Block: #4294800

Purpose

The purpose, and a loosely defined overview of tasks can be found here. This has not been created, or reviewed by the people writing this, so:

Scope of Work

  1. The Lead, or a delegate of their choosing, review the issue, and:
  • Create a shortlist of the information required
  • Create a rough list of tasks
    • Reply in the issue with these.
  • Create a list of the workers in the OPS group that has the skillset, and the interest (assuming $30/h) to contribute
    • Once done, share the results with Martin and Robert in Discord :)
  1. Once we have solved the outstanding in 1. start working!

Grading

TBD

KPI 38

  • KPIs: 17+3
  • Total Possible Rewards: $3025+$325
  • Max Fiat Pool Difference: $442.5
  • Council Elected in Round: 40
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3891600 / 05.01.22
    • End Block/Date: #3992400 / 12.01.22
  • Deadline to Submit Summary: #4021200 / 14.01.22

Notes

We are targeting the runtime upgrade to occur on the 12th or 13th next week ~1500 CET.
Unfortunately, the new incentives will not go live right away, so the current council size etc. will stick around a couple of weeks more...

Section I - Council work, Proposals and Bureaucracy

38.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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

38.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

38.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

38.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3992400
    • End Block: #4107600

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.

Scope of Work

  1. The Council 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

38.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

No weighting will apply here*, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.
* If 6. isn't done within 12h of Term end, $50 will be forfeited.

Grading

TBD

Section II - Community Management

38.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

  1. we may perform spotchecks
  2. the manager can split the rewards across multiple CMs.

Grading

TBD

38.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

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

38.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3992400
    • End Block: #4122000

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

38.II-4 - Investigate Validators - Part I

  • Reward: $375
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

Still not clear if (fully) done
Final Call

Purpose

The network still suffers from increased blocktime which increases term lengths and reduces the salary of all workers (less blocks per era). To fix this we need to take a closer look at under-performing validators.

Note Based on proposal #881.

Scope of Work

  1. Use https://telemetry.joystream.org/#/Joystream and create list of nodes that over a longer period are stuck (blocktime does not increase) have a non-zero transactions in Queue or infinite Block Propagation Time. Ignore syncing nodes. Update every other day.

  2. Try and contact as many validators as possible, and ask them to log to the telemetry server. This will make it easier to compare, as the Validator key here can be used to figure out which validator it is. Currently, there are only 17. For each new Validator showing a key, a reward of USD 1 is added (only actual validators will count).

  3. Try to contact their operators and ask to to restart the node and check logs for suspicious messages that could indicate possible reasons a node gets stuck (research on the substrate issue tracker could reveal known software issues). Use the member handle from the node name and possible other means to get in touch with operators (preferably in private) and create a table with following fields for all nodes:

    • node name / member (with pioneer link)
    • discord handle
    • controller key
    • CPU
    • RAM
    • Location
    • Version
    • Available Space
    • Costs (per month)
      For each node, a reward of USD 1 is added (capped at $100)
  4. Go through the last 14 days, eg. 201600 blocks (the history depth), and get the following data for each block:

    • Which validator signed the block n
    • What was the timestamped difference between block n and the previous block (n-1).
      • Who found the previous block.
    • What was the timestamped difference between block n and the next block (n+1).
      • Who found the next block.
  5. Use the data to get the following:

    • For each block producer, get the average timestamp difference. This should be four separate numbers:
      • timestamp difference between n-1 and n, including blocks that are over 12s later.
      • timestamp difference between n-1 and n, NOT including blocks that are over 12s later.
      • timestamp difference between n and n+1, including blocks that are over 12s later.
      • timestamp difference between n and n+1, NOT including blocks that are over 12s later.
        • Does this imply that a "slow" validator adds a delay for the block they found (n-1 to n), or do they delay the next block (n, n+1)? Does it change for blocktimes over 12s?
    • Look at the 1% slowest blocktimes under 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
    • Look at all the blocktimes over 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
      • Need to look at the relative numbers for these, as a validator that has found 2000 blocks SHOULD have more in both categories than one that has found 200.

Reward Distribution

  1. $50
  2. $100
  3. $100
  4. $50
  5. $75

Grading

TBD

38.II-5 - Investigate Validators - Part II

  • Reward: $0
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

TBD
Awaiting results of Part I

38.II-6 - Content Migration for Giza

  • Reward: $150
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: First 5 Days
    • Start Block: #3963600
    • End Block: 4035600

Final Call

Purpose

As the new storage system introduced for Giza also makes some smaller changes to the Content Directory, migration is manual. That means we need to find out what to migrate!

Hint: Using the query node playground will make your life easier.

Scope of Work

  1. Perform a review of all the channels, and sort them in a table, with the following information:
  • Channel: channelId, title, number of assets, size of all the assets (in GB)
  • Channel owner: memberId, memberHandle
  • Video stats: number of videos, [videoId]
    • does the channel have any censored or hidden videos? If yes - add notes.
      Finally, place them in one of three buckets:
  • Should be migrated (A)
  • May be worth migrating (B)
  • Shouldn't be migrated (C)
    • Regardless of why, a quick "one-liner" as to WHY you suggest this.
  1. Ask the owners if they want their channel migrated. Prioritize those in bucket (B).
    Update the table with the replies as: "yes/no/noreply,notIdentified"
    Include a link to the discord/forum post where they replied, and the discord handle of the owner (or tlgrm, etc. if that's where you reached them.)
    Note They will (still) be the owner of the channel, but the channelId/videoIds will change.

  2. When you are done, make sure the Curator Lead gets the sheet, so they can perform their KPI.

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

  1. $200 (assumes ALL channels )
  2. For each reply, link:
    A - $0.5
    B - $1.5
    C - $1

38.II-7 - User Friendly API Guides

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3898800
    • End Block: #3985200

This KPI is inspired by this "Create New KPIs" suggestion by @laura.

Purpose

In order to figure out a lot of things on our testnet, some usage of either:

  1. the chain state in Pioneer
  2. the Javascript console in Pioneer
  3. creating your own script in typescript, using our API

is needed. Although there is some tools for this in the Community Repo, it's not very well documented.

Scope of Work

  1. The Community Repo now looks great, but finding out and using the API is not straight forward. Consider renaming, and/or moving the "Scripts" directory. (eg. /joystream-api). The downside is that some people will try to make code PRs to /contributions, so not clear if this is best. In any event:
  • Add a small note in the main, eg. /README.md about how to find this section.
  • From the looks of the current setup, adding a new directory to the current /contributions/tech, will not build as intended, as the /contributions/tech/joystream-api is the root directory. Fix this!
  1. How to use the chain state in pioneer (including enabling it!) Examples:
  • Finding the balance of an account
  • Getting a membershipId from a membershipHandle and vice versa.
  • Getting the membershipRootAccount (and, if they differ the membershipControllerAccount) from either of the above, and vice versa.
  • How much a worker has staked by workerId.
  • More?
  1. How to use the Javascript in pioneer (including enabling it!) Examples:
  • Finding the balance of an account currently, and on block n
  • Finding the total issuance of an account currently, and on block n
  • How to get all balance changes for an account between block n and block m
  • More?
  1. Create a new README.md in the whatever path chosen above, equivalent to the current /contributions/tech, outlining:
  • How to use the API (similar to what is found here, but more n00b friendly).
  • How to create a new "Council Tokenomics" report step-by-step.
  • Add an example of how to get historical data.
  • How and where to ask for help!

Reward Distribution

1-3 $60 each
4 $120

Grading

TBD

Section III - Working Groups

38.III-1 - New Working Groups

  • Reward: $200
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: First 5 Days
    • Start Block: #3963600
    • End Block: 4035600

Purpose

We are targeting the upgrade on the 12th or 13th of January, so we need to prepare! This will require a lot of collaboration.

Three new Working Groups will be created:

  1. Operations Beta - focusing on Marketing efforts.
  2. Operations Gamma - focusing on Bounties, and welcoming new community members
  3. Distribution - responsible for distributing the content on the new network

For 1. and 2. there will be somewhat of a delayed start due to the new incentives being delayed.
For 3. we need to fill up this one ASAP after launch. Skills needed:

  • Devops
  • Using the CLI
  • High availability
  • Quick to learn
  • Experience being an SP is a major bonus.

Note that although we won't ban it outright, being the Lead of a group AND a CM going forward should be avoided. As there will only be 5 slots for the Council, this should be easy to manage.

Scope of Work

  1. For each of these roles, start "looking" for someone interested in, and qualified to, taking them.
  2. For the Distribution Lead:
    At launch, we will hire ourselves through Sudo, to ensure we can get a decent start. Finding a new Lead should be started ASAP after launch. Any strong candidates for the job will be hired as workers in the meantime, meaning:
  • Give us the memberId/memberHandle and Discord contact info for all interested, alongside a TL;DR of their "informal" applications.

Reward Distribution

Weighting:

  1. $150 ($50 for each)
  2. $50

Grading

TBD

38.III-2 - Existing Working Groups - Storage

  • Reward: $80
  • Fiat Pool Factor: 1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: First 5 Days
    • Start Block: #3963600
    • End Block: 4035600

Purpose

We are targeting the upgrade on the 12th or 13th of January, so we need to prepare! This will require a lot of collaboration.

Scope of Work

  1. Answer:
  • How long has the currently sitting Lead been the Lead of the Group?
  • Does the Council want to keep status quo, knowing that the scope will change MATERIALLY, and the Lead will need to understand, and/or monitor the network a lot more?
  • Does the Lead want to continue knowing that they need to work a lot more, and failure to pay attention may cause some (short term) downtime?
  1. After going live, we have three options for how to get ready. Choose one of:
    1. The current Storage Lead makes themselves available, and we provide the commands to make and when. This will likely be around ~15:00 CET of said day.
    1. We fire the Lead, and place ourselves as the Lead for a couple of hours, to get everything set up. In the meantime (eg. starting now), the Council, creates a new opening for the Lead, so that the final "Fill opening proposal" can be made after said hour.
    1. We use sudoAs to pretend being the Lead, and do the basic tasks ourselves. This is the worst outcome, but we will have to use it in case of option 1, without the Lead actually showing up.
  1. As there will be some interim period before the new incentives are set, set a reasonable reward for the Lead, knowing that they will likely have to work a fair amount.

Reward Distribution

Weighting:

  1. $30
  2. $20
  3. $30
    Reward is paid to the CM creating the first approved proposal.

Grading

TBD

38.III-3 - Existing Working Groups - Curators

  • Reward: $60
  • Fiat Pool Factor: 1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: First 5 Days
    • Start Block: #3963600
    • End Block: 4035600

Purpose

We are targeting the upgrade on the 12th or 13th of January, so we need to prepare! This will require a lot of collaboration.

Scope of Work

  1. Answer:
  • How long has the currently sitting Lead been the Lead of the Group?
  • Does the Council want to keep status quo, knowing that the scope will change, and the Lead will spend more time managing others?
  • Does the Lead want to continue knowing that they will be required to work more, and spend more time managing others?
  1. As there will be some interim period before the new incentives are set, set a reasonable reward for the Lead, knowing that they will likely have to work a little more.

Reward Distribution

Weighting:

  1. $30
  2. $30
    Reward is paid to the CM creating the first approved proposal.

Grading

TBD

38.III-4 - Existing Working Groups - Operations

  • Reward: $60
  • Fiat Pool Factor: 1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: First 5 Days
    • Start Block: #3963600
    • End Block: 4035600

Purpose

We are targeting the upgrade on the 12th or 13th of January, so we need to prepare! This will require a lot of collaboration.

Scope of Work

  1. Answer:
  • How long has the currently sitting Lead been the Lead of the Group?
  • Does the Council want to keep status quo, knowing that the scope will change, and the Lead will spend more time managing others?
  • Does the Lead want to continue knowing that they will be required to work more, and spend more time managing others?
  1. As there will be some interim period before the new incentives are set, set a reasonable reward for the Lead, knowing that they will likely have to work a little more.

Reward Distribution

Weighting:

  1. $30
  2. $30
    Reward is paid to the CM creating the first approved proposal.

Grading

TBD

Section IV - Bounties

38.IV-1 - Bounty Managers

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3891600
    • End Block: #3992400

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.

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

Some general information can be found here.

Scope of Work

  1. For all "Official" Jsgenesis created/endorsed bounties: what is the current status of the grading/payment? Is there an action on JSG?

  2. What is the status of Bounty 27? Note that OP isn't the offical text.

  3. What is the status of Bounty 21? We have heard whispers that it's completed, but would like to know more specifics.

Reward Distribution

Weighting:

  1. $20
  2. $40
  3. $40

Grading

TBD

Working Group KPIs

38.CC-1 - Content Migration

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #3891600
    • End Block: #4194000

Purpose

Once KPI 38.II-6 is completed, we need to make sure we're not migrating any bad files.

Scope of Work

  1. Review all videos in bucket A, B and whatever channels in bucket C that the channel owner wants to migrate.
  • If you find a video in clear violation of the ToS - censor, and ask the user to delete the video if they want to have their channel migrated. Log the channelId and videoId, and the reason for your action (to the table).
  • If you find videos that are simply distasteful, add a note of the channelId and videoId (to the table), and why.
  • If you find channels that are pure copypasta from YT, especially if not all YT videos have the correct license, add a note of the channelId and videoId (to the table), and why.

Grading

TBD

Grading

TBD

38.SP-1 - Content Directory Status

  • Reward: $100
  • Fiat Pool Factor: 0.2
    • Start Block: #3862800
    • End Block: #4093200

Purpose

Perform a quick check of the current content directory, and storage usage.

Hint: Requires using the query node playground.

Scope of Work

  1. How many assets have been uploaded?
  2. What is the current size of the content directory, considering:
  • all uploads, no filtering
  • all uploads that was accepted by the liaison
  • same as above, but remove duplicate ipfsContentId (they are only stored once in IPFS)
  • how much is the ipfs repo storing for each of the SPs?
  1. What is the reason for the discrepancies?

Grading

TBD

38.OP-1 - Giza Testing - Final Round

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3891600
    • End Block: #4093200

Note
We will finish this soon finally :)

Purpose

Ensure the new network works!
$25/h

Grading

TBD

KPI 37

  • KPIs: 11+6
  • Total Possible Rewards: $2225+$550
  • Max Fiat Pool Difference: $92.5
  • Council Elected in Round: 38
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3690000 / 29.12.21
    • End Block/Date: #3790800 / 05.01.22
  • Deadline to Submit Summary: #3819600 / 07.01.22

Notes

Once again, we're publishing a somewhat uninspired set of KPIs. Reasons:

  • targeting a new release early January
  • holiday season
  • new incentives in pipeline

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 117 4661735
644 lkskrn 4 159376
2141 plycho 6 239063
635 xfactorus 15 597658
1843 spat_sochi 7 278907
2531 nanapa6otaet 6 239063
1962 nkhlghbl 9 358595
957 leet_joy 104 4143764
1345 kadyrovs 113 4502359
2462 chiffah 14 557814
2 tomato 308 12271918
2137 kalpakci 4 159376
2174 alekjoy 13 517971
2329 laura 340 13546922
2836 art_khabibullin 8 318751
1048 igrex 118 4701579
2435 zazik 132 5259393
2148 controlla 4 159376
513 kriptos 16 637502
2182 isonar 31 1235161
SUM 20 2019 54546283

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
3029 oxygen 125 4980486
515 l1dev 525 20918041

Payouts done on blocks #4,036,196 & 4,036,197.

Fiat pool growth: -$22.5.

Section I - Council work, Proposals and Bureaucracy

37.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

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
2194 ilich 24 93 17
644 lkskrn 6 24 4
2141 plycho 9 35 6
635 xfactorus 21 80 15
1843 spat_sochi 8 36 7
2531 nanapa6otaet 8 32 6
1962 nkhlghbl 13 49 9
957 leet_joy 5 20 4
1345 kadyrovs 17 68 13
2462 chiffah 19 75 14
2 tomato 12 45 8
2137 kalpakci 7 22 4
2174 alekjoy 18 68 13
2329 laura 20 79 15
2836 art_khabibullin 11 44 8
1048 igrex 21 99 18
2435 zazik 18 65 12
2148 controlla 6 24 4
513 kriptos 24 89 16
2182 isonar 9 33 6
SUM 20 276 1080 200

37.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

37.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

37.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3790800
    • End Block: #3906000

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.

Scope of Work

  1. The Council 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

37.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

Section II - Community Management

37.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

37.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

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

  • No work submitted, no rewards.

37.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3790800
    • End Block: #3920400

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

37.II-4 - Investigate Validators - Part I

  • Reward: $375
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Still not clear if (fully) done

Purpose

The network still suffers from increased blocktime which increases term lengths and reduces the salary of all workers (less blocks per era). To fix this we need to take a closer look at under-performing validators.

Note Based on proposal #881.

Scope of Work

  1. Use https://telemetry.joystream.org/#/Joystream and create list of nodes that over a longer period are stuck (blocktime does not increase) have a non-zero transactions in Queue or infinite Block Propagation Time. Ignore syncing nodes. Update every other day.

  2. Try and contact as many validators as possible, and ask them to log to the telemetry server. This will make it easier to compare, as the Validator key here can be used to figure out which validator it is. Currently, there are only 17. For each new Validator showing a key, a reward of USD 1 is added (only actual validators will count).

  3. Try to contact their operators and ask to to restart the node and check logs for suspicious messages that could indicate possible reasons a node gets stuck (research on the substrate issue tracker could reveal known software issues). Use the member handle from the node name and possible other means to get in touch with operators (preferably in private) and create a table with following fields for all nodes:

    • node name / member (with pioneer link)
    • discord handle
    • controller key
    • CPU
    • RAM
    • Location
    • Version
    • Available Space
    • Costs (per month)
      For each node, a reward of USD 1 is added (capped at $100)
  4. Go through the last 14 days, eg. 201600 blocks (the history depth), and get the following data for each block:

    • Which validator signed the block n
    • What was the timestamped difference between block n and the previous block (n-1).
      • Who found the previous block.
    • What was the timestamped difference between block n and the next block (n+1).
      • Who found the next block.
  5. Use the data to get the following:

    • For each block producer, get the average timestamp difference. This should be four separate numbers:
      • timestamp difference between n-1 and n, including blocks that are over 12s later.
      • timestamp difference between n-1 and n, NOT including blocks that are over 12s later.
      • timestamp difference between n and n+1, including blocks that are over 12s later.
      • timestamp difference between n and n+1, NOT including blocks that are over 12s later.
        • Does this imply that a "slow" validator adds a delay for the block they found (n-1 to n), or do they delay the next block (n, n+1)? Does it change for blocktimes over 12s?
    • Look at the 1% slowest blocktimes under 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
    • Look at all the blocktimes over 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
      • Need to look at the relative numbers for these, as a validator that has found 2000 blocks SHOULD have more in both categories than one that has found 200.

Reward Distribution

  1. $50
  2. $100
  3. $100
  4. $50
  5. $75

Grading

  • No work submitted, no rewards.

37.II-5 - Investigate Validators - Part II

  • Reward: $0
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

TBD
Awaiting results of Part I

37.II-6 - Content Migration for Giza

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Purpose

As the new storage system introduced for Giza also makes some smaller changes to the Content Directory, migration is manual. That means we need to find out what to migrate!

Hint: Using the query node playground will make your life easier.

Scope of Work

  1. Perform a review of all the channels, and sort them in a table, with the following information:
  • Channel: channelId, title, number of assets, size of all the assets (in GB)
  • Channel owner: memberId, memberHandle
  • Video stats: number of videos, [videoId]
    • does the channel have any censored or hidden videos? If yes - add notes.
      Finally, place them in one of three buckets:
  • Should be migrated (A)
  • May be worth migrating (B)
  • Shouldn't be migrated (C)
    • Regardless of why, a quick "one-liner" as to WHY you suggest this.
  1. Ask the owners if they want their channel migrated. Prioritize those in bucket (B).
    Update the table with the replies as: "yes/no/noreply,notIdentified"
    Include a link to the discord/forum post where they replied, and the discord handle of the owner (or tlgrm, etc. if that's where you reached them.)
    Note They will (still) be the owner of the channel, but the channelId/videoIds will change.

  2. When you are done, make sure the Curator Lead gets the sheet, so they can perform their KPI.

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

  1. $200 (assumes ALL channels )
  2. For each reply, link:
    A - $0.5
    B - $1.5
    C - $1

Grading

  • No work submitted, no rewards.

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

37.CC-1 - Update Featured Categories

  • Reward: $75
  • Fiat Pool Factor: 0.2
    • Start Block: #3661200
    • End Block: #3891600

Purpose

Scope of Work

Reward Distribution

Grading

37.CC-2 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3661200
    • End Block: #3891600

Purpose

Scope of Work

Reward Distribution

Grading

37.CC-3 - Content Migration

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #3690000
    • End Block: #3992400

Purpose

Once KPI 37.II-6 is completed, we need to make sure we're not migrating any bad files.

Scope of Work

  1. Review all videos in bucket A, B and whatever channels in bucket C that the channel owner wants to migrate.
  • If you find a video in clear violation of the ToS - censor, and ask the user to delete the video if they want to have their channel migrated. Log the channelId and videoId, and the reason for your action (to the table).
  • If you find videos that are simply distasteful, add a note of the channelId and videoId (to the table), and why.
  • If you find channels that are pure copypasta from YT, especially if not all YT videos have the correct license, add a note of the channelId and videoId (to the table), and why.

Grading

  • No work submitted, no rewards.

37.SP-1 - Content Directory Status

  • Reward: $100
  • Fiat Pool Factor: 0.2
    • Start Block: #3661200
    • End Block: #3891600

Purpose

Perform a quick check of the current content directory, and storage usage.

Hint: Requires using the query node playground.

Scope of Work

  1. How many assets have been uploaded?
  2. What is the current size of the content directory, considering:
  • all uploads, no filtering
  • all uploads that was accepted by the liaison
  • same as above, but remove duplicate ipfsContentId (they are only stored once in IPFS)
  • how much is the ipfs repo storing for each of the SPs?
  1. What is the reason for the discrepancies?

Grading

  • No work submitted, no rewards.

37.OP-1 - Giza Testing - restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3589200
    • End Block: #3891600

Note
Will finally start again tomorrow!
Need two people that are available the next few days

Purpose

Ensure the new network works!

Scope of Work

  1. New testing notes/setup published tomorrow ~1500 CET.

Grading

36.II-6
Incomplete grading last week, adding:

KPI 36

  • KPIs: 11+3
  • Total Possible Rewards: $2575+$150
  • Max Fiat Pool Difference: $72.5
  • Council Elected in Round: 37
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3690000 / 22.12.21
    • End Block/Date: #3790800 / 29.12.21
  • Deadline to Submit Summary: #3819600 / 31.12.21

Notes

Again, we're publishing a somewhat uninspired set of KPIs. Reasons:

  • targeting a new release early January
  • holiday season
  • new incentives in pipeline

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 40 1570862
644 lkskrn 5 196358
2141 plycho 3 117815
1843 spat_sochi 109 4280598
2531 nanapa6otaet 127 4987485
1962 nkhlghbl 9 353444
957 leet_joy 85 3338081
3029 oxygen 86 3377352
1345 kadyrovs 11 431987
2 tomato 331 12998879
2137 kalpakci 1 39272
1997 marinag_mary 8 314172
2329 laura 190 7461592
2836 art_khabibullin 211 8286295
790 ururu 11 431987
319 sparky 0 0
1048 igrex 118 4634041
2435 zazik 165 6479804
2182 isonar 13 510530
2154 marat_mu 361 14177025
SUM 20 1966 73987579

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
3029 oxygen 82 3220266

Paid out on blocks #3,877,769 and #3,87 7,770.

Fiat pool factor +$17.55.

Section I - Council work, Proposals and Bureaucracy

36.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

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
2194 ilich 28 84 15
644 lkskrn 11 29 5
2141 plycho 8 17 3
1843 spat_sochi 24 80 14
2531 nanapa6otaet 13 40 7
1962 nkhlghbl 14 52 9
957 leet_joy 14 56 10
3029 oxygen 22 89 16
1345 kadyrovs 22 60 11
2 tomato 9 32 6
2137 kalpakci 2 8 1
1997 marinag_mary 15 48 8
2329 laura 28 87 15
2836 art_khabibullin 19 64 11
790 ururu 17 65 11
319 sparky 0 0 0
1048 igrex 28 102 18
2435 zazik 26 88 15
2182 isonar 22 71 13
2154 marat_mu 17 64 11
SUM 20 339 1136 200

36.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

36.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

36.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3790800
    • End Block: #3906000

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.

Scope of Work

  1. The Council 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

36.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

Section II - Community Management

36.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3690000
    • End Block: #3790800

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

36.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

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

36.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3790800
    • End Block: #3920400

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

36.II-4 - Investigate Validators - Part I

  • Reward: $375
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Not clear if done

Purpose

The network still suffers from increased blocktime which increases term lengths and reduces the salary of all workers (less blocks per era). To fix this we need to take a closer look at under-performing validators.

Note Based on proposal #881.

Scope of Work

  1. Use https://telemetry.joystream.org/#/Joystream and create list of nodes that over a longer period are stuck (blocktime does not increase) have a non-zero transactions in Queue or infinite Block Propagation Time. Ignore syncing nodes. Update every other day.

  2. Try and contact as many validators as possible, and ask them to log to the telemetry server. This will make it easier to compare, as the Validator key here can be used to figure out which validator it is. Currently, there are only 17. For each new Validator showing a key, a reward of USD 1 is added (only actual validators will count).

  3. Try to contact their operators and ask to to restart the node and check logs for suspicious messages that could indicate possible reasons a node gets stuck (research on the substrate issue tracker could reveal known software issues). Use the member handle from the node name and possible other means to get in touch with operators (preferably in private) and create a table with following fields for all nodes:

    • node name / member (with pioneer link)
    • discord handle
    • controller key
    • CPU
    • RAM
    • Location
    • Version
    • Available Space
    • Costs (per month)
      For each node, a reward of USD 1 is added (capped at $100)
  4. Go through the last 14 days, eg. 201600 blocks (the history depth), and get the following data for each block:

    • Which validator signed the block n
    • What was the timestamped difference between block n and the previous block (n-1).
      • Who found the previous block.
    • What was the timestamped difference between block n and the next block (n+1).
      • Who found the next block.
  5. Use the data to get the following:

    • For each block producer, get the average timestamp difference. This should be four separate numbers:
      • timestamp difference between n-1 and n, including blocks that are over 12s later.
      • timestamp difference between n-1 and n, NOT including blocks that are over 12s later.
      • timestamp difference between n and n+1, including blocks that are over 12s later.
      • timestamp difference between n and n+1, NOT including blocks that are over 12s later.
        • Does this imply that a "slow" validator adds a delay for the block they found (n-1 to n), or do they delay the next block (n, n+1)? Does it change for blocktimes over 12s?
    • Look at the 1% slowest blocktimes under 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
    • Look at all the blocktimes over 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
      • Need to look at the relative numbers for these, as a validator that has found 2000 blocks SHOULD have more in both categories than one that has found 200.

Reward Distribution

  1. $50
  2. $100
  3. $100
  4. $50
  5. $75

Grading

36.II-5 - Investigate Validators - Part II

  • Reward: $0
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

TBD
Awaiting results of Part I

36.II-6 - Community Cohesion

  • Reward: $25*20
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3697200
    • End Block: #3783600

Open for all CMs

Purpose

There's been a of infighting lately.
Although one has to expect this as a project grows, it seems valuable to see if there is some overarching reason why it's happening.

Scope of Work

  1. Without referring to any users, or any specific* arguments, outline what you think may be a/the reason why their appears to be more "disagreements".
    We're not interested in person A or topic B, but what has happened lately that may have spurred this.

* We're not looking for reasons of specific arguments/topics/users. Instead, has something happened, not happened or changed, such as:
Examples:

  • Less KPIs, not as much to do
  • Release delayed for a while. Current network has gotten "stale", not enough too sink teeth in to
  • Different visions for mainnet

Reward Distribution

Up to $25 for each contribution. Open for all CMs.
Any references to specific topics or users, even if implicit, will return 0 reward.

Grading

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

36.CC-1 - Update Featured Categories

  • Reward: $75
  • Fiat Pool Factor: 0.2
    • Start Block: #3661200
    • End Block: #3891600

Purpose

We want to change these every day!

Scope of Work

  1. Make changes every day, and provide screenshots to prove it!

Grading

36.CC-2 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3661200
    • End Block: #3891600

Purpose

We want to change these every day!

Scope of Work

  1. Make changes every day, and provide screenshots to prove it!

Grading

TBD

36.OP-1 - Giza Testing - restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3589200
    • End Block: #3891600

Note
A new chain will be started today, meaning I have stopped the instances of joystream-node running on testers machines. It will be upgraded today or tomorrow, opening up for testing to finally continue, but possible not until ~Monday

Purpose

Ensure the new network works!

Scope of Work

New testing notes/setup TBD.

Grading

NA

KPI 35

  • KPIs: 11+5
  • Total Possible Rewards: $2400+$500
  • Max Fiat Pool Difference: $57.5
  • Council Elected in Round: 37
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3589200 / 15.12.21
    • End Block/Date: #3690000 / 22.12.21
  • Deadline to Submit Summary: #3718800 / 24.12.21

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 15 558223
644 lkskrn 8 297719
361 blackmass 6 223289
2141 joyval 0 0
515 l1dev 329 12243695
635 xfactorus 11 409364
2096 svasilenko 12 446579
2531 nanapa6otaet 13 483793
321 freakstatic_council 8 297719
957 leet_joy 110 4093636
3029 oxygen 12 446579
2 tomato 308 11462182
2137 kalpakci 0 0
1997 marinag_mary 157 5842736
2329 laura 199 7405761
2836 art_khabibullin 8 297719
1048 igrex 117 4354141
2435 zazik 14 521008
2148 controlla 9 334934
2154 marat_mu 9 334934
SUM 20 1595 50054011

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 250 9303719

Payouts made on blocks #3,784,223.

The fiat pool shrank by $12.45.

Section I - Council work, Proposals and Bureaucracy

35.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3589200
    • End Block: #3690000

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
2194 ilich 20 74 15
644 lkskrn 13 42 8
361 blackmass 9 30 6
2141 joyval 2 2 0
515 l1dev 18 79 16
635 xfactorus 17 56 11
2096 svasilenko 18 63 12
2531 nanapa6otaet 19 64 13
321 freakstatic_council 13 43 8
957 leet_joy 16 52 10
3029 oxygen 17 61 12
2 tomato 13 42 8
2137 kalpakci 0 0 0
1997 marinag_mary 10 37 7
2329 laura 19 84 16
2836 art_khabibullin 11 40 8
1048 igrex 23 85 17
2435 zazik 20 73 14
2148 controlla 12 45 9
2154 marat_mu 14 47 9
SUM 20 284 1019 200

35.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3589200
    • End Block: #3690000

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

35.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3596400
    • End Block: #3682800

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

35.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3690000
    • End Block: #3805200

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.

Scope of Work

  1. The Council 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

35.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3596400
    • End Block: #3682800

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.
  6. Go through the Discord channels, and award the best contributor(s) the Discord Channel Management reward.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

Section II - Community Management

35.II-1 - Discord Channel Management

  • Reward: $100
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3589200
    • End Block: #3690000

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. 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!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

35.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3596400
    • End Block: #3682800

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

35.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3690000
    • End Block: #3819600

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

35.II-4 - Investigate Validators - Part I

  • Reward: $375
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3596400
    • End Block: #3682800

Purpose

The network still suffers from increased blocktime which increases term lengths and reduces the salary of all workers (less blocks per era). To fix this we need to take a closer look at under-performing validators.

Note Based on proposal #881.

Scope of Work

  1. Use https://telemetry.joystream.org/#/Joystream and create list of nodes that over a longer period are stuck (blocktime does not increase) have a non-zero transactions in Queue or infinite Block Propagation Time. Ignore syncing nodes. Update every other day.

  2. Try and contact as many validators as possible, and ask them to log to the telemetry server. This will make it easier to compare, as the Validator key here can be used to figure out which validator it is. Currently, there are only 17. For each new Validator showing a key, a reward of USD 1 is added (only actual validators will count).

  3. Try to contact their operators and ask to to restart the node and check logs for suspicious messages that could indicate possible reasons a node gets stuck (research on the substrate issue tracker could reveal known software issues). Use the member handle from the node name and possible other means to get in touch with operators (preferably in private) and create a table with following fields for all nodes:

    • node name / member (with pioneer link)
    • discord handle
    • controller key
    • CPU
    • RAM
    • Location
    • Version
    • Available Space
    • Costs (per month)
      For each node, a reward of USD 1 is added (capped at $100)
  4. Go through the last 14 days, eg. 201600 blocks (the history depth), and get the following data for each block:

    • Which validator signed the block n
    • What was the timestamped difference between block n and the previous block (n-1).
      • Who found the previous block.
    • What was the timestamped difference between block n and the next block (n+1).
      • Who found the next block.
  5. Use the data to get the following:

    • For each block producer, get the average timestamp difference. This should be four separate numbers:
      • timestamp difference between n-1 and n, including blocks that are over 12s later.
      • timestamp difference between n-1 and n, NOT including blocks that are over 12s later.
      • timestamp difference between n and n+1, including blocks that are over 12s later.
      • timestamp difference between n and n+1, NOT including blocks that are over 12s later.
        • Does this imply that a "slow" validator adds a delay for the block they found (n-1 to n), or do they delay the next block (n, n+1)? Does it change for blocktimes over 12s?
    • Look at the 1% slowest blocktimes under 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
    • Look at all the blocktimes over 12s. Are there any frequent flyers here, taking into account how many blocks they found overall?
      • Need to look at the relative numbers for these, as a validator that has found 2000 blocks SHOULD have more in both categories than one that has found 200.

Reward Distribution

  1. $50
  2. $100
  3. $100
  4. $50
  5. $75

Grading

  • @laura - $63
    • https://pioneer.joystreamstats.live/#/forum/threads/826?replyIdx=7
      • SOW 1 (create list of stuck nodes): $50
      • SOW 2 (contact validators):
      • SOW 3 (operators list): $13
        • 6 had full details ($6)
        • 7 had attempted contact ($7)
      • SOW 4 (blocks and timestamps): $0
        • List did not include blockheights making it impossible to verify any of the data
        • List did not include 201600 blocks (the amount appears to be far less)
        • List did not include timestamp differences, only calculations in seconds.
          • A timestamp difference should look like this: (timestamp: 1640606724000 for block 3765008, timestamp 1640606730000 for block 3765009. The difference would be 6000)
      • SOW 5 (more data, analysis of blocktimes):
        • Not completed

35.II-5 - Community Call #4

  • Reward: $50
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3553200
    • End Block: #3589200

Purpose

Another Community Call will be held Wednesday, the 15th of Decemeber.

Scope of Work

  1. Gather questions from the community, and share them with:
    • @mrexpat#1656
    • bwhm#6514

Grading

* This was already completed and graded within KPI 34
* @igrex
	* https://pioneer.joystreamstats.live/#/forum/threads/826?replyIdx=5

Section III - Working Groups

35.III-1 - Follow up the Storage Working Group

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3596400
    • End Block: #3682800

Not clear if done or not...

Purpose

Our dear leader Bedeho, has pointed out that playing some videos from Atlas is rather slow at the moment. We need to know which ones.

For all tasks, use the Hydra Playground, with the following query:

query {
  videos (limit:1000000, orderBy:createdAt_DESC){
    id
    title
    updatedAt
    createdAt
    createdInBlock
    mediaDataObject {
      joystreamContentId
      liaisonJudgement
      ipfsContentId
      liaison {
        workerId
        metadata
        isActive
      }
    }
  }
}

Scope of Work

  1. Does all nodes have what they should have?
  2. How fast is downloading an asset from each worker?
  3. Get liaison statistics for all the workers, and parse the data.
Hints

For 1 and 2:

  • Get all the active workers. (using pioneer OR the QN), so you have their workerId and the worker metadata (URL).
  • Take 6 different assets (eg. their joystreamContentId), chosen pseudorandomly.
    • Avoid a very small one (say <20MB)
    • Two of the "oldest"
    • Two of the "newest"
    • Two in the "middle"
  • For each metadata and each joystreamContentId, either paste <metadata>/asset/v0/<joystreamContentId> in the browser, and "save video", or better yet: wget <metadata>/asset/v0/<joystreamContentId>.
    Log the following:
  • videoId/joystreamContentId
  • workerMetadata
  • Did they have the file?
  • Download speed
  • Download time
  • Ping (between you and the SP)
    Make sure you only do one at the time! wget + a script will make this rather easy :)

For 3:
Export the data, and make a script that displays how many times each SP was the liaison for a video. Not all Storage Providers has been active the entire time, meaning they can't have been able to receive the same amount of uploads, simply for that reason. Create some more datasets, where you only include videos that was uploaded after:

  1. The last time an active SP was created
  2. The last time an active SP was updated
  3. The first time all active liaisons had been a liaison at least once.
    If one of those happened within the last 2 weeks, use the second to last (first for 3) instead.

For all:
Disregard workerId 19 (no metadata).

Lots of info can be found using the wonderful joystreamstats. storage page. Here however, you need to perform your own checks first.

  1. Compare (where applicable) to the data in the aforementioned joystreamstats.
  2. What does this mean?

The deliverable is not a pure dump of data, but:
1-2: A single spreadsheet or markdown table showing both the individual results, a sum (for each provider), an average (for all providers), and distance from the average (for each provider).
3: Are there any SPs that appear to never be liaisons, or has long stretches where they were active, but didn't? Which ones, and in what range?
Get a list of all instances of a video where "liaisonJudgement": "PENDING",, and for each case a Worker appears to not have been a liaison, provide relevant timestamps where the video is PENDING.
4. Eg. If one or more providers appears to have been slow to download from, is that corroborated by the data in joystreamstats? Could it have been latency, or just "bad luck"?
5. Should the Storage Lead take action towards a Worker? Should the Council take action towards the Lead?

Reward Distribution

Weighting:

  1. $50
  2. $100
  3. $100
  4. $25
  5. $25

Grading

  • This was already completed and graded within KPI 34

Section IV - Bounties

Working Group KPIs

35.CC-1 - Update Featured Categories

  • Reward: $50
  • Fiat Pool Factor: 0
    • Start Block: #3560400
    • End Block: #3690000

Purpose

We want to change these every day!

Scope of Work

  1. Make changes every day, and provide screenshots to prove it!

Grading

  • No work submitted, no rewards.

35.CC-2 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3560400
    • End Block: #3690000

Purpose

We want to change these every day!

Scope of Work

  1. Make changes every day, and provide screenshots to prove it!

Grading

  • No work submitted, no rewards.

35.OP-1 - Fix Opening Rendering

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #3488400
    • End Block: #3690000

Purpose

Both the forum, and the proposals page was very slow to render. This was fixed recently, with very little effort.

Hopefully, the same is true for the Openings!

Scope of Work

  1. Make a PR to the Joystream/joystream repo, fixing the issue

Grading

  • This was already completed in a previous term

35.OP-2 - Giza Testing - restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3589200
    • End Block: #3690000

Purpose

Apologies for the many fails here. We hope to restart testing Sunday.

Scope of Work

Scope will be added in time.

Grading

:(

35.OP-3 - Runtime Upgrade Test

  • Reward: $250
  • Fiat Pool Factor: 0
    • Start Block: #3488400
    • End Block: #3790800

Purpose

Among other things, we want to adjust the Validator Staking Rewards through a runtime upgrade. We did this with the Constantinople runtime upgrade, so we know it was "safe" on previous versions of substrate. Let's confirm it works on this version as well, alongside some other changes.

A technical guide can be found in this issue.

Note
The deliverable will be graded very strictly. This may seem unfair if you do all the work and get a low reward, but the work will be used for the next testnet. If we can't easily trust and verify your work, it has no value as we will have to do it again myself, or spend even more time to investigate.

The reason we're asking the community to test this, is simply because they will need to know to build and deploy networks for testing purposes. Although we're finalizing a tool that will take care of most the steps, you need to know the actual nitty gritty if that is to be useful instead of dangerous, and to maintain it in the future.

Scope of Work

  1. Build a runtime based on the Sumer branch. Make sure the nodes are configured so you can access, and use pioneer. (This is not really "safe" with a node that is running a validator, but for testing purposes, it should be fine).
  2. Add more stake to the validators/add more validators.
  3. Note down the EXACT stakes and issuance for a couple of eras, then change the values (sudo can create and destroy tokens with sudo.setBalance). Ideally use "easy" numbers - eg.
  • 10k/100k
  • 30k/100k
  • 50k/100k
  • 100k/100k
  • 0/100k
    The key is to test with a stake ratio lower, higher and at the ideal one.
  1. Upgrade the runtime, and re-do 3.
  2. Let the chain for a couple of days, and try to:
  • make changes to the validator set
  • add a couple more validators, then turn off two, and have them kicked out for a couple eras before restarting them
  • make some random transactions (balance, forum, content, etc.)
  1. The deliverable is a document with:
  • All steps so that it can be easily reproduced
  • All results, in table format with blockheights, issuances, stakes, stakers, actions, rewards, eraIndex, etc.

Grading

KPI 34

  • KPIs: 11+5
  • Total Possible Rewards: $2100+$500
  • Max Fiat Pool Difference: $75
  • Council Elected in Round: 36
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3488400 / 07.12.21
    • End Block/Date: #3589200 / 14.12.21
  • Deadline to Submit Summary: #3618000 / 16.12.21

Notes

Due to sickness, this weeks KPI set is rather uninspired.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 16 584980
644 lkskrn 8 292490
361 blackmass 11 402173
2141 joyval 1 36561
605 okayko 1 36561
635 xfactorus 17 621541
2096 svasilenko 166 6069163
2531 nanapa6otaet 29 1060275
1962 nkhlghbl 1 36561
321 freakstatic_council 12 438735
1345 kadyrovs 37 1352765
2 tomato 306 11187733
2137 kalpakci 4 146245
1997 marinag_mary 161 5886356
2329 laura 228 8335958
2836 art_khabibullin 108 3948612
790 ururu 11 402173
2435 zazik 315 11516784
2148 controlla 9 329051
2154 marat_mu 188 6873509
SUM 20 1729 61386287

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 50 1828061

Paid out on blocks #3,685,517 and #3,685,518.

Fiat pool increased by $15.

Section I - Council work, Proposals and Bureaucracy

34.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3488400
    • End Block: #3589200

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
2194 ilich 25 106 16
644 lkskrn 14 53 8
361 blackmass 18 69 11
2141 joyval 1 4 1
605 okayko 2 8 1
635 xfactorus 27 109 17
2096 svasilenko 24 106 16
2531 nanapa6otaet 15 57 9
1962 nkhlghbl 2 8 1
321 freakstatic_council 20 77 12
1345 kadyrovs 27 108 17
2 tomato 11 41 6
2137 kalpakci 7 24 4
1997 marinag_mary 18 71 11
2329 laura 26 114 18
2836 art_khabibullin 14 53 8
790 ururu 18 69 11
2435 zazik 25 97 15
2148 controlla 15 60 9
2154 marat_mu 13 52 8
SUM 20 322 1286 200

34.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3488400
    • End Block: #3589200

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

34.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3495600
    • End Block: #3582000

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

34.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3589200
    • End Block: #3704400

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.

Scope of Work

  1. The Council 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

34.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3495600
    • End Block: #3582000

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

Section II - Community Management

34.II-1 - Discord & Telegram Channel Management

  • Reward: $75
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3488400
    • End Block: #3589200

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

34.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3495600
    • End Block: #3582000

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

34.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3589200
    • End Block: #3718800

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

34.II-4 - Community Call #4

  • Reward: $50
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3553200
    • End Block: #3582000

Purpose

Another Community Call will be held Wednesday, the 15th of Decemeber.

Scope of Work

  1. Gather questions from the community, and share them with:
    • @mrexpat#1656
    • bwhm#6514

Grading

Section III - Working Groups

34.III-1 - Follow up the Storage Working Group

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3495600
    • End Block: #3582000

Purpose

Our dear leader Bedeho, has pointed out that playing some videos from Atlas is rather slow at the moment. We need to know which ones.

For all tasks, use the Hydra Playground, with the following query:

query {
  videos (limit:1000000, orderBy:createdAt_DESC){
    id
    title
    updatedAt
    createdAt
    createdInBlock
    mediaDataObject {
      joystreamContentId
      liaisonJudgement
      ipfsContentId
      liaison {
        workerId
        metadata
        isActive
      }
    }
  }
}

Scope of Work

  1. Does all nodes have what they should have?
  2. How fast is downloading an asset from each worker?
  3. Get liaison statistics for all the workers, and parse the data.
Hints

For 1 and 2:

  • Get all the active workers. (using pioneer OR the QN), so you have their workerId and the worker metadata (URL).
  • Take 6 different assets (eg. their joystreamContentId), chosen pseudorandomly.
    • Avoid a very small one (say <20MB)
    • Two of the "oldest"
    • Two of the "newest"
    • Two in the "middle"
  • For each metadata and each joystreamContentId, either paste <metadata>/asset/v0/<joystreamContentId> in the browser, and "save video", or better yet: wget <metadata>/asset/v0/<joystreamContentId>.
    Log the following:
  • videoId/joystreamContentId
  • workerMetadata
  • Did they have the file?
  • Download speed
  • Download time
  • Ping (between you and the SP)
    Make sure you only do one at the time! wget + a script will make this rather easy :)

For 3:
Export the data, and make a script that displays how many times each SP was the liaison for a video. Not all Storage Providers has been active the entire time, meaning they can't have been able to receive the same amount of uploads, simply for that reason. Create some more datasets, where you only include videos that was uploaded after:

  1. The last time an active SP was created
  2. The last time an active SP was updated
  3. The first time all active liaisons had been a liaison at least once.
    If one of those happened within the last 2 weeks, use the second to last (first for 3) instead.

For all:
Disregard workerId 19 (no metadata).

Lots of info can be found using the wonderful joystreamstats. storage page. Here however, you need to perform your own checks first.

  1. Compare (where applicable) to the data in the aforementioned joystreamstats.
  2. What does this mean?

The deliverable is not a pure dump of data, but:
1-2: A single spreadsheet or markdown table showing both the individual results, a sum (for each provider), an average (for all providers), and distance from the average (for each provider).
3: Are there any SPs that appear to never be liaisons, or has long stretches where they were active, but didn't? Which ones, and in what range?
Get a list of all instances of a video where "liaisonJudgement": "PENDING",, and for each case a Worker appears to not have been a liaison, provide relevant timestamps where the video is PENDING.
4. Eg. If one or more providers appears to have been slow to download from, is that corroborated by the data in joystreamstats? Could it have been latency, or just "bad luck"?
5. Should the Storage Lead take action towards a Worker? Should the Council take action towards the Lead?

Reward Distribution

Weighting:

  1. $50
  2. $100
  3. $100
  4. $25
  5. $25

Grading

Section IV - Bounties

Working Group KPIs

34.CC-1 - Update Featured Categories

  • Reward: $75
  • Fiat Pool Factor: 0.2
    • Start Block: #3459600
    • End Block: #3690000

Purpose

We want to change these every day!

Scope of Work

  1. Come up with a routine to change these on a daily basis. As we can't rely on tomato being available every day, look into creating a script for this. If required, ask the Operations group for assistance.
  2. There are currently 12 videos (with 3 clips) in each category, and 9 more video clips created (but not uploaded). Assuming we want a new top video for each category every day, it's currently possible to have 12 (11 left) permutations without finding more videos. Example for category 1:
  • Day 1: [[0,1,2],[3-11]]
  • Day 2: [[3,4,5],[0-2,6-11]]
  • ...
  • Day 5: [[1,3,6],[0,2,4,5,7-11]]
    Create a schedule for the next 12 days.
  1. Deploy the script that does this. Before it's done, change them manually (must be done at least once before the next term). Make sure to run the script manaully the first few times before it's set to start automatically.
  2. Publish the script, and write step by step guide on all the actions needed, with examples, on how to "Update Featured Categories". Publish it to the Community Repo.
  3. Before block #3500800, source at least 7 more videos to each Category, and create clips.
  4. Note that we can start rotating some of the old ones back in at some point. For this reason:
  • create a database of which videos was featured when, and in what "position"
  • give each of video a single score to indicate how well it works (eg. good clip/video, and relevance to the category)

Grading

34.CC-2 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3459600
    • End Block: #3690000

Purpose

We want to change these every day!

Scope of Work

  1. Change the Featured Videos on chain, using the CLI. Make sure your changes works, and that there is:
  • no overlap with the Featured Video Hero
  • no overlap with the videos with clips in Featured Categories
  • little overlap with the other (without clips) videos in Featured Categories
  1. Plan a schedule of which videos should be featured for the upcoming Term, including which Curator should make the changes. Test to make sure they have the permissions, as I don't remember whether it's Lead only, or if the Lead can delegate this with groups.

Grading

34.OP-1 - Fix Opening Rendering

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #3488400
    • End Block: #3690000

Purpose

Both the forum, and the proposals page was very slow to render. This was fixed recently, with very little effort.

Hopefully, the same is true for the Openings!

Scope of Work

  1. Make a PR to the Joystream/joystream repo, fixing the issue

Grading

  • Done, graded last term.

34.OP-2 - Giza Testing - Restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3488400
    • End Block: #3790800

Purpose

Testing will continue late this week. See KPI 32.OP-1 for more info.

Scope of Work

Scope will be added in time.

Grading

  • No scope included/TBA

34.OP-3 - Runtime Upgrade Test

  • Reward: $250
  • Fiat Pool Factor: 0
    • Start Block: #3488400
    • End Block: #3790800

Purpose

Among other things, we want to adjust the Validator Staking Rewards through a runtime upgrade. We did this with the Constantinople runtime upgrade, so we know it was "safe" on previous versions of substrate. Let's confirm it works on this version as well, alongside some other changes.

A technical guide can be found in this issue.

Note
The deliverable will be graded very strictly. This may seem unfair if you do all the work and get a low reward, but the work will be used for the next testnet. If we can't easily trust and verify your work, it has no value as we will have to do it again myself, or spend even more time to investigate.

The reason we're asking the community to test this, is simply because they will need to know to build and deploy networks for testing purposes. Although we're finalizing a tool that will take care of most the steps, you need to know the actual nitty gritty if that is to be useful instead of dangerous, and to maintain it in the future.

Scope of Work

  1. Build a runtime based on the Sumer branch. Make sure the nodes are configured so you can access, and use pioneer. (This is not really "safe" with a node that is running a validator, but for testing purposes, it should be fine).
  2. Add more stake to the validators/add more validators.
  3. Note down the EXACT stakes and issuance for a couple of eras, then change the values (sudo can create and destroy tokens with sudo.setBalance). Ideally use "easy" numbers - eg.
  • 10k/100k
  • 30k/100k
  • 50k/100k
  • 100k/100k
  • 0/100k
    The key is to test with a stake ratio lower, higher and at the ideal one.
  1. Upgrade the runtime, and re-do 3.
  2. Let the chain for a couple of days, and try to:
  • make changes to the validator set
  • add a couple more validators, then turn off two, and have them kicked out for a couple eras before restarting them
  • make some random transactions (balance, forum, content, etc.)
  1. The deliverable is a document with:
  • All steps so that it can be easily reproduced
  • All results, in table format with blockheights, issuances, stakes, stakers, actions, rewards, eraIndex, etc.

Grading

KPI 33

  • KPIs: 15+6
  • Total Possible Rewards: $3250+$855
  • Max Fiat Pool Difference: $241
  • Council Elected in Round: 35
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3387600 / 30.11.21
    • End Block/Date: #3488400 / 06.12.21
  • Deadline to Submit Summary: #3517200 / 09.12.21

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 190 6716420
1521 arseniy2706 3 106049
644 lkskrn 7 247447
361 blackmass 12 424195
2141 joyval 1 35350
515 l1dev 285 10074630
635 xfactorus 15 530244
2574 alexznet 12 424195
2531 nanapa6otaet 36 1272585
2697 ardashoff 7 247447
2988 sevenup 102 3605657
321 freakstatic_council 14 494894
1345 kadyrovs 178 6292225
2 tomato 307 10852321
2137 kalpakci 1 35350
1997 marinag_mary 107 3782405
2329 laura 303 10710923
1048 igrex 96 3393560
2435 zazik 312 11029069
2154 marat_mu 209 7388062
SUM 20 2122 67058154

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2435 zazik 125 4418697
644 lkskrn 100 3534958

Payouts done on blocks #3,557,473 and #3,557,474.

The fiat pool shrank by $67.

Section I - Council work, Proposals and Bureaucracy

33.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

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
2194 ilich 26 94 15
1521 arseniy2706 4 16 3
644 lkskrn 13 46 7
361 blackmass 20 74 12
2141 joyval 3 9 1
515 l1dev 18 63 10
635 xfactorus 26 95 15
2574 alexznet 20 79 12
2531 nanapa6otaet 18 71 11
2697 ardashoff 14 47 7
2988 sevenup 28 109 17
321 freakstatic_council 23 91 14
1345 kadyrovs 15 50 8
2 tomato 12 43 7
2137 kalpakci 1 4 1
1997 marinag_mary 17 62 10
2329 laura 22 83 13
1048 igrex 24 102 16
2435 zazik 22 76 12
2154 marat_mu 15 54 9
SUM 20 341 1268 200

33.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

33.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

33.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3488400
    • End Block: #3603600

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.

Scope of Work

  1. The 30th "official" Council #3085200-#3186000 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

33.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

33.I-6 - Council Insight

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

33.I-7 - Review New Incentives Draft

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end - 4 days
    • Start Block: #3328000
    • End Block: #3430800

Over time, the KPI scheme has seen many iterations. We think it's gotten better over time, but as many of you have pointed out, and we are fully aware of, there are still quite a few flaws. With the growth in participation and activity, this is becoming more and more of a problem.

The new system will attempt to get us closer to this "world", provide more opportunities for everyone, not just CMs, to learn about the system and/or perform valuable JOYtasks for the platform, while earning FM points and some fiat along the way.

A draft of a new system (which may have nothing in common with what we end up doing), is roughly outlined here.
Note that this is very much a WIP, and the draft may be updated "in flight".

Note
SoW 1 and 2 is presumably done, so only 3 is remaining. Unless you already started, you probably shouldn't ask for this one...

Scope of Work

  1. For each CM, review the draft, and write a short summary of your thoughts, questions and comments. Share this with the KPI Manager, or, whoever the KPI Manager "assigns" the (rest of the) KPI to.
  2. Generate some feedback from the Community at large, and the Leads (especially) and Workers (preferably) in each WG. Here, it's enough if they review their "own" WG and the "JOYtask Participant" section. Feel free to create a survey, and even a Q&A to establish whether they actually read it :)
  3. Gather all the results in a single document, where:
  • Each persons feedback is included, with (either) their Handle/Member Id/Role, or only their role (if any).
  • An overview containing the most common (objectively) or the most valuable (subjectively) feedback.
  • Create a "payout" list based in line with * below (memberId,accountId,role,dollarAmount).
    Share the feedback summary with me, either as a comment to the gist, an issue/PR to the Community Repo, or in discord.

Reward Distribution

Weighting

  1. Everyone on the Council* gets $20. Capped at $100.
  2. The Leads all get $10, Workers all get $5.* Capped at $100.
  • Top 5 "valuable" comments gets $20 each
  1. $150 (including organizing 2)
    * Only applies if there is any feedback. We won't set a min_text_length constraint, but comments like "it looks good!" won't receive any rewards.

Grading is individual.

Grading

Section II - Community Management

33.II-1 - Discord & Telegram Channel Management

  • Reward: $75
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

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

33.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

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

33.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3488400
    • End Block: #3618000

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

33.II-4 - Council Term Summary Video Reviews

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3488400
    • End Block: #3618000

Purpose

The "Council Term Summary Videos" KPI has been running since round #23. How are they working? Who is consuming them? How can they be approved?

Scope of Work

  1. Watch all the videos that's been made, with an emphasis on the later ones. Before you proceed to SoW #2, dm me:
  • What is good?
  • What is not good?
  • What would you like them to include, but is missing?
  1. Part of the SOW when making these videos, was to get feedback using the forum. To save some time, open the current and old KPI pages, search the page for all the KPIs of this kind, and find the forum posts (if made, they can be found in the linked term summaries in the grading).
  • Create a document with a link to all videos and the forum feedback page.
  • For all videos, grouped by the same creator(s) and parse the feedback.
    • What is the most frequent sort of feedback?
    • Having (re-)watched the videos, was any of the feedback "fixed" in future videos?
    • Does any of the feedback strike a chord with you - meaning: "I should have written that"? If so, what is it?
  1. Engage the community, and ask them:
  • Do you like the concept of "Term Summary Videos"?
  • If yes:
    • What do you think they should contain/hightlight?
    • How long should they be?
    • Who should be part?
  • If no:
    • Are there any other Community driven "News" series that you'd want instead?

Reward Distribution

Weighting:

  1. 100
  2. 100
  3. 100

Grading

33.II-5 - Community Call 1 Subtitles

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

Purpose

Ref KPI 32.II-4 - only SoW #5 remains.

Scope of Work

  1. Create russian subtitles for the video from from SoW #4 of the "old" KPI, using the .srt, or other "widespread" format.

Reward Distribution

NA

Grading

33.II-6 - Pay the Community Rewards for the Maze Test

  • Reward: $175
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term - 4 days
    • Start Block: #3387600
    • End Block: #3430800

Purpose

We got plenty of responses - now is the time to pay them back!

Scope of Work

  1. Once assigned by the KPI manager, DM me (@bwhm#6514) on Discord, to get the incomplete* payout list. Pay each of them in tJOY, and after getting re-imbursed, pocket $25.

Reward Distribution

If you round down too much (eg. verifiable complaints re exchange rate), you will not get re-imbursed!

Grading

  • unclaimed

Section III - Working Groups

33.III-1 - Follow up the Storage Working Group

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

Our dear leader Bedeho, has pointed out that playing some videos from Atlas is rather slow at the moment. We need to know which ones.

For all tasks, use the Hydra Playground, with the following query:

query {
  videos (limit:1000000, orderBy:createdAt_DESC){
    id
    title
    updatedAt
    createdAt
    createdInBlock
    mediaDataObject {
      joystreamContentId
      liaisonJudgement
      ipfsContentId
      liaison {
        workerId
        metadata
        isActive
      }
    }
  }
}

Scope of Work

  1. Does all nodes have what they should have?
  2. How fast is downloading an asset from each worker?
  3. Get liaison statistics for all the workers, and parse the data.
Hints

For 1 and 2:

  • Get all the active workers. (using pioneer OR the QN), so you have their workerId and the worker metadata (URL).
  • Take 6 different assets (eg. their joystreamContentId), chosen pseudorandomly.
    • Avoid a very small one (say <20MB)
    • Two of the "oldest"
    • Two of the "newest"
    • Two in the "middle"
  • For each metadata and each joystreamContentId, either paste <metadata>/asset/v0/<joystreamContentId> in the browser, and "save video", or better yet: wget <metadata>/asset/v0/<joystreamContentId>.
    Log the following:
  • videoId/joystreamContentId
  • workerMetadata
  • Did they have the file?
  • Download speed
  • Download time
  • Ping (between you and the SP)
    Make sure you only do one at the time! wget + a script will make this rather easy :)

For 3:
Export the data, and make a script that displays how many times each SP was the liaison for a video. Not all Storage Providers has been active the entire time, meaning they can't have been able to receive the same amount of uploads, simply for that reason. Create some more datasets, where you only include videos that was uploaded after:

  1. The last time an active SP was created
  2. The last time an active SP was updated
  3. The first time all active liaisons had been a liaison at least once.
    If one of those happened within the last 2 weeks, use the second to last (first for 3) instead.

For all:
Disregard workerId 19 (no metadata).

Lots of info can be found using the wonderful joystreamstats. storage page. Here however, you need to perform your own checks first.

  1. Compare (where applicable) to the data in the aforementioned joystreamstats.
  2. What does this mean?

The deliverable is not a pure dump of data, but:
1-2: A single spreadsheet or markdown table showing both the individual results, a sum (for each provider), an average (for all providers), and distance from the average (for each provider).
3: Are there any SPs that appear to never be liaisons, or has long stretches where they were active, but didn't? Which ones, and in what range?
Get a list of all instances of a video where "liaisonJudgement": "PENDING",, and for each case a Worker appears to not have been a liaison, provide relevant timestamps where the video is PENDING.
4. Eg. If one or more providers appears to have been slow to download from, is that corroborated by the data in joystreamstats? Could it have been latency, or just "bad luck"?
5. Should the Storage Lead take action towards a Worker? Should the Council take action towards the Lead?

Reward Distribution

Weighting:

  1. $50
  2. $100
  3. $100
  4. $25
  5. $25

Grading

33.III-2 - Follow up the Curator Working Group

  • Reward: $50
  • Fiat Pool Factor: 1.0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

The Curator Group is getting plenty of recurring tasks in this KPI. Assist, and make sure they succeed!

(No Curators can get rewarded for this task.)

Scope of Work

  1. Check in on them on a daily basis and report their progress to the Council. If they have any issues, make sure these are dealt with.

Reward Distribution

NA

Grading

Section IV - Bounties

Working Group KPIs

33.CC-1 - Update Featured Video Hero

  • Reward: $150
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

This should be replaced pretty regularly, and it's been a while since the last time!

We want to start changing these every day!
Feel free to look for information in the joystream or atlas repos (especially #4).

Scope of Work

  1. In line with the process established in a previous KPI, propose 2 or 3 alternatives for the featured video to Jsgenesis. The proposal should be the finished json with all data required.
  2. We want to start updating these on a daily basis. Create a catalogue of 5 videos (not used before), and 5 videos (re-use allowed).
  3. Come up with an estimate how many videos would be "good enough" for this already,
  4. Write step by step guide on all the actions needed, with examples, on how to "Update Featured Video Hero". Publish it to the Community Repo.

Reward Distribution

  1. $30
    2-4. $120 (combined. All must be completed!)

Grading

33.CC-2 - Update Featured Categories

  • Reward: $280
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

We want to start changing these every day!

Note that tomato is likely needed for this task. The CC Lead decides how much of the reward they should earn. Some inspiration for the future can be found here. Feel free to look for information in the joystream or atlas repos.

Scope of Work

  1. Come up with a routine to change these on a daily basis. As we can't rely on tomato being available every day, look into creating a script for this. If required, ask the Operations group for assistance.
  2. There are currently 12 videos (with 3 clips) in each category, and 9 more video clips created (but not uploaded). Assuming we want a new top video for each category every day, it's currently possible to have 12 (11 left) permutations without finding more videos. Example for category 1:
  • Day 1: [[0,1,2],[3-11]]
  • Day 2: [[3,4,5],[0-2,6-11]]
  • ...
  • Day 5: [[1,3,6],[0,2,4,5,7-11]]
    Create a schedule for the next 12 days.
  1. Deploy the script that does this. Before it's done, change them manually (must be done at least once before the next term). Make sure to run the script manaully the first few times before it's set to start automatically.
  2. Publish the script, and write step by step guide on all the actions needed, with examples, on how to "Update Featured Categories". Publish it to the Community Repo.
  3. Before block #3500800, source at least 7 more videos to each Category, and create clips.
  4. Note that we can start rotating some of the old ones back in at some point. For this reason:
  • create a database of which videos was featured when, and in what "position"
  • give each of video a single score to indicate how well it works (eg. good clip/video, and relevance to the category)

Grading

  • No work submitted, no rewards

33.CC-3 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

This should be replaced pretty regularly, and it's been a while since the last time. We want to start changing these every day!

Scope of Work

  1. Change the Featured Videos on chain, using the CLI. Make sure your changes works, and that there is:
  • no overlap with the Featured Video Hero
  • no overlap with the videos with clips in Featured Categories
  • little overlap with the other (without clips) videos in Featured Categories
  1. Plan a schedule of which videos should be featured for the upcoming Term, including which Curator should make the changes. Test to make sure they have the permissions, as I don't remember whether it's Lead only, or if the Lead can delegate this with groups.

Grading

  • No work submitted, no rewards

33.OP-1 - Fix Opening Rendering

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #3387600
    • End Block: #3589200

Purpose

Both the forum, and the proposals page was very slow to render. This was fixed recently, with very little effort.

Hopefully, the same is true for the Openings!

Scope of Work

  1. Make a PR to the Joystream/joystream repo, fixing the issue

Grading

33.OP-2 - Giza Testing - Restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3387600
    • End Block: #3690000

Purpose

Testing will continue late this week. See KPI 32.OP-1 for more info.

Scope of Work

Scope will be added in time.

Grading

  • This KPI was never announced fully

33.OP-3 - Runtime Upgrade Test

  • Reward: $250
  • Fiat Pool Factor: 0
    • Start Block: #3428000
    • End Block: #3790800

Purpose

Among other things, we want to adjust the Validator Staking Rewards through a runtime upgrade. We did this with the Constantinople runtime upgrade, so we know it was "safe" on previous versions of substrate. Let's confirm it works on this version as well, alongside some other changes.

A technical guide can be found in this issue.

Note
The deliverable will be graded very strictly. This may seem unfair if you do all the work and get a low reward, but the work will be used for the next testnet. If we can't easily trust and verify your work, it has no value as we will have to do it again myself, or spend even more time to investigate.

The reason we're asking the community to test this, is simply because they will need to know to build and deploy networks for testing purposes. Although we're finalizing a tool that will take care of most the steps, you need to know the actual nitty gritty if that is to be useful instead of dangerous, and to maintain it in the future.

Scope of Work

  1. Build a runtime based on the Sumer branch. Make sure the nodes are configured so you can access, and use pioneer. (This is not really "safe" with a node that is running a validator, but for testing purposes, it should be fine).
  2. Add more stake to the validators/add more validators.
  3. Note down the EXACT stakes and issuance for a couple of eras, then change the values (sudo can create and destroy tokens with sudo.setBalance). Ideally use "easy" numbers - eg.
  • 10k/100k
  • 30k/100k
  • 50k/100k
  • 100k/100k
  • 0/100k
    The key is to test with a stake ratio lower, higher and at the ideal one.
  1. Upgrade the runtime, and re-do 3.
  2. Let the chain for a couple of days, and try to:
  • make changes to the validator set
  • add a couple more validators, then turn off two, and have them kicked out for a couple eras before restarting them
  • make some random transactions (balance, forum, content, etc.)
  1. The deliverable is a document with:
  • All steps so that it can be easily reproduced
  • All results, in table format with blockheights, issuances, stakes, stakers, actions, rewards, eraIndex, etc.

Grading

KPI 32

  • KPIs: 17+4
  • Total Possible Rewards: $3875+$505
  • Max Fiat Pool Difference: $355
  • Council Elected in Round: 34
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3286800 / 23.11.21
    • End Block/Date: #3387600 / 30.11.21
  • Deadline to Submit Summary: #3416400 / 02.12.21

KPIs:

Added on the 26th of November, 32.CC-1 - Update Featured Video Hero revised.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
1305 joystreamstats 3 105411
2194 ilich 215 7554478
644 lkskrn 4 140548
361 blackmass 11 386508
515 l1dev 54 1897404
2096 svasilenko 317 11138463
2531 nanapa6otaet 33 1159525
2697 ardashoff 162 5692212
1962 nkhlghbl 0 0
321 freakstatic_council 10 351371
3029 oxygen 153 5375978
1345 kadyrovs 43 1510896
2 tomato 314 11033052
1997 marinag_mary 208 7308519
2329 laura 430 15108957
2836 art_khabibullin 37 1300073
319 sparky 0 0
1048 igrex 191 6711188
2435 zazik 231 8116672
2154 marat_mu 150 5270566
SUM 20 3246 90161821

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 180 6324679
2098 0x2bc 125 4392139
515 l1dev 375 13176416

Payouts made on block #3,469,791. Payouts for participants of 32.I-8 - Review New Incentives Draft will be done tomorrow.

The fiat pool shrank by $5.

Section I - Council work, Proposals and Bureaucracy

32.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

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
1305 joystreamstats 5 20 3
2194 ilich 29 107 15
644 lkskrn 8 32 4
361 blackmass 22 82 11
515 l1dev 26 104 14
2096 svasilenko 27 99 14
2531 nanapa6otaet 14 56 8
2697 ardashoff 23 89 12
1962 nkhlghbl 0 0 0
321 freakstatic_council 18 69 10
3029 oxygen 7 25 3
1345 kadyrovs 24 95 13
2 tomato 23 101 14
1997 marinag_mary 23 90 13
2329 laura 28 110 15
2836 art_khabibullin 13 49 7
319 sparky 0 0 0
1048 igrex 31 130 18
2435 zazik 28 112 16
2154 marat_mu 19 70 10
SUM 20 368 1440 200

32.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

32.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

32.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3387600
    • End Block: #3502800

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.

Scope of Work

  1. The 30th "official" Council #3085200-#3186000 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

32.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

32.I-6 - Council Insight

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

32.I-7 - Joystream Node Issues

  • Reward: $250
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Final Call:
Will not be renewed (or reviewed) if not completed by end of this term.

Purpose

A while back, we had an unfortunate event where some of our RPC and Bootnodes had gone down.
We have, and continue to, look into exactly what has happened to them, but thus far we have yet to solve the issue.

Information:

  • The nodes are running different versions. At least one was running joystream-node-5.1.0-9d9e77751.
  • The problematic seems to be #2661218, with hash 0xf5a468e133149fc094bdfa9d8842610a82fbdae10d57a4d5e980093d4691bbbc.
    • Note that this block was re-orged in (common occurance), replacing 0x7c1e11029ada770a98100f4aae3a4d4c23192343eaaf879ab57b888ae18dd841
    • Also note that it's the first block in a new era (4458)
  • One node stopped finalizing at this exact height, whereas some other continued for a little while before halting.
  • At some point, all failing nodes (that is running with --log runtime) will show:
INFO 💔 Invalid justification provided by 12D3KooWFkZZ23LoeyrpFpsDWEQwwRSWx9VaG6bwiz6jL8AE8HfS for #0x2e04…620a
  • The block in question being #2661813 with hash 0x2e04e790f04d336e2d58efb705e4773782d15041de776f755034b6355100620a
    • This happens to be the first block in a new era (4459)

Note that the "old" part 1 was completed last term.

Scope of Work

  1. Get ALL events that has to with slashing, eg. imOnline.SomeOffline, and offences.* starting from block #2000000 up until the current height. Create a dataset and chart the development of occurrences.
    (If you also get all the blocks with the event staking.payout, 3 will be significantly easier.)

  2. How many validators were there in each era, starting from #4457 up until now, and what was the set of validators? It's sufficient to check a single block in each activeEra. Provide:

  • the full validator set
  • number of validators
  • blockheight
  • era (activeEra and currentEra)
  • validator points for each era
  1. Having the data from 1 and 2, see if there is any reason to believe it implies anything "bad" happening around the problem blocks listed above.

Reward Distribution

Weighting:

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

Grading

32.I-8 - Review New Incentives Draft

  • Reward: $450
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3328000
    • End Block: #3387600

Added 26.11.21

Purpose

Over time, the KPI scheme has seen many iterations. We think it's gotten better over time, but as many of you have pointed out, and we are fully aware of, there are still quite a few flaws. With the growth in participation and activity, this is becoming more and more of a problem.

The new system will attempt to get us closer to this "world", provide more opportunities for everyone, not just CMs, to learn about the system and/or perform valuable JOYtasks for the platform, while earning FM points and some fiat along the way.

A draft of a new system (which may have nothing in common with what we end up doing), is roughly outlined here.
Note that this is very much a WIP, and the draft may be updated "in flight".

Scope of Work

  1. For each CM, review the draft, and write a short summary of your thoughts, questions and comments. Share this with the KPI Manager, or, whoever the KPI Manager "assigns" the (rest of the) KPI to.
  2. Generate some feedback from the Community at large, and the Leads (especially) and Workers (preferably) in each WG. Here, it's enough if they review their "own" WG and the "JOYtask Participant" section. Feel free to create a survey, and even a Q&A to establish whether they actually read it :)
  3. Gather all the results in a single document, where:
  • Each persons feedback is included, with (either) their Handle/Member Id/Role, or only their role (if any).
  • An overview containing the most common (objectively) or the most valuable (subjectively) feedback.
  • Create a "payout" list based in line with * below (memberId,accountId,role,dollarAmount).
    Share the feedback summary with me, either as a comment to the gist, an issue/PR to the Community Repo, or in discord.

Reward Distribution

Weighting

  1. Everyone on the Council* gets $20. Capped at $100.
  2. The Leads all get $10, Workers all get $5.* Capped at $100.
  • Top 5 "valuable" comments gets $20 each
  1. $150 (including organizing 2)
    * Only applies if there is any feedback. We won't set a min_text_length constraint, but comments like "it looks good!" won't receive any rewards.

Grading is individual.

Grading

33.I-9 - KPI Presentation - Part 2

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

There's been plenty of feedback on the rather crude way the KPI's are presented, and how it negatively impacts several aspects of the KPIs.

  • It's very hard to read and parse, scaring people away from even trying
  • There are often errors in the ToC and formatting
  • It's very hard to read and parse the results
  • The page is infinite

I'm sure I could go on, but let's instead focus on how to improve it.

Part 1 of this was mostly completed in 26.I-5 and 27.I-5. Lets finish this!

Scope of Work

  1. Go through the work, with emphasis on what to include, design briefs and wireframes in the aforementioned Part 1 (follow the links above), and provide a quick summary:
  • Does the "what to include" cover the basics needed?
  • Is the wireframe(s) and/or design brief(s) cover the above?
  • Can the best wireframe be implemented?
  1. Although not part of the Scope in Part 1, complete json files for some older KPIs was created an merged here. This would have been some of the scope for Part 2, so it'll be retroactively rewarded!

  2. Does the json in 2 contain all the data needed to work as the backend for the design? If yes, make a PR:

  • That moves the file to a reasonable place in the repo (similar to the bounty-status.json and bounties.schema.json)
  • Adds the latest KPI info in to the file
  • Create a json.schema to validate the json
  • Write basic instructions for updating the json, so that it can be done frequently by the KPI manager
  1. Have the operations group implement the design, and make it a part of joystreamstats.live (or some other website accessible for the community).

Reward Distribution

Parts 1-3 must all be addressed (not necessarily by the same person) for this to be graded.

Weighting:

  1. $50
  2. $125
  3. $75
  4. $50

Section II - Community Management

32.II-1 - Discord & Telegram Channel Management

  • Reward: $75
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

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

32.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

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

  • No work submitted, no rewards.

32.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #3387600
    • End Block: #3517200

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

32.II-4 - Community Call 1 - Part 2

  • Reward: $800
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Final Call:
Will not be renewed (or reviewed) if not completed by end of this term.

Purpose

The Community call has been successfully held, and the raw video was uploaded here.

A little follow up work (editing, translating, etc) is needed!

Note

The reward has been reduced a bit, as these kind of videos needs to go out quickly to get the best value. Remember for next time!
(The tasks that was completed by the end of the last term will be graded with the "old" rewards)

Scope of Work

  1. Create a spreadsheet with:
  • index of the question (1, 2, etc.)
  • each question asked written in English
  • the timestamp of when the question started, in hours, minutes, seconds, milliseconds, eg. 00:20:30,4000
  • the timestamp of when the answer was finish, in hours, minutes, seconds, milliseconds, eg. 00:21:31,4100
  • if two (or more) subsequent questions are linked, such as a follow up question, make a note of it.
    Chit chat, off-topic, pauses, etc- in between questions should not be included, meaning the timestamp of the end of question 1, should in most cases not be the same as the timestamp of the start of question 2

Then, With the list from above, do an informal poll among the community, and find out which 3-10 questions is considered most interesting/important. Note that this doesn't (necessarily) mean the best question. The entertainment value is the most important element:

  • If the answer isn't very interesting, the clip won't be either!
  • If a question spurred further conversation, even if somewhat off-topic, it might still have been more interesting to watch.
  1. For each of the 3-10 "questions" from 1, create a "teaser" for each video. These should all be in the same style. Examples:
  • 2/3-off, 2s-5s clips enticing the prospective viewer to wathc the video, edited in a "nice" way
  • a concise, short "version" of the question spelled out
  • soft (license free) music?
    Note that the above are just suggestions - we hope someone in the community knows how to create engaging videos, and grow a base better than we do :)
    (Let me know if you want the chatlog!)
  1. Create a text based FAQ based on the questions that was asked. Both the question and answer needs a rewrite to make it suitable as an FAQ. This may even mean creating your question, if something interesting was said, that wasn't spurred by a direct question.

  2. Create a condensed version of the video, keeping more than the just the top rated above, but removing section that seems less interesting. How much to keep is up to you!
    (Let me know if you want the chatlog!)

  3. Create russian subtitles for the video from 2, using the .srt, or other "widespread" format.

Notes

For all videos, subtitles and artwork, you are free to upload yourself, but it has to be "CC0", and jsgenesis will likely re-upload.

Reward Distribution

For 1, only the first "good" submission will be rewarded.
For 2-3, only the best submission will be rewarded.
For 3, we are thinking it may be an iterative process, where we (may):

  • want to combine the work of two people
  • potentially request small changes/fixes
  • if/when we get something that looks great, we would want that team or person create more of these (paid) in the future
  1. $125
  2. $275
  3. $150
  4. $75
  5. $75
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

32.II-5 - Community Call 2 - Part 2

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

As we are getting trying out how to best share/present the recordings of these calls after they've been made, and the first is taking some time to finish, we're trying out a simpler approach for the second call.

Scope of Work

  1. A new blog post has been published. Review the blog post, and give some constructive feedback on:
  • the format (what it contains)
  • the presentation (is there a better way?)
  • the selected highlights (is there something else you think is more important?)
  1. Create a video containing only the hightlights (if you disagreed with the hightlights Jsgenesis chose, use your own!)

Reward Distribution

  1. $50
  2. $50

Ideally, two different groups/individuals tackles this KPI - one group/person that was there, and one group that didn't (and hasn't seen it yet). Both can earn the full reward.

Grading

Section III - Working Groups

32.III-1 - Follow up the Storage Working Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Lead tracking of the performance of each node at regular interval? If yes, is there a carrot/stick system in place?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

32.III-2 - Follow up the Content Curator Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. What is the Curator Groups system/approach for reviewing/approving each new video as they are uploaded? Are they all checked, or is that done for Bounties only?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

* @ardashoff - $150
	* https://pioneer.joystreamstats.live/#/forum/threads/783?page=1&replyIdx=8
		* https://testnet.joystream.org/#/forum/threads/775
			* Included all information necessary and was quite in-depth.

32.III-3 - Follow up the Operations Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Operations handling their "basic" workload as defined in the helpdesk repo?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

Section IV - Bounties

Working Group KPIs

32.CC-1 - Update Featured Video Hero

  • Reward: $150
  • Fiat Pool Factor: 0.2
    • Start Block: #3286800
    • End Block: #3488400

Revised 26.11.21, SoW 2+

Purpose

This should be replaced pretty regularly, and it's been a while since the last time!

Addition
We want to start changing these every day!
Feel free to look for information in the joystream or atlas repos (especially #4).

Scope of Work

  1. In line with the process established in a previous KPI, propose 2 or 3 alternatives for the featured video to Jsgenesis. The proposal should be the finished json with all data required.
  2. We want to start updating these on a daily basis. Create a catalogue of 5 videos (not used before), and 5 videos (re-use allowed).
  3. Come up with an estimate how many videos would be "good enough" for this already,
  4. Write step by step guide on all the actions needed, with examples, on how to "Update Featured Video Hero". Publish it to the Community Repo.

Reward Distribution

  1. $30
    2-4. $120 (combined. All must be completed!)

Grading

  • No work submitted, no rewards.

32.CC-2 - Update Featured Categories

  • Reward: $280
  • Fiat Pool Factor: 0.2
    • Start Block: #3328000
    • End Block: #3500800

Added 26.11.21

Purpose

We want to start changing these every day!

Note that tomato is likely needed for this task. The CC Lead decides how much of the reward they should earn. Some inspiration for the future can be found here. Feel free to look for information in the joystream or atlas repos.

Scope of Work

  1. Come up with a routine to change these on a daily basis. As we can't rely on tomato being available every day, look into creating a script for this. If required, ask the Operations group for assistance.
  2. There are currently 12 videos (with 3 clips) in each category, and 9 more video clips created (but not uploaded). Assuming we want a new top video for each category every day, it's currently possible to have 12 (11 left) permutations without finding more videos. Example for category 1:
  • Day 1: [[0,1,2],[3-11]]
  • Day 2: [[3,4,5],[*]]
  • ...
  • Day 5: [[1,3,6],[*]]
    Create a schedule for the next 12 days.
  1. Deploy the script that does this. Before it's done, change them manually (must be done at least once before the next term). Make sure to run the script manaully the first few times before it's set to start automatically.
  2. Publish the script, and write step by step guide on all the actions needed, with examples, on how to "Update Featured Categories". Publish it to the Community Repo.
  3. Before block #3500800, source at least 7 more videos to each Category, and create clips.
  4. Note that we can start rotating some of the old ones back in at some point. For this reason:
  • create a database of which videos was featured when, and in what "position"
  • give each of video a single score to indicate how well it works (eg. good clip/video, and relevance to the category)

Grading

32.CC-3 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3328000
    • End Block: #3488400

Added 26.11.21

Purpose

This should be replaced pretty regularly, and it's been a while since the last time. We want to start changing these every day!

Scope of Work

  1. Change the Featured Videos on chain, using the CLI. Make sure your changes works, and that there is:
  • no overlap with the Featured Video Hero
  • no overlap with the videos with clips in Featured Categories
  • little overlap with the other (without clips) videos in Featured Categories
  1. Plan a schedule of which videos should be featured for the upcoming Term, including which Curator should make the changes. Test to make sure they have the permissions, as I don't remember whether it's Lead only, or if the Lead can delegate this with groups.

Grading

  • No work submitted, no rewards.

32.OP-1 - Giza Testing

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3085200
    • End Block: #3488400

Purpose

As we have started testing of Giza, we want the Operations group to help in testing. The reward will be $25/h of testing. However, we need some continuity, and reliability in terms of the testers availability.

The Lead is free to select a subset of the group they think is most qualified. Qualifications:

  • Some familiarity with using the command line (linux) and git (for most, not required for all)
  • If possible, one or more that has been a storage provider
  • Basic english (for communication, documentation and instructions parsing)
  • Likes to try and break things :)

We will provide linodes for the testers to ssh into.

Scope of Work

Giza testing has been ongoing for a while, but we have hit a roadblock, and we ask for no one to touch anything before that has been resolved. The Lead will be contacted when we can continue!

Grading

KPI 31

  • KPIs: 17+3
  • Total Possible Rewards: $3925+$665
  • Max Fiat Pool Difference: $364
  • Council Elected in Round: 33
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3186000 / 16.11.21
    • End Block/Date: #3286800 / 23.11.21
  • Deadline to Submit Summary: #3315600 / 25.11.21

Notes

We're seeing some signs that whenever the new KPIs are posted, some of the CMs lay claim to a large amount of them ASAP, and are then, in effect, the only ones who can work on them. This is not how the system was intended to work.

If everyone WANTS to co-operate, that's fine, but not if two CMs can claim half of KPIs each, leaving the remaining 18 to fight for the remaining half.

If the CMs would rather compete that's fine too, but in most cases, the winner will take it all.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 74 2574346
644 lkskrn 7 243519
361 blackmass 8 278308
2141 joyval 0 0
515 l1dev 216 7514307
635 xfactorus 16 556615
1843 spat_sochi 4 139154
2531 nanapa6otaet 109 3791942
1962 nkhlghbl 1 34788
321 freakstatic_council 12 417461
1345 kadyrovs 38 1321961
2 tomato 311 10819210
2137 kalpakci 9 313096
1997 marinag_mary 308 10714845
2329 laura 294 10227806
790 ururu 8 278308
319 sparky 0 0
1048 igrex 191 6644595
2435 zazik 187 6505442
2182 isonar 107 3722365
SUM 20 2140 66098068

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 150 5218269
644 lkskrn 90 3130961

Payouts completed on blocks 3,356,378 and 3,356,379.

The fial pool shrunk by $42.

Section I - Council work, Proposals and Bureaucracy

31.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

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
2194 ilich 25 81 14
644 lkskrn 11 38 7
361 blackmass 14 44 8
2141 joyval 1 1 0
515 l1dev 25 91 16
635 xfactorus 28 90 16
1843 spat_sochi 6 24 4
2531 nanapa6otaet 23 77 14
1962 nkhlghbl 1 4 1
321 freakstatic_council 21 68 12
1345 kadyrovs 19 72 13
2 tomato 17 64 11
2137 kalpakci 14 53 9
1997 marinag_mary 13 46 8
2329 laura 28 108 19
790 ururu 11 44 8
319 sparky 0 0 0
1048 igrex 26 88 16
2435 zazik 25 93 17
2182 isonar 10 37 7
SUM 20 318 1123 200

31.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

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.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • 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
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

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

31.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • 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. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

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

31.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3286800
    • End Block: #3402000

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.

Scope of Work

  1. The 30th "official" Council #3085200-#3186000 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

31.I-5 - KPI Manager

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

31.I-6 - Council Insight

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

31.I-7 - Joystream Node Issues

  • Reward: $250
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Two weeks ago, we had an unfortunate event where some of our RPC and Bootnodes had gone down.
We have, and continue to, look into exactly what has happened to them, but thus far we have yet to solve the issue.

Information:

  • The nodes are running different versions. At least one was running joystream-node-5.1.0-9d9e77751.
  • The problematic seems to be #2661218, with hash 0xf5a468e133149fc094bdfa9d8842610a82fbdae10d57a4d5e980093d4691bbbc.
    • Note that this block was re-orged in (common occurance), replacing 0x7c1e11029ada770a98100f4aae3a4d4c23192343eaaf879ab57b888ae18dd841
    • Also note that it's the first block in a new era (4458)
  • One node stopped finalizing at this exact height, whereas some other continued for a little while before halting.
  • At some point, all failing nodes (that is running with --log runtime) will show:
INFO 💔 Invalid justification provided by 12D3KooWFkZZ23LoeyrpFpsDWEQwwRSWx9VaG6bwiz6jL8AE8HfS for #0x2e04…620a
  • The block in question being #2661813 with hash 0x2e04e790f04d336e2d58efb705e4773782d15041de776f755034b6355100620a
    • This happens to be the first block in a new era (4459)

Note that the "old" part 1 was completed last term.

Scope of Work

  1. Get ALL events that has to with slashing, eg. imOnline.SomeOffline, and offences.* starting from block #2000000 up until the current height. Create a dataset and chart the development of occurrences.
    (If you also get all the blocks with the event staking.payout, 3 will be significantly easier.)

  2. How many validators were there in each era, starting from #4457 up until now, and what was the set of validators? It's sufficient to check a single block in each activeEra. Provide:

  • the full validator set
  • number of validators
  • blockheight
  • era (activeEra and currentEra)
  • validator points for each era
  1. Having the data from 1 and 2, see if there is any reason to believe it implies anything "bad" happening around the problem blocks listed above.

Reward Distribution

Weighting:

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

Grading

Section II - Community Management

31.II-1 - Discord & Telegram Channel Management

  • Reward: $75
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

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

31.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

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

  • No work submitted, no rewards.

31.II-3 - Council Term Summary Videos

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #3286800
    • End Block: #3416400

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount.

Weighting:

  1. $300

Grading

31.II-4 - Community Call 1 - Part 2

  • Reward: $700
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

The Community call has been successfully held, and the raw video was uploaded here.

A little follow up work (editing, translating, etc) is needed!

Note

The reward has been reduced a bit, as these kind of videos needs to go out quickly to get the best value. Remember for next time!
(The tasks that was completed by the end of the last term will be graded with the "old" rewards)

Scope of Work

  1. Create a spreadsheet with:
  • index of the question (1, 2, etc.)
  • each question asked written in English
  • the timestamp of when the question started, in hours, minutes, seconds, milliseconds, eg. 00:20:30,4000
  • the timestamp of when the answer was finish, in hours, minutes, seconds, milliseconds, eg. 00:21:31,4100
  • if two (or more) subsequent questions are linked, such as a follow up question, make a note of it.
    Chit chat, off-topic, pauses, etc- in between questions should not be included, meaning the timestamp of the end of question 1, should in most cases not be the same as the timestamp of the start of question 2

Then, With the list from above, do an informal poll among the community, and find out which 3-10 questions is considered most interesting/important. Note that this doesn't (necessarily) mean the best question. The entertainment value is the most important element:

  • If the answer isn't very interesting, the clip won't be either!
  • If a question spurred further conversation, even if somewhat off-topic, it might still have been more interesting to watch.
  1. For each of the 3-10 "questions" from 1, create a "teaser" for each video. These should all be in the same style. Examples:
  • 2/3-off, 2s-5s clips enticing the prospective viewer to wathc the video, edited in a "nice" way
  • a concise, short "version" of the question spelled out
  • soft (license free) music?
    Note that the above are just suggestions - we hope someone in the community knows how to create engaging videos, and grow a base better than we do :)
    (Let me know if you want the chatlog!)
  1. Create a text based FAQ based on the questions that was asked. Both the question and answer needs a rewrite to make it suitable as an FAQ. This may even mean creating your question, if something interesting was said, that wasn't spurred by a direct question.

  2. Create a condensed version of the video, keeping more than the just the top rated above, but removing section that seems less interesting. How much to keep is up to you!
    (Let me know if you want the chatlog!)

  3. Create russian subtitles for the video from 2, using the .srt, or other "widespread" format.

Notes

For all videos, subtitles and artwork, you are free to upload yourself, but it has to be "CC0", and jsgenesis will likely re-upload.

Reward Distribution

For 1, only the first "good" submission will be rewarded.
For 2-3, only the best submission will be rewarded.
For 3, we are thinking it may be an iterative process, where we (may):

  • want to combine the work of two people
  • potentially request small changes/fixes
  • if/when we get something that looks great, we would want that team or person create more of these (paid) in the future
  1. $125
  2. $275
  3. $150
  4. $75
  5. $75
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

  • No work submitted, no rewards.

31.II-5 - Community Call 2 - Part 1

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

As announced on Discord, we will host a community call this Wednesday!

Scope of Work

  1. Gather questions and present them at least 2h before the scheduled start.
  2. Translate questions made in Russian (both written and oral) to English. Requires proficient (spoken) English, and a willingness to show your face on camera :)

Reward Distribution

1-2: $100 each.

Grading

Section III - Working Groups

31.III-1 - Follow up the Storage Working Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Lead tracking of the performance of each node at regular interval? If yes, is there a carrot/stick system in place?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

31.III-2 - Follow up the Content Curator Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. What is the Curator Groups system/approach for reviewing/approving each new video as they are uploaded? Are they all checked, or is that done for Bounties only?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

31.III-3 - Follow up the Operations Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

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. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Operations handling their "basic" workload as defined in the helpdesk repo?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

Section IV - Bounties

31.IV-1 - Joystream Education Series Bounty

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Note

Extended, as it's not clear if finished.

Purpose

Creating a series of explainer videos was proposed by @marinag_mary on Discord. Creating video(s) explaining in particular the Council role, and more testnet specific information was planned way back in 5.10, but never materialized. Let's try again!

Quite some topics was introduced, but I think we should start somewhere smaller and rather branch out.

As these videos:

  1. should be a series, created in the same style,
  2. will be a lot of work to get nice,
  3. will require frequent tweaking, both with feedback, and with changes to the testnet (runtime)/kpi, etc.
    I think it should be a Bounty. Who is better to write it than the Council?

Scope of Work

  1. What topics should be covered in the initial 3-5 videos? I propose:
  • How to join the project
  • What is the Councils role
  • Intro to the Joystream player
  • Intro to the governance app
    There are many other topics, and future additions should be mentioned. I think it's counterproductive to pretend like we can complete them all rather soon, if we want to uphold a certain standard. However, these four might not the be the right ones! It would be good to loop in the people doing Community Feedback, and other surveys, the AMA, etc. Anything that indicates where the pain points are really.
  1. Create a (draft) Bounty text for this series of explainer videos. Be as specific as possible, including a fairly opinionated list of:
  • What each should covered in each video
  • How they should look (animated, screensharing/screenshots, etc)
    Check out the status of the Official music theme, as that would be a nice addition!
  1. Present the draft to the council/community for approval. When approved, Jsgenesis wants to review as well.

Reward Distribution

All parts must be attempted for this to get graded.

Grading

  • (this was completed + graded as part of KPI 30.x)

31.IV-2 - Bounty Managers

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Note

Extended, as it's not clear if finished.

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.

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

Some general information can be found here.

Scope of Work

  1. For all "Official" Jsgenesis created/endorsed bounties: what is the current status of the grading/payment? Is there an action on JSG?

  2. What is the status of Bounty 27? Note that OP isn't the offical text.

  3. What is the status of Bounty 21? We have heard whispers that it's completed, but would like to know more specifics.

Reward Distribution

Weighting:

  1. $20
  2. $40
  3. $40

Grading

  • (this was completed + graded as part of KPI 30.x)

Working Group KPIs

31.CC-1 - Discover Category Videos - Part 2

  • Reward: $250
  • Fiat Pool Factor: 0.3
    • Start Block: #3186000
    • End Block: #3387600

Purpose

As part of a small update to the Joystream Player, we're adding some featured videos to each category for exploring. See example of the design here. For this, we need to curators to step in. After the leg work was done in KPI 25.CC-1, we're now ready to go live with this feature!

Notes

  • A json with the current videos can be found here.
  • Note that the timestamps (in seconds) denotes the rough start/stop of the clip.
  • A guide showing how to trim the video files can be found here.
  • The Curator Lead must also read through the further instructions here to ensure there is nothing missing between what is created and what is needed.

Scope of Work

  1. Prepare a somewhere where all the clips can be stored, and accessed (eg. dropbox, google drive, etc.). They should all be ~10s long, so this shouldn't require much storage.
  2. For each video in the list, ensure once more that it doesn't violate any license.
  3. If the video is "kosher", create a clip of the video, and upload it to the destination in 1, with the title of the file being <categoryId>-<videoId>.<extension> -> eg. 1-3.mp4 for "Did An Alternate Reality Game Gone Wrong Predict QAnon?".
  4. Update a spreadsheet that keeps the following information:
  • categoryId
  • categoryName
  • videoId
  • channelId
  • ownerId
  • title
  • Exact start of the clip (in ms)
  • Exact end of the clip (in ms)
  • Rating. (Meaning how appropriate you think this is, scale 1-5 - 5 being the best, for highlighting this category)
  1. Once they're all ready, ping me (@bwhm) and @tomato on discord. This will in the future be solely run by the community. For the time being, tomato will be the only one with the key that allows setting and changing the featured vids for a category.

Reward Distribution

This should be split among many curators, to ensure it's done quickly. The payout scheme works as following:

  • If completed within block 3207600, the reward is $250
  • If completed within block 3214800, the reward is $200
  • If completed within block 3222000, the reward is $150
  • If completed within block 3229200, the reward is $100

If not completed by the end of the term, all members of the Curator group will be annihilated for the Term.

Grading

31.OP-1 - Pioneer 2.0

  • Reward: $90
  • Fiat Pool Factor: 0.1
    • Start Block: #2883600
    • End Block: #3488400

Purpose

Now that we are finally closing in on the release launching pioneer 2.0, we want to focus on something that we've wanted to for some time. Namely giving the community both an opportunity and reason to contribute.

As we've stated many times before, we wish for the community to take charge of the platform in the future, which means they have to understand the software they're working on. Starting early, on an something that's both unfinished and that will require lots of improvements and updates sounds ideal. To make things "even better", there are both developer docs, contributor guides, and a fair amount of (good first) issues to start with!

KPI 27.OP-1 had the Lead review all the (then) open issues, and assign a dollar value for grading them. These values have been set as rewards!

Scope of Work

For each of the issues below, open a PR that gets merged. Even if the PR is merged in the end, the reward may be lower than what is stated, if:

  • There are lots of requested changes
  • It takes "too long" from the review, until the changes has been made.
  1. #888 - $60
  2. #1260 - $30

Reward Distribution

Each of the issues are graded separately. No requirement to complete all.

Grading

31.OP-2 - Giza Testing

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #2984400
    • End Block: #3286800

Purpose

As we have started testing of Giza, we want the Operations group to help in testing. The reward will be $25/h of testing. However, we need some continuity, and reliability in terms of the testers availability.

The Lead is free to select a subset of the group they think is most qualified. Qualifications:

  • Some familiarity with using the command line (linux) and git (for most, not required for all)
  • If possible, one or more that has been a storage provider
  • Basic english (for communication, documentation and instructions parsing)
  • Likes to try and break things :)

We will provide linodes for the testers to ssh into.

Scope of Work

Testing will likely continue throughout the week. Information has been/will be shared to those participating.

Grading

Sumer KPIs (old)

The old KPIs can be found here!

Antioch KPIs

Antioch KPIs can be found here!