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

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

Table of Contents

Overview

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

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

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

Current

KPI 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.

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

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

TBD

Previous KPIs

KPI 30

  • KPIs: 14+3
  • Total Possible Rewards: $3865+$465
  • Max Fiat Pool Difference: $299
  • Council Elected in Round: 32
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3085200 / 09.11.21
    • End Block/Date: #3186000 / 16.11.21
  • Deadline to Submit Summary: #3214800 / 18.11.21

Notes

Changes has been made to the Council (Deputy) Secretary KPI!

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 116 3952229
1521 arseniy2706 4 136284
361 blackmass 6 204426
2141 joyval 2 68142
515 l1dev 109 3713732
2574 alexznet 12 408851
2531 nanapa6otaet 88 2998243
2697 ardashoff 109 3713732
1962 nkhlghbl 10 340709
321 freakstatic_council 15 511064
1345 kadyrovs 71 2419037
2462 chiffah 6 204426
2 tomato 313 10664204
2137 kalpakci 3 102213
1997 marinag_mary 178 6064627
2329 laura 463 15774845
319 sparky 0 0
2435 zazik 313 10664204
582 hayabusa 10 340709
2154 marat_mu 296 10084998
SUM 20 2174 72366675

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 50 1703547

Paid out on blocks #3,258,261 and #3,258,262.

The Fiat Pool Factor resulted in the -$250.

Section I - Council work, Proposals and Bureaucracy

30.I-1 - Proposal Clearance

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

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 85 16
1521 arseniy2706 5 19 4
361 blackmass 10 31 6
2141 joyval 2 8 2
515 l1dev 15 45 9
2574 alexznet 20 63 12
2531 nanapa6otaet 17 65 13
2697 ardashoff 19 75 14
1962 nkhlghbl 13 52 10
321 freakstatic_council 24 80 15
1345 kadyrovs 22 67 13
2462 chiffah 8 29 6
2 tomato 22 68 13
2137 kalpakci 4 16 3
1997 marinag_mary 12 41 8
2329 laura 27 91 18
319 sparky 0 0 0
2435 zazik 27 96 18
582 hayabusa 13 52 10
2154 marat_mu 18 56 11
SUM 20 304 1039 200

30.I-2 - Council Secretary

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

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

30.I-3 - Deputy Council Secretary

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

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

30.I-4 - Council Minutes

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

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

30.I-5 - KPI Manager

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

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. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • 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. ~24h before the end of the Term, post the progress for each KPI on discord.
  4. When term summaries thread has been created, remind everyone who has "claimed" a KPI to post their work there.

Note
This includes WG KPIs. If no one claims this KPI, the work must be done by the Council Secretary or Deputy.

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.

Grading

30.I-6 - Council Insight

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

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

30.I-7 - Joystream Node Issues

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

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

30.I-8 - KPI Presentation - Part 2

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3092400
    • End Block: #3178800

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

Grading

  • No work submitted, no rewards.

Section II - Community Management

30.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: #3085200
    • End Block: #3186000

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

30.II-2 - Create new KPIs

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

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.

30.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: #3186000
    • End Block: #3315600

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

30.II-4 - Community Feedback - Part 2

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

Purpose

As we are closing on Giza, and further towards mainnet, it seems like a good time to get some feedback from the Community. There are a couple of ways to go about this, so it will be divided in to two tasks. The results from Part 1 can be found here and here.

The person(s) or group(s) tackling this KPI should cooperate with the whoever is tackling the Joystream Education Series Bounty.

Scope of Work

  1. The survey(s) created has been up for a while. Combine the results, from all surveys in "all" languages, and divide the questions in to (at least) three categories:
  • Questions that is best answered in a video series, eg. the Joystream Education Series.
    • Consider a sub-category for questions that fits in here, but the overall topic is not in the top priority, for whatever reason.
  • Questions that is best answered by Jsgenesis, eg. in a Q&A/AMA setting.
  • Questions that should be answered in some other context, eg. simply a reply on discord, longer article form, etc. (explain).
  1. How many people replied to the survey? How many were members, and how "active" are the members in the community (posts on discord, roles occupied, transactions made, age of membership, etc.)
  2. What is the best way to get this information in the future?

Reward Distribution

Weighting:

  1. $100
  2. $20
  3. $20

Grading

30.II-5 - Community Call - Part 2

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

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!

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. $150
  2. $350
  3. $200
  4. $100
  5. $100
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

Section III - Working Groups

Section IV - Bounties

30.IV-1 - Joystream Education Series Bounty

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

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

30.IV-2 - Bounty Managers

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

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

Working Group KPIs

30.OP-1 - Pioneer 2.0

  • Reward: $390
  • Fiat Pool Factor: 0.1
    • Start Block: #2883600
    • End Block: #3387600

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. #1566 - $90
  2. #858 - $120
  3. [#888]((https://github.com/Joystream/pioneer/issues/888) - $60
  4. #1260 - $30
  5. #1480 - $30
  6. #1497 - $60

Reward Distribution

Each of the issues are graded separately. No requirement to complete all.

Grading

30.OP-2 - Giza Testing Schedule

  • Reward: $50
  • Fiat Pool Factor: 0
    • Start Block: #3085200
    • End Block: #3200400

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.

Note that this has been delayed multiple times on Jsgenesis' account. Won't happen again!

Scope of Work

Ask the members of the Operations if they are interested, and provide a rough timetable of their availability starting from 11.11 - 19.11.

We are going to start at the latest on the 12th, but it's unclear how many days after. There will be more series' of testing to come though!

Create a table, showing their availability for the days in question, and a rough summary of the qualifications.

Grading

30.OP-3 - 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 start (latest) on the 12th of November. Information will be presented then.

Grading

  • @l1dev
    • Still in progress.

KPI 29

  • KPIs: 16+3
  • Total Possible Rewards: $4300+$540
  • Max Fiat Pool Difference: $401.5
  • Council Elected in Round: 31
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #2984400 / 02.11.21
    • End Block/Date: #3085200 / 09.11.21
  • Deadline to Submit Summary: #3114000 / 11.11.21

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 kate_fm 9 357796
2194 ilich 164 6519842
1521 arseniy2706 3 119265
644 lkskrn 6 238531
361 blackmass 5 198776
515 l1dev 107 4253799
635 xfactorus 14 556572
2096 svasilenko 305 12125315
321 freakstatic_council 13 516817
1345 kadyrovs 50 1987757
2 tomato 312 12403602
1997 marinag_mary 145 5764494
2329 laura 311 12363846
790 ururu 11 437306
319 sparky 0 0
2130 maxlevush 14 556572
1048 igrex 292 11608499
2435 zazik 238 9461722
2182 isonar 3 119265
3045 oklick 15 596327
SUM 20 2567 80186103

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
644 lkskrn 300 11926540
1905 kate_fm 50 1987757
2194 ilich 100 3975513
515 l1dev 100 3975513

Paid out on blocks #3,177,697 and #3,177,698.

The Fiat Pool was reduced by $220.

Section I - Council work, Proposals and Bureaucracy

29.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
1905 kate_fm 18 57 9
2194 ilich 24 87 14
1521 arseniy2706 4 16 3
644 lkskrn 11 40 6
361 blackmass 8 29 5
515 l1dev 11 46 7
635 xfactorus 24 87 14
2096 svasilenko 20 65 10
321 freakstatic_council 23 80 13
1345 kadyrovs 20 65 10
2 tomato 20 78 12
1997 marinag_mary 10 34 5
2329 laura 26 104 16
790 ururu 20 71 11
319 sparky 0 0 0
2130 maxlevush 25 92 14
1048 igrex 29 109 17
2435 zazik 25 95 15
2182 isonar 6 21 3
3045 oklick 24 94 15
SUM 20 348 1270 200

29.I-2 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

Note that the SoW is somewhat outdated.

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

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

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

Reward Distribution

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

Grading

29.I-3 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

Note that the SoW is somewhat outdated.
The main task for the Deputy Council Secretary is to assist and offload the Secretary.

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

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

Reward Distribution

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

Grading

29.I-4 - Council Minutes

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

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

29.I-5 - KPI Manager

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

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. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • 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. Update the post 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. ~24h before the end of the Term, post the progress for each KPI on discord.

Note
This includes WG KPIs. If no one claims this KPI, the work must be done by the Council Secretary or Deputy.

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.

Grading

29.I-6 - Council Insight

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

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

29.I-7 - Joystream Node Issues

  • Reward: $400
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2991600
    • End Block: #3078000

Purpose

Last week, 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)

Scope of Work

  1. We asked in discord whether someone else had the same issue, but the replies were all negative. We are fairly confident however that someone has indeed had this issue. Perhaps having not yet realized it. Try to reach as many validators/node runners as possible and ask them:

    1. Are you running a validator, or "just" a node?
    2. How long has it been running, and when was it last down (systemctl status joystream-node)
    3. What flags are you running? (eg. --pruning=archive, --log runtime, etc.)
    4. Which version of the node are you running, and on what OS? (/path/to/joystream-node --version)
    5. Check the logs for the blocks in question, and provide the entire output between first spotting block #2661217 for the next ~20 blocks, and the same starting from #2661813.
    6. Is your node finalizing the new blocks?
    7. If your node is not finalizing, restart it, and provide full logs for the first minute after restart.

  2. 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.)

  3. 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 2 and 3, see if there is any reason to believe it implies anything "bad" happening around the problem blocks listed above.

Reward Distribution

Weighting:

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

Grading

Section II - Community Management

29.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: #2984400
    • End Block: #3085200

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

29.II-2 - Create new KPIs

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

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

29.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: #3085200
    • End Block: #3214800

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

29.II-4 - Community Feedback - Part 2

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2984400
    • End Block: #3085200

Purpose

HOLD

Scope of Work

Reward Distribution

Grading

TBD

29.II-5 - Research Boardroom

  • Reward: $200
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2984400
    • End Block: #3085200

Purpose

Boardroom is a website that showcases the governance side of a selection of DAO projects. Some of the projects put out a weekly update which is included in a newsletter, as well as contribute to a calendar which lists updates and proposals from projects. It would be interesting to know how Joystream could integrate with Boardroom.

Scope of Work

  1. Investigate Boardroom and write a report showing whether it is possible for Joystream to integrate with it.
  • This must include what the process and/or requirements to be featured on the site
  • If there is an application process, and how this looks like
  • Whether the Community can maintain this
  • Any other any other relevant information, as well as Joystream's blockchain compatibility with the project.
  1. Are there any other Polkadot or Substrate based projects currently included on Boardroom? If yes, what are they?
  2. Are there any similar websites/platforms to Boardroom where the Joystream project could possibly be listed? These sites should similarly show proposals, newsletters and some governance information from the Joystream project alongside other projects.
  3. If possible, an indication of how many people are using Boardroom (and other similar platforms) would be useful.

Reward Distribution

1-4: $50 each

Grading

29.II-6 - Community Call - Part I

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term start + 2 days
    • Start Block: #2984400
    • End Block: #3114000

Purpose

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

Scope of Work

  1. Spread the word, ask who will join and whether they are planning any questions. Create a post on discord, with your best guesstimate on how many that will participate. The zoom join link will be posted before 17:55 CET in the #general channel on discord. Whoever is closest when the clock strikes 18:10 CET will win $100 :)

  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

29.II-7 - Community Call - Part II

  • Reward: $1000
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2984400
    • End Block: #3023300

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!

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. $150
  2. $350
  3. $200
  4. $100
  5. $100
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

TBD

Section III - Working Groups

Section IV - Bounties

29.IV-1 - Bounty Managers

Working Group KPIs

29.SP-1 - Storage Status

  • Reward: $150
  • Fiat Pool Factor: 0.25
    • Start Block: #2984400
    • End Block: #3186000

Purpose

Lately, my subjective impression is that the playing videos on the Joystream Player is slower than before. Let's get some stats!

Scope of Work

Gather as much as you can of the following data:

  • What is the current size of the Content Directory as found through hydra playground
  • How much storage does ipfs consume for the individual SPs?
  • How much bandwidth does ipfs consume for each SP per week? (Requires deducting resources for running a joystream-node etc.)
  • What are the runnning costs for each SP?
  • What is the distribution of uploads received since you were hired? (For each item, the liasion was the one that received it)
  • How good is the uptime for each node?
  • How many failed uploads have we seen since you were hired?

Note
Some of this information should be available through joystreamstats.

Grading

Completed during last term

29.OP-1 - Pioneer 2.0

  • Reward: $390
  • Fiat Pool Factor: 0.1
    • Start Block: #2883600
    • End Block: #3186000

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. #1566 - $90
  2. #858 - $120
  3. [#888]((https://github.com/Joystream/pioneer/issues/888) - $60
  4. #1260 - $30
  5. #1480 - $30
  6. #1497 - $60

Reward Distribution

Each of the issues are graded separately. No requirement to complete all.

Grading

29.OP-2 - Giza Testing

  • Reward: $25/h
  • 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 start on the 4th of November. Information will be presented then.

Grading

KPI 28

  • KPIs: 11+3
  • Total Possible Rewards: $2375+$590
  • Max Fiat Pool Difference: $96.5
  • Council Elected in Round: 30
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #2883600 / 26.10.21
    • End Block/Date: #2984400 / 02.11.21
  • Deadline to Submit Summary: #3013200 / 04.11.21

Notes

The below notes are a copypasta from the last few weeks, simply as reminders.

We're adding the new concept of having KPIs affect the fiat pool replenishment rate! As there hasn't been approved proposal to a KPI to this effect, it will work like so:

Every KPI now has a "Fiat Pool Factor", where the minimum is 0. For this round, the maximum is 1, but that may change.
This determines how much the fiat pool will grow or shrink depending on the grading. The reasoning behind it's weighting is two-fold:

  1. Important and/or urgent KPIs will get a higher number, to incentivize peer pressure and voting power behind getting it done.
  2. Some KPIs, although they can be important, will be set to zero as the reward doesn't always imply good/bad work has happened. A good examples is the Council Dissent.

How it works:
Suppose a KPI rewards up to $100, and the "Fiat Pool Factor" is 1. Suppose it's the only KPI with a factor not equal to 0.

  • If nothing has been done, the fiat pool replenishment shrinks by $100
  • If it gets graded as partially completed, and rewarded $25, the fiat pool replenishment shrinks by $50
  • It it gets graded as partially completed, and rewarded $50, the fiat pool replenishment is unchanged
  • If it gets graded as partially completed, and rewarded $75, the fiat pool replenishment grows by $50
  • If it gets graded as fully completed, and rewarded $100, the fiat pool replenishment grows by $100

If the factor is 0.2, simply multiple the calculated change from the example with 0.2.

This will be another way for us to "force" the Council to act on some of the KPIs that has been neglected for a while, in addition to the existing ones (changing rewards, changing the scope, improving the writing).

Note that if a KPI isn't completed in time for round x, but gets extended to round x+1 where it's fully completed, the net change will be zero. So although there is an incentive to deliver in time, a CM/WG Lead may "redeem" themselves!

We hope this will make things more fun, and allow for a gradual increase in the fiat pool replenishment!

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 265+45 11418354+1938965
2346 anastasiiahurina 9 387793
1541 godshunter 14 603234
1521 arseniy2706 7 301617
644 lkskrn 13 560146
361 blackmass 5 215441
2531 nanapa6otaet 92 3964108
2697 ardashoff 69 2973081
1962 nkhlghbl 94 4050284
321 freakstatic_council 16 689410
957 leet_joy 3 129264
1345 kadyrovs 57 2456023
2 tomato 1 43088
2137 kalpakci 0 0
2329 laura 586 25249643
319 sparky 0 0
1048 igrex 187 8057480
2276 joydiesel 5 215441
582 hayabusa 35 1508084
2154 marat_mu 283 12193940
SUM 20 1941+45 75016431+1938965

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2098 0x2bc 150 6463219
515 l1dev 50 2154406

Paid out on blocks 3,063,903 and 3,063,904.

Section I - Council work, Proposals and Bureaucracy

28.I-1 - Proposal Clearance

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

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 97 15
2346 anastasiiahurina 14 58 9
1541 godshunter 23 89 14
1521 arseniy2706 12 45 7
644 lkskrn 20 84 13
361 blackmass 8 32 5
2531 nanapa6otaet 23 81 13
2697 ardashoff 15 59 9
1962 nkhlghbl 22 87 14
321 freakstatic_council 27 100 16
957 leet_joy 4 16 3
1345 kadyrovs 22 82 13
2 tomato 1 4 1
2137 kalpakci 0 0 0
2329 laura 23 103 16
319 sparky 0 0 0
1048 igrex 25 111 18
2276 joydiesel 8 31 5
582 hayabusa 26 100 16
2154 marat_mu 21 85 13
SUM 20 318 1264 200

28.I-2 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

Note that the SoW is somewhat outdated.

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

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

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

Reward Distribution

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

Grading

28.I-3 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

Note that the SoW is somewhat outdated.
The main task for the Deputy Council Secretary is to assist and offload the Secretary.

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

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

Reward Distribution

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

Grading

28.I-4 - Council Minutes

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

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

28.I-5 - KPI Manager

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

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. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • 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. Update the post 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. ~24h before the end of the Term, post the progress for each KPI on discord.

Note
This includes WG KPIs. If no one claims this KPI, the work must be done by the Council Secretary or Deputy.

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.

Grading

28.I-6 - Council Insight

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

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

Section II - Community Management

28.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: #2883600
    • End Block: #2984400

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

28.II-2 - Create new KPIs

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

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

28.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: #2984400
    • End Block: #3114000

Purpose

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

Updated 30.10
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

28.II-4 - Community Feedback - Part 1

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2883600
    • End Block: #2984400

Not clear if this was completed, so extended...

Purpose

As we are closing on Giza, and further towards mainnet, it seems like a good time to get some feedback from the Community. There are a couple of ways to go about this, so it will be divided in to two tasks. This may be a recurring KPI, but let's see how the first attemot goes first!

The idea for this KPI can seen in this proposal.

Scope of Work

  1. Conduct a survey of as many community members as possible in order to identify what they consider to be the most pressing problems and issues at the moment. Make sure the respondents adds some data, links or explanation, and not "just" something like "pioneer is slow". Once the survey is ready, ping @bwhm#6514 on discord, for a quick review, then leave it open for at least 1 full week. (Part 2 will deal with the rest.)

  2. Not everyone will be willing to participate in surveys, but it is assumed that there are similar concerns raised on the forum, in proposals, on discord and on telegram. Create an issue in the community repo, and add these as you see them appear.

Reward

Weighting:

  1. $75
  2. $75

Grading

Section III - Working Groups

Section IV - Bounties

28.IV-1 - Bounty Managers

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

Purpose

Status unclear - HOLD.

Working Group KPIs

28.SP-1 - Storage Status

  • Reward: $150
  • Fiat Pool Factor: 0.25
    • Start Block: #2883600
    • End Block: #3085200

Not clear if this was completed, so extended...

Purpose

Lately, my subjective impression is that the playing videos on the Joystream Player is slower than before. Let's get some stats!

Scope of Work

Gather as much as you can of the following data:

  • What is the current size of the Content Directory as found through hydra playground
  • How much storage does ipfs consume for the individual SPs?
  • How much bandwidth does ipfs consume for each SP per week? (Requires deducting resources for running a joystream-node etc.)
  • What are the runnning costs for each SP?
  • What is the distribution of uploads received since you were hired? (For each item, the liasion was the one that received it)
  • How good is the uptime for each node?
  • How many failed uploads have we seen since you were hired?

Note
Some of this information should be available through joystreamstats.

Grading

28.OP-1 - Pioneer 2.0

  • Reward: $390
  • Fiat Pool Factor: 0.1
    • Start Block: #2883600
    • End Block: #3186000

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. #1566 - $90
  2. #858 - $120
  3. [#888]((https://github.com/Joystream/pioneer/issues/888) - $60
  4. #1260 - $30
  5. #1480 - $30
  6. #1497 - $60

Reward Distribution

Each of the issues are graded separately. No requirement to complete all.

Grading

28.OP-2 - Giza Testing Schedule

  • Reward: $50
  • Fiat Pool Factor: 0
    • Start Block: #2883600
    • End Block: #3027600

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

Ask the members of the Operations if they are interested, and provide a rough timetable of their availability starting from 29.10 - 12.11.
Note that the testing will most likely occur mostly from 01.11-05.11, between 10:00-20:00 CET (not CEST).
Create a table, showing their availability for the days in question, and a rough summary of the qualifications.

Grading

KPI 27

  • KPIs: 13+3
  • Total Possible Rewards: $3275+$850
  • Max Fiat Pool Difference: $592.5
  • Council Elected in Round: 29
  • Council Members: 16
  • KPI Length: 7 days / 100800
    • Start Block/Date: #2782800 / 18.10.21
    • End Block/Date: #2883600 / 27.10.21
  • Deadline to Submit Summary: #2912400 / 29.10.21

Notes

(Notes are the same as last week ones!)
We're adding the new concept of having KPIs affect the fiat pool replenishment rate! As there hasn't been approved proposal to a KPI to this effect, it will work like so:

Every KPI now has a "Fiat Pool Factor", where the minimum is 0. For this round, the maximum is 1, but that may change.
This determines how much the fiat pool will grow or shrink depending on the grading. The reasoning behind it's weighting is two-fold:

  1. Important and/or urgent KPIs will get a higher number, to incentivize peer pressure and voting power behind getting it done.
  2. Some KPIs, although they can be important, will be set to zero as the reward doesn't always imply good/bad work has happened. A good examples is the Council Dissent.

How it works:
Suppose a KPI rewards up to $100, and the "Fiat Pool Factor" is 1. Suppose it's the only KPI with a factor not equal to 0.

  • If nothing has been done, the fiat pool replenishment shrinks by $100
  • If it gets graded as partially completed, and rewarded $25, the fiat pool replenishment shrinks by $50
  • It it gets graded as partially completed, and rewarded $50, the fiat pool replenishment is unchanged
  • If it gets graded as partially completed, and rewarded $75, the fiat pool replenishment grows by $50
  • If it gets graded as fully completed, and rewarded $100, the fiat pool replenishment grows by $100

If the factor is 0.2, simply multiple the calculated change from the example with 0.2.

This will be another way for us to "force" the Council to act on some of the KPIs that has been neglected for a while, in addition to the existing ones (changing rewards, changing the scope, improving the writing).

Note that if a KPI isn't completed in time for round x, but gets extended to round x+1 where it's fully completed, the net change will be zero. So although there is an incentive to deliver in time, a CM/WG Lead may "redeem" themselves!

We hope this will make things more fun, and allow for a gradual increase in the fiat pool replenishment!

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 265 10283545
1521 arseniy2706 33 1280592
644 lkskrn 361 14008904
361 blackmass 10 388058
2141 joyval 1 38806
605 okayko 5 194029
2098 0x2bc 6 232835
635 xfactorus 14 543282
2096 svasilenko 214 8304447
2531 nanapa6otaet 39 1513427
321 freakstatic_council 11 426864
2462 chiffah 2 77612
2 tomato 1 38806
2137 kalpakci 3 116417
2329 laura 808 31355110
790 ururu 15 582087
1048 igrex 262 10167127
2682 alenleps 66 2561185
2182 isonar 178 6907438
2154 marat_mu 360 13970098
SUM 20 2804 102990669

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 150 5820874

Payous done on blocks #2,949,530 and 2,949,531.

Section I - Council work, Proposals and Bureaucracy

27.I-1 - Proposal Clearance

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

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 100 15
1521 arseniy2706 15 51 8
644 lkskrn 22 74 11
361 blackmass 19 64 10
2141 joyval 1 4 1
605 okayko 9 33 5
2098 0x2bc 10 37 6
635 xfactorus 28 94 14
2096 svasilenko 28 93 14
2531 nanapa6otaet 26 95 14
321 freakstatic_council 21 75 11
2462 chiffah 4 15 2
2 tomato 2 8 1
2137 kalpakci 7 22 3
2329 laura 29 116 18
790 ururu 30 101 15
1048 igrex 30 111 17
2682 alenleps 31 104 16
2182 isonar 15 54 8
2154 marat_mu 18 66 10
SUM 20 370 1317 200

27.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2782800
    • End Block: #2883600

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

27.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2790000
    • End Block: #2876400

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

27.I-4 - Council Minutes

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

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

27.I-5 - KPI Presentation

  • Reward: $500
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2790000
    • End Block: #2876400

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.

The first key part, which will be addressed separately, is to store the data in a json or yaml format, making so that it can be presented in a flexible way.

The second is to start thinking about the design. It's not if this is a task the Council is currently able to attempt, as design is hard. What can be done however, is to write a design brief. In order to do that, we need to establish what the page must and should contain.

Note that what we're doing here, isn't solely being able to read a single, ungraded KPI, but create (a) page(s) where all the KPI information can be kept in a functional way.

Note
Extended from last Term. Not clear exactly what is finished.

Scope of Work.

  1. List "all of the things" such a page should contain. This can include, but is not limited to:
  • The current KPIs
  • Full (or at least covering a significant part of the) KPI history, with results and stats.
    • Links to all the work that was done
    • Links to all the old term summaries
    • Stats on how many KPIs were "done" per round
    • Stats on how much was earned for each KPI
    • Stats on how many KPIs each member has done, how much they've earned, and how many councils they've been a part
    • etc.
  • Not clear if these belongs here, and much less clear if it should be prioritized early, but:
    • Should this "page" also track the token value and inflation over time?
    • Should it include some way to "claim" you want to work on a task, and other "KPI manager" tools?
    • What else?

Use what you find (as a group, this likely requires input from several sources) in one, to either:

  1. Write a design brief, covering at least current KPIs.

  2. Create a wireframe of (at least) the current KPIs. We have been using balsamiq for these things, and will re-imburse anyone giving it a go. If you prefer other tools, preferably open source, that would be even better!

Reward Distribution

Grading will be shared across the contributors for 1, individual for 2 and 3.

Weighting:

  1. 200
  2. 100
  3. 200

Grading

  • @isonar - $170
    • https://pioneer.joystreamstats.live/#/forum/threads/707?page=1&replyIdx=4 (SOW 3)
      • This design does a good job of simplifying the information shown, in particular the dropdown box for each KPI round looks like a good idea. It is a little unclear how the unassigned/graded parts would work and although a link to an admin control panel was provided (which was beyond the scope of this KPI) I was unable to get it working.
      • The only potential negative is that maybe the two column design is a little confusing in terms of readability. It would also be nice to see the headings for each set of KPIs (i.e. Section II - Community Management) which are collapsible.
      • It is also a little unclear from the provided screenshot what is shown when using the View Details button. It is assumed that the full description is shown.
      • The design also doesn't include dates for each KPI round, nor deadline information. This information should be included for both the current KPIs as well as historical KPIs.
  • @svasilenko - $0

27.I-6 - KPI Manager

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

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. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • 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. Update the post 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. ~24h before the end of the Term, post the progress for each KPI on discord.

Note
This includes WG KPIs. If no one claims this KPI, the work must be done by the Council Secretary or Deputy.

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.

Grading

Section II - Community Management

27.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: #2782800
    • End Block: #2883600

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

27.II-2 - Create new KPIs

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

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.

27.II-3 - Minting and Burning - Part 2

  • Reward: $400
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #2790000
    • End Block: #2876400

Purpose

See KPI 25.II-3 for part 1, and grading!

Although lots were solved for this KPI, there are still some issues to sort out! Note that I haven't "finely" read the code, so some of the issues below may be explained from that.

Scope of Work

  1. Missing from SoW 1 from Part 1. An exhaustive list of all the things which CAN impact the issuance. This should include:
  • A list of all events that may affect issuance, and how to find them from the chain state. Note that you sometimes need to parse the corresponding extrinsic to find the number.
  • A list of non-events that may impact issuance, and how to figure it out using the chain state.
    This should include both a written explaination, and a snippet of code.
  1. Missing from SoW 3 from Part 1. There were 49 blocks that included an unexplained delta between the expected issuance and the actual issuance. These can be found here. Go through each block (many appear similar, so solve one, solve many), and try and figure out what the cause of the discrepancy was. Once solved, add an explaination and "fix" the code so that future runs will not have this error. Some hints:
  • When an exchange of tJOY is done, the tokens sent to 5D5PhZQNJzcJXVBxwJxZcsutjKPqUPydrvpu6HeiBfMaeKQu will be sent back to the same account, with the full amount as a "tip". This gets burned. All extrinsic MAY include a tip. Examples in block 746873 and 860789.
    • It appears the script gets the "burning" numbers from the status server. This is not a reliable source, and should be replaced by the aforementioned tip check.
  • When a member is registered through the player onboarding, the member is added by a screener, and no fee is paid. Examples in blocks 776192, 1199575 and 1262558
  • If a mint is empty, tokens that "should" have been minted, will not get minted. This can affect both proposals, and worker rewards.
  • When someone is hired to the operations group, the staked tokens are burned due to a bug in the runtime. This will get corrected, but is still the case.

  1. Once updated, do a new "run", and collect all the warn blocks still remaining. Hypothesize over what the source of error can be for each of them.

  2. If there is anything in the code where you have simply corrected the error through "guessing", or fetched it from another source than the state, explain what they are, and where in the code it is. Examples:

  • Is the amount burned when a member is registered a constant you have added (100), or taken from the chain constants?
  • Is the amount minted when the screener adds a member a constant from the chain, or "manual"?
  1. Update the PR, so that it:
  • contains all the newest code, but moved to a new root directory, called joystream-api. Make sure it builds when cloning the repo
  • all the text and information can be kept where they are
    • contains all the warn blocks
    • instead of leaving the entire log in there, upload it as a "gist", and add a link to it

Reward Distribution

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

Grading

  • @lkskrn - $350
    • https://pioneer.joystreamstats.live/#/forum/threads/707?page=1&replyIdx=8
      • Comments for SoW 1
        • Some things are missing here, but probably not occurred in practice
          • proposal slashed
          • workers slashed
          • validator slashed
        • wrt. tip, every extrinsic can be made with it tip, so although these may be the instances where they have been "seen", a general explanation should be rephrased
        • wrt. worker rewards, all checking the value of a mint may be easier, if not (always) as precise.

27.II-4 - Council Term Summary Videos

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #2883600
    • End Block: #3013200

Purpose

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

Scope of Work

  1. Record a video (in English) presenting the "highlights" of the Term, from a community point of view. The video should be recorded after the following information is secured:
  • The Council Minutes
  • A KPI status update, made by the Council Secretary. Example
  • As many of the Term Summaries as possible.

This means the video should be recorded approximately two days after the end of the Term.
Some potential topics:

  • Who were on the Council
  • Fiat Pool and exchange rate changes
  • Any changes to the workers or Leads?
  • Did something fun happen?

  1. We imagine the format will change over time, and with feedback, but in order to bootstrap it, someone has to give it a go. After you made your video, create a forum thread for feedback/discussion. Then create a text proposal with the format you opted for, and a link to the forum post.

  2. Have the video re-recorded in Russian, either by yourself, or someone else.

Note

Ideally, this should be a running project (ie. no longer be a KPI) once it "settles". In the meantime, if you are fluent in both languages you can make both. If not, collaborate with someone that masters the "other" language.

Reward Distribution

Individual grading. If more than one CM creates (a) video(s), the reward is not capped. So multiple people can all earn $400 each.

Weighting:

  1. $300
  • Soft cap, an extremely good video may earn even more.
  • A 1 min short where someone is reading the Council Minutes will not earn anything.
  1. $50
  2. $150

Grading

  • For all:
    • Great to hear real voices this time :)
    • All videos mainly show only screenshots/recordings of proposals etc. As mentioned last week, this will be "punished" quite a bit.
  • @igrex
  • @laura
  • @marat_mu

27.II-5 - Community Feedback - Part 1

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2782800
    • End Block: #2883600

Purpose

As we are closing on Giza, and further towards mainnet, it seems like a good time to get some feedback from the Community. There are a couple of ways to go about this, so it will be divided in to two tasks. This may be a recurring KPI, but let's see how the first attemot goes first!

The idea for this KPI can seen in this proposal.

Scope of Work

  1. Conduct a survey of as many community members as possible in order to identify what they consider to be the most pressing problems and issues at the moment. Make sure the respondents adds some data, links or explanation, and not "just" something like "pioneer is slow". Once the survey is ready, ping @bwhm#6514 on discord, for a quick review, then leave it open for at least 1 full week. (Part 2 will deal with the rest.)

  2. Not everyone will be willing to participate in surveys, but it is assumed that there are similar concerns raised on the forum, in proposals, on discord and on telegram. Create an issue in the community repo, and add these as you see them appear.

Reward

Weighting:

  1. $75
  2. $75

Grading

Section III - Working Groups

27.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: #2790000
    • End Block: #2876400

Purpose

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

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

There has been little follow up of this WG lately - perhaps all the way back since a new Lead was hired.

Scope of Work

  1. Has the Lead submitted reports? If yes:
  • Are they providing helpful insight to the status?
  • Do they include any stats, from helios or otherwise?
  1. How many workers have they hired or fired since the Lead was hired? What is the current spending of the WG, and what was it when they started?
  2. Assist the Lead in their WG KPI for the Term.

Reward Distribution

Weighting:

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

Grading

  • @laura - $90
    • https://pioneer.joystreamstats.live/#/forum/threads/707?page=1&replyIdx=9
      • SOW 1: $10/$50
        • Did not include a summary on whether the reports include enough information/statistics. Although it states there is "useful status information" more detail is necessary.
      • SOW 2: $30/$50
        • Partially covered what was required by the SOW, however it did not include actual spending information and only broad budget information. Actual spending information should include the weekly mint usage by the working group.
      • SOW 3: $50/50

Section IV - Bounties

27.IV-1 - Bounty Managers

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

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets.

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. Review the Status of all Open Bounties, as they appear here.
  • What is the progress?
  • How many have a Bounty Manager, how many do not?
  • How many were created by JSG?
  • How much has been paid out in the last month?
  1. Check the issues community repo, and see how many are Bounties are either Drafts, or simply not (yet) published to the bounty-json.
  • How many are created by the community?
  • What is missing for these to go live?
  1. If they are created by Jsg, and not yet live, ensure they do!

Reward Distribution

Weighting:

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

Grading

Working Group KPIs

27.CC-1 - Free Editing Tools

  • Reward: $500
  • Fiat Pool Factor: 0.2
    • Start Block: #2782800
    • End Block: #2984400

Purpose

The Curators will sometimes need to be able to edit videos. For example in order to create previews/teasers. Although it's doubtful the best tools are available for free, there may go some that are good enough!

Scope of Work

Research video editing software that has (some) the following functionalities, in order of priority:
A) Cut and splice videos
B) Add still images
C) Add/replace audio tracks (for specific frames only)
D) Transcoding (change the video format, without negatively affecting the audio/video quality)

For each of the Operative System below, test the default software, and search for the "top" recommended free alternatives, and report back:

  • If possible (A-D)
  • Ease of use
  • Quality of end product
  • Precision (eg. can you cut from specific frame, or by second?)
  • What file formats are supported
  1. In browser tools
  2. Windows
  3. MacOS
  4. Linux (ubuntu)

Reward Distribution

Unlike most WG KPIs, you do not have to submit all at once in order to be graded. The same person does not have to do them all.

Weighting:
1: $200
2-3: Depends on which OS is most used by the current Curator group.

  • The most used OS: $150
  • The second most used OS: $100
  • The least used OS: $50

Grading

  • @laura - $150
    • https://pioneer.joystreamstats.live/#/forum/threads/707?page=1&replyIdx=9
      • @igrex ( https://pioneer.joystreamstats.live/#/forum/threads/707?page=1&replyIdx=7)
      • SOW 1: $75
        • Includes some promising looking browser-based video editors. Did not include links.
        • It does not appear that any of the software was tested as required by the KPI. The report information only includes lists of formats, but is not clear on whether these formats can be ingested by the software or exported.
      • SOW 2-3: $75
        • Did not identify which OS is most commonly used by curators.
        • Included some powerful editors that are free.
        • Included tools which are products that require payment, which is not within the scope of the KPI.
        • It does not appear that any of the software was tested as required by the KPI. The report information only includes lists of formats, but is not clear on whether these formats can be ingested by the software or exported.

27.SP-1 - Storage Status

  • Reward: $150
  • Fiat Pool Factor: 0.25
    • Start Block: #2782800
    • End Block: #2984400

Purpose

Lately, my subjective impression is that the playing videos on the Joystream Player is slower than before. Let's get some stats!

Scope of Work

Gather as much as you can of the following data:

  • What is the current size of the Content Directory as found through hydra playground
  • How much storage does ipfs consume for the individual SPs?
  • How much bandwidth does ipfs consume for each SP per week? (Requires deducting resources for running a joystream-node etc.)
  • What are the runnning costs for each SP?
  • What is the distribution of uploads received since you were hired? (For each item, the liasion was the one that received it)
  • How good is the uptime for each node?
  • How many failed uploads have we seen since you were hired?

Note
Some of this information should be available through joystreamstats.

Grading

  • No work submitted, no rewards.

27.OP-1 - Pioneer 2.0

  • Reward: $400
  • Fiat Pool Factor: 0.25
    • Start Block: #2782800
    • End Block: #2984400

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!

Scope of Work

  1. Find your way in to the pioneer repo, try out the build, and play around a bit.
  2. Read through the aforementioned contribution guidelines and developer docs. If they're helpful and all you need, great! If not, make an issue with your feedback.
  3. Review the "good first issue"(s), and estimate the time needed to solve each of them, assuming you are somewhat comfortable with the stack, but no knowledge of codebase. If anything is unclear in any of the issues, ask kindly for clarification.
  4. Provide feedback on how these issues would best be presented to the community. By that, I mean:
  • Should it be separate bounties for all the n issues?
  • Should there be n-k bounties for these n issues?
  • Should they instead be KPIs, or simply general tasks for (one or more of) the operations group(s) to tackle?
  • Other?
    Present your findinds not through an issue in the pioneer repo this time, but rather in the community repo.

Grading

KPI 26

  • KPIs: 10+3
  • Total Possible Rewards: $2825+$900
  • Max Fiat Pool Difference: $1035
  • Council Elected in Round: 28
  • Council Members: 16
  • KPI Length: 7 days / 100800
    • Start Block/Date: #2696400 / 12.10.21
    • End Block/Date: #2797200 / 19.10.21
  • Deadline to Submit Summary: #2826000 / 21.10.21

Notes

(Notes are the same as last week ones!)
We're adding the new concept of having KPIs affect the fiat pool replenishment rate! As there hasn't been approved proposal to a KPI to this effect, it will work like so:

Every KPI now has a "Fiat Pool Factor", where the minimum is 0. For this round, the maximum is 1, but that may change.
This determines how much the fiat pool will grow or shrink depending on the grading. The reasoning behind it's weighting is two-fold:

  1. Important and/or urgent KPIs will get a higher number, to incentivize peer pressure and voting power behind getting it done.
  2. Some KPIs, although they can be important, will be set to zero as the reward doesn't always imply good/bad work has happened. A good examples is the Council Dissent.

How it works:
Suppose a KPI rewards up to $100, and the "Fiat Pool Factor" is 1. Suppose it's the only KPI with a factor not equal to 0.

  • If nothing has been done, the fiat pool replenishment shrinks by $100
  • If it gets graded as partially completed, and rewarded $25, the fiat pool replenishment shrinks by $50
  • It it gets graded as partially completed, and rewarded $50, the fiat pool replenishment is unchanged
  • If it gets graded as partially completed, and rewarded $75, the fiat pool replenishment grows by $50
  • If it gets graded as fully completed, and rewarded $100, the fiat pool replenishment grows by $100

If the factor is 0.2, simply multiple the calculated change from the example with 0.2.

This will be another way for us to "force" the Council to act on some of the KPIs that has been neglected for a while, in addition to the existing ones (changing rewards, changing the scope, improving the writing).

Note that if a KPI isn't completed in time for round x, but gets extended to round x+1 where it's fully completed, the net change will be zero. So although there is an incentive to deliver in time, a CM/WG Lead may "redeem" themselves!

We hope this will make things more fun, and allow for a gradual increase in the fiat pool replenishment!

Grading

CMs:

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 kate_fm 84 3256351
2194 ilich 318 12327616
644 lkskrn 18 697790
361 blackmass 4 155064
515 l1dev 180 6977896
2096 svasilenko 138 5349720
2531 nanapa6otaet 36 1395579
321 freakstatic_council 12 465193
2462 chiffah 15 581491
2 tomato 3 116298
736 mmsaww 7 271363
2137 kalpakci 12 465193
2329 laura 621 24073741
2130 maxlevush 13 503959
2435 zazik 80 3101287
2154 marat_mu 304 11784891
SUM 16 2245 71523432

WGs:

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 400 15506435

Paid out at blocks #2,864,063 and #2,864,064.

The fiat pool factor ensured a growth of $335 -> $2015 in reccuring rewards.

Section I - Council work, Proposals and Bureaucracy

26.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
1905 kate_fm 27 101 19
2194 ilich 24 95 18
644 lkskrn 23 94 18
361 blackmass 6 21 4
515 l1dev 8 25 5
2096 svasilenko 17 67 13
2531 nanapa6otaet 16 55 11
321 freakstatic_council 15 64 12
2462 chiffah 19 78 15
2 tomato 4 18 3
736 mmsaww 11 35 7
2137 kalpakci 16 61 12
2329 laura 27 110 21
2130 maxlevush 17 65 13
2435 zazik 21 76 15
2154 marat_mu 20 75 14
SUM 16 271 1040 200

26.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2696400
    • End Block: #2797200

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

26.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2703600
    • End Block: #2790000

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

26.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #2797200
    • End Block: #2811600

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

26.I-5 - KPI Presentation

  • Reward: $500
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2703600
    • End Block: #2790000

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.

The first key part, which will be addressed separately, is to store the data in a json or yaml format, making so that it can be presented in a flexible way.

The second is to start thinking about the design. It's not if this is a task the Council is currently able to attempt, as design is hard. What can be done however, is to write a design brief. In order to do that, we need to establish what the page must and should contain.

Note that what we're doing here, isn't solely being able to read a single, ungraded KPI, but create (a) page(s) where all the KPI information can be kept in a functional way.

Scope of Work.

  1. List "all of the things" such a page should contain. This can include, but is not limited to:
  • The current KPIs
  • Full (or at least covering a significant part of the) KPI history, with results and stats.
    • Links to all the work that was done
    • Links to all the old term summaries
    • Stats on how many KPIs were "done" per round
    • Stats on how much was earned for each KPI
    • Stats on how many KPIs each member has done, how much they've earned, and how many councils they've been a part
    • etc.
  • Not clear if these belongs here, and much less clear if it should be prioritized early, but:
    • Should this "page" also track the token value and inflation over time?
    • Should it include some way to "claim" you want to work on a task, and other "KPI manager" tools?
    • What else?

Use what you find (as a group, this likely requires input from several sources) in one, to either:

  1. Write a design brief, covering at least current KPIs.

  2. Create a wireframe of (at least) the current KPIs. We have been using balsamiq for these things, and will re-imburse anyone giving it a go. If you prefer other tools, preferably open source, that would be even better!

Reward Distribution

Grading will be shared across the contributors for 1, individual for 2 and 3.

Weighting:

  1. 200
  2. 100
  3. 200

Grading

Section II - Community Management

26.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: #2696400
    • End Block: #2797200

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

26.II-2 - Create new KPIs

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

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

26.II-3 - Council Term Summary Videos

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #2797200
    • End Block: #2926800

Purpose

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

Scope of Work

  1. Record a video (in English) presenting the "highlights" of the Term, from a community point of view. The video should be recorded after the following information is secured:
  • The Council Minutes
  • A KPI status update, made by the Council Secretary. Example
  • As many of the Term Summaries as possible.

This means the video should be recorded approximately two days after the end of the Term.
Some potential topics:

  • Who were on the Council
  • Fiat Pool and exchange rate changes
  • Any changes to the workers or Leads?
  • Did something fun happen?

  1. We imagine the format will change over time, and with feedback, but in order to bootstrap it, someone has to give it a go. After you made your video, create a forum thread for feedback/discussion. Then create a text proposal with the format you opted for, and a link to the forum post.

  2. Have the video re-recorded in Russian, either by yourself, or someone else.

Note

Ideally, this should be a running project (ie. no longer be a KPI) once it "settles". In the meantime, if you are fluent in both languages you can make both. If not, collaborate with someone that masters the "other" language.

Reward Distribution

Individual grading. If more than one CM creates (a) video(s), the reward is not capped. So multiple people can all earn $400 each.

Weighting:

  1. $300
  • Soft cap, an extremely good video may earn even more.
  • A 1 min short where someone is reading the Council Minutes will not earn anything.
  1. $50
  2. $150

Grading

Section III - Working Groups

26.III-1 - Deputy Working Group Lead

  • Reward: $200
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #2703600
    • End Block: #2790000

Purpose

The WG Lead is expected to be available and active, but just as any other job, it's impossible to be available 24/7.

The idea of having deputy leads was raised again last Term. As has having Leads in shifts. What should each working group do?

Scope of Work

For each of the WGs:

  1. Is the groups output, productivity and/or efficiency hampered by the Lead? Is that person a bottleneck for getting things done? (This is not meant to imply the Lead is underperforming. As groups have grown, the workload has followed!)

  2. There are at least three options for each group:

  • Keep the leadership hierarchy as is
  • Assign a deputy Lead
  • Have two (or more) people share the title as Lead
    • Can be done on-chain, or off-chain (by sharing account)
      What seems like the most "applicable" for each group?
  1. What does the Leads themselves think of this?

Reward Distribution

Grading is individual.

Weighting:
1,3: $50
2: $100

Grading

Section IV - Bounties

26.IV-1 - Weekly Bounty Managers

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #2696400
    • End Block: #2797200

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. Manage Bounty #9
    After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

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

  3. There are currently 10 more open Bounties, some of them not created/funded by Jsgenesis. Which one of these has a format which lends themselves to weekly Bounty Managers?

Reward Distribution

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

Weighting:
1: $50
2: $100
3: $100

Grading

Working Group KPIs

26.OP-1 - Runtime Upgrade Verification

  • Reward: $300
  • Fiat Pool Factor: 1.5
    • Start Block: #2696400
    • End Block: #2898000

Purpose

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

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

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

Note

Extended from last KPI round, with small reward increase.

Scope of Work

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

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

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

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

Grading

  • completed in the last term

26.OP-2 - Event Email Service

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #2696400
    • End Block: #2998800

Purpose

It can be quite useful to have notifications setup for various on chain events. The telegram/discord bots partially fulfills this role, but it could be equally, or more, useful to have email notifications as well!

Scope of Work

  1. Outline the feasibility of deploying a hosted service for this, where a user can sign up, and choose from a list of events to which they want subscribe.

  2. Outline the feasibility of building a self hosted service for users that are running nodes themselves. This would mean making the source code available on our community repo, where users can compile, configure and run it themselves.

  3. Estimate the hours and resource needed to build these tools, and the resource consumption for a user running it themselves like in 2.

Grading

  • completed in the last term

26.OP-3 - Pioneer 2.0

  • Reward: $400
  • Fiat Pool Factor: 0.5
    • Start Block: #2696400
    • End Block: #2898000

Purpose

Not 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!

Scope of Work

  1. Find your way in to the pioneer repo, try out the build, and play around a bit.
  2. Read through the aforementioned contribution guidelines and developer docs. If they're helpful and all you need, great! If not, make an issue with your feedback.
  3. Review the "good first issue"(s), and estimate the time needed to solve each of them, assuming you are somewhat comfortable with the stack, but no knowledge of codebase. If anything is unclear in any of the issues, ask kindly for clarification.
  4. Provide feedback on how these issues would best be presented to the community. By that, I mean:
  • Should it be separate bounties for all the n issues?
  • Should there be n-k bounties for these n issues?
  • Should they instead be KPIs, or simply general tasks for (one or more of) the operations group(s) to tackle?
  • Other?
    Present your findinds not through an issue in the pioneer repo this time, but rather in the community repo.

Reward Distribution

Grading is individual.

Grading

KPI 25

  • KPIs: 15+3
  • Total Possible Rewards: $4125+$750
  • Max Fiat Pool Difference: $925
  • Council Elected in Round: 27
  • Council Members: 16
  • KPI Length: 7 days / 100800
    • Start Block/Date: #2595600 / 05.10.21
    • End Block/Date: #2696400 / 12.10.21
  • Deadline to Submit Summary: #2725200 / 14.10.21

Notes

We're adding the new concept of having KPIs affect the fiat pool replenishment rate! As there hasn't been approved proposal to a KPI to this effect, it will work like so:

Every KPI now has a "Fiat Pool Factor", where the minimum is 0. For this round, the maximum is 1, but that may change.
This determines how much the fiat pool will grow or shrink depending on the grading. The reasoning behind it's weighting is two-fold:

  1. Important and/or urgent KPIs will get a higher number, to incentivize peer pressure and voting power behind getting it done.
  2. Some KPIs, although they can be important, will be set to zero as the reward doesn't always imply good/bad work has happened. A good examples is the Council Dissent.

How it works:
Suppose a KPI rewards up to $100, and the "Fiat Pool Factor" is 1. Suppose it's the only KPI with a factor not equal to 0.

  • If nothing has been done, the fiat pool replenishment shrinks by $100
  • If it gets graded as partially completed, and rewarded $25, the fiat pool replenishment shrinks by $50
  • It it gets graded as partially completed, and rewarded $50, the fiat pool replenishment is unchanged
  • If it gets graded as partially completed, and rewarded $75, the fiat pool replenishment grows by $50
  • If it gets graded as fully completed, and rewarded $100, the fiat pool replenishment grows by $100

If the factor is 0.2, simply multiple the calculated change from the example with 0.2.

This will be another way for us to "force" the Council to act on some of the KPIs that has been neglected for a while, in addition to the existing ones (changing rewards, changing the scope, improving the writing).

Note that if a KPI isn't completed in time for round x, but gets extended to round x+1 where it's fully completed, the net change will be zero. So although there is an incentive to deliver in time, a CM/WG Lead may "redeem" themselves!

We hope this will make things more fun, and allow for a gradual increase in the fiat pool replenishment!

Grading

Due to the Fiat Pool Factor, the Fiat Pool replinshment grows by $605.

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 362 13971267
644 lkskrn 441 17020246
2141 joyval 1 38595
515 l1dev 8 308757
2096 svasilenko 181 6985634
321 freakstatic_council 16 617515
957 leet_joy 1 38595
2462 chiffah 120 4631359
2 tomato 3 115784
736 mmsaww 12 463136
2137 kalpakci 17 656109
2329 laura 362 13971267
2836 art_khabibullin 4 154379
790 ururu 17 656109
2130 maxlevush 12 463136
1048 igrex 195 7525959
SUM 16 2467 67617847

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 215 8297852
515 l1dev 500 19297331

Section I - Council work, Proposals and Bureaucracy

25.I-1 - Proposal Clearance

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

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 29 131 22
644 lkskrn 23 98 16
2141 joyval 3 9 1
515 l1dev 12 48 8
2096 svasilenko 23 91 15
321 freakstatic_council 24 99 16
957 leet_joy 2 8 1
2462 chiffah 23 95 16
2 tomato 5 20 3
736 mmsaww 17 70 12
2137 kalpakci 27 102 17
2329 laura 30 134 22
2836 art_khabibullin 6 24 4
790 ururu 27 105 17
2130 maxlevush 17 70 12
1048 igrex 26 103 17
SUM 16 294 1207 200

25.I-2 - Council Dissent

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2595600
    • End Block: #2696400

Purpose

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

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

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

Note

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

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

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

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

Scope of Work

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

  1. Raise concerns
A

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

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

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

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

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

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

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

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

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

Reward Distribution

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

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

Further:

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

Reporting

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

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

Grading

25.I-3 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #2595600
    • End Block: #2696400

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

25.I-4 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #2602800
    • End Block: #2689200

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

25.I-5 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.5
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #2696400
    • End Block: #2811600

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

25.I-6 - Runtime Paramaters

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

Purpose

A new runtime upgrade is coming up. What could/should be changed?

Scope of Work

  1. Create a text proposal outlining any runtime parameters that you would like changed, and why. If the proposal is approved, Jsgenesis will review and provide feedback.

Reward Distribution

Grading is individual.

The rewards will be based on the level of details presented in the proposal. A proposal pointing to the exact line that needs to be changed, what it does and what the secondary effects are will earn more than "Make X higher".

Grading

  • 25.I-6 - Runtime Parameters ($500)
    • No work submitted, no rewards.

Section II - Community Management

25.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: #2595600
    • End Block: #2696400

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

25.II-2 - Create new KPIs

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

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

25.II-3 - Minting and Burning - Part 1

  • Reward: $700
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #2602800
    • End Block: #2689200

Purpose

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

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

Note

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

Scope of Work

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

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

  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

  2. Create a script that, at every block:

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

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

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

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

Reward Distribution

Individual grading.

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

Grading

  • lkskrn - $425
    • https://testnet.joystream.org/#/forum/threads/671?replyIdx=2
    • https://testnet.joystream.org/#/proposals/672
      1. Not really done ($50)
        • Some examples (of events) are listed, but this is meant to be a comprehensive list.
        • How does each of them affect the issuance?
      2. Completed ($250)
      3. Partially completed ($125).
        • It's not clear how much "research" is done in the cases where there is a discrepancy.
          • In some cases, it's somewhat "clear" from looking at the block what the reason was.
        • It appears that some blocks may be missing, as similar transaction only sometimes triggers a [WARN]. Not deducted for this.

25.II-4 - Council Term Summary Videos

  • Reward: $500
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #2696400
    • End Block: #2826000

Purpose

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

Scope of Work

  1. Record a video (in English) presenting the "highlights" of the Term, from a community point of view. The video should be recorded after the following information is secured:
  • The Council Minutes
  • A KPI status update, made by the Council Secretary. Example
  • As many of the Term Summaries as possible.

This means the video should be recorded approximately two days after the end of the Term.
Some potential topics:

  • Who were on the Council
  • Fiat Pool and exchange rate changes
  • Any changes to the workers or Leads?
  • Did something fun happen?

  1. We imagine the format will change over time, and with feedback, but in order to bootstrap it, someone has to give it a go. After you made your video, create a forum thread for feedback/discussion. Then create a text proposal with the format you opted for, and a link to the forum post.

  2. Have the video re-recorded in Russian, either by yourself, or someone else.

Note

Ideally, this should be a running project (ie. no longer be a KPI) once it "settles". In the meantime, if you are fluent in both languages you can make both. If not, collaborate with someone that masters the "other" language.

Reward Distribution

Individual grading. If more than one CM creates (a) video(s), the reward is not capped. So multiple people can all earn $400 each.

Weighting:

  1. $300
  • Soft cap, an extremely good video may earn even more.
  • A 1 min short where someone is reading the Council Minutes will not earn anything.
  1. $50
  2. $150

Grading

  • No work submitted, no rewards.

Section III - Working Groups

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

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

Note

As we are about to launch a new system, it seems a bit redundant to spend to much resources on this atm.

25.III-2 - Follow up the Content Curators Working Group

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

Note

HOLD

25.III-3 - Follow up the Operations Working Group

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

Note

HOLD

25.III-4 - Deputy Working Group Lead

  • Reward: $200
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #2602800
    • End Block: #2689200

Purpose

The WG Lead is expected to be available and active, but just as any other job, it's impossible to be available 24/7.

The idea of having deputy leads was raised again last Term. As has having Leads in shifts. What should each working group do?

Scope of Work

For each of the WGs:

  1. Is the groups output, productivity and/or efficiency hampered by the Lead? Is that person a bottleneck for getting things done? (This is not meant to imply the Lead is underperforming. As groups have grown, the workload has followed!)

  2. There are at least three options for each group:

  • Keep the leadership hierarchy as is
  • Assign a deputy Lead
  • Have two (or more) people share the title as Lead
    • Can be done on-chain, or off-chain (by sharing account)
      What seems like the most "applicable" for each group?
  1. What does the Leads themselves think of this?

Reward Distribution

Grading is individual.

Weighting:
1,3: $50
2: $100

Grading

Section IV - Bounties

25.IV-1 - Weekly Bounty Managers

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #2595600
    • End Block: #2696400

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. Manage Bounty #9
    After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

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

  3. There are currently 10 more open Bounties, some of them not created/funded by Jsgenesis. Which one of these has a format which lends themselves to weekly Bounty Managers?

Reward Distribution

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

Weighting:
1: $50
2: $100
3: $100

Grading

Working Group KPIs

25.CC-1 - Discover Category Videos Part 1

  • Reward: $250
  • Fiat Pool Factor: 1
    • Start Block: #2595600
    • End Block: #2739600

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!

Scope of Work

  1. For each category, find 12 videos (if possible) that matches best with the following criteria (in a somewhat ordered list):
    a. Content is in fact representative for the category
    b. Good quality (resolution and frame rate)
    c. "Appropriate" for making a 10sec clip/snippet, that will look good and display relevance to the category
    Obviously, if any video is not in line with the ToS, it should be discarded from consideration. This, of course, includes any video that have suspicious license data.

  2. For the 12 proposals in each category, provide the results in a json (preferable) or csv/markdown format:

  • category ID+name
  • video ID+title
  • timestamps for start/stop of each clip
  • channel ID+owner
  1. Point out which categories, if any, that needs more videos to achieve a reasonable level of quality.

Notes

Although the Lead is free to delegate as they see fit, this is a lot of work for a single person, and delegating among the curators seems good to quickly resolve the issue. The Lead should review the work if possible, but it's not feasible that all videos can be equally good ref criteria in 1.

Grading

25.OP-1 - Runtime Upgrade Verification

  • Reward: $300
  • Fiat Pool Factor: 1
    • Start Block: #2595600
    • End Block: #2797200

Purpose

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

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

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

Note

Extended from last KPI round, with small reward increase.

Scope of Work

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

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

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

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

Grading

25.OP-2 - Event Email Service

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #2595600
    • End Block: #2898000

Purpose

It can be quite useful to have notifications setup for various on chain events. The telegram/discord bots partially fulfills this role, but it could be equally, or more, useful to have email notifications as well!

Scope of Work

  1. Outline the feasibility of deploying a hosted service for this, where a user can sign up, and choose from a list of events to which they want subscribe.

  2. Outline the feasibility of building a self hosted service for users that are running nodes themselves. This would mean making the source code available on our community repo, where users can compile, configure and run it themselves.

  3. Estimate the hours and resource needed to build these tools, and the resource consumption for a user running it themselves like in 2.

Grading

KPI 24

  • KPIs: 17+4
  • Total Possible Rewards: 4750$ + 750$
  • Council Elected in Round: 26
  • Council Members: 16
  • KPI Length: 7 days / 100800 blocks
    • Start Block/Date: #2494800 / 28.09.21
    • End Block/Date: #2595600 / 05.10.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2624400 / 07.10.21

Grading Results

Council

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 167 6315622
644 lkskrn 7 264727
515 l1dev 4 151272
2098 0x2bc 5 189090
2096 svasilenko 111 4197809
867 xandrell 19 718544
321 freakstatic_council 20 756362
1842 uliczny 16 605090
2462 chiffah 311 11761427
2 tomato 271 10248704
2137 kalpakci 8 302545
2329 laura 199 7525801
2836 art_khabibullin 62 2344722
790 ururu 19 718544
2130 maxlevush 16 605090
2154 marat_mu 443 16753416
SUM 16 1778 63458765

Working Groups

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 150 5672715

Paid out on blocks #2,664,568 and #2,664,569.

Section I - Council work, Proposals and Bureaucracy

24.I-1 - Proposal Clearance

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

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 75 17
644 lkskrn 9 29 7
515 l1dev 5 16 4
2098 0x2bc 9 24 5
2096 svasilenko 16 49 11
867 xandrell 22 81 19
321 freakstatic_council 23 89 20
1842 uliczny 18 71 16
2462 chiffah 14 50 11
2 tomato 12 48 11
2137 kalpakci 10 37 8
2329 laura 21 84 19
2836 art_khabibullin 8 32 7
790 ururu 21 83 19
2130 maxlevush 17 69 16
2154 marat_mu 10 36 8
SUM 16 235 873 200

24.I-2 - Council Dissent

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

Purpose

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

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

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

Note

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

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

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

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

Scope of Work

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

  1. Raise concerns
A

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

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

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

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

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

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

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

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

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

Reward Distribution

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

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

Further:

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

Reporting

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

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

Grading

24.I-3 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

24.I-4 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

24.I-5 - Council Minutes

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

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2494800) 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

24.I-6 - New Fiat Pool Scheme

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

Purpose

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

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

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

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

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

Scope of Work

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

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

Reward Distribution

Grading is individual.

Weighting:

  1. $150
  2. $50

Grading

  • No work submitted, no rewards.

24.7 - Runtime Parameters

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

Purpose

A new runtime upgrade is coming up. What could/should be changed?

Scope of Work

  1. Create a text proposal outlining any runtime parameters that you would like changed, and why. If the proposal is approved, Jsgenesis will review and provide feedback.

Reward Distribution

Grading is individual.

The rewards will be based on the level of details presented in the proposal. A proposal pointing to the exact line that needs to be changed, what it does and what the secondary effects are will earn more than "Make X higher".

Grading

  • No work submitted, no rewards.

Section II - Community Management

24.II-1 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

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

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

    • Start Block: #2494800
    • End Block: #2595600

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

24.II-2 - Find All PRs/Issues That Require Jsgenesis Action

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

Purpose

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

We need to compile a new list of actions required.

Scope of Work

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

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

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

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

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

Reward Distribution

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

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

Grading

  • No work submitted, no rewards.

24.II-3 - Create new KPIs

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

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.

24.II-4 - Minting and Burning - Part 1

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

Purpose

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

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

Note

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

Scope of Work

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

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

  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

  2. Create a script that, at every block:

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

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

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

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

Reward Distribution

Individual grading.

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

Grading

  • No work submitted, no rewards.

24.II-5 - Council Term Summary Videos

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #2595600
    • End Block: #2624400

Purpose

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

Scope of Work

  1. Record a video (in English) presenting the "highlights" of the Term, from a community point of view. The video should be recorded after the following information is secured:
  • The Council Minutes
  • A KPI status update, made by the Council Secretary. Example
  • As many of the Term Summaries as possible.

This means the video should be recorded approximately two days after the end of the Term.
Some potential topics:

  • Who were on the Council
  • Fiat Pool and exchange rate changes
  • Any changes to the workers or Leads?
  • Did something fun happen?

  1. We imagine the format will change over time, and with feedback, but in order to bootstrap it, someone has to give it a go. After you made your video, create a forum thread for feedback/discussion. Then create a text proposal with the format you opted for, and a link to the forum post.

  2. Have the video re-recorded in Russian, either by yourself, or someone else.

Note

Ideally, this should be a running project (ie. no longer be a KPI) once it "settles". In the meantime, if you are fluent in both languages you can make both. If not, collaborate with someone that masters the "other" language.

Reward Distribution

Individual grading. If more than one CM creates (a) video(s), the reward is not capped. So multiple people can all earn $400 each.

Weighting:

  1. $300
  • Soft cap, an extremely good video may earn even more.
  • A 1 min short where someone is reading the Council Minutes will not earn anything.
  1. $50
  2. $150

Grading

24.II-6 - Community Calls

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

Purpose

As stated before, we have unfortunately not been able to follow up, assist and inform the community sufficiently for some time. Let's schedule some community calls (or similar) to remedy this!

Scope of Work

  1. In addition to having tried a community call or two before, we have also made a (long inactive) podcast, and Bedeho has made a number of community update videos. Although the latter will surely return soon (tm), we believe there are many topics and questions that are more suitable for other formats. Start a discussion with the community, and decide on a format for which Jsgenesis should start a weekly, or fortnightly calls with the Community. The following should be decided:
  • Should it be an actual call, where everyone are free to join and ask question (Q&A)
  • Pre-recorded questions by the community answered over a call, with everyone muted?
  • Should it be a discussion moderated by a selected community member?
  • Should it not be a call at all, but an AMA somewhere?
  • Do you prefer the presentation style from Bedehos videos?
  • Other?
  1. What should the first 3 calls cover? Although we understand there are many different topics the community wants more information about, some structure may be useful. If nothing else because people may want very different granularity.
  • Topics/agenda
  • Who should be present from JSG
    • Can be either a name/handle, or representative of some product/feature (eg. Atlas)
  1. Schedule a time and date next week that is suitable. Note that most of the Jsgenesis team are on UTC+2.

Reward Distribution

Individual grading. Although this must be based on feedback not just from the Council, but the entire community, a single person should lead.

Grading

Section III - Working Groups

Note

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

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

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

Purpose

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

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

Note

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it'ss being renewed.

Scope of Work

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

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

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

Reward Distribution

Individual grading.

* Firing is not the only valid consequence

Weighting:

  • 1: $300

Grading

TBD

24.III-2 - Follow up the Content Curators Working Group

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

Purpose

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

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

Note

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

Scope of Work

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

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

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

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

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

Reward Distribution

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

Weighting:

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

Grading

24.III-3 - Follow up the Operations Working Group

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

Purpose

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

For our next release, we are planning on adding two more Operations groups. How to organize them is another thing!

Scope of Work

  1. Discuss the downsides and benefits with each of the approaches below:
  • Separate the groups in two specific fields, such as:
    • Marketing
    • Coding (general)
    • Front-end
    • Scripts and tools
    • Moderators
    • etc.
  • Have three independent groups, with no group-specific overarching theme, but assign new tasks to a specific group every time.
  • Have the groups "compete", with all teams competing for the same tasks

Reward Distribution

Grading is individual.

Grading

  • No work submitted, no rewards.

Section IV - Bounties

24.IV.1 - Weekly Bounty Managers

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

Purpose

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

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

Scope of Work

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

Some general information can be found here.

Link to Bounties, and specifics:

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

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

Reward Distribution

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

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

Grading

Working Group KPIs

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

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

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

24.CC-1 - Update Featured Video

  • Reward: $150
    • Start Block: #2502000
    • End Block: #2595600

Purpose

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

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.

Grading

24.CC-2 - Discover Category Videos Part 1

  • Reward: $250
    • Start Block: #2577000
    • End Block: #2624400

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!

Scope of Work

  1. For each category, find 12 videos (if possible) that matches best with the following criteria (in a somewhat ordered list):
    a. Content is in fact representative for the category
    b. Good quality (resolution and frame rate)
    c. "Appropriate" for making a 10sec clip/snippet, that will look good and display relevance to the category
    Obviously, if any video is not in line with the ToS, it should be discarded from consideration. This, of course, includes any video that have suspicious license data.

  2. For the 12 proposals in each category, provide the results in a json (preferable) or csv/markdown format:

  • category ID+name
  • video ID+title
  • timestamps for start/stop of each clip
  • channel ID+owner
  1. Point out which categories, if any, that needs more videos to achieve a reasonable level of quality.

Notes

Although the Lead is free to delegate as they see fit, this is a lot of work for a single person, and delegating among the curators seems good to quickly resolve the issue. The Lead should review the work if possible, but it's not feasible that all videos can be equally good ref criteria in 1.

Grading

  • No work submitted, no rewards.

24.OP-1 - Runtime Upgrade Verification

  • Reward: $300
    • Start Block: #2502000
    • End Block: #2595600

Purpose

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

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

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

Note

Extended from last KPI round, with small reward increase.

Scope of Work

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

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

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

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

Grading

  • No work submitted, no rewards.

24.SP-1 - Storage OKRs

  • Reward: $300
  • Start Block: #2494800
  • End Block: #2595600

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

Purpose

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it's being renewed.

Scope of Work

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

24.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #2494800
  • End Block: #2595600

Purpose

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it'ss being renewed.

Scope of Work

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

Grading

  • No work submitted, no rewards.

KPI 23

  • KPIs: 20+3
  • Total Possible Rewards: 5800$ + 650$
  • Council Elected in Round: 25
  • Council Members: 16
  • KPI Length: 7 days / 100800 blocks
    • Start Block/Date: #2394000 / 21.09.21
    • End Block/Date: #2494800 / 28.09.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2523600 / 30.09.21

Notes

Not sure if this is the "correct" place to first release this information, but a new JSG voting policy will be introduced soon, in harmony with KPI 23.I-7:

  • JSG will no longer vote for Founding Members in Council Elections.
  • JSG will primarily prioritize voting in first timers, that puts in an effort.
  • If there are more tokens "left" to vote for, the priority will be non-FMs that has done well on the Council before, or deserves another chance.

Grading

CMs:

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 280 11012887
644 lkskrn 27 1061957
361 blackmass 21 825967
635 xfactorus 27 1061957
2574 alexznet 21 825967
867 xandrell 51 2005919
321 freakstatic_council 25 983294
957 leet_joy 13 511313
1842 uliczny 22 865298
2462 chiffah 148 5821098
2 tomato 291 11445537
2137 kalpakci 27 1061957
2329 laura 285+75 11209546+
790 ururu 29 1140620
1048 igrex 258 10147589
2182 isonar 477 18761240
SUM 16 2427 81253056

Workers:

Member ID Member Handle Reward [USD] Reward [tJOY]
2098 0x2bc 350 13766109

Paid out at blocks #2,591,063 and #2,591,098.

Section I - Council work, Proposals and Bureaucracy

23.I-1 - Proposal Clearance

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

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 97 17
644 lkskrn 21 81 14
361 blackmass 11 44 8
635 xfactorus 21 80 14
2574 alexznet 11 44 8
867 xandrell 20 74 13
321 freakstatic_council 19 69 12
957 leet_joy 0 0 0
1842 uliczny 14 50 9
2462 chiffah 15 57 10
2 tomato 10 44 8
2137 kalpakci 20 81 14
2329 laura 28 123 22
790 ururu 22 91 16
1048 igrex 26 111 20
2182 isonar 20 77 14

23.I-2 - Council Dissent

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

Purpose

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

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

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

Note

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

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

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

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

Scope of Work

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

  1. Raise concerns
A

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

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

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

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

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

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

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

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

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

Reward Distribution

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

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

Further:

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

Reporting

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

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

Grading

23.I-3 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

  • @tomato - $270

23.I-4 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

23.I-5 - Council Minutes

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

Purpose

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

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

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2394000) 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

23.I-6 - New Fiat Pool Scheme

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

Purpose

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

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

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

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

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

Scope of Work

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

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

Reward Distribution

Grading is individual.

Weighting:

  1. $150
  2. $50

Grading

23.7 - Expand Council Size

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

Purpose

Competition for seats on the Council has gotten fierce. Although that is a good thing in almost every way, it has (at least) one bad side: It blocks entry for new, or newly dedicated, community members to show their worth.

Scope of Work

  1. Get a Set Election Parameters proposal, with a larger Council size, approved before the end of the Term.

Note that the process to get it approved is up to the Council. We decided to stick to the undefined "larger" instead of a number or range, to let the community find reasonable values.

Reward Distribution

If passed, the creator of the proposal gets $100. The Council will share a $200 bonus.

Grading

Section II - Community Management

23.II-1 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

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

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

    • Start Block: #2394000
    • End Block: #2494800

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

23.II-2 - Find All PRs/Issues That Require Jsgenesis Action

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

Purpose

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

We need to compile a new list of actions required.

Scope of Work

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

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

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

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

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

Reward Distribution

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

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

Grading

23.II-3 - Create new KPIs

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

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

  • @laura - $75
    • 25.III-4 - Deputy Working Group Lead

23.II-4 - Minting and Burning - Part 1

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

Purpose

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

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

Note

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

Scope of Work

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

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

  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

  2. Create a script that, at every block:

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

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

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

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

Reward Distribution

Individual grading.

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

Grading

  • No work submitted, no rewards.

23.II-5 - Implement Community Repo Changes

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

Purpose

With KPI 21.8 completed, it's time to merge and bask in the glory!

Scope of Work

  1. Go through all open PRs and:
  • Merge those that can be
  • Tag @bwhm and @DzhideX on those that require jsgenesis attention
  • Notify/assist the people that created the "remaining" PRs.
  1. Create a new branch that has also cleans up after the changes from 1. Have a last look, and consider:
  • Are any the files that are being read/used by other repos, or the joystream website seeing their path/name changed? If yes, notify @bwhm and @DzhideX
  • Any other potential issues?
  1. Merge!

Reward Distribution

Individual grading. All items must be completed in order to earn any rewards.

Grading

23.II-6 - Community Calls

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

Purpose

As stated before, we have unfortunately not been able to follow up, assist and inform the community sufficiently for some time. Let's schedule some community calls (or similar) to remedy this!

Scope of Work

  1. In addition to having tried a community call or two before, we have also made a (long inactive) podcast, and Bedeho has made a number of community update videos. Although the latter will surely return soon (tm), we believe there are many topics and questions that are more suitable for other formats. Start a discussion with the community, and decide on a format for which Jsgenesis should start a weekly, or fortnightly calls with the Community. The following should be decided:
  • Should it be an actual call, where everyone are free to join and ask question (Q&A)
  • Pre-recorded questions by the community answered over a call, with everyone muted?
  • Should it be a discussion moderated by a selected community member?
  • Should it not be a call at all, but an AMA somewhere?
  • Do you prefer the presentation style from Bedehos videos?
  • Other?
  1. What should the first 3 calls cover? Although we understand there are many different topics the community wants more information about, some structure may be useful. If nothing else because people may want very different granularity.
  • Topics/agenda
  • Who should be present from JSG
    • Can be either a name/handle, or representative of some product/feature (eg. Atlas)
  1. Schedule a time and date next week that is suitable. Note that most of the Jsgenesis team are on UTC+2.

Reward Distribution

Individual grading. Although this must be based on feedback not just from the Council, but the entire community, a single person should lead.

Grading

23.II-7 - Council Term Summary Videos

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #2494800
    • End Block: #2523600

Purpose

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

Scope of Work

  1. Record a video (in English) presenting the "highlights" of the Term, from a community point of view. The video should be recorded after the following information is secured:
  • The Council Minutes
  • A KPI status update, made by the Council Secretary. Example
  • As many of the Term Summaries as possible.

This means the video should be recorded approximately two days after the end of the Term.
Some potential topics:

  • Who were on the Council
  • Fiat Pool and exchange rate changes
  • Any changes to the workers or Leads?
  • Did something fun happen?

  1. We imagine the format will change over time, and with feedback, but in order to bootstrap it, someone has to give it a go. After you made your video, create a forum thread for feedback/discussion. Then create a text proposal with the format you opted for, and a link to the forum post.

  2. Have the video re-recorded in Russian, either by yourself, or someone else.

Note

Ideally, this should be a running project (ie. no longer be a KPI) once it "settles". In the meantime, if you are fluent in both languages you can make both. If not, collaborate with someone that masters the "other" language.

Reward Distribution

Individual grading. If more than one CM creates (a) video(s), the reward is not capped. So multiple people can all earn $400 each.

Weighting:

  1. $300
  • Soft cap, an extremely good video may earn even more.
  • A 1 min short where someone is reading the Council Minutes will not earn anything.
  1. $50
  2. $150

Grading

  • No work submitted, no rewards.

Section III - Working Groups

Note

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

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

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

Purpose

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

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

Note

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it'ss being renewed.

Scope of Work

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

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

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

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

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

Reward Distribution

Individual grading.

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

* Firing is not the only valid consequence

Weighting:

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

Grading

23.III-2 - Follow up the Content Curators Working Group

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

Purpose

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

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

Note

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

Scope of Work

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

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

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

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

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

Reward Distribution

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

Weighting:

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

Grading

23.III-3 - Follow up the Operations Working Group

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

Purpose

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

For our next release, we are planning on adding two more Operations groups. How to organize them is another thing!

Scope of Work

  1. Discuss the downsides and benefits with each of the approaches below:
  • Separate the groups in two specific fields, such as:
    • Marketing
    • Coding (general)
    • Front-end
    • Scripts and tools
    • Moderators
    • etc.
  • Have three independent groups, with no group-specific overarching theme, but assign new tasks to a specific group every time.
  • Have the groups "compete", with all teams competing for the same tasks

Reward Distribution

Grading is individual.

Grading

Section IV - Bounties

23.IV.1 - Weekly Bounty Managers

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

Purpose

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

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

Scope of Work

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

Some general information can be found here.

Link to Bounties, and specifics:

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

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

Reward Distribution

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

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

Grading

23.IV.2 - Other Bounty Managers

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

Purpose

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

Scope of Work

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

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

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

Reward Distribution

Individual.

Weighting:

  • 9 : $100

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

Grading

  • No work submitted, no rewards.

23.IV.3 - Decentralized Domains Bounty

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

Purpose

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

Scope of Work

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

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

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

Reward Distribution

Individual grading.

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

Weighting:

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

Grading

Working Group KPIs

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

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

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

23.CC-1 - TBD

23.OP-1 - Runtime Upgrade Verification

  • Reward: $300
    • Start Block: #2401200
    • End Block: #2494800

Purpose

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

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

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

Note

Extended from last KPI round, with small reward increase.

Scope of Work

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

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

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

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

Grading

  • No work submitted, no rewards.

23.SP-1 - Storage OKRs

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

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

Purpose

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it's being renewed.

Scope of Work

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

Grading

23.SP-2 - Storage Provider Sanctions

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

Purpose

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

Although the task was "claimed", it's not clear whether all the work here is completed, so it'ss being renewed.

Scope of Work

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

Grading

KPI 22

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

Notes

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

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 kate_fm 18 728545
2194 ilich 346 14004263
644 lkskrn 207 8378273
361 blackmass 3 121424
635 xfactorus 13 526172
867 xandrell 22 890444
321 freakstatic_council 114 4614121
2462 chiffah 148 5990263
2 tomato 282 11413879
736 mmsaww 14 566646
2137 kalpakci 13 526172
2329 laura 272 11009131
790 ururu 15 607121
2130 maxlevush 163 6597384
2435 zazik 16 647596
513 kriptos 15 607121
SUM 16 1661 67228555

Paid out on blocks #2,437,365 and #2,437,366.

Section I - Council work, Proposals and Bureaucracy

22.1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
1905 kate_fm 22 90 18
2194 ilich 20 76 16
644 lkskrn 7 34 7
361 blackmass 4 16 3
635 xfactorus 16 64 13
867 xandrell 15 57 12
321 freakstatic_council 15 67 14
2462 chiffah 22 87 18
2 tomato 3 12 2
736 mmsaww 5 20 4
2137 kalpakci 16 61 13
2329 laura 24 105 22
790 ururu 18 72 15
2130 maxlevush 15 61 13
2435 zazik 17 78 16
513 kriptos 19 73 15
SUM 16 238 973 200

22.2 - Council Dissent

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

Purpose

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

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

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

Note

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

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

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

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

Scope of Work

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

  1. Raise concerns
A

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

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

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

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

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

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

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

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

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

Reward Distribution

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

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

Further:

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

Reporting

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

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

Grading

22.3 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

22.4 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

22.5 - Council Minutes

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

Purpose

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

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

22.6 - New Fiat Pool Scheme

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

Purpose

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

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

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

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

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

Scope of Work

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

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

Reward Distribution

Grading is individual.

Weighting:

  1. $150
  2. $50

Grading

Section II - Community Management

22.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

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

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

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

Purpose

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

Note

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

Scope of Work

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

Reward Distribution

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

Grading is individual.

Grading

22.8 - Find All PRs/Issues That Require Jsgenesis

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

Purpose

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

We need to compile a new list of actions required.

Scope of Work

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

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

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

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

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

Reward Distribution

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

  1. $50
  2. $100

Grading

  • No work submitted, no rewards.

22.9 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

22.10 - KPIs Overview

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

Purpose

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

Note

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

Scope of Work

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

Reward Distribution

Individual grading.

Grading

22.11 - Minting and Burning - Part 1

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

Purpose

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

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

Note

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

Scope of Work

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

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

  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.

  2. Create a script that, at every block:

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

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

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

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

Reward Distribution

Individual grading.

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

Grading

  • No work submitted, no rewards.

Section III - Working Groups

Note

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

22.12 - Follow up the Storage Working Group

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

Purpose

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

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

Note

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

Scope of Work

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

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

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

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

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

Reward Distribution

Individual grading.

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

* Firing is not the only valid consequence

Weighting:

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

Grading

22.13 - Follow up the Content Curators Working Group

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

Purpose

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

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

Note

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

Scope of Work

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

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

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

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

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

Reward Distribution

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

Weighting:

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

Grading

  • No work submitted, no rewards.

22.14 - Follow up the Operations Working Group

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

Purpose

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

Note

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

Scope of Work

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

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

Reward Distribution

Grading is individual.

Grading

Section IV - Bounties

22.15 - Weekly Bounty Managers

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

Purpose

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

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

Scope of Work

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

Some general information can be found here.

Link to Bounties, and specifics:

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

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

Reward Distribution

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

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

Grading

22.16 - Other Bounty Managers

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

Purpose

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

Scope of Work

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

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

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

Reward Distribution

Individual.

Weighting:

  • 9 : $100

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

Grading

22.17 - Decentralized Domains Bounty

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

Purpose

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

Scope of Work

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

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

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

Reward Distribution

Individual grading.

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

Weighting:

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

Grading

  • The work for this was submitted after the council term ended. Grading will be deferrred until the next council term. This KPI was continued in KPI 23.x.

Working Group KPIs

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

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

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

22.CC-1 - Bounty 18 Status Update

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

Purpose

See KPI 21.16!

Scope of Work

Same as KPI 21.16, but for Bounty 18.

Grading

22.OP-1 - Runtime Upgrade Verification

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

Purpose

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

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

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

Note

Extended from last KPI round, with small reward increase.

Scope of Work

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

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

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

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

Grading

  • No work submitted, no rewards.

22.SP-1 - Storage OKRs

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

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

Purpose

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

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

Scope of Work

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

Grading

22.SP-2 - Storage Provider Sanctions

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

Purpose

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

Scope of Work

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

Grading

  • No work submitted, no rewards.

KPI 21

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

Notes

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

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 65 2624282
644 lkskrn 17 686351
361 blackmass 11 444109
515 l1dev 10 403736
2096 svasilenko 89 3593247
867 xandrell 42 1695690
321 freakstatic_council 18 726724
957 leet_joy 2 80747
2703 strowdeath 11 444109
2462 chiffah 141 5692673
2 tomato 280 11304598
2329 laura 143 5773420
705 flakes9776 36 1453448
2130 maxlevush 166 6702012
2182 isonar 482 19460058
2154 marat_mu 108 4360345
SUM 16 1621 65445549

Paid out at block #2,376,668.

Section I - Council work, Proposals and Bureaucracy

21.1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
2194 ilich 22 89 15
644 lkskrn 27 103 17
361 blackmass 16 64 11
515 l1dev 15 63 10
2096 svasilenko 21 86 14
867 xandrell 26 101 17
321 freakstatic_council 25 107 18
957 leet_joy 3 12 2
2703 strowdeath 17 66 11
2462 chiffah 24 97 16
2 tomato 15 62 10
2329 laura 28 109 18
705 flakes9776 17 68 11
2130 maxlevush 23 98 16
2182 isonar 10 42 7
2154 marat_mu 12 48 8
SUM 16 301 1215 200

21.2 - Council Dissent

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

Purpose

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

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

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

Note

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

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

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

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

Scope of Work

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

  1. Raise concerns
A

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

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

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

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

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

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

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

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

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

Reward Distribution

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

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

Further:

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

Reporting

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

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

Grading

  • @laura
    • https://testnet.joystream.org/#/proposals/562
      • Cost: $500+
      • Was it a malicious, or objectively bad proposal: No, but it was a highly expensive bounty request.
      • Did the vote/comment affect the outcome: No, but it did generate discussion.
      • Reward: $50

21.3 - Council Secretary

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

Purpose

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

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

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

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

  • @tomato - $270
    • Managing PR's in community repo per rules: Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes

21.4 - Deputy Council Secretary

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

Purpose

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

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

Requirements:

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

  • @maxlevush - $150

21.5 - Council Minutes

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

Purpose

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

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

21.6 - FM Surveys

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

Purpose

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

21.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

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

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full Term

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

Purpose

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

Note

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

Scope of Work

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

Reward Distribution

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

Grading is individual.

Grading

21.8 - Clean up Community Repo - Part 2

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

Purpose

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

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

Extended from last KPI round.

Scope of Work

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

  1. When the proposal is made, tag the Council Secretary and @bwhm#6514 on Discord, to participate in the discussion.

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

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

Reward Distribution

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

Weighting:

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

Grading

21.9 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

  • No work claimed, no rewards.

21.10 - KPIs Overview

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

Purpose

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

Scope of Work

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

Reward Distribution

Individual grading.

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

Grading

  • SOW 1, 2 + 3 were completed in KPI 19/20
  • SOW 4 has not been claimed or completed.

21.11 - Minting and Burning - Part 1.

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

Purpose

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

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

Scope of Work

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

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

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

Reward Distribution

Individual grading.

  1. $150
  2. $150

Grading

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

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

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

Section III - Working Groups

Note

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

21.12 - Follow up the Storage Working Group

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

Purpose

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

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

Scope of Work

  1. Hire a new Lead!

Reward Distribution

Individual grading.

Grading

21.13 - Follow up the Content Curators Working Group

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

Purpose

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

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

Scope of Work

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

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

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

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

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

Reward Distribution

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

Weighting:

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

Grading

  • SOW 1/2/3 - Bounty 10 refined data
    • No work submitted.

21.14 - Follow up the Operations Working Group

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

Purpose

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

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

Scope of Work

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

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

Reward Distribution

Grading is individual.

Grading

Section IV - Bounties

21.15 - Weekly Bounty Managers

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

Purpose

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

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

Scope of Work

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

Some general information can be found here.

Link to Bounties, and specifics:

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

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

Reward Distribution

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

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

Grading

21.16 - Other Bounty Managers

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

Purpose

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

Scope of Work

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

Reward Distribution

Grading is individual.

Weighting:

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

Grading

Working Group KPIs

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

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

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

21.CC-1 - TBD

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

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

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

21.OP-1 - Runtime Upgrade Verification

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

Purpose

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

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

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

Extended from last KPI round.

Scope of Work

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

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

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

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

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

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

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

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

Purpose

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

Scope of Work

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

KPI 19

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

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

Important Note

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

The purpose of the change is two-fold:

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

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

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

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

Added 19.8 on the 31st of August.

Added 19.14-19.16 on the 2nd of September.

Section I - Council work, Proposals and Bureaucracy

19.1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 36 134 18
2194 ilich 29 105 14
644 lkskrn 35 125 17
2098 0x2bc 6 24 3
635 xfactorus 34 117 16
798 shtihmas 34 120 16
867 xandrell 33 114 16
1962 nkhlghbl 7 30 4
439 fierydev 0 0 0
2 tomato 23 90 12
736 mmsaww 22 83 11
2329 laura 36 136 19
2130 maxlevush 30 119 16
1048 igrex 38 151 21
2435 zazik 21 76 10
2182 isonar 11 43 6
SUM 16 395 1467 200
Member ID Member Handle Voted Points Reward
1905 lyazufey1812 30 107 15
2194 ilich 21 75 11
644 lkskrn 30 110 16
361 blackmass 13 40 6
2098 0x2bc 10 34 5
2096 svasilenko 24 83 12
867 xandrell 34 118 17
321 freakstatic_council 30 120 17
2462 chiffah 25 93 13
2329 laura 30 129 18
790 ururu 23 83 12
2130 maxlevush 23 101 14
1048 igrex 33 129 18
2435 zazik 11 40 6
2148 controlla 19 76 11
2182 isonar 18 79 11
SUM 16 374 1417 200

19.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: 2 council terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

The Council appeared to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

After seeing this play out for a while, we still have mixed feelings about it. On one had, there is clearly more discussion, questioning and disagreeing. Whereas before, all proposals were basically approved, this is no longer the case.

On the flip-side, some (smaller) traces of fractioning has happened. To address this, we are doubling down on what was said last time:

We are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Finally, note that some of the SoW and reward requirements have changed.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

For all of the above, your comment should be precise, concise, polite, and if required, well sourced. A simple "no" will get you no where.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $200)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $150)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Further:

  • Only comments made in the proposal discussion will be evaluated. You can of course link to a longer post somewhere else there, but then you have to add a summary in the proposal discussion. Remember, having someones attention is not permanent.
  • Stay polite, even if you are replying to a personal comment, keep it civil.
  • You can only claim rewards for up to three proposals you dissented to.
  • Total Cap at $1000 per KPI, eg. $500 per Term

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

19.3 - Council Secretary

  • Reward: $300 per council term
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: (elected once per council term)
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • W1 - tomato - $280 - https://testnet.joystream.org/#/proposals/478
    • Managing PR's in community repo per rules: Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes
  • W2 - maxlevush - $280 - https://testnet.joystream.org/#/proposals/518
    • Managing PR's in community repo per rules: Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes

19.4 - Deputy Council Secretary

  • Reward: $150 per council term
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: (elected once per council term)
    • Start Block: #1990800
    • End Block: #2192400

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

19.5 - Council Minutes

  • Reward: $100 per council term
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full Term(s) + 1 day
    • Start Block: #1990800
    • End Blocks: #2091600, #2192400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

As the KPIs now cover 2 Council Terms, these reports must be generated for both terms. The naming convention should be 19A and 19B to refer to the two terms.

Scope of Work

  1. The 21st & 22nd "official" Councils (#1990800-#2091600 & #2091600-#2192400) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

19.6 - FM Surveys

  • Reward: $75 per term
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: 2 Full Terms
    • Start Block: #1990800
    • End Blocks: #2091600, #2192400

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others). These surveys must be completed each council term.
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + (1 the lead). For each CC after the 6th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 (the lead). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge. These surveys must be completed each council term.

Reward Distribution

Grading is individual. Note that if you are elected for both terms, you still need to fill out the survey twice.

Grading

  • No claims

Section II - Community Management

19.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: 2x Full Terms

    • Start Block: #1990800
    • End Block: #2192400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

19.8 - Clean up Community Repo - Part 2

  • Reward: $225+$150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

KPI 17.8 - Clean up Community Repo - Part 1, was partially completed, but it was nevertheless meant as a two-parter. Now it's time to finish it up!

Note that the @maxlevush, who submitted the work for Part 1, may be part of a team completing this task, but as the Scope of Work will reveal, they shouldn't complete it alone.

Scope of Work

  1. Review the work already completed here, and consider the following:
  • Is the hierarchy proposed coherent and intiutive?
  • Are the conventions proposed both "good" enough, and not too difficult to adhere to?
  • What, if anything, is missing in the (now outdated) "preview" branch from the "original" SoW?
  1. Based on the findings in 1:
  • Draft up the "Contribution Guidelines", and for the purposes of the Council and the user of the repo, add some context about your choices.
  • Make a new, and updated*, branch on your fork showing how the repo would if all your proposed changes were included.
    • * the branch must not be based on a fork older than 48h.
  • Make a PR to the Joystream repo, so that all the changes are visible.
  • Make a Text Proposal to the Council with everything above.

  1. When the proposal is made, tag the Council Secretary and @bwhm#6514 on Discord, to participate in the discussion.

  2. While the proposal is being discussed, check in frequently, to participate in the discussion and ensure that any changes requested can be implemented quickly. In order to complete this task, all of the below must be done:

  • a (doesn't have to be the first one!) Text Proposal is approved by the Council
  • the format is accepted by @bwhm#6514
  • the PR must be updated to include any new PRs merged in the Joystream repo

Reward Distribution

As alluded to, this should KPI ideally be a collaborative effort. Unless 1-3 are all completed within the Term, the KPI will be extended and not graded before the next round.

Weighting:

  1. $50
  2. $150
  3. $25
  4. $150 *
    Note that this part is unlikely not to be completed before the end of the Term. If so, create a Spending Proposal that JSG will re-imburse after all the items in 4. is completed.

Grading

  • Continued in KPI 21

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this section of KPIs.

19.9 - Follow up the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Establishing the new OKR system for the SPs has unfortunately stalled. The technical part is more or less complete, and will be completed for the next Council Term, so we're going to cut through and propose something more specific. The work is to find out exactly what the numbers R_rec.L, R_okr.L, R_rec.W and R_okr.W should be:
  • The Lead currently earns ~$72 per week in recurring rewards
  • The Workers (ex JSG) all earn ~$30 per week in recurring rewards
  • Going forward, we propose all Workers (R_rec.W) earn either the break-even cost in terms of hardware, or slightly below.
  • Whether the recurring reward for the Lead (R_rec.L) should be higher or lower than this isn't clear.
    • The Lead has extra responsibilities to running their node, which has a value
    • The Lead will however potentially earn an extra income on this, as they will earn OKR rewards for the groups performance, and for Storage KPIs, which will cover most of their extra tasks
  • After establishing a benchmark value for OKRs, the OKR payout scheme will mean that of max OKR payout pool, equal to R_rec.L + R_rec.W, so that:
    • For the Group:
      • For each of the 7* KRs that exceeds the weekly target -> 1/7th of R_okr.W is shared between all the SPs that reached this individual KR.
      • If the group on average exceeds the target for 4/7 KRs, the Lead gets a bonus equal to R_okr.L/10
      • If the group on average exceeds the target for 5/7 KRs, the Lead gets a bonus equal to R_okr.L/5
      • If the group on average exceeds the target for 6/7 KRs, the Lead gets a bonus equal to R_okr.L/2
      • If the group on average exceeds the target for 7/7 KRs, the Lead gets a bonus equal to R_okr.L
  • Get these independent numbers approved by the Council, and provide specific examples of outcomes for the Workers and Lead with this schedule.
    • Note that half of the OKR rewards will come from minting of new tokens, so only half of the OKR rewards needs to be accounted for in the budget.
    • Further note that it's unlikely that the FULL OKR rewards (R_okr.W+R_okr.L) will actually be paid out each week, so the Council can assume the budget for the SP group won't have to pay all of R_rec.L + R_rec.W + (R_okr.W + R_okr.L)/2.

* Note that while the OKRs are being rolled out, the number will be lower than 7. The general process will still apply.

  1. Finally, as the OKRs will be tracked starting with the next Council Term, ensure that the Lead has set the new rewards for the workers before block #2091600.

  2. Assist the Lead with their other KPIs for the Term.

The CM addressing this task should familiarize themselves with the somehwat overlapping Storage KPIs.

Reward Distribution

Individual grading.

For 3. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $250
  • 2: $150

Grading

19.10 - Follow up the Content Curators Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms
    • Start Block: #1990800
    • End Block: #2192400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. After the closing of Bounty 10, the amount of uploads to the platform dropped substantially. Create a report containing information about content between blocks #717987 (first block with the current content directory) and #1998000 the following information, with charts where applicable:
  • Channel creation over time
  • Members with Channels over time
  • Uploads over time
  • Size of the dataDirectory over time
  • Curators (including Lead) over time
  • Curator rewards (including Lead), both in USD and tJOY.
  • Changes made to Channels and Videos over time
  • Curation/Censoring over time

Note that the information for the first 3 bullets above can be generated from the Hydra Playground, whereas the rest will require getting historical data from the chain. In the latter case, getting data for every 14400 blocks (eg. every day) is sufficient. The historical exchange rate can be derived from the status server.

  1. Use the data, and compare to the previous Curator Lead reports to get an estimate of the workload over time for the Curators, and compare the result to what was found in 1.

  2. Use the results as a baseline to review the current budget for the Curator group, keeping in mind that the workload is expected to go up (substantially) once the "new" content bounty is live.

  3. Assist the Curator Lead with their Curator KPI, KPI 19.CC-1.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $100
    1. $50
    1. $100

Grading

  • SOW 1 (Bounty 10 report) - $150
  • SOW 2 (Estimate curator workload) - $100
    • No work submitted/completed
  • SOW 3 (Review the budget) - $50
    • No work submitted/completed
  • SOW 4 (Assist lead wth Curator KPI) - $100
    • No work submitted/completed

19.11 - Follow up the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1998000
    • End Block: #2192400

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. The Operations group regularly presents interesting work that can enhance the platform. Get a an updated, and exhaustive list of what they want to achieve, and present it to the Council, in order to get a ranking of what the Council wants them to focus on. Note that this requires understanding not only what the end product is, but also insight about the complexity, value and time line for each of them.

  2. Once the results are in from the first Term, repeat the process for the second Council. Once the "final" results are in, co-operate with the Lead to get a firm timeline and manpower required for the top 3 items.

Reward Distribution

Grading is individual.

Grading

  • SOW 1 (Get a list of what Operations wants to achieve)
  • SOW 2 (Get a firm timeline)
    • No work submitted/completed

Section IV - Bounties

19.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per term
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full terms + 1 day
    • Start Block: #1990800
    • End Block: #2106000 (denote as 19-12.A)
    • End Block: #2192400 (denote as 19-12.B)

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

19.13 - Other Bounty Managers

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day (single term)
    • Start Block: #1990800
    • End Block: #2106000 (denote as 19-12.A)
    • End Block: #2192400 (denote as 19-12.B)

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language
  1. The JSG "Specs" for Community Bounty #24 - "Upload Content", can be found here. From KPI 18.CC-3, these terms and conditions were presented. KPI 19.CC-2 will continue to focus on launching this Bounty.
  • Set a weekly reward for the BM, reflecting the expected workload of reviewing 100s of videos each week.
  • Find one or two BMs (ideally yourself) that:
    • Speaks English and Russian
    • Is interested in, and knowledge of, videos and old films
    • Is willing not to participate in the Bounty themselves
    • Has some understanding of the platform
    • Is not currently, or is willing to quit as, a Curator
    • Get the person approved by the Council
  • Push the BM, and the Curator Lead, to get the final Bounty text for the participants, and the workflow for the Curators and the BM(s) approved by JSG.
  • Ensure the BM sets a reward structure that rewards the best video(s) a little extra.
    Note that some extra information can be found in KPI 19.CC-2.

Reward Distribution

Grading is individual.

Weighting:

  • 1-2: $50
  • 3: $200 - Note that the BM(s) should get half of this, if it's not the same person(s) as the CM

Grading

Section V - Interim KPIs

Due to the numbering system, these are added here. Note that [KPI 19.8](#19.8) was also added after the "first" Term, but the ones below at an even later stage. (We'll go back to weekly KPIs starting next Term)

19.14 - Create new KPIs

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

19.15 - KPIs Overview

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

The community has started voting as a unit, to ensure that a new Council is working well. As they have somewhat limited data to make that judgement, let's make it easier!

Scope of Work

  1. Go through all the KPIs from Antioch and Sumer, and collect the following in a spreadsheet or json:
  • What was the total possible rewards for each Term
  • How much was paid out for each Term
  • Who where the CMs for each Term
  • How much did they earn in rewards
  1. Make sure the data is presented in such a way that it can be used to create tables ranking all past (and future) CMs by performance, both relatively and absolutely. Examples:
  • Rank all by total KPI earnings
  • Rank all by total KPI earnings per Term
  • Rank all by ratio of KPI earnings in a Term over total possible rewards for that Term
  • Rank all by ratio of KPI earnings in a Term over total paid rewards for that Term
  • etc.
  1. Make sure the data is presented in a way that allows creation of charts showing the performance over time for the both the entire Council and individual CMs. Examples:
  • Paid out per Term
  • Ratio of earned / total possible rewards
  • etc.
  1. Get the stake for each CM for every Term. Note that unlike 1-3, this data must come from historical chain data. Should be separated in four datapoints:
  • Own stake
  • Other stake
  • If applicable, how much of the "other" stake was from JSG (5CJzTaCp5fuqG7NdJQ6oUCwdmFHKichew8w4RZ3zFHM8qSe6)
  • If applicable, how much of the "other" stake was themselves (eg. membership root and/or ctrl account)

Reward Distribution

Individual grading.

  1. $150
  2. $50
  3. $50
  4. $150

Grading

19.16 - Minting and Burning - Part 1

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core (last) term
    • Start Block: #2091600
    • End Block: #2192400

Purpose

The platform has taken a larger interest in the minting and burning of tokens recently. We believe this is good progress from previously, and it was a large part of the reason the dreaded "Council Dissent" KPI was introduced.

Although the "Tokenomics" and the status server combined gives a good idea of the mints and burns of Tokens, they do not provide the full picture.

Scope of Work

The list below will hopefully cover all the sources of minting and burning of tokens on the platform, with some information on how to quantify it in (parentheses) from the historical chain data:

  • Minting:
    • Validator rewards (event)
    • Council rewards (from the Council Mint, which also funds proposals, refill is an event)
    • Other Worker and Lead rewards (from the respective mints, refill is an event)
    • Spending Proposals (event)
    • sudo 1 (event)
    • Other?
  • Burning:
    • Membership creation 2 (event)
    • Exchanges (when user sends to the exchange account, 5D5PhZQNJzcJXVBxwJxZcsutjKPqUPydrvpu6HeiBfMaeKQu, it makes a new transfer to itself with all tokens as fees)
    • Extrinsics/tx fees (must be set manually, see above)
    • Proposal fee (when not approved)
    • Proposal slashes
    • Worker and Lead slashes
      • Due to an issue with the current runtime, all stakes (both role and application) for the Operations group are/were burned
    • Other?
  1. Create a document with:
  • if applicable, the event, eg. sudo.setBalance for each mint/burn
  • what values from the chain state you need to compare for each block to calculate the mint/burn for that block
  • other sources of mints and burns.
    • if you find one, add the information requested above
  1. Write up a chunk of code (in typescript) that can be used to calculate this from the API, and comment the code to explain in words what you are trying to do/doing.
  • sudo always mints new tokens as KPI rewards, but on rare occasions for other purposes
  • when created through the Player onboarding, it's minted first

Reward Distribution

Individual grading.

  1. $150
  2. $150

Grading

  • Continued in KPI 21

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.

19.CC-1 - Update Featured Video Rules

  • Reward: $75
  • Start Block: #1990800
  • End Block: #2192400

The "Main" featured video for the Joystream Player was just changed, but the rules are still missing!

Some notes:

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Notes:
  • JSG reserves the right to veto this choice, for any reason.
  • Certain metadata is required, including a cover cut.
  • The community should keep in mind the featured video slot should be reserved for the absolute best ones in terms of production value etc.
    Remember that the featured video is the first thing any new user will see when opening the Joystream Player, and it autoplays the "cover cut" by default. That means that this video has to be standout, and the cover cut needs to be interesting. The main goal of this video (in the future) is to get the person opening the Joystream Player buy a subscription to the platform!
  1. Decide on frequency for how often the video should be changed.

Grading

19.CC-2 - New "Upload Content" Bounty

  • Reward: $100
  • Start Block: #1990800
  • End Block: #2192400

Purpose

We have been working on finalizing this for a while, and now it's time to finish!

The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here.
Last week, the Curators presented a set of terms and conditions here.

Scope of Work

  1. The terms contained some good additions to the rules, but some elements requested in the "Specs" and KPI 18.CC-3 was not included:
  • The BM, ie. the person that grades the "quality" and thus reward distribution must not be a (current) Curator.
  • The exact format that participants should post in the forum (making it easier for all)
  • A template for the Curators "approval" spreadsheet
  • The workflow and timeline
    As the first to act at the end of each week, this must be settled!
Grading

19.OP-1 - Runtime Upgrade Verification

  • Reward: $250
  • Start Block: #1998000
  • End Block: #2192400

Purpose

With KPI 17.OP-1), the runtime upgrade was tested. However, the results weren't straight forward to parse. We need to verify exactly what happened, before we perform the upgrade on the real testnet!

Note that an updated version of pioneer can be found here, and that you can use the endpoint wss://staging-3.joystream.app/rpc for both pioneer and the API. Also note that the noteworthy fixes in this runtime upgrade was to:

  1. Fix the bug that caused all stakes when applying to the operations group caused the role and application stakes to get burned.
  2. Increase the max mint capacity increase through proposals from 5,000,000 to 50,000,000.

Scope of Work

  1. After the proposed testing protocol was shared on Discord, I replied with some extra tasks. Although the tasks appear to have been performed, it's not easy to confirm from the results. Go through the list, and verify everything was done.

  2. Using the Member IDs, worker IDs, block heights, membership and worker accounts listed in the report, get the historical chain data from the applicable reports and test/verify for each opening and application:

  • What was the opening ID, opening parameters (max applicants, application/role stake, rewards and the various unstaking parameters)
  • Was the opening created before or after the runtime upgrade
  • What was the member ID, member handle, membership root/controller account, and role account
  • Was the application made before or after the runtime upgrade
  • What was the balance of each account, and the total issuance, on the block, and the block before, the member:
    • applied
    • was crowded out, not hired or hired
    • if hired:
      • fired or quit
    • note that if the unstaking parameter was >0, you need to check the block + the applicable unstaking value
    • note that if they were hired, they may have earned rewards that further complicates things
    • they may also have received tokens from other addresses/rewards in the window
    • also note that if the same member applied to multiple openings, you need to keep track of all stakes/values/rewards

After having generated all this information, create a report containing all the numbers above, an explanation of what you think happened, and whether the bug was fixed.

Grading
  • No work submitted/completed

19.SP-1 - Storage OKRs (Joint with 19.OP-2)

  • Reward: $250
  • Start Block: #1998000
  • End Block: #2192400

Note that this task is shared between the Operations Lead and the Storage Provider Lead. Ideally, they'll either co-operate, or delegate to workers in their respective groups to co-operate.

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, and the KPI 17.SP-1 wasn't completed last term, we'll give them one more chance, but with a shorter deadline.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the proposed Key Results 1 - uptime, 5 - Rendering Time, and 6 - Upload Speed, and:
    • Are there any changes required to these?
    • What tools, not already available (eg. helios and joystreamstats.live has some helpful tools already) are needed to start measuring these right away?
    • Add examples, and improve the instructions and notations used so that the Council, Storage Providers and others understand exactly what and how is being measured, how it's going to be graded, and how frequently the should be measured
      Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. Deploy a script that measures the data you can, and share the script so that others can do so.
  2. Finally, review the proposed OKR system outlined in KPI 19.9, and the numbers that come out of it.
Grading
  • No progress.

19.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #1998000
  • End Block: #2192400

Purpose

Although the OKR system will make it less profitable to be an underperforming SP on paper, the savings in costs by running a "cheap" node may break that assumption. Although we believe the Lead should have some subjective decision making power in deciding when the sanction a Worker, some objective data should be made available for the benefit of all parties. That doesn't mean that for long running SPs, with a great track record, some underperformance for some time is accepted.

Scope of Work

  1. Based on OKR related data, and/or other criteria, create a set of rules that could or should lead to the firing, slashing, or other sanctions agains an SP.
Grading
  • No work submitted/completed

19.SP-3 - Test Storage Node Upgrade

  • Reward: $400
  • Start Block: #1998000
  • End Block: #2192400

Purpose

A PR with another upgrade to the storage node was made a while back. This has been testet quite well, and seems to improve the performance further, with some improvements added to helios as well that should be helpful for the OKRs.

Scope of Work

  1. Fire up two new storage nodes at the same time, where one runs the current master branch, and the other the branch with the upgrade. Log which commit they are built from. Configure them as such:
  • both in the same datacenter
  • with the same specs
  • run as --anonymous
  • set --max-sync 50
  • ensure they have enough storage (at least 300GB) to reduce randomness.

  1. Check the amount of storage they have available at regular intervals (say every 1h), and compare the time it takes for each to complete, and whether they have any issues.

  2. Deploy them (don't think you need to actually hire them, but you need a URL at least) to test downloading and playing 20-30 videos both have to a third computer, and compare the the download speed.

  3. Test the new helios functionalities.

  4. Report the results.

Grading

KPI 18

  • KPIs: 13+7
  • Total Possible Rewards: $2450+$1075
  • Council Elected in Round: 20
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1890000 / 17.08.21
    • End Block/Date: #1990800 / 24.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #2019600 / 26.08.21

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 51 1798036
2124 julysake 10 352556
361 blackmass 9 317300
515 l1dev 164 5781919
635 xfactorus 19 669857
867 xandrell 57 2009570
318 supunssw 7 246789
2039 doppelganger23 9 317300
321 freakstatic_council 117 4124906
957 leet_joy 6 211534
439 fierydev 2 70511
2462 chiffah 68 2397381
4 nexusfallout 10 352556
2 tomato 348 12268951
2435 zazik 75 2644170
2182 isonar 215 7579955
2329 laura 480 16922691
SUM 17 1647 58065982

Note that some of the CMs shouldn't have gotten rewards, as they forgot to fill out the CM/FM survey. Fortunately for them, we forgot to annihilate them :)

Payouts made on block #2049149.

Section I - Council work, Proposals and Bureaucracy

18.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 39 147 21
2124 julysake 21 69 10
361 blackmass 16 61 9
515 l1dev 25 95 14
635 xfactorus 37 134 19
867 xandrell 39 132 19
318 supunssw 12 48 7
2039 doppelganger23 18 60 9
321 freakstatic_council 32 118 17
957 leet_joy 14 40 6
439 fierydev 4 16 2
2462 chiffah 28 106 15
4 nexusfallout 18 67 10
2 tomato 22 90 13
2435 zazik 27 106 15
2182 isonar 28 103 15
SUM 16 380 1392 200

18.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

As we have yet to conclude the second "round" of these, we will give it a little more time. Note however that the grading will require far better arguments (when in disagreement), and more precise questions (when information is required) for qualifying for rewards. A simple "no.", or "why?" will not command anything. Finally, we are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Total Cap at $500

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

  • @lyazufey1812 ($30)
    • https://testnet.joystream.org/#/proposals/463
      • Cost: Unknown
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No
      • Reward: $35
        • The comment raised some important small mistakes with the written proposal
  • @chiffah ($15)
    • https://testnet.joystream.org/#/proposals/449
      • Cost: Up to $400
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and there was no comment made.
      • Reward: $15
    • https://testnet.joystream.org/#/proposals/438
      • Cost: Up to $10
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and the comment didn't provide any dissent.
      • Reward: $0
    • https://testnet.joystream.org/#/proposals/437
      • Cost: Up to $10
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No. The vote was an abstain vote and the comment didn't provide any dissent.
      • Reward: $0
  • @tomato ($50)

18.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

18.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1890000
    • End Block: #1990800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

18.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 19th "official" Council (#1890000-#1990800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

18.6 - FM Surveys

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others).
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + (1 the lead). For each CC after the 6th one, $25 will be awarded to the CM(s) in charge.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 (the lead). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge.

Reward Distribution

Grading is individual.

Grading

Section II - Community Management

18.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1897200
    • End Block: #1983600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

18.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it needs to be "re-orged".

Note

Extended from KPI 16 and 17. Note that this is final extension!

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds contribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

18.9 - Follow up the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Establishing the new OKR system for the SPs has unfortunately stalled. The technical part is more or less complete, and will be completed for the next Council Term, so we're going to cut through and propose something more specific. The work is to find out exactly what the numbers R_rec.L, R_okr.L, R_rec.W and R_okr.W should be:
  • The Lead currently earns $72 per week in recurring rewards
  • The Workers (ex JSG) all earn $27 per week in recurring rewards
  • Going forward, we propose all Workers (R_rec.W) earn either the break-even cost in terms of hardware, or slightly below.
  • Whether the recurring reward for the Lead (R_rec.L) should be higher or lower than this isn't clear.
    • The Lead has extra responsibilities to running their node, which has a value
    • The Lead will however potentially earn an extra income on this, as they will earn OKR rewards for the groups performance, and for Storage KPIs, which will cover most of their extra tasks
  • After establishing a benchmark value for OKRs, the OKR payout scheme will mean that of max OKR payout pool, equal to R_rec.L + R_rec.W, so that:
    • For the Group:
      • For each of the 7(?) KRs that exceeds the weekly target -> 1/7th of R_okr.W is shared between all the SPs that reached this individual KR.
      • If the group on average exceeds the target for 4/7 KRs, the Lead gets a bonus equal to R_okr.L/10
      • If the group on average exceeds the target for 5/7 KRs, the Lead gets a bonus equal to R_okr.L/5
      • If the group on average exceeds the target for 6/7 KRs, the Lead gets a bonus equal to R_okr.L/2
      • If the group on average exceeds the target for 7/7 KRs, the Lead gets a bonus equal to R_okr.L
  • Get these independent numbers approved by the Council, and provide specific examples of outcomes for the Workers and Lead with this schedule.
    • Note that half of the OKR rewards will come from minting of new tokens, so only half of the OKR rewards needs to be accounted for in the budget.
    • Further note that it's unlikely that the FULL OKR rewards (R_okr.W+R_okr.L) will actually be paid out each week, so the Council can assume the budget for the SP group won't have to pay all of R_rec.L + R_rec.W + (R_okr.W + R_okr.L)/2.

  1. Finally, as the OKRs will be tracked starting with the next Council Term, ensure that the Lead has set the new rewards for the workers within that time. (Also a Storage KPI).

  2. Assist the Lead with their other KPIs for the Term.

Reward Distribution

Individual grading.

For 3. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $200
  • 2: $100

Grading

  • SOW 1 (OKRs + payouts) - ($200)
    • No work submitted. No rewards.
  • SOW 2 (set new rewards) - ($100)
    • No work submitted. No rewards.
  • SOW 3 (assist lead with their KPIs)
    • No work submitted. No rewards.

18.10 - Follow up the Content Curators Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. With the new "Upload Content" Bounty being presented, ensure we get a good start. Act as the Council's arm, to ensure that all the tasks outlined in KPI 18.13-3 and KPI 18.CC-3 are not only done, but in a satisfactory manner.

  2. Assist the Curator Lead with their other Curators KPIs, KPI 18.CC-1 and KPI 18.CC-2.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1-3: $50

Grading

  • SOW 1 (Public domain videos + KPI 18.CC-3) - ($75)
    • No work submitted. No rewards.
  • SOW (assist with KPI 18.CC-1 + 2) ($75)
    • No work submitted. No rewards.

18.11 - Follow up the Operations Working Group

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1897200
    • End Block: #1983600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Assist the Lead in achieving their Operations KPIs, 18.OP-1 and 18.OP-2.

Reward Distribution

Grading is individual.

Grading

  • SOW 1 (assist lead in achieving their KPIs) - ($100)
    • No work submitted. No rewards.

h2 id="section-iv">Section IV - Bounties

18.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No work submitted. No rewards.

18.13 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1890000
    • End Block: #2005200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language
  1. The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • ensure a BM, or a small team is hired, for the scope of grading the "value" of the videos
      • these people should NOT be Curators, to avoid overlap
    • ensure the Curators are deploying resources to validate/approve the videos
    • ensure a good workflow is established between them, with precise timelines
    • officially open the Bounty through a forum post, before the end of the Term

Reward Distribution

Grading is individual.

Weighting:

  • 1-2: $50
  • 3: $100

Grading

  • Bounty 20 ($50)
  • Bounty 21 - Website Translation ($50)
    • No work submitted. No rewards.
  • Bounty 22/24 - Upload Content ($100)
    • No work submitted. No rewards.

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.
    • Example: If the Operations Group performs the Update Featured Video, but fails to test anything and/or take notes, they will not be rewarded at all.

Note that there were some incorrect block heights for the End Block for all of these. It was meant to be the end of the term, but it's not clear exactly if it was understood to be a typo, so they'll be extended (mostly).

18.CC-1 - Update Featured Video

  • Reward: $75
  • Start Block: #1897200
  • End Block: #1983600

The "Main" featured video for the Joystream Player has been the same for a while now. It's time to change it!

Last week, the same KPI was made, with these results:

  1. A proposal to establish the rules was made, with a link to the mechanism on github.
  2. ?
  3. Video

Some notes:

  1. This mechanism certainly rules out a number of videos, but it doesn't establish a mechanism, unless one accepts that the Lead and curators agree offchain. Further, one has to remember that the featured video is the first thing any new user will see when opening the Joystream Player, and it autoplays the "cover cut" by default. That means that this video has to be standout, and the cover cut needs to be interesting.

  2. Nothing provided.

  3. Continuing from 1, although this particular video was indeed well made, it's rather short.

  • No cover cut was provided, as the link doesn't work

It has to be mentioned that:

  • The link provided in the KPI (by me) was not correct, as the file name had been changed.
  • The Council approved the "faulty" mechanism.

To summarize, we'll try again!

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Notes:
  • JSG reserves the right to veto this choice, for any reason.
  • Certain metadata is required, including a cover cut.
  • The community should keep in mind the featured video slot should be reserved for the absolute best ones in terms of production value etc. The main goal of this video (in the future) is to get the person opening the Joystream Player buy a subscription to the platform!

  1. Following 1., use said mechanism to select the video.

  2. Propose one (or more if needed) videos to Jsgenesis - @kdembler(koalva#6880) and @bedeho(bedeho#0275) on Discord for approval.

  3. After one has been approved, follow the steps here, and share the json with @kdembler(koalva#6880) on Discord.

Grading

18.CC-2 - Bounty 10 Cleanup

  • Reward: $150
  • Start Block: #1897200
  • End Block: #1933200

Purpose

The post-mortem of Bounty 10 still hasn't been completed. However, with the "old" Lead having left, and "new blood" on the way in, we can't expect them to fix it for free.

Although some work may have been done on this last Term, nothing has been shared as far as we know. We'll give the Curator Lead one more go. (Note the early End Block).

Scope of Work

  1. Familiarize yourself with the task defined in KPI 15.8 and KPI 16.10, and the WIP delivery. Get an overview of what is done AND correct, what is done but not correct, and what is missing.
  2. Create a realistic timeline, with milestones, for when the task is completed for all the videos, assuming the entire team will divert their full attention to it.
  3. Share the work that has been done thus far, with emphasis on the format of what will be delivered when the Cleanup is done.

Grading

@laura ($450)
* As mentioned when grading the last term, the Curators basically finished the work instead of following the KPI rigorously.
* The "issue" with that, is that the rewards for completing hadn't been defined.
* Furthermore, the task in 1. and 2. were graded last week.
* The actual work submitted was great, and spot checks uncovered only a couple minor errors. The only real problem one could find is that it appears not to have been clear to the Curators why this was a KPI - namely identifying incorrect and/or dishonest licensing. In the future, it would be nice to highlight which videos needs curation, and why.
* The reward for this KPI is going to be higher than the reward stated, as it completes KPI 16.10 only double. The reward for those would have been $400.
* Adding another $50 from this brings the total to $450.

18.CC-3 - New "Upload Content" Bounty

  • Reward: $100
  • Start Block: #1897200
  • End Block: #1983600

Purpose

As we sincerely wants to have a lot of uploads on our platform, we're planning to re-open a similar Bounty to #10, but with more strict and precise rules for all parties. The Curators will verify/approve each video, before the BM will do the actual grading.

The JSG "Specs" for Community Bounty #22 - "Upload Content", can be found here.

Scope of Work

  1. Review the issue, and in collaboration with the Council and the BM that gets assigned, agree on the exact:
  • Scope of Work for the Curator group
  • Workflow
  • Weekly deadlines
  • The format of the validation performed by the Curators
  1. Allocate resources from the Curator Group and "train" them, to ensure what was agreed in 1. is upheld.

Grading

18.OP-1 - KPI JSON

  • Reward: $300
  • Start Block: #1897200
  • End Block: #1983600

Purpose

As many have pointed out, using this blog post to read the KPIs is cumbersome at best. The Operations group has proposed a new format for this, under the assumption we still used a JSON to present the data. As this is, sadly, not the case anymore, we need to make it happen!

Note that the Operations Lead proposed using YAML instead of a JSON, but I prefer the latter for the simple fact that it's used in so many other parts of the Joystream Platform, making it easier for most to grasp (if not master).

Scope of Work

  1. Based on the structure of this, and previous KPIs, come up with a JSON Schema for presenting the data in the KPIs.

  2. Find a "clever" standard of presenting tables, line changes, bullet points (and numbered/lettered) presented.

  3. Create a script that parses a markdown and creates a nice looking JSON, OR vice-versa.

Weighing:

  1. $150
  2. $50
  3. $100

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. or 3. is not completed.

Grading

  • SOW 1 (JSON schema) ($150)
  • SOW 2 (standard for presenting tables/bullet points) ($50)
    • No work submitted. No rewards.
  • SOW 3 (create a script) ($100)
    • No work submitted. No rewards.

18.OP-2 - CLI Integration in Pioneer

  • Reward: $200
  • Start Block: #1897200
  • End Block: #1983600

Purpose

Some amount users has issues accessing the CLI, mostly due to the slightly cumbersome installation process, but for others, even opening the terminal is a little scary. Is there a way we could integrate the CLI in to Pioneer? Ideally, it would be similar to how the current JS integration works, but allow you to choose between the keys you have in your local storage.

This was not done last week, but I'm giving it one more Term. I'll also bump the reward, as it seems it may be underpaid a bit.

Scope of Work

  1. Do some research, and research if this is feasible. If yes, outline the challenges associated with the making this, create an estimate of the time needed and the expected costs.
  • It can be used in the browser, similar to how the current JS integration works
  • It can use the keys you have in your local storage
    Make a PR with the findings to the Community Repo
  1. Write the draft for making this a Bounty.

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. is not completed.

Grading

  • SOW 1 (Research)
    • This was already completed in KPI 17.x and paid out $75/$100 to isonar.
  • SOW 2 (Write Bounty Draft)
    • The KPI 17.x grading notes that this was impractical, no work was reported, so no rewards have been given.

18.SP-1 - Storage OKRs

  • Reward: $200
  • Start Block: #1897200
  • End Block: #1962000

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, and the KPI 17.SP-1 wasn't completed last term, we'll give them one more chance, but with a shorter deadline.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the metrics, and propose what:
    • changes
    • removals, or;
    • additions are in order, and;
    • why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
    Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. For the Storage OKRs that CAN be measured without new tools, start getting numbers as a benchmark value for the OKRs. In addition to the "final" numbers, the data sources must be provided.
  2. Finally, review the proposed OKR system outlined in KPI 18.9, and the numbers that come out of it.

Grading

  • SOW 1 (Review Storage OKRs)
    • No work submitted. No rewards.
  • SOW 2 (Start measurements)
    • No work submitted. No rewards.
  • SOW 3 (Review proposed OKR system)
    • No work submitted. No rewards.

18.SP-2 - Storage Provider Sanctions

  • Reward: $50
  • Start Block: #1897200
  • End Block: #1983600

Purpose

Although the OKR system will make it less profitable to be an underperforming SP on paper, the savings in costs by running a "cheap" node may break that assumption. Although we believe the Lead should have some subjective decision making power in deciding when the sanction a Worker, some objective data should be made available for the benefit of all parties. That doesn't mean that for long running SPs, with a great track record, some underperformance for some time is accepted.

Scope of Work

  1. Based on OKR related data, and/or other criteria, create a set of rules that could or should lead to the firing, slashing, or other sanctions agains an SP.

Grading

  • SOW 1 (set of rules for firing/slashing/sanctions against SPs)
    • No work submitted. No rewards.

KPI 17

  • KPIs: 13+5
  • Total Possible Rewards: $2825+$725
  • Council Elected in Round: 18
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1789200 / 10.08.21
    • End Block/Date: #1890000 / 17.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1918800 / 19.08.21
Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 19+45 639959+1515692
2124 julysake 6 202092
361 blackmass 6 202092
515 l1dev 11 370502
982 drmarkovi 9 303138
867 xandrell 17 572594
321 freakstatic_council 124 4176571
439 fierydev 8 269456
4 nexusfallout 12 404184
2 tomato 329 11081387
736 mmsaww 56 1886193
2329 laura 141 4749166
705 flakes9776 10 336820
2130 maxlevush 663 22331184
1048 igrex 126 4243935
2182 isonar 282 9498331
SUM 16 1819 61267604
  • due to an error, lyazufey1812 didn't get credit for 17.2 in the initial transfer.

Paid out on block #1,963,066 and block #1,963,067.

Section I - Council work, Proposals and Bureaucracy

17.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 34 127 19
2124 julysake 12 36 6
361 blackmass 11 38 6
515 l1dev 18 72 11
982 drmarkovi 17 59 9
867 xandrell 31 109 17
321 freakstatic_council 24 93 14
439 fierydev 14 50 8
4 nexusfallout 21 79 12
2 tomato 18 70 11
736 mmsaww 21 83 13
2329 laura 26 104 16
705 flakes9776 21 66 10
2130 maxlevush 31 135 21
1048 igrex 34 140 21
2182 isonar 14 47 7
SUM 16 347 1308 200

17.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Note

As we have yet to conclude the second "round" of these, we will give it a little more time. Note however that the grading will require far better arguments (when in disagreement), and more precise questions (when information is required) for qualifying for rewards. A simple "no.", or "why?" will not command anything. Finally, we are trying to build a strong, yet friendly community, welcoming to all. There is no reason to be rude, and personal attacks without substance will automatically void an otherwise insightful message. There are standards even when disagreeing on the internet.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  • How clear and reasonably was the message your question/comment?
    • was your argument(s) backed up by verifiable facts?
    • did you link to source(s)?
    • did your question(s) make it clear what your concern were?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Total Cap at $500

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

  • @laura $0
    • https://testnet.joystream.org/#/proposals/424
      • Cost (Claimed): $100
      • Was it a malicious, or objectively bad proposal: No
        • Did the vote/comment affect the outcome: No, comment was made after 5/9 votes were in.
        • "Cost" of proposal: unknown
        • Reward: $0
  • @igrex $55
    • https://testnet.joystream.org/#/proposals/408
      • Cost: unknown, but presumably some non-trivial amount
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Yes, likely
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $50
    • https://testnet.joystream.org/#/proposals/416
      • Proposal was an improvement to the above.
      • Cost: $25
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Possibly
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $5 (shared)
  • @isonar $0
    • "I really hate this KPI, frankly, but this week there was a case which I couldn't help but reporting as anything else but my dissent."
    • https://testnet.joystream.org/#/proposals/423
      • Proposal ongoing, will be graded next term
    • https://testnet.joystream.org/#/proposals/417
      • Cost: $450 (text proposal, so inferred)
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No
      • No comment was made to the actual voters. Discord comments are fine and well, but unless the voters can see them...
      • Reward: $0
  • @lyazufey1812 $45
  • @mmsaww $5
    • https://testnet.joystream.org/#/proposals/416
      • Cost: $25
      • Was it a malicious, or objectively bad proposal: no, but substance was lacking
      • Did the vote/comment affect the outcome: Possibly
      • Was the objection reasonable, and presented in an acceptable way: yes
      • Reward: $5 (shared)
  • @maxlevush $22
  • @freakstatic_council $10
    • https://testnet.joystream.org/#/proposals/417
      • Cost: $450 (text proposal, so inferred)
      • Was it a malicious, or objectively bad proposal: no
      • Did the vote/comment affect the outcome: No.
      • Reasonable objection, but a more helpful one would be to link to alternatives.
      • Reward: $10

17.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

17.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1789200
    • End Block: #1890000

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

17.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 2 days
    • Start Block: #1789200
    • End Block: #1918800

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 18th "official" Council (#1789200-#1890000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

17.6 - FM Surveys

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

We are still trying to figure out exactly why we don't see more FM submissions from the Working Groups. These specific Surveys are likely to be a recurring KPI. Note that these are not anonymous!

Scope of Work

  1. Have the Council Members fill out this survey. Any individual CM that doesn't complete will get annihilated, but only that CM (not the others).
  2. Have the Content Curators fill out this survey. At the time of writing, there are 9 workers + but no lead. For each CC after the 6th one, $25 will be awarded to the CM(s) in charge.
  3. Have the Storage Providers fill out this survey. At the time of writing, there are 9 workers + 1 the lead - soon(tm). For each SP after the 6th one, $25 will be awarded to the CM(s) in charge.

Reward Distribution

Grading is individual.

Grading

  1. CMs completed in time: julysake, mmsaww, igrex, Nexusfallout, flakes9776, freakstatic_council, maxlevush, tomato, lyazufey1812, isonar
    • Technically, @laure should be DQ'd, but it's assumed to be a misunderstanding this time, as the curator survey was completed.
  2. CCs completed in time: 4/10 -> no reward.
  3. SPs completed in time: 9/10 -> $75.

Section II - Community Management

17.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1796400
    • End Block: #1983600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

17.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it needs to be "re-orged".

Note

Extended from KPI 16

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds constribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

17.9 - Follow up the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Assist the Lead with their KPI for the Term.

  2. Assuming:

  • There will, on average, be ~$200 available as KPI rewards (minted by JSG, not part of the budget) for the Storage Group (KPIs managed by the Lead)
  • There will be weekly grading of the OKRs, where the Lead is rewarded if the group performs well, and the workers are rewarded if they perform well individually.

Propose on an exact reward structure for the SPs:

  • How much should simply occupying the role award, for both workers and Lead?
    • What is the assumed break-even point for one SP?
    • Why so much/little?
  • How much should the individual SP earn for running good nodes through the OKR system?
    • Should the OKR system pay for their internal rank, ie. relative grading or should it be absolute?
  • How much should the SP Lead earn for managing a team that gets "good" scores?
  • How does the KPIs play in here?
    • Should we assume the Lead always assigns themselves?

Based on numbers found, and the current budget, how many SPs should the platform have?

Reward Distribution

Individual grading.

For 1. If the SP KPI is graded as complete, the SP Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $200
  • 2: $100

Grading

  1. Assist the Lead with their KPI for the term ($200)
    • No claims for this KPI.
  2. Propose exact reward structure for SPs + KPIs ($100)
    • No claims for this KPI.

17.10 - Follow up the Content Curators Working Group

  • Reward: $350
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Hire a new Lead. It needs be made abundantly clear to the applicant what is expected of them from the get go, as they will be "under fire" immediately.

  2. The platform needs a well defined curation policy for the Curators. Although some examples have been made in the helpdesk, both for the Lead and Workers, the Council should improve and update these based on the experiences thus far. This is not to say that there can't be any degrees of freedom for the Curators, but some basic rules should be prepared, and presented in a comprehensible way. Prepare a PR to the community repo, and get it approved by the rest of the Council. Ensure the new Lead is on board with these rules, keeping in mind the reward they will earn. Finally, present the rules to JSG for approval.

  3. Ensure the Lead immediately addresses their KPIs for the Term. If they are hired before block #1947600, ie. three or more full days before the end of the term, but is unable to complete the tasks outlined in their KPIs, a warning should be issued.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $200
  • 3: $50

Grading

  1. Hire a new lead ($100)
  2. Curation Policy ($200)
  3. Ensure the lead immediately addresses their KPIs ($50)

17.11 - Follow up the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1796400
    • End Block: #1983600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. As for the other Working Groups, we are considering switching the Operations Working Group's rewards scheme to a combination of specific Operations KPIs, and perhaps at a later stage OKRs. Review KPI 15.9-1, adapt it to the Operations Working Group, and propose a scheme. An important thing that is unique to this group is that some of it's Workers are hosting infrastructure out of pocket. It's not entirely clear exactly what that is, who is doing it, how it's being compensated, and whether these tasks are tied to individuals who happens to be part of the Operations WG, or whether these are tasks that are tied to the WG itself.
  2. Assist the Lead in achieving their Runtime Upgrade Test KPI.

Reward Distribution

Grading is individual.

For 2. If the KPI is graded as complete, the Operations Lead will decide the reward for the CM(s). If not, nothing will be granted unless there are consequences* for the Lead.

* Firing is not the only valid consequence

Weighting:

  • 1: $150
  • 2: $100

Grading

  1. Reward Scheme ($150)
    • No claims for this KPI.
  2. Assist the lead in achieving their Runtime Upgrade Test KPI ($100)

h2 id="section-iv">Section IV - Bounties

17.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • Bounty 9 ($25/$50 per week)
    • No claims for this KPI.

17.13 - Other Bounty Managers

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

Working Group KPIs

We are trying out new ways of rewarding the Working Groups, for multiple reasons.

The Working Group KPIs will, at least for this Council Term, work like so:

  • The Lead assigns a group or individual to the task (they can choose themselves).
  • Unless otherwise noted, all subtasks must be completed. If not, no rewards will be given.
    • Example: If the Operations Group performs the runtime upgrade, but fails to test anything and/or take notes, they will not be rewarded at all.

17.CC-1 - Update Featured Video

  • Reward: $75
  • Start Block: #1796400
  • End Block: #1983600

Purpose

The "Main" featured video for the Joystream Player has been the same for a while now. It's time to change it!

Scope of Work

  1. Decide on some "good" mechanism for deciding what it should be, eg:
  • Community Vote
  • Council Vote
  • Most viewed
  • Other
    Note that:
  • JSG reserves the right to veto this choice
  • Certain metadata is required.
  1. Following 1., use said mechanism to select the video.
  2. Follow the steps here, and share the json with @kdembler(koalva#6880) on Discord.

Grading

17.CC-2 - Bounty 10 Cleanup

  • Reward: $150
  • Start Block: #1796400
  • End Block: #1983600

Purpose

The post-mortem of Bounty 10 still hasn't been completed. However, with the "old" Lead having left, and "new blood" on the way in, we can't expect them to fix it for free.

Scope of Work

  1. Familiarize yourself with the task defined in KPI 15.8 and KPI 16.10, and the WIP delivery. Get an overview of what is done AND correct, what is done but not correct, and what is missing.
  2. Create a realistic timeline for when the task is completed for all the videos, assuming the entire team will divert their full attention to it.

Grading

  • @laura (lead) - $125/$150
    • https://testnet.joystream.org/#/forum/threads/545?replyIdx=2
      1. Presumably done
      2. Estimation not provided during council term, but instead, it seems like the actual work was close to being done.
        • This leads to a quite awkward situation, as the next CC KPI was supposed to set a reward for doing the work based on this.
        • The final, "human, readable" version of the cleanup was presented formally after the deadline for this term.
        • Therefore, the grading of the actual work will be done for the next term, this grading (and reward) covers only what was stated in 17.CC-1.
        • In summary, it feels harsh to deduct in this case, but the Lead should expect the next grading to more accurately reflect the work that's been done.

17.OP-1 - Runtime Upgrade Test

  • Reward: $200
  • Start Block: #1796400
  • End Block: #1983600

Purpose

Looking at the progress for KPI 16.11-3, it seems unlikely that the full test, plus report can be completed before the end of the Term.

Scope of Work

  1. Finish the test, per the testing protocol.
  2. Prepare a step by step by step report, with all the relevant information needed to verify the findings. This includes:
  • For all the mint proposal testing:
    • Proposal IDs
    • Results
  • Blockheights of every transaction of importance
  • For all Operations Group stake testing:
    • The addresses and memberships for all applicants
    • The blockheights for each "event" and the balances of the relevant accounts before and after each of them.
    • Results
  • For all "random" tests performed:
    • What was tested
    • Results

Grading

  • @isonar $100/$200
    • https://github.com/Joystream/community-repo/pull/294
      1. Test was finished
      2. It seems as though the major parts were actually done, but there were many issues with the report:
        • The structure of the report makes it very difficult to read.
        • The same accounts have been used for multiple openings, and the naming (mix of memberId, memberHandle, workerId)
        • It's impossible to tell (from the report notes alone) whether the Operations WG applicants that applied before the upgrade got their stake(s) back or not.
    • In @isonars defense, the instructions could have been made more clear, but in general (eg. not just in this case), I think it's important for users to try and think what is actually being done. In this particular case, it means that in order to verify the runtime works as intended, one has to get lots of historical state in order to parse the results.
    • Furthermore, Pioneer was not upgraded.
  • @l1dev

17.OP-2 - CLI Integration in Pioneer

  • Reward: $100
  • Start Block: #1796400
  • End Block: #1983600

Purpose

Some amount users has issues accessing the CLI, mostly due to the slightly cumbersome installation process, but for others, even opening the terminal is a little scary. Is there a way we could integrate the CLI in to Pioneer? Ideally, it would be similar to how the current JS integration works, but allow you to choose between the keys you have in your local storage.

Scope of Work

  1. Do some research, and research if this is feasible. If yes, outline the challenges associated with the making this, create an estimate of the time needed and the expected costs.
  • It can be used in the browser, similar to how the current JS integration works
  • It can use the keys you have in your local storage
    Make a PR with the findings to the Community Repo
  1. Write the draft for making this a Bounty.

Note that unlike most WG KPIs, 1. will be graded (and rewarded) even if 2. is not completed.

Grading

17.SP-1 - Storage OKRs

  • Reward: $200
  • Start Block: #1796400
  • End Block: #1983600

Purpose

We still believe OKRs to be a good way to reward the Storage Provider Lead, and workers. However, the actual OKRs needs to be settled, and some benchmark numbers must be established. As it appears KPI 16.8-2 was not done, this will be assigned to the group itself.

Scope of Work

  1. Review the Storage OKRs here.
  • Review the metrics, and propose what:
    • changes
    • removals, or;
    • additions are in order, and;
    • why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
    Feel free to co-ordinate with the Operations group if additional technical support is needed.
  1. For the Storage OKRs that CAN be measured without new tools, start getting numbers as a benchmark value for the OKRs. In addition to the "final" numbers, the data sources must be provided.

Grading

KPI 16

  • KPIs: 13
  • Total Possible Rewards: $3600
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1688400 / 03.08.21
    • End Block/Date: #1789200 / 10.08.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1818000 / 12.08.21
Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 44 1473131
2124 julysake 7 234362
361 blackmass 6 200882
515 l1dev 11 368283
635 xfactorus 16 535684
867 xandrell 55 1841414
1962 nkhlghbl 2 66961
2039 doppelganger23 7 234362
321 freakstatic_council 130 4352433
439 fierydev 5 167401
4 nexusfallout 13 435243
2 tomato 645 21594765
2130 maxlevush 473 15836161
2148 controlla 11 368283
1027 stavr 17 569164
2182 isonar 428 14329550
SUM 16 1870 62608079

Paid out at block #1,849,466.

Section I - Council work, Proposals and Bureaucracy

16.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 36 139 19
2124 julysake 15 53 7
361 blackmass 13 46 6
515 l1dev 21 81 11
635 xfactorus 30 118 16
867 xandrell 35 125 17
1962 nkhlghbl 4 13 2
2039 doppelganger23 14 50 7
321 freakstatic_council 32 121 17
439 fierydev 12 36 5
4 nexusfallout 26 97 13
2 tomato 26 109 15
2130 maxlevush 41 154 21
2148 controlla 20 77 11
1027 stavr 34 126 17
2182 isonar 27 97 13
SUM 16 386 1442 200

16.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before. Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

16.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $280/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: N/A
    • Council wrangling in #council channel - Yes

16.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

16.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1688400
    • End Block: #1789200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 17th "official" Council (#1688400-#1789200) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

16.6 - Council Term Length and Size

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

We have had one week Council Terms and 16 CMs for a while now, giving everyone time to get used to it. Are these the "right" numbers?

Scope of Work

  1. Discuss the benefits and drawbacks of increasing and decreasing both numbers. Then propose new numbers, and back them up with data and/or arguments.

Reward Distribution

Ideally however, this should be a collaborative effort, but the organizer(s) will earn the rewards. They can however split as they like.

Grading

Section II - Community Management

16.7 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1688400
    • End Block: #1789200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

16.8 - Clean up Community Repo - Part 1

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

The Community Repo has gotten quite disorganized.

To make it easier for the community to find what they are looking for, it to be organized logically.

Scope of Work

  1. Design a set of constribution guidelines (rules) that covers:
  • How the repo should be organized, meaning:
    • what folders should be in the root directory, eg. should bounties, api-examples and council-reports be in the root directory?
    • a further hierarchy, eg. /council-reports/testnets/sumer/ or /council/council-reports/networks/sumer/
  • Naming convention rules, meaning:
    • naming convention for folders, eg. dash-separated-words,camelCase, underscore_separated_words
    • naming convention for files
      • may require conventions to depend on type of files
    • naming conventions for work submitted as part of a:
      • bounty, eg. bounty_021-websiteTranslation
      • kpi, eg. sumer_kpi_016_dot_6-cleanUpCommunityRepo
      • working group reports, eg. curator_lead_report-210803
  • Etc.
  1. Create a table/overview to makes browsing easier
  2. Make a PR, that adds constribution guidelines in a prominent and visible way.
  3. Create a proposal, and take feedback from:
  • the rest of the Council
  • the Working Groups (and Leads in particular)
  • the community (with a preference for contributors)

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Grading

  • Work submitted, but incomplete. Grading deffered as this KPI is repeated in KPI 17

Section III - Working Groups

Note

While finishing these KPIs, this proposal came to our attention. Very relevant for this secion of KPIs.

16.9 - Follow up the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

All tasks can be performed by the Council, but some co-ordination with the Lead seems prudent.

  1. We are considering switching the Storage Working Group's rewards scheme to a combination of Specific Storage KPIs, and OKRs. Propose a new compensation strategy based on all the information below.
Recurring Rewards

Some amount of their compensation should still come from recurring rewards. This could either be meant to:

  • Cover the actual running costs of operating a storage node
  • Cover the running costs, plus a small bonus for the work of bootstrapping, upgrading and maintaining
  • Cover less than the costs, assuming there are secondary incentivizes tied to extraordinary tasks and/or performance
KPIs
  • For extraordinary tasks, such as co-ordinated upgrades, testing new software, and debugging or researching errors, the Lead (and workers) have seen little to no incentives (eg. financial rewards) of doing so. Performing these tasks have only (directly) rewarded the Council through their KPIs. This can be fixed in multiple ways:
    • The Council could simply pay them extra through spending proposals, thus having "everyone" pay
    • The Council could increase their rewards temporarily to pay for it
    • The Council could increase their rewards permanently, while also be more "vigilant" in firing/slashing the Leads, thus having a more effective carrot and stick
      • All these will in some way affect the budget, complicating the financial side of the equation. Although this has some secondary benefits, it appears as though the Council(s) hasn't thought about it, or discarded it for some reason.
    • The Council could pay them directly out of their own pockets (and claimed the KPI rewards themselves).
      • This would make backroom deals more profitable. Unclear if this is good or bad.
    • We could add Storage Working KPIs to address these.
      • This approach would reduce the pressure on the Council, but add to Jsgenesis power and workload.

Assuming introducing Storage KPIs is the starting point for discussion:

  • The extraordinary these tasks would be irregular, but important.
    • Should they be for the Lead only?
    • Is it reasonable at all for the Lead to receive these, or should they be expected to perform "these sort of tasks" anyway?
    • What should the Leads recurring rewards be, if the only thing that distinguishes from the Workers is managing the Workers, (eg. hiring, firing and setting rewards) and reporting?
OKRs

Having objective and numeric metrics to evaluate the performance of the group has been long wanted, and used to some extent for a while. A formal system of measuring it, as outlined in #2 could be used to either:

  • Give the Council better data to evaluate the performance of the Storage group, or
  • Have the OKR system account for some percentage of the Leads, and potentially groups, overall rewards

Assuming we opt for the OKRs tied to rewards is the starting point for discussion. JSG proposes a system where:

  • The Council either assigns someone to perform the measuring and grading, or it's done by JSG.
    • The metrics and tools needed are provided through a group effort (JSG, the Operations group, and potentially others)
  • The "official" OKRs only measures and rewards the Lead.
    • The Lead gets the data measured, and uses it to measure and reward the individual Workers.
  • They are measured each Council term.
    Questions:
  • Does the above make sense? If not, propose improvements
  • How much of the Leads, and potentially Workers, should be tied to the OKRs?
  • Should the rewards come from budget, or some other source?
  • How should they be paid out.
  • Should there be a stick in addition to the carrot?
  1. Review the Storage OKRs.

An issue outlining the storage OKRs will be posted no later than block #1723000.

  • Review the metrics, and propose what changes, removals or additions are in order, and why
  • Review the proposed tools needed
  • Add examples, and improve the instructions and notations used
  1. Time permitting, start measuring what the values of each Key Result is right now, to create a benchmark.

Reward Distribution

If multiple PRs are made, only the best one will be rewarded.
Ideally however, this should be a collaborative effort.

Weighting:

  1. $150
  2. $100
  3. $150

Grading

  1. Propose a KPI/OKR rewards scheme
  2. Review the Storage OKRs
  3. Start measuring to create a benckmark
    • No work completed

16.10 - Follow up the Content Curators Working Group

  • Reward: $600
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Note

Scope of Work

Task 1. is expected to be performed/coordinated by the Curator group. The Council, or a Council Member's job is to push them into doing so. The first half should have been completed during the last term.

Tasks 2-4 can be performed by the Council, but some co-ordination with the Lead seems prudent.

  1. Bounty #10 was cancelled, mainly because a quick spotcheck revealed that the Bounty meant to reward publishing videos in the Public Domain ("PD") (to be fair, other permissive licenses was also allowed, if the license was "valid" - eg. attribution included, no derivates, etc.), was mostly rewarding copying videos from YouTube (YT). After we announced this, a concern that not only was most of the videos taken from, but not all videos was even properly licensed from there.
    The Curators must perform a "post mortem", going through ALL videos that submitted a claim to Bounty #10 (even if they weren't rewarded), and provide a spreadsheet with the following columns:
  • Video Id
  • Channel ID
  • Owner Id
  • On-chain License
    • The on-chain license ID can be mapped to the name - see helpdesk for Curators
  • On-chain Attribution
  • Whether other licensing requirements are upheld
    • Only applicable to certain CC licenses, eg. CC BY-ND - "No derivates"
  • Information Provided
    • If the forum post with Bounty claim contained extra info about the source
  • Original YT link
    • If available with a quick search
  • Actual license of original source
    • What license the media is actually licensed as
    • On YT, any video that doesn't explicitly say License - Creative Commons Attribution license (reuse allowed), is NOT free to share by anyone else than the owner.

Before the end of the Term, the Curators must have completed the FULL report, and shared it with me @bwhm#6514 on Discord.

  1. The platform needs a well defined curation policy for the Curators. Although some examples have been made in the helpdesk, both for the Lead and [Workers]](https://github.com/Joystream/helpdesk/tree/master/roles/content-curators), the Council should improve and update these based on the experiences thus far. This is not to say that there can't be any degrees of freedom for the Curators, but some basic rules should be prepared, and presented in a comprehensible way. Prepare a PR to the community repo, and get it approved by the rest of the Council.

  2. At the time of writing, it's not clear whether task 4. and 5. from KPIs 15.8 were completed. These are loosely related to task 2. above.

  3. As for the Storage Working Group, we are considering switching the Curators Working Group's rewards scheme to a combination of specific Curator KPIs, and perhaps at a later stage OKRs. Review KPI 16.9-1, adapt it to the Curator Working Group, and propose a scheme.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $200
  • 2: $100
  • 3-4: $150

Grading

  1. Bounty 10 report
  2. Curation Policy
    • No work completed.
  3. KPI 15.8 follow up
    • No work completed.
  4. Propose a KPI/OKR rewards scheme
    • No work completed.

16.11 - Follow up the Operations Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1702800
    • End Block: #1774800

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

Task 1 and 2 needs to be performed with assistance, if not by, the Operations group. Tasks 3 and 4 are open for the Council.

  1. A runtime upgrade has been prepared quite some time ago, but haven't been properly tested yet. The PR can be found here, and building should return a .wasm file with the blake2 checksum:
(0x)d6a5f19b0a9834921a2e778676f2c8255d56e1a792bdfcd31dd29263b52c1021416adc126c152d1a425afd859f45f167a17847ec5e3288a75cfb2bfa74172ad2 joystream_runtime.wasm

If you get a different hash, ask us for the wasm.

As there is a staging network mirroring the current network, this can be used for testing. All that is needed is to ask us for the chain_spec.json, sync a node (or two), and host the version of pioneer in the PR above. At least the main tester must have access to this node, so they can check the logs when/if needed.

  1. Prepare a testing protocol, which includes:
  • Where to access the old, and new, pioneer
  • What needs to be done BEFORE performing the runtime upgrade?
    • a step by step list of the transactions that should be made, and
    • what should be documented along the way
  • What is going to be tested AFTER the runtime upgrade?
    • a step by step list of the transactions that should be made, and
    • what should be documented along the way

What is needed from JSG to perform the test? When (if at all) is the sudo key needed?

  • Set the Council?
  • Provide tokens for the runtime upgrade proposals? (your keys should have the same amount of tokens as at launch)
  • Sudo in the runtime ugprade? (if you don't have time to wait the full two days)
  • Provide keys to the current occupants of roles?

The test protocol must be approved by @bwhm#6514 on Discord or github.

  1. Perform the test.

  2. As for the other Working Groups, we are considering switching the Operations Working Group's rewards scheme to a combination of specific Operations KPIs, and perhaps at a later stage OKRs. Review KPI 16.9-1, adapt it to the Operations Working Group, and propose a scheme. An important thing that is unique to this group is that some of it's Workers are hosting infrastructure out of pocket. It's not entirely clear exactly what that is, who is doing it, how it's being compensated, and whether these tasks are tied to individuals who happens to be part of the Operations WG, or whether these are tasks that are tied to the WG itself.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-4: $150

Grading

  1. Runtime Upgrade
    • This has not been completed yet, grading deferred as this KPI is repeated in KPI 17
  2. Prepare a testing protocol
  3. Perform the test
  4. Propose a KPI/OKR rewards scheme

Section IV - Bounties

16.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No reports submitted covering Bounty 9

16.13 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1688400
    • End Block: #1717200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

  • Community Bounty #20 - "Github Bounty Guide"
    • @isonar $100/$200 - Managed Bounty 20
  • Community Bounty #21 - "Website Translation"
    • No claims for this bounty

KPI 15

  • KPIs: 11
  • Total Possible Rewards: $3600
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1587600 / 27.07.21
    • End Block/Date: #1688400 / 03.08.21
  • Term Summaries Forum Thread: link
  • Deadline to Submit Summary: #1717200 / 04.08.21

Annihilation

As is explained further here, there were strong arguments for simply annihilating this entire KPI, as 15.8-1 was not handled at the level expected. Instead, we opted to reduce the payments by 50%. Some points that lead to this (final) decision:

  • The workload, as described, may have been too much to expect
  • The Curators did eventually start producing what seems like an honest attempt (although late AND lacking)
  • The Council did try some last minute save, and a firing proposal is at least scary, although it won't pass.
    • Note again that this is not Jsgenesis saying the Lead should be fired.
    • The Council could, and should also have considered both carrots and sticks:
      • Providing better incentives (temporary budget increase, spending proposals, etc)
      • Slashing some amount
      • Formal warning
      • Assisted
  • Finally, a lot of excellent work would not have been rewarded.

In summary, future annihilation conditions will be better and/or more realistically constructed. If they fail however, it will be 100%.

Grading

Member ID Member Handle Reward* [USD] Reward** [USD] Reward [tJOY]
361 blackmass 12 6 207168
515 l1dev 12 6 207168
982 drmarkovi 8 4 138112
867 xandrell 70 35 1208481
318 supunssw 2 1 34528
1316 andybut 102 51 1760929
2039 doppelganger23 6 3 103584
321 freakstatic_council 246 123 4246947
957 leet_joy 0 0 0
439 fierydev 6 3 103584
4 nexusfallout 12 6 207168
2 tomato 1078 539 18610603
736 mmsaww 118 59 2037153
2329 laura 90 45 1553761
2130 maxlevush 838 419 14467241
1048 igrex 22 11 379808
SUM 16 2613 1307 45266235

* denotes the grading value
** denotes the actual amount paid, after discounting for the "annihilation"

Payouts were made at block #1748912.

Notes

This set of KPIs will have two "major" changes from the usual:

  • A primary focus in KPIs 15.7 and 15.8 (see also Annihilation Modes)
  • Stricter submissions rules:
    • if your contributions aren't added to the Term Summaries forum thread in time, or
    • doesn't include the context needed to grade (not applicable to 15.6), or
    • lacks all links needed for a reviewer
      Your work will NOT be graded.
  • Stricter grading
    • if your work lacks key components, or
    • is presented in a poor way
      Your reward will be deducted more heavily than before

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 16th (confusingly listed as "Election round 17" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.
  2. For 15.7:
  • If conditions 1-3 isn't met AND no actions are taken, or
  • If the Council isn't posting daily status updates said conditions, or
  • Nothing is submitted, or the quality of work is really poor for conditions 4-5
  1. For 15.8:
  • If condition 1 isn't met AND no actions are taken, or
  • Nothing is submitted, or the quality of work is really poor for conditions 2-3

All KPI rewards will be forfeited.

Section I - Council work, Proposals and Bureaucracy

15.1 - Proposal Clearance

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 22 85 11
515 l1dev 22 80 11
982 drmarkovi 14 50 7
867 xandrell 39 149 20
318 supunssw 2 8 1
1316 andybut 39 161 21
2039 doppelganger23 12 48 6
321 freakstatic_council 32 123 16
957 leet_joy 0 0 0
439 fierydev 10 40 5
4 nexusfallout 24 92 12
2 tomato 21 85 11
736 mmsaww 33 128 17
2329 laura 39 149 20
2130 maxlevush 37 160 21
1048 igrex 38 165 22
SUM 16 384 1523 200

15.2 - Council Dissent

  • Reward: $500
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

The Council appears to be suffering from a lack of dissent, or group think if you will.

This can at least partly be attributed to the Proposal Clearance KPI, which to some extent makes it rational for an actor to simply vote in line with the others. Taken to the extreme, this means that if you create a proposal yourself, and immediately vote approve, you're likely to get "anything" passed.

It's quite difficult to create incentives for something like this without also introducing unwanted secondary effects, which is why we haven't touched on this before.
Therefore, the Scope of Work is meant as a guideline, more than a rule for earning rewards.

Scope of Work

Whenever you are to cast a vote, read the proposal text thoroughly (should be obvious).
There are far to many permutations to cover all of them, and ideally, there should also be room to comment or add/request further information even if you agree with the proposal. Too keep it short-ish, we'll stick to dissent for now. Some examples are presented below, but these should not be emphasized over common sense:

  1. Raise concerns
A

Suppose you know "enough" about the subject, and you know there is incorrect information that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • Vote.
B

Suppose you know "enough" about the subject, and you know there is information missing that could/should have an impact on the voters decision:

  • Make a comment in the proposal, outlining what you think is incorrect, even if you still think the proposal should pass.
  • If the missing information is not available ATM, and your decision depend on clarifying this, do not yet cast your vote.
C

Suppose you don't know "enough" about the subject, but you suspect there is information incorrect that could/should have an impact on the voters decision:

  • Ask for clarification
  • Do not yet cast your vote, or vote abstain.
D

Suppose you don't know "enough" about the subject, and there is not enough information for you to cast your vote:

  • Same as C
  1. Reply to raised concerns
    If a CM has raised concerns, in either of the cases above, or through some other mechanism:
  • If you have information that would support, or add context to, either viewpoint, add your comment on the matter.

In all the cases above, it is prudent to add a link to it in the #proposals room in Discord, or simply paste the comment there as well.

Reward Distribution

It's impossible to quantify the reward in advance, as it will be a function of:

  • What is the potential cost of the error?
    • easy for spending proposal
    • possibly impossible for other proposal types)
  • How big and important was your insight?
    • did/should your point have been enough to reverse the decision?
    • or was it a combination of multiple community members comments and thoughts?
  • Did you manage to make your point clear to enough CMs in time?
    • did your comment change the outcome?
    • was your concern raised too late?
    • was it not made clear enough?
  1. If the outcome of a vote appear to have been changed because of one or more CMs comments alone, they will split a reward equal to 50% of the perceived cost of the proposal. (Capped at $250)
  2. If the outcome should have been changed because of one or more CMs comments alone, they will split a reward equal to 35% of the perceived cost of the proposal. (Capped at $175)
  3. If the outcome could have been changed based some missing/unclear information that was requested by one or more comments alone, they will split a reward equal to 20% of the perceived cost of the proposal. (Capped at $100)

Reporting

In your term summary, present a link to your comment(s) in the proposal discussion, and any relevant follow up in Discord (if applicable). Also a note containing:

  • Which of 1-3 above you think you qualify for
  • The perceived (in your view) cost of the proposal
  • Whether the reward should be shared by one or more other CMs

Grading

15.3 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1587600
    • End Block: #1702800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $275/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - Yes
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: N/A
    • Council wrangling in #council channel - Yes

15.4 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1587600
    • End Block: #1702800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

15.5 - Council Minutes

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1587600
    • End Block: #1688400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 16th "official" Council (#1486800-#1587600) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

Section II - Community Management

15.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term

    • Start Block: #1587600
    • End Block: #1688400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Section III - Working Groups

15.7 - Follow up the Storage Working Group

  • Reward: $900
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

For this Term, the Storage and Curation working groups will be the focal point of the KPIs.

Scope of Work

Task 1-3 are expected to be performed/coordinated by the Storage Lead. The Council, or a Council Member's job is to

  • track the results continuously
  • report the progress to the Council
  • update/notify/warn/slash/fire the SP

Task 4 and 5 can be performed by one or more CMs.

  1. A new version of the Storage Node is expected on the 28th of July (expect an @everyone in the #storage-provider room on Discord). As restarting a Storage Node takes is offline for ~1h, the rollout needs to be coordinated. As there are 10 nodes not operated by Jsgenesis, the rollout should be something like:
  • Within 1h of the release, 2-3 Storage Providers has STARTED upgrading. This can be monitored by the version number when running the new helios.
  • At all times, there should be NO less than 5 Storage Nodes Operational (eg. running with a URL set).
    • This means the Lead must ensure that nodes are following their "orders"
  • Within 24h of the release, max one Storage Node is still Operating the "old" version.
  • Within 36h of the release, no Storage Node is still Operating the "old" version.
    • The Operational, ie. URL set, part is to ensure the Storage Lead can make arrangements with good Storage Providers that, for some reason or other, is unable to make the changes in time.
  • At no point during the 36h is more than one "new" Storage Node Operational, without having all files stored locally
  1. After 72h of the release:
  • All SPs Operational (must be at least 7) have ALL files available locally.
  • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.06s/file and 0.06s/unique_size [GB]
    • Where unique_size refers to ACCEPTED files, with non-duplicate ipfs hashes.
  1. By the end of the term:
  • All SPs Operational (must be at least 9) have ALL files available locally.
  • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.05s/file and 0.05s/unique_size [GB]
    • Where unique_size refers to ACCEPTED files, with non-duplicate ipfs hashes.
  1. Deploy a script, or manually perform a check of the Joystream Player landing page asset loading time. A brief explanation of how to do so manually in the browser is outlined below:
  • Open the landing page, with the web developer tools open in the network tab, with images and media enabled.
    • Make sure you use incognito mode and/or disable/clear caching.
  • Scroll down the page, to request more and more assets (video thumbnails and channel avatars are fetched once "visible").
  • The SP the asset is getting fetched from, the size of the asset, and the time it takes to complete.
  • Log the results
    This should be done at least once a day, following the same "procedure" (eg. scrolling speed, etc.) each time.
  • Use the data to get the average speed for each provider each day.
  • Track the data throughout the Term.

Publish a TL;DR of the results every time in #storage-provider room on Discord, and at the end of the Term, deliver a report of your results, presented in a readable way.

  1. The Council must go through All reports delivered by the current Storage Lead (4/nexusfallout) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the Workers Lead in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.

Reward Distribution

Grading is individual.
For 1-3: The CM that reports on these results will get the reward regardless of the actual results, on the condition that "appropriate action" is taken if the results are "bad".
For 4: If one or more publishes a report, the reward will be split based on the quality of the report and results.

Weighting:

  • 1: $200
  • 2: $100
  • 3: $100
  • 4: $300
  • 5: $200

Grading

  1. First 36h
  • Within 1h of the release, 2-3 Storage Providers has STARTED upgrading. This can be monitored by the version number when running the new helios. - OK
  • Within 24h of the release, max one Storage Node is still Operating the "old" version. - OK
  • At all times, there should be NO less than 5 Storage Nodes Operational (eg. running with a URL set). - OK
  • Within 24h of the release, max one Storage Node is still Operating the "old" version. - OK
  • Within 36h of the release, no Storage Node is still Operating the "old" version. - OK
  • At no point during the 36h is more than one "new" Storage Node Operational, without having all files stored locally - OK
    • SP 4 and 16 had many failed for a brief period, but corrective actions were taken quickly. A few nodes had 1 or 2 missing, but that is sync issue and no fault of their own.
  1. @tomato - $100 (no one else took credit) https://testnet.joystream.org/#/forum/threads/522?replyIdx=5
    • After 72h of the release:
      • All SPs Operational (must be at least 7) have ALL files available locally. - OK
      • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.06s/file and 0.06s/unique_size [GB] - OK
        • 0.021s/file
  2. @tomato - $50 (no one else took credit) https://testnet.joystream.org/#/forum/threads/522?replyIdx=5
    • By the end of the term:
      • All SPs Operational (must be at least 9) have ALL files available locally. - OK
        • It was in fact only 8, but:
        • the "final" SP with ID 4 was operational withing 24h.
        • SP 6 was live within 26h
        • SP 16 was live within 48h
      • The AVERAGE time it takes helios, to complete checking the Operational SPs, must be less than 0.05s/file and 0.05s/unique_size [GB] - OK
        • 0.018s/file
  3. @tomato - $150
  4. @maxlevush - $200

15.8 - Follow up the Content Curators Working Group

  • Reward: $700
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

For this Term, the Storage and Curation working groups will be the focal point of the KPIs.

Scope of Work

Task 1 is expected to be performed/coordinated by the Curator group. The Council, or a Council Member's job is to push them into doing so.

Tasks 2-4 can be performed by one or more CMs.

  1. Bounty #10 was cancelled, mainly because a quick spotcheck revealed that the Bounty meant to reward publishing videos in the Public Domain ("PD") (to be fair, other permissive licenses was also allowed, if the license was "valid" - eg. attribution included, no derivates, etc.), was mostly rewarding copying videos from YouTube (YT). After we announced this, a concern that not only was most of the videos taken from, but not all videos was even properly licensed from there.
    The Curators must perform a "post mortem", going through ALL videos that submitted a claim to Bounty #10 (even if they weren't rewarded), and provide a spreadsheet with the following columns:

  • Video Id

  • Channel ID

  • Owner Id

  • On-chain License

    • The on-chain license ID can be mapped to the name - see helpdesk for Curators

  • On-chain Attribution

  • Whether other licensing requirements are upheld

    • Only applicable to certain CC licenses, eg. CC BY-ND - "No derivates"

  • Information Provided

    • If the forum post with Bounty claim contained extra info about the source

  • Original YT link

    • If available with a quick search

  • Actual license of original source

    • What license the media is actually licensed as
    • On YT, any video that doesn't explicitly say License - Creative Commons Attribution license (reuse allowed), is NOT free to share by anyone else than the owner.

    Before the end of the Term, the Curators must have made the first half of the report (eg. half the items), and shared it with me @bwhm#6514 on Discord.

Note:
It's been pointed out that this is quite a time consuming task. Will try to clarify some points:

  • There are currently close to no videos getting published, with the cancellation of Bounty #10.
    • That means the curator group, 9 people, have a lot of "free" time.
    • Although the Lead is responsible, they are not expected to do it alone!
  • One you have the videoIds, getting the channelId, (owners)memberId, (on-chain)license, and (on-chain)attribution, is something that takes 5 min, using hydra playgroun.
  • All the posts where users post their videos for claiming bounty rewards should be in the same thread (or at least only a couple)
    • All payout proposals should have that info, and/or links.
    • The "Information Provided" from the claimant should be there
  • If there's no link to the original source neither in attribution nor in the "Information Provided", try a YT search of the title (and check the video thumbnail, it may also show the YT title)
  • "Only" half of the videos covered in the Bounty must be completed to avoid annihilation.

This should be the top, and ONLY priority for the Curators this term - the time is ticking :)

  1. Create a draft for a new version of said Bounty, that takes the "lessons learned" in to account.
  • What should the workflow look like?
    • What should be required of the participants? What information should they be forced to provide?
    • What should be required of the BMs? How much time and effort will this cause?
    • What should be required of the Curators? Should it be a separate role to approve the submitted material, and another to set the reward based on quality?
  • What is a reasonable reward structure?
    • The previous version seemed to reward YT copypaste "too high", even after setting a budget
    • The previous version may have been "too low", to get curated and more desirable content
  • What can be done to improve the incentives for all parties?
  • What should the conditions be?
  1. The Council must go through All reports delivered by the current Curator Lead (1048/igrex) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the Workers Lead in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.

  1. Time permitting, use the results from 3. to draft a new Scope of Work. This should be approved by the Council first, then sent forward to JSG for another round of approval.

  2. Time permitting, use the results from 3 and 4. to propose get an idea of how many Workers are needed in the group, assuming they work x hours a week.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $200
  • 2: $100
  • 3: $250
  • 4-5: $75

Grading

  1. No one took credit/blame
    Failure here, unless an action was taken, was listed as a cause for annihilation.
    • Some work has been done, but there are some concerns:
      • It's not clear whether all the videos in the list were in fact rewarded by bounty 10
      • There are some unaddressed questions about the work here
      • It appears to have been too late (even if we're kind and assume 03.08 was withing the term)
      • It was not sent to me
    • Which raises the question if there was any consequences:
      • A proposal was opened to fire the lead here
      • It appears as if it won't pass, but it's certainly a consequence.
        • Note that this is not Jsgenesis saying the Lead should be/have been fired.
      • Conclusion can be found here
  2. @tomato - $100
  3. @maxlevush - $200
  4. NA
  5. NA

15.9 - Follow up the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

Task 1 is expected to be performed/coordinated by the Operations lead. The Council, or a Council Member's job is to push them into doing so.

Tasks 2 can be performed by one or more CMs.

  1. The Operations group current list of assigned tasks (by the Council), and what they are actually doing, appears to not be 100% synced. It appears a trello board has been created (good initiative!), but I didn't not have credentials to view it when I tried.
  • Make sure the trello (or similar) kanban board is open for all to view (best to keep write access contained :D), and find a way to highlight it
  • Share a list containing all infrastructure, with links to the service AND source code, hosted by the group
  • Elaborate on the trello board, and share short and long term plans for the group
  1. The Council must go through All reports delivered by the current Operations Lead (515/l1dev) and provide the following:
  • Link to all reports
  • A short note comparing the contents and frequency of the reports, to what has been decided as their SOW by the Council
  • A short note comparing the contents and frequency of the reports, to what has been suggested as the SOW for both the group in the helpdesk
  • A verdict on the performance for the Lead
  • A verdict on the performance for the Workers
  • A suggestion for the path forward, wrt the Scope of Work.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $200

Grading

Section IV - Bounties

15.10 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1594800
    • End Block: #1702800

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No summaries submitted for this.

15.11 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Core term
    • Start Block: #1594800
    • End Block: #1681200

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. Community Bounty #20 - "Github Bounty Guide"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. Community Bounty #21 - "Website Translation"
  • Ensure the following is done:
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 14

  • KPIs: 14
  • Total Possible Rewards: $3100
  • Council Elected in Round: 17
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1486800 / 20.07.21
    • End Block/Date: #1587600 / 20.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1515600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 15 473465
515 l1dev 32 1010059
635 xfactorus 21 662851
982 drmarkovi 18 568158
867 xandrell 102-75 3219563
1316 andybut 25+75 789108
2039 doppelganger23 15 473465
957 leet_joy 0 0
439 fierydev 10 315643
4 nexusfallout 40 1262574
2 tomato 1 31564
525 oiclid 216 6817897
2130 maxlevush 767 24209848
1048 igrex 76 2398890
1027 stavr 26 820673
2182 isonar 96 3030177
SUM 16 1460 46083935

The rewards were paid out at block #1664236.

Notes

As the Council Secretary has been absent, it has been a little difficult to get a perfect overview of the performance last week, and thus creating new KPIs for this term. As a consequence, the current KPI set will be a little smaller than usual, and there may be some overlap of tasks that was completed last term.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 13th (confusingly listed as "Election round 15" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

Section I - Council work, Proposals and Bureaucracy

14.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1486800
    • End Block: #1587600

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 13 49 15
515 l1dev 11 46 14
635 xfactorus 18 69 21
982 drmarkovi 15 59 18
867 xandrell 23 91 27
1316 andybut 20 83 25
2039 doppelganger23 14 50 15
957 leet_joy 0 0 0
439 fierydev 9 33 10
4 nexusfallout 19 75 22
2 tomato 1 4 1
525 oiclid 24 102 30
2130 maxlevush 21 89 26
1048 igrex 23 105 31
1027 stavr 23 89 26
2182 isonar 16 65 19
SUM 16 250 1009 300

14.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

14.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Note The long running Council Secretary is away for this term, so someone new needs to step up!

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @oiclid - $150/$150
    • Assigned all relevant PRs to the secretary:

14.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 16th "official" Council (#1486800-#1587600) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

https://testnet.joystream.org/#/forum/threads/512?replyIdx=5

14.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1486800
    • End Block: #1587600

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 2 2 18
635 xfactorus 0 0 0
982 drmarkovi 0 0 0
867 xandrell 0 0 0
1316 andybut 0 0 0
2039 doppelganger23 0 0 0
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 2 18
2 tomato 0 0 0
525 oiclid 7 4 36
2130 maxlevush 2 2 18
1048 igrex 5 5 45
1027 stavr 0 0 0
2182 isonar 3 3 27
SUM 16 22 18 164

Section II - Community Management

14.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1486800
    • End Block: #1602000

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Section III - Working Groups

14.7 - Self Managed Budgets

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Working Group budgets are currently replenished irregularly, when the Leads notice their mints are close to empty (or worse). This makes it hard to track spending and there is also no way for Leads to justify or request their budgets in advance due to the mint refill restrictions.

Identify a way of handling budgets that would allow for a once-per-Council refill and involve some system of request and accountability (the upcoming runtime upgrade will include a greatly increased working group mint capacity).

Scope of Work

Note: All tasks should be performed in a cooperative manner with the respective Leads.

  1. Prepare some "sample" budgets for each working group that:
  • provides a reusable format (if not an actual template)
  • shows the level of details/granularity required
  • shows what each worker make, and contains a narrow range of workers expected to be part of the WG for the Term
  • if applicable (eg. for Storage and Curators), takes the OKR system in to account
    • as the OKR rewards are paid from the Council mint, these should be included in the budget, but not the Proposal
  • other?
  1. Establish some rules:
  • should extraordinary mint replenished for a WG not be allowed at all, or something that is expected to occur rather frequently?
    • should mint replenishes require that the Lead has submitted their pending reports?
    • if yes, what happens to the workers that (supposedly) did their jobs?
  • other?
  1. Set a deadline to move to the new system.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $75 for each of the three WGs
  • 2: $75
  • 3: $0

Grading

  • Scope of Work 1 (Prepare sample budgets for each WG)
    • Not completed - $/$75
  • Scope of Work 2 (Establish some rules)
    • Not completed - $/$75
  • Scope of Work 3 (Set a deadline)
    • Not completed - $/$0

14.8 - Follow up the Storage Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. It has been discovered that when a Storage Provider is down, for a variety of reasons, the Joystream Player is struggling heavily to load all the assets. Especially if the Worker in question was the liaison (ie. the SP that first received the assets). A solution for this has been established, and outlined in the #storage-provider discord. Tasks:

  • Update the helpdesk, for both the Lead and the Workers, explaining how this should be done.
  • Revise the criteria for a Storage Provider to be fired for downtime, depending on how quickly they perform this fix themselves (which doesn't require actually running the storage-node)
  • Update the workflow after getting hired for the role, so that these workers aren't negatively impacting the system while syncing the data, and aren't selected for uploads during this time.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $150

Grading

14.9 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

  • Design an OKR system
    • Already completed and paid during a previous council term.

14.10 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

  • Scope of Work 1 (Curator Lead tasks on community repo)
    • Not completed - $/$150
  • Scope of Work 2 (Follow up with leads, perform checks and sign off on reports)
  • Scope of Work 3 (Create a list of problems with the current curator workflow)
    • Not reported - $0/$37.5

14.11 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 14.9 for more information.

Reward Distribution

Grading is individual.

Grading

  • Already completed and paid during a previous council term.

14.12 - Follow up the Operations Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Ensure the Working Group updates the Joystream api examples in the community repo:
  • Updates the package.json file with correct types
  • Updates/ensures all the applicable examples work
  • Remove the examples that no longer applies
    • Ideally also adds new ones, but that will be added to the next set of KPIs.
  1. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50
  • 3: $50

Grading

  • Scope of Work 1 (Create a budget based on current tasks)
    • Not completed/reported
  • Scope of Work 2 (Ensure API examples are updated)
  • Scope of Work 3 (Follow up and sign off on lead's reports)

Section IV - Bounties

14.13 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1486800
    • End Block: #1602000

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

14.14 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1486800
    • End Block: #1580400

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. For Bounty #20:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. For Bounty #21:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 13

  • KPIs: 16
  • Total Possible Rewards: $3850
  • Council Elected in Round: 15
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1386000 / 13.07.21
    • End Block/Date: #1486800 / 20.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1515600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 lyazufey1812 27 786112
361 blackmass 13 378498
635 xfactorus 18 524075
867 xandrell 28 815227
1962 nkhlghbl 6 174692
318 supunssw 3 87346
1316 andybut 294 8559886
2039 doppelganger23 9 262037
321 freakstatic_council 171 4978709
439 fierydev 16 465844
4 nexusfallout 43 1251956
2 tomato 40 1164610
1989 2themoon 8 232922
2130 maxlevush 188 5473668
1048 igrex 111 3231794
2182 isonar 220 6405357
SUM 16 1195 34792733

Payouts done at block #1562012.

Small Changes

Starting with the last KPI round, a few changes are made:

  • The deadlines for KPIs that requires submitting a report, will be set to 12h (7200 blocks) BEFORE the end of the Term
  • All KPIs become active 12h (7200 blocks) AFTER a new Council is elected
    • These two are to make it easier to create new KPIs, as it's sometimes hard to know whether something should be included for the next term or not.
  • KPIs are broken into smaller pieces when possible, even if there is some overlap

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 13th (confusingly listed as "Election round 15" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

Section I - Council work, Proposals and Bureaucracy

13.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1386000
    • End Block: #1486800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1905 lyazufey1812 28 118 27
361 blackmass 14 56 13
635 xfactorus 20 77 18
867 xandrell 30 120 28
1962 nkhlghbl 6 24 6
318 supunssw 3 12 3
1316 andybut 30 119 27
2039 doppelganger23 11 41 9
321 freakstatic_council 22 90 21
439 fierydev 17 68 16
4 nexusfallout 20 80 18
2 tomato 24 102 23
1989 2themoon 9 36 8
2130 maxlevush 29 130 30
1048 igrex 32 159 36
2182 isonar 19 76 17
SUM 16 314 1308 300

13.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

@tomato (0/$300)

  • No summary submitted

13.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @maxlevush ($75/150)
    • All relevant PRs merged (presumably meant handled)
    • Adjustet Lead rewards

13.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 15th "official" Council (#1386000-#1486800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

13.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1386000
    • End Block: #1486800

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
1905 lyazufey1812 0 0 0
361 blackmass 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
1316 andybut 2 2 17
2039 doppelganger23 0 0 0
321 freakstatic_council 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 3 25
2 tomato 2 2 17
1989 2themoon 0 0 0
2130 maxlevush 7 7 58
1048 igrex 9 9 75
2182 isonar 1 1 8
SUM 16 24 24 200

Section II - Community Management

13.6 - Founding Member Statistics

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400 *
    • End Block: #1479600

* extended from round 12.
AFAICT, No one has attempted this. Will be made into a bounty next Council Term, if no one starts. It's a good way to learn more about the Joystream API (as well)!

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!
Further note that there is some overlap with KPI 13.7. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

Some statistics:

  • Total platform Memberships: 2434
  • Member that have submitted scores (including up to Scoring Period 9 only): 736
  • Total >0 submissions: 1819
  • Members that have earned >0 for every Scoring Period: 37
  • Members that have earned >0 for all but two or fewer Scoring Periods : 34+47
  • Graded submissions per Scoring Period: [15,562,287,122,143,139,144,140,144,123]
  • Direct scores per Scoring Period: [9550,90420,35190,18840,21080,34645,31245,28145,33035,25660]
  • Referral scores per Scoring Period: [0,6442,2679,1590,1812,2403,2055,1458,1458,1747]
  • Average direct scores pr submission by Scoring Period: [637,161,123,154,147,249,217,201,229,209]

Some worrying signs:

  • There are fewer submissions per Scoring Period
  • There are fewer points awarded per Scoring Period
    • This is partially due to re-calibration, but shouldn't be the case for the last 6 or so rounds, and it's still crashing
  • Our statistics indicate that very few of both CMs and workers are reporting their activities

Although there are some known reasons for this development, we want to know more!

Scope of Work

For all of the above:

  • Getting the verbose FM points data needed can be found here
  • ctrl+f of cmd+f the memberId or memberHandle to find that person (you may have to download the file)
  • What you need is the directScores for each round
    • they are indexed from Scoring Period 0 and upwards
  1. Assemble more data for CMs:
  • Doing work on the Council is supposed to be the best/most efficient way of earning FM points
    • Use the KPI grading results, available for Sumer and Antioch to find out the memberId and memberHandle of the CMs was for Council Term.
    • Take advantage of the fact that each Scoring Period, starting from round 1 lasted two weeks, and figure out which Scoring Period each Council Term "belongs" in
    • Find out how many points all the CMs earned per Scoring Period (even if 0), and whether they were CMs in "both" Terms or not, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their CM KPI work
      • the CMS that reports their Council KPI rewards, should earn a (roughly) "fixed" amount of FM points pr KPI $ earned
  1. Assemble more data for workers:
  • Being part of a WG is supposed to be another key way of earning FM points:
  • You can ignore rounds from before the release of Antioch - 7th April 2021 (eg. start from Scoring Period 5)
    • Using on-chain data, find the memberId and memberHandle that was active in a role at the end of each Scoring Period
    • Hints:
      • Use the KPI gradings to find an approximate blockHeight corresponding to that date (will be <14400 off - good enough!)
      • Create a script, or use the javascript playground to find the active workers for each of the WGs (the operations WG didn't exist before #717987)
    • Once you know who was hired as worker for each group during each Scoring Period, find out how many points each of them earned per Period, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their WG work
  1. Assemble data for bounties:
  • Bounties are another great way of earning large "chunks" of FM points, although not as recurring as the other two
    • Use this json to get the "closedDate" and the corresponding github issue to figure out who was paid out for each bounty completed after the FM program launch.
    • You can also ask the Council Secretary for more info
    • Find out whether points the bounty solver earned points for their work, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their Bounty work
      • much like for CMs, the FM points awarded should be roughly proportional to the $ earned on a bounty
  1. Combine the data:
  • At this point, you should be able to identify roughly whether the user reported their work from 1, 2 or 3
    • If you need more information, you can ask the user themselves for "full" information (if they kept it), or blrhc#0162 / bwhm#6514 on discord for some more information on specific summaries on Discord
    • Knowing that some will have reported other activities as well, try to estimate what was earned from what
  • You have now separated the source of points, and can produce a report with:
    • the raw data gathered, in MS excel/google sheets/mac number/open office or json format
CMs

For CMs, knowing that CMS that reported their Council KPI rewards, should earn a roughly "fixed" amount of FM points per KPI $ earned, estimate which CMs submitted their CM KPI work in their scores:

  • From all the Councils: how many out of all reported their work?
  • How many FM points (estimate) is a CM awarded per KPI $ earned?
  • How many KPI $ was earned?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual CMs?
Workers

For workers, it may not always be the case that they earn points solely for being in the WG. They may be awarded extra for actual activity, but assume they're not

  • For all the WGs: how many out of all reported their work per Scoring Period?
  • How many FM points (estimate) is awarded per week of being hired in each WG (if they reported)?
  • How many FM points are the Leads awarded?
  • How many of the workers, for each WG, submitted their scores in each Scoring Period out of the total possible?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual Workers?
Bounties

For Bounties, knowing that you earn a roughly "fixed" amount of FM points per Bounty:

  • How many FM points (estimate) is bounty $ worth?
  • How many FM points was awarded from bounties?
  • How many FM points was "lost" - both in total and for the individual bounty solver?

Reward Distribution

If multiple reports are made, the KPI reward may be increased so the total reward paid may exceed the "promised" amount.

Grading

  • No work completed
    • Will become a bounty

13.7 - Founding Member Survey

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400 *
    • End Block: #1479600

* extended from round 12.
We hope to get close to a 100 submissions here. Help @andybut spread the word :)

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!

Further note that there is some overlap with KPI 13.6. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

See KPI 13.6 for more information.

Scope of Work

Create a Questionnaire, targeting:

  • Everyone that has submitted a scoring summary for a Scoring Period
  • Everyone that has been on the Council on the latest network (eg. Antioch/ joy_testnet_5)
  • Everyone that has been part of a Working Group on the latest network (eg. Antioch/ joy_testnet_5)
Information Wanted

Most of the information wanted can be deduced by reading KPI 13.6, but some examples are added. Multiple choice questions should be used when possible:

  • Are you in one or more of the groups above?
    • Which one(s)?
  • How many times have you submitted a summary?
  • Why/why not more/some?
    • What do you typically include in your summaries?
  • How many times have you x Council/WG/Bounties?
    • Have you reported these activities?
    • Why not?
  • Did you know Council/WG/Bounties awards lots of points?
  • Did you know Council/Bounty $ earns is roughly proportional to FM points awarded?
  • Knowing this, would you (re-)submit your summaries for "older" Scoring Periods?
  • What can be done to make it "easier" for you to submit in the future?
  • etc.

At the bottom of the survey, include a "free text" field where users should paste in the signature of the message:

I am member <ID>, signing with key <rootAccount OR controllerAccount>

So for me, member 1 and root account 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx:

message:
"I am member 1, signing with key 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx"
signature:
"0xc218c9fab03783c10ee94f27b4c353f3d3a234ea98816ae6abd5e0d446957c78f91efd9a8f4824875bdc1d824f4b51fb3a5a5534461d65e44d1d6b7021aff384"
Reporting the Results

Everyone (with a memberId < 2434) that participates earns $5 worth of JOY, IF they include said signed message. Their individual responses should be anonymized, but respondents that don't supply a signature should not be included in the results.

Present the report with the results as a PR to the Community Repo

  • in markdown format
  • all questions and answer statistics, with numbers and pie charts
  • short summary with interpretation of the results

All messages and signatures must be sent to me through:

  • @bwhm #6514 (discord)
    or
  • @bwhm (keybase)

The respondents will be rewarded when the KPI is graded.

Reward Distribution

If multiple reports are made, the KPI reward will go the to the "best" one.

Grading

13.8 - Runtime Upgrade Parameters Discussion

  • Reward: $100++
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1508400 *

* extended two more days (only), as we need to finalize this.

Purpose

As there was a bug with the stakes for the Operations Working Group, we are planning to perform a runtime upgrade that fixes this. As we prefer not to do these regularly (as it requires extensive testing), it makes sense to see what else could be addressed!

Scope of Work

  1. Invite the Community at large to participate, and propose which parameters could be changed to improve the "quality of life" for the Council, WGs and the Community.
  2. Create proposals for each specific parameter change. Then discuss and vote on them.
  3. Present the results in a short report.

Reward Distribution

The writer of the report can earn up to $50.

  • Each member that proposed a change (that gets approved by the Council) earns between $25
  • If the value gets approved by Jsgenesis, a further $25 is awarded, even if it isn't included in the upgrade

Grading

  • Nothing submitted

13.9 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1386000
    • End Block: #1501200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

  • @andybut ($100)
  • @isonar (25$)
  • @mexlevush (25$)

Section III - Working Groups

13.10 - Self Managed Budgets

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Working Group budgets are currently replenished irregularly, when the Leads notice their mints are close to empty (or worse). This makes it hard to track spending and there is also no way for Leads to justify or request their budgets in advance due to the mint refill restrictions.

Identify a way of handling budgets that would allow for a once-per-Council refill and involve some system of request and accountability (the upcoming runtime upgrade will include a greatly increased working group mint capacity).

Scope of Work

Note: All tasks should be performed in a cooperative manner with the respective Leads.

  1. Prepare some "sample" budgets for each working group that:
  • provides a reusable format (if not an actual template)
  • shows the level of details/granularity required
  • shows what each worker make, and contains a narrow range of workers expected to be part of the WG for the Term
  • if applicable (eg. for Storage and Curators), takes the OKR system in to account
    • as the OKR rewards are paid from the Council mint, these should be included in the budget, but not the Proposal
  • other?
  1. Establish some rules:
  • should extraordinary mint replenished for a WG not be allowed at all, or something that is expected to occur rather frequently?
    • should mint replenishes require that the Lead has submitted their pending reports?
    • if yes, what happens to the workers that (supposedly) did their jobs?
  • other?
  1. Set a deadline to move to the new system.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $75 for each of the three WGs
  • 2: $75
  • 3: $0

Grading

  • Nothing submitted

13.11 - Follow up the Storage Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.

  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $100

Grading

  • Nothing submitted

13.12 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

  • Nothing submitted

13.13 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

  • Nothing submitted

13.14 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 13.12 for more information.

Reward Distribution

Grading is individual.

Grading

TBD

13.15 - Follow up the Operations Working Group

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Ensure the Working Group updates the Joystream api examples in the community repo:
  • Updates the package.json file with correct types
  • Updates/ensures all the applicable examples work
  • Remove the examples that no longer applies
    • Ideally also adds new ones, but that will be added to the next set of KPIs.
  1. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50
  • 3: $50

Grading

  • @isonar ($50/$150)
    • Set up a trello board (I don't have access)
    • Conflict of interest makes it hard to see what is done as a Role occupant, vs CM

Section IV - Bounties

13.16 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1386000
    • End Block: #1501200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • Nothing submitted

13.17 - Other Bounty Managers

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1386000
    • End Block: #1479600

Purpose

With two new Bounties Community Bounty #20 - "Github Bounty Guide" and Community Bounty #21 - "Website Translation", ready to go and two more expected during this Term, some work is needed!

Scope of Work

  1. For Bounty #20:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager
    • either a technical person from the Curator group or,
    • a person from the Operations group with some knowledge about the Content system
    • open and promote the Bounty to the community
  1. For Bounty #21:
  • Review the issue made by JSG, eg.
    • see if something is unclear, missing, too much, etc.
    • add reasonable milestones
    • officially open the Bounty through a forum post
  • Assign an appropriate Bounty Manager from the Operations group
    • open and promote the Bounty to the community
    • once the work has reached the first milestone, find a suitable member of the Community to review the language

Reward Distribution

Grading is individual.

Grading

KPI 12

  • KPIs: 16
  • Total Possible Rewards: $3800
  • Council Elected in Round: 13
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1285200 / 06.07.21
    • End Block/Date: #1386000 / 13.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1414800

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 13 385032
515 l1dev 0 0
635 xfactorus 19 562740
867 xandrell 78 2310194
318 supunssw 11 325797
1316 andybut 132 3909560
2039 doppelganger23 8 236943
321 freakstatic_council 105 3109877
957 leet_joy 1 29618
439 fierydev 13 385032
4 nexusfallout 39 1155097
2 tomato 610 18066905
525 oiclid 75 2221341
2130 maxlevush 658 19488563
1048 igrex 60 1777073
2182 isonar 14 414650
SUM 16 1836 54378422

Paid out at block 1446734.

Small Changes

Starting with this KPI, a few changes are made:

  • The deadlines for KPIs that requires submitting a report, will be set to 12h (7200 blocks) BEFORE the end of the Term
  • All KPIs become active 12h (7200 blocks) AFTER a new Council is elected
    • These two are to make it easier to create new KPIs, as it's sometimes hard to know whether something should be included for the next term or not.
  • KPIs are broken into smaller pieces when possible, even if there is some overlap

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

Section I - Council work, Proposals and Bureaucracy

12.1 - Proposal Clearance

  • Reward: $300
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1285200
    • End Block: #1386000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 16 64 13
515 l1dev 0 0 0
635 xfactorus 29 92 19
867 xandrell 40 136 28
318 supunssw 13 52 11
1316 andybut 40 144 30
2039 doppelganger23 10 40 8
321 freakstatic_council 34 116 24
957 leet_joy 1 4 1
439 fierydev 16 61 13
4 nexusfallout 29 102 21
2 tomato 26 115 24
525 oiclid 39 155 32
2130 maxlevush 39 145 30
1048 igrex 38 149 31
2182 isonar 18 68 14
SUM 16 388 1443 300

12.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

  • @tomato - $275/$300
    • Managing PR's in community repo per rules: https://github.com/Joystream/community-repo/pulls?q=is%3Apr+is%3Aclosed
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 65%
    • Council mint refilled - Yes
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: No
    • Council wrangling in #council channel - Yes

12.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

12.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1285200
    • End Block: #1400400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 12th "official" Council (#1285200-#1386000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

12.5 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1292400
    • End Block: #1386000

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
318 supunssw 0 0 0
1316 andybut 2 1 6
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 6
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 3 3 18
2 tomato 7 7 41
525 oiclid 7 3 18
2130 maxlevush 6 6 35
1048 igrex 7 5 29
2182 isonar 1 0 0
SUM 16 34 26 153

Section II - Community Management

12.6 - Founding Member Statistics

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!
Further note that there is some overlap with KPI 12.7. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

Some statistics:

  • Total platform Memberships: 2434
  • Member that have submitted scores (including up to Scoring Period 9 only): 736
  • Total >0 submissions: 1819
  • Members that have earned >0 for every Scoring Period: 37
  • Members that have earned >0 for all but two or fewer Scoring Periods : 34+47
  • Graded submissions per Scoring Period: [15,562,287,122,143,139,144,140,144,123]
  • Direct scores per Scoring Period: [9550,90420,35190,18840,21080,34645,31245,28145,33035,25660]
  • Referral scores per Scoring Period: [0,6442,2679,1590,1812,2403,2055,1458,1458,1747]
  • Average direct scores pr submission by Scoring Period: [637,161,123,154,147,249,217,201,229,209]

Some worrying signs:

  • There are fewer submissions per Scoring Period
  • There are fewer points awarded per Scoring Period
    • This is partially due to re-calibration, but shouldn't be the case for the last 6 or so rounds, and it's still crashing
  • Our statistics indicate that very few of both CMs and workers are reporting their activities

Although there are some known reasons for this development, we want to know more!

Scope of Work

For all of the above:

  • Getting the verbose FM points data needed can be found here
  • ctrl+f of cmd+f the memberId or memberHandle to find that person (you may have to download the file)
  • What you need is the directScores for each round
    • they are indexed from Scoring Period 0 and upwards
  1. Assemble more data for CMs:
  • Doing work on the Council is supposed to be the best/most efficient way of earning FM points
    • Use the KPI grading results, available for Sumer and Antioch to find out the memberId and memberHandle of the CMs was for Council Term.
    • Take advantage of the fact that each Scoring Period, starting from round 1 lasted two weeks, and figure out which Scoring Period each Council Term "belongs" in
    • Find out how many points all the CMs earned per Scoring Period (even if 0), and whether they were CMs in "both" Terms or not, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their CM KPI work
      • the CMS that reports their Council KPI rewards, should earn a (roughly) "fixed" amount of FM points pr KPI $ earned
  1. Assemble more data for workers:
  • Being part of a WG is supposed to be another key way of earning FM points:
  • You can ignore rounds from before the release of Antioch - 7th April 2021 (eg. start from Scoring Period 5)
    • Using on-chain data, find the memberId and memberHandle that was active in a role at the end of each Scoring Period
    • Hints:
      • Use the KPI gradings to find an approximate blockHeight corresponding to that date (will be <14400 off - good enough!)
      • Create a script, or use the javascript playground to find the active workers for each of the WGs (the operations WG didn't exist before #717987)
    • Once you know who was hired as worker for each group during each Scoring Period, find out how many points each of them earned per Period, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their WG work
  1. Assemble data for bounties:
  • Bounties are another great way of earning large "chunks" of FM points, although not as recurring as the other two
    • Use this json to get the "closedDate" and the corresponding github issue to figure out who was paid out for each bounty completed after the FM program launch.
    • You can also ask the Council Secretary for more info
    • Find out whether points the bounty solver earned points for their work, and write it up
    • Note that:
      • some may have reported their activities in the "wrong" round
      • some will have reported other activities
      • do your best thinking here, and return the number of points you think they earned in the round they (may) have reported their Bounty work
      • much like for CMs, the FM points awarded should be roughly proportional to the $ earned on a bounty
  1. Combine the data:
  • At this point, you should be able to identify roughly whether the user reported their work from 1, 2 or 3
    • If you need more information, you can ask the user themselves for "full" information (if they kept it), or blrhc#0162 / bwhm#6514 on discord for some more information on specific summaries on Discord
    • Knowing that some will have reported other activities as well, try to estimate what was earned from what
  • You have now separated the source of points, and can produce a report with:
    • the raw data gathered, in MS excel/google sheets/mac number/open office or json format
CMs

For CMs, knowing that CMS that reported their Council KPI rewards, should earn a roughly "fixed" amount of FM points per KPI $ earned, estimate which CMs submitted their CM KPI work in their scores:

  • From all the Councils: how many out of all reported their work?
  • How many FM points (estimate) is a CM awarded per KPI $ earned?
  • How many KPI $ was earned?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual CMs?
Workers

For workers, it may not always be the case that they earn points solely for being in the WG. They may be awarded extra for actual activity, but assume they're not

  • For all the WGs: how many out of all reported their work per Scoring Period?
  • How many FM points (estimate) is awarded per week of being hired in each WG (if they reported)?
  • How many FM points are the Leads awarded?
  • How many of the workers, for each WG, submitted their scores in each Scoring Period out of the total possible?
  • How many FM points was awarded?
  • How many FM points was "lost" - both in total and for the individual Workers?
Bounties

For Bounties, knowing that you earn a roughly "fixed" amount of FM points per Bounty:

  • How many FM points (estimate) is bounty $ worth?
  • How many FM points was awarded from bounties?
  • How many FM points was "lost" - both in total and for the individual bounty solver?

Reward Distribution

If multiple reports are made, the KPI reward may be increased so the total reward paid may exceed the "promised" amount.

Grading

  • No work completed

12.7 - Founding Member Survey

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Note

This bounty will be rolled over at least 1 term, so if you don't finish - you'll be given a second try!

Further note that there is some overlap with KPI 12.6. It would be beneficial if they communicate/cooperate.

Purpose

We believe a lot of the contributors are not capitalizing on the work they are doing on the testnet(s).

See KPI 12.6 for more information.

Scope of Work

Create a Questionnaire, targeting:

  • Everyone that has submitted a scoring summary for a Scoring Period
  • Everyone that has been on the Council on the latest network (eg. Antioch/ joy_testnet_5)
  • Everyone that has been part of a Working Group on the latest network (eg. Antioch/ joy_testnet_5)
Information Wanted

Most of the information wanted can be deduced by reading KPI 12.6, but some examples are added. Multiple choice questions should be used when possible:

  • Are you in one or more of the groups above?
    • Which one(s)?
  • How many times have you submitted a summary?
  • Why/why not more/some?
    • What do you typically include in your summaries?
  • How many times have you x Council/WG/Bounties?
    • Have you reported these activities?
    • Why not?
  • Did you know Council/WG/Bounties awards lots of points?
  • Did you know Council/Bounty $ earns is roughly proportional to FM points awarded?
  • Knowing this, would you (re-)submit your summaries for "older" Scoring Periods?
  • What can be done to make it "easier" for you to submit in the future?
  • etc.

At the bottom of the survey, include a "free text" field where users should paste in the signature of the message:

I am member <ID>, signing with key <rootAccount OR controllerAccount>

So for me, member 1 and root account 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx:

message:
"I am member 1, signing with key 5DaDUnNVzZPwK9KLwyPFgeSbc9Xeh6G39A2oq36tiV9aEzcx"
signature:
"0xc218c9fab03783c10ee94f27b4c353f3d3a234ea98816ae6abd5e0d446957c78f91efd9a8f4824875bdc1d824f4b51fb3a5a5534461d65e44d1d6b7021aff384"
Reporting the Results

Everyone (with a memberId < 2434) that participates earns $5 worth of JOY, IF they include said signed message. Their individual responses should be anonymized, but respondents that don't supply a signature should not be included in the results.

Present the report with the results as a PR to the Community Repo

  • in markdown format
  • all questions and answer statistics, with numbers and pie charts
  • short summary with interpretation of the results

All messages and signatures must be sent to me through:

  • @bwhm #6514 (discord)
    or
  • @bwhm (keybase)

The respondents will be rewarded when the KPI is graded.

Reward Distribution

If multiple reports are made, the KPI reward will go the to the "best" one.

Grading

12.8 - Runtime Upgrade Parameters Discussion

  • Reward: $100++
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

As there was a bug with the stakes for the Operations Working Group, we are planning to perform a runtime upgrade that fixes this. As we prefer not to do these regularly (as it requires extensive testing), it makes sense to see what else could be addressed!

Scope of Work

  1. Invite the Community at large to participate, and propose which parameters could be changed to improve the "quality of life" for the Council, WGs and the Community.
  2. Create proposals for each specific parameter change. Then discuss and vote on them.
  3. Present the results in a short report.

Reward Distribution

The writer of the report can earn up to $50.

  • Each member that proposed a change (that gets approved by the Council) earns between $25
  • If the value gets approved by Jsgenesis, a further $25 is awarded, even if it isn't included in the upgrade

Grading

12.9 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1292400
    • End Block: #1400400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

12.10 - Update Membership Profiles

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Being able to reach a member through their address and/or their memberId is sometimes needed. Both for our own benefit, and for the Community as a whole, adding contact info in the profile would be a great help.

Scope of Work

Reach out to the community, and ask them to add contact information and avatars in their membership profiles.

Make sure they are aware of the potential doxxing risk, and only share information they are "comfortable" with.

Contact Info

For the contact information, one or more of the below "counts":

  • Discord (full ID)
  • Keybase
  • Telegram
  • Twitter
    Optionally, GitHub handle is also a "nice to have".
Avatar

Any avatar other than the default is nice :)

Reward Distribution

The rewards will be split between those that tries to reach the Community.

For each user, that in between the start block and end block:

  • adds at least one contact info grants: ¢50
  • adds three or more (including GitHub) and HAS an avatar: $1

Capped at $300!

Grading

Section III - Working Groups

12.11 - Follow up the Storage Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.

  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $100

Grading

12.12 - Storage Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Design an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". This has been discussed before, and this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.

Reward Distribution

Grading is individual.

Grading

12.13 - Follow up the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75

Grading

12.14 - Content Curators Working Group OKRs

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the limited tools available to both the Lead and the Council, poorly performing actors are often rewarded the same as the MVPs of a WG, Lead or not.

A potential way to fix this, at least short term (before said tools are created), is through an OKR system that tracks the performance of the Lead, and perhaps workers, in an objective way.

Scope of Work

Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 12.12 for more information.

Reward Distribution

Grading is individual.

Grading

12.15 - Follow up the Operations Working Group

  • Reward: $100
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term - 12h
    • Start Block: #1292400
    • End Block: #1378800

Purpose

With the release of Sumer a new Working Group was added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $50
  • 2: $50

Grading

Section IV - Bounties

12.16 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $100 to finalize all submissions
    • Bounty 19: $25/100 per week
    • Bounty 20: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1292400
    • End Block: #1400400

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties, and specifics:

  • #9
  • #14
    • The grading appears too generous - contact Council Secretary for more info
  • #19
  • #20
    • Should be opened by 08.07.21

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 11

  • KPIs: 11
  • Total Possible Rewards: $2775
  • Council Elected in Round: 11
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1184400 / 29.06.21
    • End Block/Date: #1285200 / 6.07.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1314000

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 10 282818
515 l1dev 4 113127
635 xfactorus 34 961581
867 xandrell 63 1781753
1962 nkhlghbl 3 84845
318 supunssw 2 56564
1316 andybut 111 3139279
2039 doppelganger23 20 565636
321 freakstatic_council 146 4129141
957 leet_joy 12 339381
439 fierydev 24 678763
4 nexusfallout 50 1414090
2 tomato 592 16742820
525 oiclid 108 3054433
2130 maxlevush 568 16064057
1048 igrex 110 3110997
SUM 16 1857 52519285

Paid out at block #1333558.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

11.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 6 24 10
515 l1dev 3 9 4
635 xfactorus 21 84 34
867 xandrell 23 86 35
1962 nkhlghbl 2 8 3
318 supunssw 3 6 2
1316 andybut 24 92 37
2039 doppelganger23 12 48 20
321 freakstatic_council 21 84 34
957 leet_joy 7 30 12
439 fierydev 15 60 24
4 nexusfallout 19 78 32
2 tomato 24 101 41
525 oiclid 16 60 24
2130 maxlevush 25 100 41
1048 igrex 24 112 46
SUM 16 245 982 400

11.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

11.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

11.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 11th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

11.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1270800
    • End Block: #1285200

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

11.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1184400
    • End Block: #1299600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

11.7 - Manage the Storage Working Group

  • Reward: $400
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:

  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2: $200
  • 3: $100

Grading

11.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 11.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

11.9 - Manage the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks have been assigned.
  2. Follow up and sign off on the Lead's report

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2: $50

Grading

11.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1184400
    • End Block: #1285200

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
1316 andybut 1 1 9
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 9
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 2 2 18
2 tomato 3 3 27
525 oiclid 1 1 9
2130 maxlevush 6 5 45
1048 igrex 8 7 64
SUM 16 22 20 182

11.11 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $150 to finalize all submissions
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1184400
    • End Block: #1299600

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 10

  • KPIs: 12
  • Total Possible Rewards: $3025
  • Council Elected in Round: 12
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #1083600 / 22.06.21
    • End Block/Date: #1184400 / 29.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1213200

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 32 941327
635 xfactorus 35 1029577
867 xandrell 111 3265230
1962 nkhlghbl 15 441247
318 supunssw 5 147082
2039 doppelganger23 27 794245
321 freakstatic_council 133 3912392
957 leet_joy 4 117666
439 fierydev 24 705996
4 nexusfallout 41 1206076
2 tomato 652 19179548
1989 2themoon 12 352998
2130 maxlevush 661 19444296
1048 igrex 122 3588811
355 manipal 0 0
2182 isonar 22 647163
SUM 16 1896 55773654

Payouts on block #1236226.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

Ensure the 11th (confusingly listed as "Election round 13" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

10.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 19 76 32
635 xfactorus 22 82 35
867 xandrell 23 86 36
1962 nkhlghbl 9 36 15
318 supunssw 4 13 5
2039 doppelganger23 17 65 27
321 freakstatic_council 19 76 32
957 leet_joy 4 10 4
439 fierydev 14 56 24
4 nexusfallout 19 76 32
2 tomato 21 90 38
1989 2themoon 7 28 12
2130 maxlevush 24 108 46
1048 igrex 22 93 39
355 manipal 0 0 0
2182 isonar 13 52 22
SUM 16 237 947 400

10.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Given write access to the Community Repo
  • For all new PRs made to the repo, the Secretary and/or is expected to:
    • perform a review
    • link to a spending or text proposal, confirming the Councils approval
    • request Jsgenesis review for all PRs that require their attention
    • merge the PR, under the conditions that the PR:
      • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
      • does not violate any license
      • does not introduce any code users can run
      • it has also been approved by the Deputy Secretary
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

10.3 - Deputy Council Secretary

  • Reward: $150
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

The Council Secretary has been re-elected more than 10 times in a row. We believe the reason is that the Councils seem to recognize their excellent performance - an opinion shared by us.
It does however make the platform, albeit in a testnet stage, highly reliant on a single individual or entity, which may cause trouble down the road.

We believe it's time to add a deputy. This will hopefully have multiple benefits, the key being preparing more people to coordinate the Council and get a better overview of the recurring and, sometimes, critical tasks that needs to be performed.

Requirements:

  • must have been on the Council before
  • must be able to check in at least once every day
  • must be eager to learn
  • preferably somewhat familiar with github

Scope of Work

The main task for the Deputy Council Secretary is to assist and offload the Secretary.

  • Given triage access to the Community Repo
  • Assigning the Secretary, and/or Jsgenesis to review* all PRs made to the Community Repo, with a link to the text or spending proposals and other applicable information.
  • See the SoW for the Secretary for a full list of tasks

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Only a single member may be chosen for this role.

Grading

10.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 9th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

10.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1170000
    • End Block: #1184400

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

10.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #1083600
    • End Block: #1198800

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

10.7 - Manage the Storage Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Storage Lead role is scattered across the Helpdesk, proposal(s) and forum post(s). This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other SPs) must be available and helpful in Discord and the forum.
  • The Storage Lead should be conducting:
    • frequent spotchecks
    • general "system health" checks
    • asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.

This should be accompanied by a set of rules defining some terms under which the Storage Lead should be:

  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. In collaboration with the Lead, create a budget that allows the hiring of 4 more SPs, to a total of 10 (including the Lead). This should include

  • Estimates of costs for different VPS providers
  • A reasonable profit for the workers, taking their time in to account.
  • At which point(s) the SPs needs a payment increase to account for increased costs, eg. growth of the data directory.
  • Note that this budget should take any OKR compensations in to account, when those are ready.
  1. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:
  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads have been failing at an alarming frequency. At the time of writing: pending vs accepted (168/2867). Although still pretty bad, the last week we have seen the change being "only" 35 vs 1329, hinting that perhaps there's been some changes in the Storage Provider working group.
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • Was it in fact due to some changes in the working group?
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-3: $75
  • 4-5: $150

Grading

10.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
    This should be accompanied by a set of rules defining some terms under which the Curator Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 10.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

10.9 - Manage the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Hire a team of at least 3 (more) people.
  3. Follow up and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-4: $50

Grading

10.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 3 3 26
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 1 1 9
2 tomato 8 7 61
1989 2themoon 0 0 0
2130 maxlevush 6 4 35
1048 igrex 5 5 43
355 manipal 0 0 0
2182 isonar 0 0 0
SUM 16 23 20 174

10.11 - Working Group Term Limits

  • Reward: $150
  • Reward Distribution: Shared
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #1083600
    • End Block: #1184400

Purpose

Unlike the Council, where there are (currently) 16 spots every week, the Working Groups naturally sees less turnover. Especially the Lead. On the positive side, this should mean a long standing Lead gets significant insight to what the job entails. It does also mean that potentially only a single person knows how the system works.

Especially as it has also proven to be very rare for the Lead to be fired, even if they are not performing as instructed.

Scope of Work

  1. Discuss the merits for term limits for each of the Working Group Leads.
  2. If considered useful, set a reasonable length, and agree on some process for doing the handover.
  • Should the former Lead stay on as a Worker, to ease the transition?
  • Under what circumstances should this apply?
  • Should they receive extra compensation for this?
    • If so, how long?
    • Is a single bonus payout better?

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

10.12 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #1083600
    • End Block: #1198800

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

KPI 9

  • KPIs: 11
  • Total Possible Rewards: $2875
  • Council Elected in Round: 11
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #982800 / 15.06.21
    • End Block/Date: #1083600 / 22.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #112400

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 12 328081
515 l1dev 0 0
635 xfactorus 28 765522
867 xandrell 153 4183033
1962 nkhlghbl 27 738182
318 supunssw 6 164041
321 freakstatic_council 123 3362831
957 leet_joy 24 656162
439 fierydev 13 355421
4 nexusfallout 24 656162
552 cheomsk 30 820203
2 tomato 791 21626008
1323 kakashi 14 382761
2130 maxlevush 51 1394344
1048 igrex 61 1667745
2182 isonar 18 492122
SUM 16 1375 37592618

Payouts were done on block #1153461.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 9th (confusingly listed as "Election round 11" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

9.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 6 24 12
515 l1dev 0 0 0
635 xfactorus 15 54 28
867 xandrell 20 74 38
1962 nkhlghbl 13 52 27
318 supunssw 3 12 6
321 freakstatic_council 19 72 37
957 leet_joy 11 46 24
439 fierydev 8 26 13
4 nexusfallout 13 46 24
552 cheomsk 16 58 30
2 tomato 20 98 50
1323 kakashi 7 28 14
2130 maxlevush 20 77 40
1048 igrex 19 76 39
2182 isonar 9 36 18
SUM 16 199 779 400

9.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $270/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 75%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/203)
    • Council wrangling in #council channel - Yes

9.3 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

  • No one claimed referral commissions.
  • Bounty 9
    • @ - $0/$25
      • No new submissions, no payments
      • Still requires structure improvement due to merge/review delays
  • Bounty 19
    • @ - $0/$25
      • No submissions, no applications, no payments.

9.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 9th "official" Council on Babylon (#982800-#1098000) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

9.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #1069200
    • End Block: #1083600

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

9.6 - Discord & Telegram Channel Management

  • Reward: $75 Per Channel Group

    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
    1. Russian Telegram Community and #russian Discord channel

  • Reward Structure: Individual

  • Grading Process: Manual

  • Active: Full term + 1 day

    • Start Block: #982800
    • End Block: #1098000

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

9.7 - Manage the Storage Working Group

  • Reward: $550
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #982800
    • End Block: #1098000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council. The storage lead role entails some recurring tasks, and some reactive tasks.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Storage Lead role is scattered across the Helpdesk, proposal(s) and forum post(s). This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other SPs) must be available and helpful in Discord and the forum.
  • The Storage Lead should be conducting:
    • frequent spotchecks
    • general "system health" checks
    • asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.

This should be accompanied by a set of rules defining some terms under which the Storage Lead should be:

  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.

  1. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.

  2. In collaboration with the Lead, create a budget that allows the hiring of 4 more SPs, to a total of 10 (including the Lead). This should include

  • Estimates of costs for different VPS providers
  • A reasonable profit for the workers, taking their time in to account.
  • At which point(s) the SPs needs a payment increase to account for increased costs, eg. growth of the data directory.
  • Note that this budget should take any OKR compensations in to account, when those are ready.
  1. Finalize an OKR system, that rewards the Storage Lead (and potentially their workers), for reaching specific "Objective Key Results". During the last term, this proposal was approved. Although a good start, there is room for improvements. General:
  • Are these graded, or simply measured, three times a week?
  • Use specific numbers, instead of relative ones.
    Specific:
  • OKR1 is not objective, as it requires the workers to not only report their capacity, but also report them correctly. Is the cost of requiring 200% capacity (at the time of writing) worth it, considering the platform will have to pay that?
    • Will a full storage node report holding all assets in helios?
  • OKR2 only measures latency to DE and UK. Although not the case as of now, the future storage system will distribute content based on "geography". Is it more reasonable to require that the working group as a whole can provide good latency to various regions, rather than focusing on "just" UK/DE?
  • Although reducing the number of failed uploads is not entirely in the control of the SPs, but it seems a valuable metric to track.
  • Consider measuring the groups downtime some way.
  • Consider measuring the groups response time on discord/forum.
  • Consider measuring the Leads reporting punctuality.
    Finally, combine the work here with the budget, and agree on a reasonable balance of rewards and OKR bonuses.
  1. Uploads are (still) failing at an alarming frequency - at the time of writing, close to 10% are pending vs accepted (133 - 1538).
  • The Council and/or the Storage Lead needs to figure out which SPs, if any, are the source of these failures, and take appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • This task requires some research, but by using the query-node playground, and the examples, it can be done.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $100
  • 2-3: $75
  • 4-5: $150

Grading

9.8 - Manage the Content Curators Working Group

  • Reward: $500
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Currently, the specific tasks associated with the Curator Lead role was agreed in this proposal, but should be both updated, and made available in the community repo. Additionally, this is very light compared to what is outlined in the Helpdesk. To avoid confusion a single source of truth, that gets updated when needed, is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples:
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Curator Lead, or one of their must be publish:
    • frequent (daily?) reports listing:
      • content directory statistics
      • new videos/channels
      • changes made (updates etc)
      • any actions (censorship and warnings) taken
    • recurring (weekly/biweekly/monthly?) council reports, listing:
      • more detailed statistics
      • summary of the frequent reports
      • notes, thoughts, needs, issues, etc.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  • Most statistics can be found using the Query Node Playground, and the examples here.
  • Note that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
    This should be accompanied by a set of rules defining some terms under which the Curator Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  2. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  3. Propose a draft for an OKR system used to measure the quality of service provided by the working group. See KPI 9.7 for more information.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-3: $75
  • 4: $200

Grading

9.9 - Manage the Operations Working Group

  • Reward: $250
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1098000

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Currently, the specific tasks associated with the Operations Lead role was agreed in proposals:
  • 127
  • 128
  • 155
  • 160
    In addition, some tasks are outlined in the helpdesk. This is rather confusing, and a single source of truth is required. Create a PR to the community repo, that lists all the current "recurring" tasks, and any specifics associated with it. Examples (some duplicates):
  • Lead (and/or other curators) must be available and helpful in Discord and the forum.
  • The Lead must adjust the workers rewards if required due to rate changes.
  • The Lead should fire and/or slash non-performing workers.
  • The Operations group always has assigned one/some of their own to act as Bounty Managers for all technical and research bounties, such as:
  • Reporting requirements and frequency
    This should be accompanied by a set of rules defining some terms under which the Operations Lead should be:
  • Warned
  • Slashed
  • Fired
  • Fired AND slashed
    This must be approved by the Council before it is merged. After that, a PR to the helpdesk with a link to the now "always updated" tasks must be made.
  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Hire a team of at least 3 (more) people.
  3. Follow up and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Weighting:

  • 1: $150
  • 2-4: $50

Grading

9.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 0 0 0
318 supunssw 0 0 0
321 freakstatic_council 1 1 11
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 0 0 0
552 cheomsk 0 0 0
2 tomato 14 12 133
1323 kakashi 0 0 0
2130 maxlevush 1 1 11
1048 igrex 2 2 22
2182 isonar 0 0 0
SUM 16 18 16 178

9.11 - Working Group Term Limits

  • Reward: $150
  • Reward Distribution: Shared
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #982800
    • End Block: #1083600

Purpose

Unlike the Council, where there are (currently) 16 spots every week, the Working Groups naturally sees less turnover. Especially the Lead. On the positive side, this should mean a long standing Lead gets significant insight to what the job entails. It does also mean that potentially only a single person knows how the system works.

Especially as it has also proven to be very rare for the Lead to be fired, even if they are not performing as instructed.

Scope of Work

  1. Discuss the merits for term limits for each of the Working Group Leads.
  2. If considered useful, set a reasonable length, and agree on some process for doing the handover.
  • Should the former Lead stay on as a Worker, to ease the transition?
  • Under what circumstances should this apply?
  • Should they receive extra compensation for this?
    • If so, how long?
    • Is a single bonus payout better?

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

  • Not completed ($0/$150)

KPI 8

  • KPIs: 10
  • Total Possible Rewards: $2375
  • Council Elected in Round: 10
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #882000 / 08.06.21
    • End Block/Date: #982000 / 15.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #1011600

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 9 249816
515 l1dev 16 444117
635 xfactorus 30 832719
867 xandrell 170 4718742
1962 nkhlghbl 124 3441906
318 supunssw 9 249816
2039 doppelganger23 14 388602
321 freakstatic_council 133 3691722
957 leet_joy 48 1332351
4 nexusfallout 28 777205
552 cheomsk 39 1082535
631 xantis 14 388602
2 tomato 798 22150331
319 sparky 0 0
2130 maxlevush 187 5190616
2182 isonar 34 943748
SUM 16 1653 45882828

Paid out at block #1,034,470.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 9th (confusingly listed as "Election round 11" in Pioneer) Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

8.1 - Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #88200
    • End Block: #982800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 4 16 9
515 l1dev 7 28 16
635 xfactorus 16 52 30
867 xandrell 19 61 35
1962 nkhlghbl 8 33 19
318 supunssw 4 16 9
2039 doppelganger23 7 25 14
321 freakstatic_council 19 75 43
957 leet_joy 15 58 33
4 nexusfallout 15 50 28
552 cheomsk 19 68 39
631 xantis 7 25 14
2 tomato 17 73 41
319 sparky 0 0 0
2130 maxlevush 19 65 37
2182 isonar 18 60 34
SUM 16 194 705 400

8.2 - Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 8.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $280/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 75%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/203)
    • Council wrangling in #council channel - Yes

8.3 - Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 14: $25/50 per week
    • Bounty 15: $25/100 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty with this format, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

8.4 - Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 8th "official" Council on Babylon (#882000-#997200) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

8.5 - Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #968400
    • End Block: #982800

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

8.6 - Discord Channel Management

  • Reward: $50 Per Channel Group
    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    1. Governance
    • #council
    • #proposal
    • #bounties
    1. Newcomers
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #882000
    • End Block: #997200

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups (1-3):
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

8.7 - Manage the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.
This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Uploads are failing at an alarming frequency - at the time of writing, close to 10% are pending vs accepted (90 - 964). Ensure the Storage Lead finds out which SP(s) are the source of these failures, and takes appropriate actions depending on their findings. If it's suspected that the failures are not related to SPs, a plausible explanation should be presented.
  • This task requires some research from the SP lead, but by using the query-node playground, and the examples, it can be done.
  • The Lead is free to ask questions in Discord if assistance is needed
  1. Ensure the Lead (and/or other SPs) are available and helpful in Discord and the forum
  2. Ensure the Storage Lead is doing frequent spotchecks, performs general "system health" checks, and asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  3. Currently, the reporting requirements are stated here and here. The Council needs to nail down a specific reporting system. See this issue for some suggestions.
  4. Ensure the Lead performs the actions required by them, and any other agreed upon deliverables.
  5. Follow up (including performing some checks of their own, to verify the Leads findings) and sign off on the Leads reports.
  6. Ensure the Lead adjusts the workers rewards if required due to rate changes
  7. Propose a draft for an OKR system used to measure the quality of service provided by the working group (this subtask commands $100/$300 of the possible rewards)
  • Who should be respnsible for making, and grading, the OKRs?
    • eg. Council creates, Lead measured
    • Lead creates, workers measured?
    • Both?
  • What sort of metrics should be measured?
    • What are those metrics now?
    • What should those metrics be?
  • How frequently should the results be measured?
  • What should the incentives be?
    • Should part of the Leads compensation be tied to the results?
  • etc.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.8 - Manage the Content Curators Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

In no particular order:

  1. The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  1. With the new content directory, the reporting requirements for the group and Lead should be revisited. Previously, the Council agreed on these requirements.
  • This seems a little lightweight, and should be expanded. Now that examples for using the query node playground has been added here, more thorough reporting should be required:
    • the suggested format for "regular checks" can be found here
    • the suggested format for "council reports" can be found here
    • not that although these may be both flawed and excessive, it's important to set a high bar right away, as it will be significantly more difficult to maintain a good overview as the content directory grows.
  1. Agree on the frequency and format of the reporting.
  • The results, as agreed in a text proposal, should then be added to the Community Repo.
  1. As stated in KPI 8.4, some content statistics should be included in the Council Minutes. This should include information about categories, channels, duration statistics and upload statistics, available from the Query Node Playground.
  2. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".
  3. Work with the curator group to create a list of problems with the current curator workflow (https://github.com/Joystream/joystream/issues/2387#issuecomment-855201361)
  4. Ensure the Lead adjusts the workers rewards if required due to rate changes
  5. Propose a draft for an OKR system used to measure the quality of service provided by the working group (this subtask commands $100/$300 of the possible rewards). This means:
  • Who should be respnsible for making, and grading, the OKRs?
    • eg. Council creates, Lead measured
    • Lead creates, workers measured?
    • Both?
  • What sort of metrics should be measured?
    • What are those metrics now?
    • What should those metrics be?
  • How frequently should the results be measured?
  • What should the incentives be?
    • Should part of the Leads compensation be tied to the results?
  • etc.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.9 - Manage the Operations Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Ensure the group immediately addresses the defined tasks listed in the groups helpdesk section.
  2. Create a list of reasonable tasks the group could be tasked with right away, or in the future once more workers are hired. Examples from last KPI (some overlap with 1.):
  • Manage/maintain the api-examples in community repo
    • update when new types are issued (urgent)
    • eg. create new/better examples (high priority)
  • Technical bounties:
    • Act as BMs
    • Suggest new ones
    • Provide guidance and assistance?
    • Decide whether they (not the BM themselves ofc) can also apply/contribute?
  • Maintain (and pay for) some server infrastructure:
    • Backup servers (pioneer, API)
    • Leeching storage nodes (as backups when needed)
    • Provide API for getting data from "old" testnets
    • Non-critical/sensitive stuff created by the community (UNO)
    • Discord/telegram bots
    • Faucets (funds to be requested in spending props)
    • Deploy mirror of QN/Atlas?
  • Make minor (unsolicited and/or solicited) improvements to CLI and Pioneer
  • Manage #tech-support (Discord)
  • Offload Council?
  1. Work together with the Lead, to establish a budget based on the current tasks, and create estimates once future tasks has been assigned.
  2. Create the initial reporting requirements for the group.
  3. Follow up (including performing some checks of the reports) and sign off on the Leads "council reports".

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

8.10 - Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #882000
    • End Block: #982800

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 2 1 15
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 1 1 15
957 leet_joy 1 1 15
4 nexusfallout 0 0 0
552 cheomsk 0 0 0
631 xantis 0 0 0
2 tomato 8 5 77
319 sparky 0 0 0
2130 maxlevush 1 1 15
2182 isonar 0 0 0
SUM 16 13 9 138

KPI 7

  • KPIs: 11
  • Total Possible Rewards: $2625
  • Council Elected in Round: 9
  • Council Members: 16
  • Term Length: 7 days / 100800 blocks
    • Start Block/Date: #781200 / 01.06.21
    • End Block/Date: #882000 / 08.06.21
  • Term Summaries Forum Thread: TBD
  • Deadline to Submit Summary: #925200

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
361 blackmass 8 214297
515 l1dev 6 160723
635 xfactorus 37 991124
867 xandrell 87 2330481
1962 nkhlghbl 313 8384374
318 supunssw 12 321446
2039 doppelganger23 33 883976
321 freakstatic_council 141 3776987
957 leet_joy 39 1044698
439 fierydev 21 562530
4 nexusfallout 33 883976
2 tomato 636 17036620
2183 dapplooker 0 0
319 sparky 0 0
2130 maxlevush 198 5303854
1746 ogpetya 4 107149
SUM 16 1568 42002235

Paid out at block #934,190.

Notes

After having the KPI system operational for 5 weeks, we've had time to monitor the rewards, and have made some adjustments. Long story short:

  • Some of the KPIs that are always completed in full, that we suspect have been particularly well paid, will see small adjustments downward.
  • Some of the KPIs that has been repeatedly issued, but not completed, has been removed (to be made into a bounty), or will pay more.

Annihilation Modes

Although the new KPI scheme is meant to improve the "tragedy of the commons" issue by making them more individual, there are certain things they have to "solve" as a group. If one or more of the items below is not achieved, the Council will not receive ANY KPI rewards, despite otherwise flawless work.

  1. Ensure the 7th Council Election gets >=16 applicants, meaning a new Council is elected on time.

For both the Antioch Council Elections, we have struggled getting a sufficient amount of applicants, leading to the "Announcing Period" being restarted both times (this happens automatically if the number of Applicants is lower than the Council Size).

This is obviously bad, for many reasons, and we want to avoid it happening again.

Proposal Clearance

  • Reward: $400
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that was open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
361 blackmass 4 16 8
515 l1dev 3 12 6
635 xfactorus 18 72 37
867 xandrell 18 72 37
1962 nkhlghbl 19 75 39
318 supunssw 6 24 12
2039 doppelganger23 16 64 33
321 freakstatic_council 19 81 42
957 leet_joy 17 76 39
439 fierydev 10 40 21
4 nexusfallout 16 64 33
2 tomato 18 82 43
2183 dapplooker 0 0 0
319 sparky 0 0 0
2130 maxlevush 18 84 44
1746 ogpetya 2 8 4
SUM 16 184 770 400

Council Secretary

  • Reward: $300
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

Scope of Work

The Council Secretary will act as a bridge between the Council and Jsgenesis. This means:

  • Assigning Jsgenesis to review* all PRs made to the Community Repo, with a link to the spending proposals and other applicable information.
  • Signing off on all reports created
  • Assist and support other CMs
  • Monitor the bounties
    • propose/hire Bounty Managers, set their rewards and secure funding after the fact
    • follow up Bounty Managers (and replace if needed)
    • select the "Weekly Bounty Managers" ref 2.3, according to interest (they will be paid through KPI rewards)
    • ensure the bounty information presented on the website is up to date
    • report on progress after the end of the Term
  • Notify Jsgenesis of urgent and important matters on the testnet
  • Open a forum thread for the "Term Summaries" where the CMs can report on their Council/KPI activities.
  • Ask Jsgenesis to refill the Council Mint in in the #council room on Discord

* Not before all formalities has been completed, eg. approved by the Council

Reward Distribution

Although a single person has the final responsibility, the Council may choose to elect a back-up, deputy, or split the work between bounties and non-bounties.

Grading

  • @tomato - $250/$300
    • Assigning Jsgenesis community repo review - Yes
    • Signing off on all reports - Yes
    • Assisting and support other CMs - Yes
    • Monitor the bounties - 50%
    • Notify Jsgenesis of network issues - Yes
    • Report on progress - Yes
    • Term summaries - Yes
    • Bounty JSON updated: Yes (https://github.com/Joystream/community-repo/pull/197)
    • Council wrangling in #council channel - Yes

Weekly Bounty Managers

  • Reward:
    • Bounty 9: $25/50 per week
    • Bounty 15: $25/100 per week
    • Bounty 19: $25/100 per week
    • Bounty Referral Bonus: $100 Commission
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

Scope of Work

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Link to Bounties:

After the Council Term has ended, create a brief "handover" report for your successor (even if you are re-elected).

Finally, the last part is to find someone, inside or outside of the community, to start working on a bounty. Any CM that manages to find someone (including themselves) to get assigned for any Bounty with this format, a $100 bonus awaits!

Reward Distribution

Individual. The Council Secretary is responsible for assigning CMs for each Bounty.

Note that $X/$Y means that if there is no work on that particular bounty, the former amount will be the reward. If there is some work done, the latter amount will be awarded IF the work is satisfactory.

Grading

Council Minutes

  • Reward: $150
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term +1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

There needs to be some level of accountability and transparency for the Council. For each Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 7th "official" Council on Babylon (#680400-#694800) produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

Find All PRs/Issues That Require Jsgenesis Action

  • Reward: $75
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Final day (14400 blocks)
    • Start Block: #781200
    • End Block: #882000

Purpose

As we are often behind on certain issues, and have multiple github repos (and discord) to monitor, assistance is often needed.

We need to compile a list of actions required.

Scope of Work

Towards the end of the term, go through the following repos, and look for open issues and PRs made by someone outside of the "organization", that has not been solved/addressed:

  • joystream
  • helpdesk
  • hydra
  • community-repo
  • atlas
  • founding-members
  • joystream-org
  • handbook

Then, go through the Discord channels (last week only), and add questions/comments that needs to be addressed.

Finally, create an issue in the community repo with a brief TL;DR for each, and a link to the issue/pr.

Note that this issue may be of help, but ensure the items are still not addressed before you make the new issue!

Reward Distribution

If multiple issues are created, only the best one will be rewarded.

Grading

  • $0/$75
    • Not completed during term

Discord Channel Management

  • Reward: $50 Per Channel Group
    1. Testnet Roles
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    1. Governance
    • #council
    • #proposal
    • #bounties
    1. Newcomers
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term + 1 day
    • Start Block: #781200
    • End Block: #896400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Scope of Work

For each of the above groups (1-3):
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

Manage the Storage Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

As the runtime upgrade is completed, the Storage Provider will see a lot more load coming their way, as they are no longer only responsible for uploads, but also all playback and downloads.

This requires the Storage Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. At an alarming frequency, uploads are failing. Ensure the Storage Lead finds out which SP(s) are the source of these failures, and takes appropriate actions depending on their findings.
  2. Ensure the Lead (and/or other SPs) are available and helpful in Discord and the forum
  3. Ensure the Storage Lead is doing frequent spotchecks, performs general "system health" checks, and asking their SPs to disclose their hardware specs, configurations, uptime, available (eg. df -h) and used storage (eg. dh -sh .ipfs), etc.
  4. Ensure the lead delivers frequent reports of the matters above, and other agreed upon deliverables.
  5. Follow up (including performing some checks of their own) and sign off on the Leads reports.
  6. Ensure the Lead adjusts the workers rewards weekly (as the rate changes)

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Manage the Content Curators Working Group

  • Reward: $200
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

In no particular order:

  1. The Curator group always has assigned one/some of their own to act as Bounty Managers for content bounties, such as bounties:
  1. Ensure the Lead adjusts the workers rewards weekly (as the rate changes)
  2. With the new content directory, the reporting requirements for the group and Lead should be revisited. See helpdesk for details.
  • The results, as agreed in a text proposal, should then be added to the Community Repo
  1. Follow up (including performing some checks of their own) and sign off on the Leads reports.
  2. Some issues have arisen after the sumer upgrade such as channel categories being missing, work with the Curator Lead to create a list of these issues and submit them on the Joystream GitHub repo: https://github.com/Joystream/joystream/issues
  3. New "helpers" for the content curators will be posted to the helpdesk some time the 2nd of June 2021. Ensure they learn to use these tools.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Manage the Operations Working Group

  • Reward: $300
  • Reward Structure: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

With the release of Sumer there will be a new Working Group added to the platform. The operations group allows for workers to be hired that don't require any on-chain privileges.

Scope of Work

  1. Create an opening for the operations group Lead, with:
  • A non-trivial (role) stake, and a temporary reward (see 4 and 5).
  • Reasonable hiring criteria
  • Promote the opening on Discord and the forum, with estimates on workload and future reward
  • Hire the best candidate as Lead
  1. Agree on a scope of work for the Operations for this term. Some examples of long term tasks below:
  • Manage/maintain the api-examples in community repo
    • update when new types are issued (urgent)
    • eg. create new/better examples (high priority)
  • Technical bounties:
    • Act as BMs
    • Suggest new ones
    • Provide guidance and assistance?
    • Decide whether they (not the BM themselves ofc) can also apply/contribute?
  • Maintain (and pay for) some server infrastructure:
    • Backup servers (pioneer, API)
    • Leeching storage nodes (as backups when needed)
    • Provide API for getting data from "old" testnets
    • Non-critical/sensitive stuff created by the community (UNO)
    • Discord/telegram bots
    • Faucets (funds to be requested in spending props)
    • Deploy mirror of QN/Atlas?
  • Make minor (unsolicited and/or solicited) improvements to CLI and Pioneer
  • Manage #tech-support (Discord)
  • Offload Council?
  1. Agree on a standard for weekly reporting.
  • The results, as agreed in a text proposal, should then be added to the Community Repo
  1. Based on 2 and 3, decide on a new budget, with reasonable rewards for the Lead, and n workers to be hired during the term.
  2. Set a new reward for the Lead
  3. Follow up and sign off on the Leads reports.

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Proposal Creation

  • Reward: $200
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

Although somewhat related to all the individual KPIs, there seems to be some hesitation to actually creating the proposals. Lets reward it!

Scope of Work

This KPI rewards the creator of each proposal that:

  1. Is made by a CM
  2. Gets approved

Reward Distribution

Let:

  • P_c be the number of proposals that gets created by a CM during the term
  • P_a be the number proposals that gets approved during the term
  • P_na be the number proposals is finalized, but not approved, during the term
  • R is the reward
  • *,n is the * for a CM

For each CM:

R,n = R * (P_a,n-P_na,n)/P_c

Grading

Member ID Member Handle Created Approved Reward
361 blackmass 0 0 0
515 l1dev 0 0 0
635 xfactorus 0 0 0
867 xandrell 0 0 0
1962 nkhlghbl 2 2 24
318 supunssw 0 0 0
2039 doppelganger23 0 0 0
321 freakstatic_council 3 2 24
957 leet_joy 0 0 0
439 fierydev 0 0 0
4 nexusfallout 0 0 0
2 tomato 10 10 118
2183 dapplooker 0 0 0
319 sparky 0 0 0
2130 maxlevush 2 2 24
1746 ogpetya 0 0 0
SUM 16 17 16 188.23529411764704

Content Migration

  • Reward: $200
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full term
    • Start Block: #781200
    • End Block: #882000

Purpose

As KPI 6.11 wasn't fully completed, nor delivered on time, we have an unresolved problem with migrating videos and channels.

Scope of Work

Come up with a plan for getting all the "good" content uploaded to the previous testnet migrated.
This plan should consider:

  • Ideally, the owner performs all uploads themselves.
    • Provide incentives based on quality first and foremost, but quantity should also matter due to the workload for the owner.
  • When a plan has been discussed and approved, promote it both on Discord and the Forum.
  • The Council will be given a budget of $300 to compensate the owners/uploaders.

Note that Jsgenesis has a backup of the "old" content directory, and can, with inputs such as memberId, assist with:

  • getting the required content for screening and/or re-uploading
  • verifying interested parties did indeed have n channels/videos
  • other

Reward Distribution

Grading is individual. If the proposals created in relation to the tasks above are made by different CMs, the rewards will be shared based on the assumed workloads.

Grading

Antioch KPIs

Antioch KPIs can be found here!