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

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

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

Table of Contents

Current

KPI 47

  • KPIs: 7+5
  • Total Possible Rewards: $1200+$375
  • Max Fiat Pool Difference: $0
  • Council Elected in Round: 49
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4798800 / 09.03.22
    • End Block/Date: #4899600 / 16.03.22
  • Deadline to Submit Summary: #4928400 / 18.03.22

Notes

We are getting closer... :(

Section I - Council work, Proposals and Bureaucracy

47.I-1 - Proposal Clearance

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

Same as kpi-46.I-1.

Grading

TBD

47.I-2 - Council Secretary

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

Same as kpi-46.I-2.

Grading

TBD

47.I-3 - Deputy Council Secretary

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

Same as kpi-46.I-3.

Grading

TBD

47.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #4899600
    • End Block: #5014800

Same as kpi-46.I-4.

Grading

TBD

47.I-5 - KPI Manager

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

Same as kpi-46.I-5.

Grading

TBD

Section II - Community Management

47.II-1 - Discord Channel Management

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

Same as kpi-46.II-1.

Grading

TBD

47.II-2 - Council Term Summary Videos

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

Same as kpi-46.II-2.

Grading

TBD

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

47.OP-1 - Olympia - Pioneer Revamp

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #4798800
    • End Block: #5000400

Not clear if done.
Same as kpi-44.OP-3.

47.CC-1 - Olympia - Content Migration

  • Reward: $75
  • Fiat Pool Factor: 0
    • Start Block: #4798800
    • End Block: #5000400

Purpose

We are once again migrating content, but this time, we plan to migrate everything.
However, it's good to do a quick check if some of the new uploads needs to be removed from the migration.

Scope of Work

  1. Use the query node playground to find out how many new channels and videos have been created AFTER we did the initial migration.

  2. Check if any of these channels/videos really should be removed from the migration list. Do not consider quality, simply if they should have been censored or removed already.

Grading

TBD

47.CC-2 - Olympia - Handover

  • Reward: $50
  • Fiat Pool Factor: 0
    • Start Block: #4798800
    • End Block: #5000400

Purpose

It's not clear if the Leads will stay the same post Olympia. It's good for the Leads to have a short list of the routines and workflow of the current group.

Scope of Work

  1. Outline the current routines and workflow of the Curator group, and how newly uploaded content is reviewed, and when applicable, dealt with.
  2. Outline the extra work you, the Lead, do that may not be obvious. Examples:
  • Organizing
  • Hiring
  • Managing the Workers (at the "human" level)
  • Adjusting rewards
  1. If there is anything else you'd wish someone told you when you became the Lead - explain!

Grading

TBD

47.SP-1 - Olympia - Handover

  • Reward: $75
  • Fiat Pool Factor: 0
    • Start Block: #4798800
    • End Block: #5000400

Purpose

It's not clear if the Leads will stay the same post Olympia. It's good for the Leads to have a short list of the routines and workflow of the current group.

Additionally, the Storage Group Lead will have some extra "knowhow" of things they have learned along the way.

Scope of Work

  1. Outline the current routines and workflow of the Storage group. Examples:
  • Routines for noticing, and the following actions, when/if:
    • a node goes down
    • uploads are failing
    • a bucket is "full"
    • a node is "full"
    • etc.
  1. Outline the current setup, and explain why it is the way it is. Examples:
  • number of nodes and buckets
  • dynamic bag policy
  • mode settings
  • hardware requirements
  • geographical distribution
  1. Outline the extra work you, the Lead, do that may not be obvious. Examples:
  • Organizing
  • Hiring
  • Managing the Workers (at the "human" level)
  • Adjusting rewards
  1. Is there anything you've learned along the way, that wasn't at all clear (or even wrong) from the guides?
  2. If there is anything else you'd wish someone told you when you became the Lead - explain!

Grading

TBD

47.DT-1 - Olympia - Handover

  • Reward: $75
  • Fiat Pool Factor: 0
    • Start Block: #4798800
    • End Block: #5000400

Purpose

It's not clear if the Leads will stay the same post Olympia. It's good for the Leads to have a short list of the routines and workflow of the current group.

Additionally, the Distributor Lead will have some extra "knowhow" of things they have learned along the way.

Scope of Work

  1. Outline the current routines and workflow of the Storage group. Examples:
  • Routines for noticing, and the following actions, when/if:
    • a node goes down
    • a distributor provides poor service
    • etc.
  1. Outline the current setup, and explain why it is the way it is. Examples:
  • number of nodes and (family) buckets
  • geographical distribution
  • dynamic bag policy
  • mode settings
  • hardware requirements
  • other?
  1. Outline the extra work you, the Lead, do that may not be obvious. Examples:
  • Organizing
  • Hiring
  • Managing the Workers (at the "human" level)
  • Adjusting rewards
  1. Is there anything you've learned along the way, that wasn't at all clear (or even wrong) from the guides?
  2. If there is anything else you'd wish someone told you when you became the Lead - explain!

Grading

TBD

KPI 46

  • KPIs: 10+2
  • Total Possible Rewards: $1600+$130
  • Max Fiat Pool Difference: $0
  • Council Elected in Round: 48
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4698000 / 02.03.22
    • End Block/Date: #4798800 / 09.03.22
  • Deadline to Submit Summary: #4827600 / 11.03.22

Notes

Our apologies for the "no-kpi" last Term.
Retroactively,
every KPI from:

Will still be graded and "honored" if submitted.
Ungraded KPIs will be graded and paid out over the weekend.

Furthermore, there was a lot more issues with pioneer than anticipated, but we're crawling towards the finish line! Within two weeks - book it!

Section I - Council work, Proposals and Bureaucracy

46.I-1 - Proposal Clearance

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

Same as kpi-44.I-1.

Grading

TBD

46.I-2 - Council Secretary

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

Same as kpi-44.I-2.

Grading

TBD

46.I-3 - Deputy Council Secretary

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

Same as kpi-44.I-3.

Grading

TBD

46.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #4798800
    • End Block: #4914000

Same as kpi-44.I-4.

Grading

TBD

46.I-5 - KPI Manager

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

Same as kpi-44.I-5.

Grading

TBD

Section II - Community Management

46.II-1 - Discord Channel Management

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

Same as kpi-44.II-1.

Grading

TBD

46.II-2 - Council Term Summary Videos

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

Same as kpi-44.II-2.

Grading

TBD

Section III - Working Groups

46.III-1 - 'Old' Working Groups Status

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

Purpose

Now that we are finally getting ready for Olympia, we need a current status!

Scope of Work

For each of these Working Groups:

  • Content Curators
  • "Developers"
  • Storage Providers
  • Distributors (considered "old" in this context)
  1. How long has the Lead been seated?

For both current and former Workers (and Leads) in the group:
2. When was each of the Workers hired?
3. How much has/did the Worker make in tJOY + estimate in USD?

For each worker no longer part of the group:
4. Did they quit, or were they fired?
5. What was the rationale?

  1. What is the groups spending/rewards right now in tJOY + estimate in USD?
  2. How has the spending changed over time in tJOY + estimate in USD?

Reward Distribution

  • $75 for each group

Grading

TBD

46.III-2 - 'New' Working Groups Status

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

Purpose

Now that we are finally getting ready for Olympia, we need a current status!

Note
If these groups have any workers - they are blacklisted for this KPI.

Scope of Work

For each of these Working Groups:

  • Marketers
  • HR group
  1. Is there any activity in the group?

If yes:
2. Link to all proposals and relevant forum threads/discord discussions.
3. Outline in words the TL;DR of these proposals/posts, and explain:

  • how they got started
  • what they're tasks are
  • how they've performed
  1. Answer as many of the questions in KPI 46.III-1 that is applicable. (Smaller reward, as there has been less activity.)

Reward Distribution

For each group:
2. $50
3. $25
4. $25

Grading

TBD

46.III-3 - Olympia Preparation

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

HOLD

Section IV - Bounties

Working Group KPIs

46.OP-1 - Olympia - Pioneer Revamp

  • Reward: $150
  • Fiat Pool Factor: 0
    • Start Block: #4698000
    • End Block: #4899600

Not clear if done.
Same as kpi-44.OP-3.

Previous KPIs

KPI 44

  • KPIs: 7+5
  • Total Possible Rewards: $1200+$560
  • Max Fiat Pool Difference: $0
  • Council Elected in Round: 46
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4496400 / 16.02.22
    • End Block/Date: #4597200 / 23.02.22
  • Deadline to Submit Summary: #4626000 / 26.02.22

Notes

Section I - Council work, Proposals and Bureaucracy

44.I-1 - Proposal Clearance

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

Same as kpi-43.I-1.

Grading

TBD

44.I-2 - Council Secretary

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

Same as kpi-43.I-2.

Grading

TBD

44.I-3 - Deputy Council Secretary

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

Same as kpi-43.I-3.

Grading

TBD

44.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #4597200
    • End Block: #4611600

Same as kpi-43.I-4.

Grading

TBD

44.I-5 - KPI Manager

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

Same as kpi-43.I-5.

Grading

TBD

Section II - Community Management

44.II-1 - Discord Channel Management

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

Same as kpi-43.II-1.

Grading

TBD

44.II-2 - Council Term Summary Videos

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

Same as kpi-43.II-2.

Grading

TBD

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

44.DT-1 - Distributor System Reports

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #4496400
    • End Block: #4611600

Purpose

As we failed to follow up here, let's turn it around!

Scope of Work

The Lead creates two reports:

  1. Within block #4525200, the Lead publishes the first report, outlining the details of the distribution system as of now. For Workers/nodes:
  • Number of nodes
  • Geographical location
  • Capacity (hardware)
  • Performance
    For the system:
  • Number, and location, of buckets and families
  • Data on how bags are distributed across these
  • Issues encountered (until now)
  1. Within #4611600, the Lead publishes a second (more thorough) report, outlining the status at the end of the Term. For Worker/nodes:
  • Who + changes in "staff" since Giza launch
  • Rewards and costs
  • Performance (upload speed, download speed, errors)
    For the system:
  • Number, and location, of buckets and families
  • Data on how bags are distributed across these
  • New issues encountered
  • Plans (for improvements)
  • Needs
  • Step by step plans for how they would want to perform the migration to olympia (configurations etc.). Note that the actual migration, from Jsgenesis PoV will be similar as with sumer->giza, but:
    • no workers at launch (new Lead to be elected by the Council)
    • Jsgenesis will only run a node for migration, then shut down once replication(s) has been made

44.SP-1 - Storage System Reports

  • Reward: $200
  • Fiat Pool Factor: 0
    • Start Block: #4496400
    • End Block: #4611600

Purpose

As we failed to follow up here, let's turn it around!

Scope of Work

The Lead creates two reports:

  1. Within block #4525200, the Lead publishes the first report, outlining the details of the storage system as of now. For Workers/nodes:
  • Number of nodes
  • Geographical location
  • Capacity (hardware)
  • Performance
    For the system:
  • Replication by bags (eg. 100 bags in one bucket only, 50 bags in two buckets only...)
  • Growth (charts) - measured in: bags, objects, size
  • Issues encountered (until now)
  1. Within #4611600, the Lead publishes a second (more thorough) report, outlining the status at the end of the Term. For Worker/nodes:
  • Who + changes in "staff" since Giza launch
  • Rewards and costs
  • Performance (upload speed, download speed, errors)
    For the system:
  • Replication by bags (eg. 100 bags in one bucket only, 50 bags in two buckets only...)
  • Growth (charts) - measured in: bags, objects, size
  • New issues encountered
  • Plans (for improvements)
  • Needs
  • Step by step plans for how they would want to perform the migration to olympia (configurations etc.). Note that the actual migration, from Jsgenesis PoV will be similar as with sumer->giza, but:
    • no workers at launch (new Lead to be elected by the Council)
    • Jsgenesis will only run a node for migration, then shut down once replication(s) has been made

Grading

TBD

44.OP-1 - Frontend Onboarding

  • Reward: $30
  • Fiat Pool Factor: 0
    • Start Block: #4496400
    • End Block: #4597200

Purpose

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

Scope of Work

  1. As far as we know, the work is underway. Pay is $30/h
  2. Report on the progress.

Grading

TBD

44.OP-2 - Olympia - Inital Testing

  • Reward: $30
  • Fiat Pool Factor: 0
    • Start Block: #4496400
    • End Block: #4597200

Purpose

Testing of Olympia - a brand new chain is needed!

A WIP Community Testing Protocol can be seen here. We will be working off of the olympia branch.

The main focus is pioneer, but some use of:

  • The CLI
  • "Old" pioneer - or really polkadot-js/apps
  • Scripts (shared and created)
    Will be needed.

Scope of Work

  1. The Lead allocates two people to assist with testing. As we need some experience and continuity, tomato and l1dev will be invited to contribute anyway, but one or two more sets of eyes would come in handy. The "chosen ones" should:
  • be available at least between 1200 and 1700 CET, daytime Friday-Monday
  • use/create the tools above
  • be systematic in reporting

Grading

TBD

44.OP-3 - Olympia - Pioneer Revamp

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #4496400
    • End Block: #4597200

Purpose

As we're preparing the move over to Olympia, we need some smaller parts of the current pioneer. Mainly for the purposes of exporting keys, as the new pioneer only uses the polkadot-js, but it would be great to also have some features that aren't in pioneer 2.0:

  • Access to the explorer
  • Access to the chain state
  • Access to the extrinsic
    Even less important nice to haves:
  • Access to the javascript
  • Access to the toolbox
  • Access to the my keys

Resources

There are two ways to go about this:
A: Fork polkadot-js/apps, and simply change the branding. This is probably easier, as you can simply inject types (see below).

To test:
Currently, a staging network is running with the endpoints found here.
If you want to connect to it using polkadot-js hosted by parity:

  • goto: https://polkadot.js.org/apps/
  • click network (top left) -> Development
  • set custom endpoint to wss://3.93.46.244.nip.io/ws-rpc -> switch
  • Settings -> Developer copypasta from https://github.com/Joystream/joystream/blob/olympia-playground/types/augment/all/defs.json -> save

B: Start from master branch of joystream repo and strip away everything non-pioneer. This will probably be A LOT more work.

Note
The reward ($100) only applies to Scope of Work - Operations Group. The reward for the task may be higher or lower.

Scope of Work

The scope of work differs quite a bit whether you go for option A or B, so the SoW assumes A is chosen.

  1. Until block #4539600, anyone (eg. not only Developer group or the Council), either as an individual or as a group can "bid" on the KPI. Go through the tasks below, estimate and include:
  • How many hours you think is needed for you to finishing the task
  • Include what branch you are building off of, and any other "design" choices you'll make
  • How much compensation you require to complete the work.
  1. Fork (A or B) that by default will connect to "our" staging network, with the defs.json "pre-injected". The URL will be wss://olympia-staging-a.joystream.app/rpc (this will be up before the end of the 48h).

  2. Add a new landing page, with room for a some images, text and links, where Jsgenesis can add a link to the new pioneer and some TBD information. (Will be prepared during the week).

  3. Build, and host the current version of ["our" pioneer](https://github.com/Joystream/joystream/tree/master/pioneer - at https://pioneer.your.url.
    Example with caddy:

# Caddyfile
giza-staging-a.joystream.app {
	root /* /root/joystream/pioneer/packages/apps/build
	file_server
}

No need to change the rpc endpoint here - this is just for ensuring keys stay in the browsers local storage

  1. Share your url on discord, so that we, and others, can test creating/importing a key there, and make a transaction on the current chain.

  2. Build your polkadot-js fork, that connects to wss://olympia-staging-a.joystream.app/rpc and host at https://pioneer.your.url.

  3. Ping again on discord, so we can test that we can retrieve our keys, and make transaction using the extrinsics tab.

  4. Share your source code, so we can review! We may want you to make a PR back to our organization with your work, so we, and/or the community, can maintain.

Scope of Work - Operations Group

  1. The Lead, or a Worker assigned by the Lead, will be responsible for selecting the best applicant. They must open a text proposal requesting bids, respond to questions, and give a short evaluation of all bids.

  2. The same person will follow up the work, and, should the assigned person fail to make progress, finish the task to the best of their abilities. If so, they can then claim parts of the reward for themselves.

Grading

TBD

KPI 43

  • KPIs: 9+5
  • Total Possible Rewards: $1650+$585
  • Max Fiat Pool Difference: $110
  • Council Elected in Round: 45
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4395600 / 09.02.22
    • End Block/Date: #4496400 / 16.02.22
  • Deadline to Submit Summary: #4525200 / 19.02.22

Notes

Please note the urgency, and potential punishment associated with 43.III-1 - Follow up the Curator Working Group and 43.CC-1 - Re-set Featured Content.

The new incentives will be rolled out with Olympia, even if that (likely) means lots of planned improvements and additions to be added the following weeks. Olympia will be a brand new chain, so there are some clear advantages there...

Grading of KPI 40 and 42 are due to an unfortunate thing - namely that the scripts we use don't work well after the runtime upgrade to Giza.

Some TBD and HOLDs here. Will be added Saturday.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
1905 kate_fm 119 4831972
2194 ilich 117 4750762
2502 adovrn 152 6171931
644 lkskrn 11 446653
361 blackmass 12 487258
515 l1dev 312 12668700
2098 0x2bc 9 365443
2531 nanapa6otaet 5 203024
1962 nkhlghbl 0 0
321 freakstatic_council 10 406048
957 leet_joy 231 9379710
2462 chiffah 13 527862
2 tomato 3 121814
2329 laura 3 121814
2836 art_khabibullin 156 6334350
2130 maxlevush 16 649677
1048 igrex 165 6699793
2148 controlla 5 203024
3234 jen4ph 168 6821608
2154 marat_mu 98 3979271
SUM 20 2370 65170714

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2098 0x2bc 50 2030240
644 lkskrn 690 28017317
3029 oxygen 25 1015120

Paid out on blocks #4,957,659 and #4,957,660.

Section I - Council work, Proposals and Bureaucracy

43.I-1 - Proposal Clearance

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

Same as kpi-42.I-1.

43.I-2 - Council Secretary

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

Same as kpi-42.I-2.

Grading

TBD

43.I-3 - Deputy Council Secretary

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

Same as kpi-42.I-3.

Grading

TBD

43.I-4 - Council Minutes

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

Same as kpi-42.I-4.

Grading

TBD

43.I-5 - KPI Manager

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

Same as kpi-42.I-5.

Grading

TBD

Section II - Community Management

43.II-1 - Discord Channel Management

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

Same as kpi-42.II-1.

Grading

TBD

43.II-2 - Council Term Summary Videos

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

Same as kpi-42.II-2.

Grading

TBD

Section III - Working Groups

43.III-1 - Follow up the Curator Working Group

  • Reward: $300
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #4395600
    • End Block: #4496400

Purpose

This has yet to be completed after the upgrade, making parts of the Joystream Player, such as categories, look really bad.

Scope of Work

  1. Push the Curators to complete 43.CC-1 within #4438800.
  2. If not completed by the Curator group within said deadline, this is open for all Members. The tools needed to complete the task, and the authentication required, is available on demand (@kdembler or @bwhm on Discord.

Punishment

If not completed by the Curator group within said deadline, all CM rewards are reduced by 25%.
If not completed by the end of the Term, all CM rewards are reduced by 50%.

Reward Distribution

  1. 50
  2. 250

Grading

TBD

Section IV - Bounties

43.IV-1 - Tasks and Bounties - New Incentives

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

Purpose

Although slowly, we are launching the new incentives soon(tm). In that regards, we need bounties for Onboarding purposes, recurring tasks for workers in the individual groups, and ways to measure their performances.

As suggested on Discord, this task should perhaps be open for everyone?

Scope of Work

  1. Get the community involved in thinking about the bounties within the constraints outlined in 42.IV-1. Create a proposal, and push people on Discord. Decide on a medium for discussion (eg. forum, discord, etc.) and funnel them there. Keep the discussion flowing, and encourage users.
  2. At the end of the Term, curate and combine the ideas in a human readable way, sorted roughly by how "good" they are subjectively, with a link to the original post and the user who made the idea. Suggest rewards based on this, with a cap of $250. The more fleshed out, interesting and useful they are, the better. As long as it's not a clear violation of the ToS, include all ideas, even if given $0.

Reward Distribution

  1. 75
  2. 75

For the community, you will be allocated a "pool" of $250 to distribute

Grading

TBD

Working Group KPIs

43.DT-1 - Maintain Distributor System

  • Reward: $200
  • Fiat Pool Factor: 0.1
    • Start Block: #4395600
    • End Block: #4597200

Purpose

HOLD
Must parse last terms results and progress.

Grading

TBD

43.SP-1 - Maintain Storage System

  • Reward: $200
  • Fiat Pool Factor: 0.1
    • Start Block: #4395600
    • End Block: #4597200

Purpose

HOLD
Must parse last terms results and progress.

Grading

TBD

43.OP-1 - Frontend Onboarding

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

Purpose

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

Scope of Work

  1. As far as we know, the work is underway. Pay is $30/h
  2. Report on the progress.

43.CC-1 - Re-set Featured Content

  • Reward: $125
  • Fiat Pool Factor: 0
    • Start Block: #4395600
    • End Block: #4597200

Purpose

After the upgrade, all the featured content was lost.

For addressing this, using the "old" and the "new" query-node is needed.

Scope of Work

  1. Use the resources above, alongside the "old" featured categories content database, to get a new database that includes all the videos that was migrated.

  2. Use the results from 1. to set featured categories content again.

  3. Set the on-chain content:setFeaturedVideos again.

Grading

TBD

43.OP-2 - Olympia - Inital Testing

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

Purpose

HOLD

KPI 42

  • KPIs: 12+5
  • Total Possible Rewards: $1900+$855
  • Max Fiat Pool Difference: $130
  • Council Elected in Round: 44
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4294800 / 02.02.22
    • End Block/Date: #4395600 / 09.02.22
  • Deadline to Submit Summary: #4424400 / 13.02.22

Notes

Unfortunately, getting the new incentives scheme takes time. As we are simultaneously rolling out olympia (by end of February), KPIs may continue for a few weeks :(

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 16 645378
644 lkskrn 8 322689
515 l1dev 13 524370
2098 0x2bc 6 242017
2574 alexznet 0 0
2531 nanapa6otaet 4 161344
321 freakstatic_council 115 4638654
957 leet_joy 114 4598318
2532 swargo 13 524370
3029 oxygen 166 6695796
2462 chiffah 16 645378
2 tomato 303 12221844
2137 kalpakci 0 0
2228 kira_skipper 61 2460503
2329 laura 1 40336
2130 maxlevush 16 645378
1048 igrex 66 2662184
2148 controlla 3 121008
3234 jen4ph 231 9317644
2182 isonar 8 322689
SUM 20 2100 84705853

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 250 10084030
644 lkskrn 690 27831923
SUM 20 2100 84705853

Paid out on blocks #4,943,827 and #4,943,828.

Section I - Council work, Proposals and Bureaucracy

42.I-1 - Proposal Clearance

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

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

42.I-2 - Council Secretary

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

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

42.I-3 - Deputy Council Secretary

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

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

42.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

TBD

42.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

TBD

Section II - Community Management

42.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

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

Grading

TBD

42.II-2 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

TBD

Section III - Working Groups

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

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #4294800
    • End Block: #4395600

Purpose

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

Scope of Work

  1. Ensure the Lead is performing their KPI tasks. Push and ping them every day. If they are failing in their stated, or other tasks, make proposal(s) with appropriate sanctions (formal warning, slash, fire).

  2. If they are producing logs of their actions (last item), check:

  • that their data is correct
  • that nothing is missing
  • outline HOW you are checking, so that others can review
    Note that this may require using the Joystream Player and/or the QN playground.

Reward Distribution

1/2 $50

Grading

TBD

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

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #4294800
    • End Block: #4395600

Purpose

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

Scope of Work

  1. Ensure the Lead is performing their KPI tasks. Push and ping them every day. If they are failing in their stated, or other tasks, make proposal(s) with appropriate sanctions (formal warning, slash, fire).

  2. If they are producing logs of their actions (last item), check:

  • that their data is correct
  • that nothing is missing
  • outline HOW you are checking, so that others can review
    Note that this may require using the Joystream Player and/or the QN playground.

Reward Distribution

1/2 $50

Grading

TBD

42.III-3 - Follow up the Curator Working Group

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #4294800
    • End Block: #4395600

Purpose

Getting the featured content set up properly is a critical task, that needs follow up.

Scope of Work

  1. Ensure the Lead is performing their KPI tasks. Push and ping them every day. If they are failing in their stated, or other tasks, make proposal(s) with appropriate sanctions (formal warning, slash, fire).

  2. If they are producing logs of their actions (last item), check:

  • that their data is correct
  • that nothing is missing
  • outline HOW you are checking, so that others can review
    Note that this may require using the Joystream Player and/or the QN playground.

Reward Distribution

1/2 $50

Grading

TBD

42.III-4 - Follow up the Developer Working Group

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #4294800
    • End Block: #4395600

Purpose

The old Lead has found another Lead role - do we need a new one? An opening was created, but no one applied. We believe the Lead roles will require a lot of attention going forward, and to have some rotation for experience purposes.

Scope of Work

  1. Define the requirements for the role. Some keys:
  • Technical
    • knows our stack
    • understands our direction
  • Good managerial skills, eg.
    • delegating to the "right person/group" based on skillset
    • follows up frequently
    • likes kanban boards :)
  • High availability
    • frequently on discord
    • (will) frequently check up on new tasks
  • Good at reviewing PRs
    Note that although the person must understand the tech, it's not expected that they will code much themselves.
  1. Create a good new opening (proposal), promote it hard, and follow up.

  2. IF a new Lead is hired, assist them, and follow up (+$10/day)

Reward Distribution

1/2 $50

Grading

TBD

Section IV - Bounties

42.IV-1 - Tasks and Bounties - New Incentives

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

Purpose

Although slowly, we are launching the new incentives soon(tm). In that regards, we need bounties for Onboarding purposes, recurring tasks for workers in the individual groups, and ways to measure their performances.

Note that due to the nature of these tasks, all CMs are free to contribute their ideas. The KPI manager (or someone they delegate) creates a discussion thread, and is responsible for curating and combining the ideas in a human readable way, sorted roughly by how "good" they are subjectively (no reward numbers needed), and with a link to the original post and the user who made the idea. As long as it's not a clear violation of the ToS, include them all. This organizing work is rewarded $50.

Scope of Work

Note that we of course have some ideas already.

  1. "Onboarding bounties": Assume you are a user new to Joystream. You have seen some Introduction videos and set to our discord. There, you are greeted by someone in the HR working group, assisted with a membership and asked what you want to do to earn some tokens and get started. Come up with some bounty ideas that fits as many as possible of the criteria below:
  • Doesn't take too much time to do (say ~30min-3h including research)
    • time estimate
  • Something that sounds "fun", and not like a pure chore (low paid - "entry level" bounties)
    • estimate reasonable reward
  • Suitable for a person with a skillset we are wanting, eg. developer, server admins, organizers, analysts (data, economics, etc), content creators, marketers, social media, HR, writing, conflict management, design, audio/video editing, etc.
    • lots of different roles here, state which group(s) you are "targeting"
  • Doesn't require too much work to grade
    • ideally substantially faster to grade than to do
  1. "Non-technical (general) bounties": Come up with some bounty ideas that fits as many as possible of the criteria below:
  • Not too technical (eg. no scripts/tools)
  • Requires more time, both to perform and grade
    • include estimates
  • Suitable for a person with a skillset we are wanting, eg. organizers, analysts (data, economics, etc), content creators, marketers, social media, HR, writing, conflict management, design, audio/video editing, etc.
    • lots of different roles here, state which group(s) you are "targeting"
  • Should be somewhat useful for the project
    • explain why
  1. "Marketing working group tasks": This is the group we have the hardest time coming up with specific tasks for. What are good tasks for this group, assuming:
  • The tasks has to be provide value for the project
  • The results should be as "sybil resistant" as possible
  • Ideally be measurable numerically

Reward Distribution

Ideas will be graded in accordance with their value. We reserve to right to go over or under the budget, based on the contributions.

Grading

TBD

Working Group KPIs

42.DT-1 - Maintain Distributor System

  • Reward: $300
  • Fiat Pool Factor: 0.1
    • Start Block: #4294800
    • End Block: #4496400

Purpose

As Giza (finally) went live last term, we need to make progress on the Distribution Side!

As of block #4,307,237, the status is:

  • 9 (5+Lead hired by non-Jsg) workers
  • 4 (new) families created (6 in total)
  • 6 (new) buckets created (9 in total)
  • 2 (new) are acceptingNewBags and distributing (4 in total)
  • 3 (new) have accepted invite+set metadata (6 in total)
  • 5/6 have working, running nodes

Scope of Work

  1. Outline the current system, wrt. families, buckets, structure etc, within block:
  • 4323600 (full score)
  • 4338000 (2/3rd score)
  • 4352400 (1/3rd score)
  1. All workers, that are still "employed" (ex. newly employed) at each blockheight, has at least 1 bucket with metadat set, is operational, has been assigned at least 1 bag, and is serving content at block #:
  • 4323600 (full score)
  • 4338000 (2/3rd score)
  • 4352400 (1/3rd score)
  1. Outline a quick approach to measuring the "quality of service" for each node, that takes into accout:
  • ping/latency
  • whether the object is in cache or not/whether they first have to get it from an SP or not
  1. Every day, measure how well each of them performs under said conditions.

  2. Get a ("censored") version of each distributors config.yml file, share them, and propose/require changes.

  3. For each of these:

  • keep a log of the status, and share a TL;DR update every day (starting from #4323600)
  • record ALL transactions you as the Lead does, including blockheights and purpose (for moving bags, just do did x across blocks[a,b])
  • share the thoughts behind your actions

Grading

TBD

42.DT-2 - Review and Improve Documentation

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #4294800
    • End Block: #4496400

Purpose

The guides on helpdesk needs improvements.

Scope of Work

  1. Review the Workers guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the Lead guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.

Grading

TBD

42.SP-1 - Maintain Storage System

  • Reward: $300
  • Fiat Pool Factor: 0.1
    • Start Block: #4294800
    • End Block: #4496400

Purpose

As Giza (finally) went live last term, we need to make progress on the Storage Side!

As of block #4,307,237, the status is:

  • 10/11 workers has been assigned, and accepted, buckets
  • 7/10 buckets have set their metadata
  • 6/10 of said nodes are running
  • 1/10 (Jsgenesis operated) buckets accepts new bags
  • 2/10 has a non-trivial amount of data

Scope of Work

  1. All workers, that are still "employed" at each blockheight, has a bucket, is operational, and has been assigned at least 1 bag at block #:
  • 4323600 (full score)
  • 4338000 (2/3rd score)
  • 4352400 (1/3rd score)
  1. All bags are stored by at least 3 different buckets/operators (Jsg node excluded), at least 2/3 of buckets are accepting new bags, all new bags are configured to be held by three different buckets/operators, at block #:
  • 4338000 (full score)
  • 4352400 (2/3rd score)
  • 4366800 (1/3rd score)
  1. The limits for all buckets that is accepting new bags, and the global limits have an excess capacity that allows for:
  • the same growth in objects and size, as the previous 7 days combined; AND
  • 200GB
  • 1000
  • 4338000 (full score)
  • 4352400 (2/3rd score)
  • 4366800 (1/3rd score)
  1. For the duration of the Term, have less than 1/50 uploads fail (not accepted). If a bucket has two or more failed uploads in a row, stop it from accepting new bags within 12h, and test it.

  2. For each of these:

  • keep a log of the status, and share a TL;DR update every day (starting from #4323600)
  • record ALL transactions you as the Lead does, including blockheights and purpose (for moving bags, just do did x across blocks[a,b])
  • share the thoughts behind your actions

Grading

TBD

42.OP-1 - Frontend Onboarding

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

Purpose

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

Scope of Work

  1. As far as we know, the work is underway. Pay is $30
  2. Report on the progress.

42.CC-1 - Re-set Featured Content

  • Reward: $125
  • Fiat Pool Factor: 0
    • Start Block: #4294800
    • End Block: #4496400

Purpose

After the upgrade, all the featured content was lost.

For addressing this, using the "old" and the "new" query-node is needed.

Scope of Work

  1. Use the resources above, alongside the "old" featured categories content database, to get a new database that includes all the videos that was migrated.

  2. Use the results from 1. to set featured categories content again.

  3. Set the on-chain content:setFeaturedVideos again.

Grading

TBD

KPI 41

  • KPIs: 12+9
  • Total Possible Rewards: $2150+$1580
  • Max Fiat Pool Difference: $10
  • Council Elected in Round: 43
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #4194000 / 27.01.22
    • End Block/Date: #4294800 / 02.02.22
  • Deadline to Submit Summary: #4323600 / 04.02.22

Notes

Runtime upgrade completed on block 4191207!

Note that this will hopefully be the last (full) round of KPIs, before the new incentives go live!

Grading

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 117 4742104
644 lkskrn 8 324246
2141 plycho 1 40531
515 l1dev 109 4417858
2098 0x2bc 12 486370
2096 svasilenko 215 8714123
2531 nanapa6otaet 161 6525460
1962 nkhlghbl 0 0
321 freakstatic_council 60 2431848
957 leet_joy 190 7700853
2532 swargo 13 526900
3029 oxygen 15 607962
2 tomato 310 12564550
2137 kalpakci 15 607962
3254 roksolana 2 81062
2329 laura 2 81062
2836 art_khabibullin 110 4458389
1048 igrex 17 689024
2435 zazik 4 162123
2182 isonar 12 486370
SUM 20 2196 55648797

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 183 7417138
644 lkskrn 390 15807015
3029 oxygen 250 10132702

Paid out (LATE!!!!) on blocks: #4,794,898 and #4,794,899.

Section I - Council work, Proposals and Bureaucracy

41.I-1 - Proposal Clearance

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

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 72 17
644 lkskrn 11 33 8
2141 plycho 3 6 1
515 l1dev 15 39 9
2098 0x2bc 17 51 12
2096 svasilenko 23 66 15
2531 nanapa6otaet 18 48 11
1962 nkhlghbl 0 0 0
321 freakstatic_council 15 45 10
957 leet_joy 21 63 15
2532 swargo 19 57 13
3029 oxygen 24 66 15
2 tomato 16 45 10
2137 kalpakci 23 66 15
3254 roksolana 3 9 2
2329 laura 5 9 2
2836 art_khabibullin 16 42 10
1048 igrex 26 72 17
2435 zazik 7 18 4
2182 isonar 18 51 12
SUM 20 341 858 200

41.I-2 - Council Secretary

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

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

  • @tomato - $300

41.I-3 - Deputy Council Secretary

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

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

41.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

  • @l1dev - $100

41.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

41.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

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

Grading

41.II-2 - Create new KPIs

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

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

  • None granted

41.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

41.II-4 - Review Helpdesk

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

Purpose

Althoug helpdesk as a concept will disappear soon, most of the information (the applicable parts), will be copied to a new resource location. So let's get it right!

Scope of Work

  1. Review the main README.md guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the proposals guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the validators guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.

Reward Distribution

NA

Grading

Section III - Working Groups

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

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

Purpose

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

Scope of Work

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

Reward Distribution

1/2 $50

Grading

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

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

Purpose

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

Scope of Work

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

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

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

Reward Distribution

1-3: $50

Grading

Section IV - Bounties

41.IV-1 - Review Bounties

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

TBA

Working Group KPIs

41.DT-1 - Get Distributor Group Started

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

Purpose

As Giza (finally) went live), we need to ensure the transition goes over as smoothly as possible!

As there won't (yet) be a real Lead for the role, the three members the community proposed art_khabibullin, maxlevush and razumv was hired as workers, alongside ourselves, to run nodes. They will be given the role key of the Lead to make the transaction needed, once they have their nodes up and running.

Scope of Work

  1. Have your nodes operational, and ready to serve conten. Once they are, ping @bwhm#6514 on discord, to receive the lead key, and set your bucket as distributing. Must be done within block #4212000.

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

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

This will be a hard one, but do your best! Note that to qualify (3. only), you must:

  • When a/the proposal to hire a distributor lead, you must apply.
  • The work must be submitted within 12h after a proposal to start the review period of opening has been created, and the work must be linked to as a reply to said proposal.

Reward Distribution

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

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

Grading

  • No work submitted, no rewards

41.DT-2 - Maintain Distributor System

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

TBA

41.DT-3 - Review and Improve Documentation

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

Purpose

The guides on helpdesk needs improvements. Wait for #114 is approved.

Scope of Work

  1. Review the Workers guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the Lead guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.

Grading

  • No work submitted, no rewards

41.SP-1 - Maintain Storage System

  • Reward: $300
  • Fiat Pool Factor: 0
    • Start Block: #4194000
    • End Block: #4395600

Purpose

As Giza (finally) went live), we need to ensure the transition goes over as smoothly as possible!

Scope of Work

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

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

  1. Starting from block #4212000, Jsgenesis will check which SPs are up. We expect (excluding Worker ID 10):
  • #4212000: > 40%
  • #4226400: > 80%
  • #4240800: > 100%
    • The Lead is free to fire to keep this ratio (firing 19 would be smart :D)

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

  1. Keep the amount of (independent) failed uploads below 10

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

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

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

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

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

Grading

  • No work submitted, no rewards

41.SP-2 - Review and Improve Documentation

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

Purpose

The guides on helpdesk needs improvements. Wait for #114 is approved.

Scope of Work

  1. Review the Workers guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the Lead guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.

Grading

  • No work submitted, no rewards

41.OP-1 - Frontend Onboarding

  • Reward: $30
  • Fiat Pool Factor: 0
    • Start Block: #4194000
    • End Block: #4597200

Purpose

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

Scope of Work

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

Grading

41.OP-2 - Review and Improve Documentation

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #4194000
    • End Block: #4395600

Purpose

The guides on helpdesk needs improvements. Wait for #114 is approved.

Scope of Work

  1. Review the (outdated) CLI guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Review the Query Node guide, and create a PR that:
  • includes any requested changes.
  • adds anything you see is missing.
  • outlines what you would want to know that isn't there.
  1. Assist the SP and DT Leads with their Review and Improve Documentation KPIs.

Grading

41.CC-1 - Finalizing Content Migration

  • Reward: $125
  • Fiat Pool Factor: 0
    • Start Block: #4194000
    • End Block: #4395600

Purpose

After the upgrade, we migrated a lot of the content from sumer over to giza. This means some follow up work is required.

Based on our own, and the community input, the channels that was migrated (including all videos) is available in thi issue.

For addressing both this, and the [KPI 41.CC-2][#41.CC-2], using the "old" and the "new" query-node is needed.

Scope of Work

  1. Find out if all of the following was in fact migrated as we inteded, or if something was missing:
  • channels
  • videos
    • the migrations says yes for both, but double check wouldn't hurt
  • assets
    • some nuances here: How many ACCEPTED (ignore PENDING/REJECTED) data objects were there in total stored under these channels? How many bytes in total? We know the exact amounts migrated.

For 1. Share the queries and scripts used to get the data.

  1. Were there any censored channels or videos that made it into the migration? If yes, re-evaluate, and censor again if needed.

  2. Are there any channels or videos that wasn't attempted migrated, but should have been? Make a channel on discord, and a forum thread where users can post what they are missing. Review what is being requested, and share the results.

Grading

41.CC-2 - Re-set Featured Content

  • Reward: $125
  • Fiat Pool Factor: 0
    • Start Block: #4194000
    • End Block: #4395600

Purpose

After the upgrade, all the featured content was lost.

See also purpose [KPI 41.CC-2][#41.CC-2].

Scope of Work

  1. Use the resources above, alongside the "old" featured categories content database, to get a new database that includes all the videos that was migrated.

  2. Use the results from 1. to set featured categories content again.

  3. Set the on-chain content:setFeaturedVideos again.

Grading

KPI 40

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

Notes

Runtime upgrade incoming!

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 315 12913374
2502 adovrn 16 655917
1541 godshunter 11 450943
644 lkskrn 8 327959
2141 plycho 4 163979
2574 alexznet 7 286964
2531 nanapa6otaet 161 6600169
1962 nkhlghbl 3 122985
321 freakstatic_council 262 10740648
957 leet_joy 214 8772896
3029 oxygen 164 6723154
2462 chiffah 6 245969
2137 kalpakci 11 450943
506 niocris 4 163979
1997 marinag_mary 10 409948
2329 laura 152 6231216
3234 jen4ph 62 2541680
2182 isonar 9 368954
2154 marat_mu 11 450943
1986 goldmember 62 2541680
SUM 20 2152 61164300

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
515 l1dev 300 12298452
644 lkskrn 360 14758142

Payouts on blocks #: 4,468,336, 4,468,337 & 4,468,352.

Fiat factor results: + $10

Section I - Council work, Proposals and Bureaucracy

40.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
2194 ilich 30 84 15
2502 adovrn 33 93 16
1541 godshunter 21 60 11
644 lkskrn 16 48 8
2141 plycho 7 21 4
2574 alexznet 13 39 7
2531 nanapa6otaet 25 60 11
1962 nkhlghbl 5 15 3
321 freakstatic_council 23 66 12
957 leet_joy 30 81 14
3029 oxygen 29 78 14
2462 chiffah 14 33 6
2137 kalpakci 24 63 11
506 niocris 8 24 4
1997 marinag_mary 20 54 10
2329 laura 25 66 12
3234 jen4ph 22 66 12
2182 isonar 20 51 9
2154 marat_mu 23 63 11
1986 goldmember 25 66 12
SUM 20 459 1131 200

40.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

40.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

40.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

40.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

40.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

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

Grading

40.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

40.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

  • @laura - $140
  • @leet_joy - $200
    • https://pioneer.joystreamstats.live/#/forum/threads/917?page=2&replyIdx=13
      • https://play.joystream.org/video/14442
      • https://testnet.joystream.org/#/forum/threads/924
        • Interesting discussion with a FM, the new WG leads, control of the council & votes, whether the council or JSG should decide who the leads are, the upcoming council side reduction to 5 (and the impacts of this, it might be too biased), possible better council size numbers, the time it takes for proposals to be voted on, a recent proposal by @l1dev about the number of FMs, payments for content creators during the testnet, the importance of motivating new users well, the purpose of the Marketing WG and whether it is necessary to have it with the current product, the quality of participants since recent FM financial announcements, referrals with the new incentives program, the other new WGs and what the number of workers might be, the quality of the current Operations Development lead and how long it would take a new participant to learn this specific role, the value of having deputies, the importance of communication, solving disputes, people getting disinterested from the project due to a variety of reasons at the moment.

Section III - Working Groups

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

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

Purpose

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

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

Scope of Work

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

Reward Distribution

1/2 $50

Grading

  • No work submitted, no rewards

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

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

Purpose

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

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

Scope of Work

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

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

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

Reward Distribution

1-3: $50

Grading

Section IV - Bounties

40.IV-1 - Bounty Managers

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

Not clear if completed

Purpose

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

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

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

Some general information can be found here.

Scope of Work

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

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

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

Reward Distribution

Weighting:

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

Grading

  • No work submitted, no rewards

Working Group KPIs

40.SP-1 - Maintain Storage System

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

Purpose

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

Scope of Work

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

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

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

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

  1. Keep the amount of failed uploads below 10

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

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

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

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

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

Grading

  • No work submitted, no rewards

40.DT-2 - Maintain Distributor System

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

Purpose

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

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

Scope of Work

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

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

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

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

Reward Distribution

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

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

Grading

  • No work submitted, no rewards

40.OP-1 - Frontend Onboarding

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

Purpose

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

Scope of Work

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

Grading

40.OP-2 - Community Repo

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

Purpose

With a new runtime comes new types!

Scope of Work

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

Grading

40.CC-1 - Finalizing Content Migration

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

Purpose

  • Never announced

KPI 39

  • KPIs: 12+3
  • Total Possible Rewards: $2250+$330
  • Max Fiat Pool Difference: $105
  • Council Elected in Round: 41
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3992400 / 12.01.22
    • End Block/Date: #4093200 / 19.01.22
  • Deadline to Submit Summary: #4122000 / 21.01.22

Notes

Due to illness last week, the upgrade was delayed. We expect it go through some time next, hopefully on the 20th, but no guarantees...

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 91 3541123
644 lkskrn 10 389134
2141 plycho 7 272394
1843 spat_sochi 8 311308
2531 nanapa6otaet 159 6187237
1962 nkhlghbl 5 194567
2988 sevenup 14 544788
321 freakstatic_council 11 428048
957 leet_joy 160 6226151
3029 oxygen 115 4475046
2462 chiffah 14 544788
2 tomato 303 11790773
2137 kalpakci 13 505875
3254 roksolana 109 4241565
2329 laura 179 6965506
2836 art_khabibullin 29 1128490
1048 igrex 168 6537458
2148 controlla 8 311308
2182 isonar 9 350221
2154 marat_mu 167 6498545
SUM 20 1579 61444325

WGs
NA

Payouts done on blocks #4,254,794 and #4,254,795.

Fiat pool growth: -USD 20

Section I - Council work, Proposals and Bureaucracy

39.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
2194 ilich 29 94 16
644 lkskrn 22 60 10
2141 plycho 12 45 7
1843 spat_sochi 16 49 8
2531 nanapa6otaet 19 57 9
1962 nkhlghbl 11 32 5
2988 sevenup 24 84 14
321 freakstatic_council 23 66 11
957 leet_joy 18 63 10
3029 oxygen 25 89 15
2462 chiffah 27 86 14
2 tomato 6 17 3
2137 kalpakci 24 78 13
3254 roksolana 15 56 9
2329 laura 15 53 9
2836 art_khabibullin 8 23 4
1048 igrex 28 106 18
2148 controlla 14 50 8
2182 isonar 15 55 9
2154 marat_mu 15 45 7
SUM 20 366 1208 200

39.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

39.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

39.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

  • Usually this KPI is not claimed by multiple people, the grading is based on the time of submitted reports.
  • @ilich - $75
  • @art_khabibullin - $25

39.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

39.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

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

Grading

39.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

  • No work submitted, no rewards.

39.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

39.II-4 - Investigate Validators - Part II

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

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

39.II-5 - Content Migration for Giza

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

Real (:D) Final Call

Purpose

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

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

Scope of Work

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

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

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

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

Grading

Completed in 38.

39.II-6 - User Friendly API Guides

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

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

Purpose

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

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

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

Scope of Work

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

Reward Distribution

1-3 $60 each
4 $120

Grading

Completed in 38

Section III - Working Groups

Section IV - Bounties

39.IV-1 - Bounty Managers

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

Purpose

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

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

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

Some general information can be found here.

Scope of Work

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

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

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

Reward Distribution

Weighting:

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

Grading

Working Group KPIs

39.CC-1 - Content Migration

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

Purpose

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

Scope of Work

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

Grading

TBD

Grading

TBD

39.SP-1 - Content Directory Status

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

Purpose

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

Hint: Requires using the query node playground.

Scope of Work

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

Grading

Completed in 38

39.OP-1 - Frontend Onboarding

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

Purpose

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

Scope of Work

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

Grading

KPI 38

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

Notes

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

Note That didn't happen ofc :(

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 95 3612706
644 lkskrn 8 304228
2141 plycho 7 266199
605 okayko 7 266199
635 xfactorus 15 570427
2531 nanapa6otaet 5 190142
1962 nkhlghbl 9 342256
2988 sevenup 17 646484
321 freakstatic_council 10 380285
957 leet_joy 101 3840877
3029 oxygen 439 16694504
1345 kadyrovs 160 6084557
2462 chiffah 76 2890165
2 tomato 302 11484602
2329 laura 161 6122586
319 sparky 0 0
1048 igrex 166 6312728
2435 zazik 90 3422563
2182 isonar 3 114085
2154 marat_mu 331 12587428
SUM 20 2462 76133021

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
3029 oxygen 200 7605697
515 l1dev 260 9887406

Payouts done on blocks #4,203,530 and  #4,203,531. Fiat pool factor: +$165.

Section I - Council work, Proposals and Bureaucracy

38.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

Member ID Member Handle Voted Points Reward
2194 ilich 28 107 15
644 lkskrn 16 58 8
2141 plycho 13 51 7
605 okayko 13 52 7
635 xfactorus 29 110 15
2531 nanapa6otaet 10 34 5
1962 nkhlghbl 17 62 9
2988 sevenup 30 123 17
321 freakstatic_council 19 70 10
957 leet_joy 19 75 11
3029 oxygen 28 109 15
1345 kadyrovs 17 74 10
2462 chiffah 29 115 16
2 tomato 5 17 2
2329 laura 21 79 11
319 sparky 0 0 0
1048 igrex 29 117 16
2435 zazik 18 68 10
2182 isonar 6 24 3
2154 marat_mu 20 77 11
SUM 20 367 1422 200

38.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

  • @tomato - $300

38.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

38.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

38.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

38.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Notes

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

Grading

38.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

  • No work done

38.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

38.II-4 - Investigate Validators - Part I

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

Still not clear if (fully) done
Final Call

Purpose

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

Note Based on proposal #881.

Scope of Work

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

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

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

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

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

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

Reward Distribution

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

Grading

38.II-5 - Investigate Validators - Part II

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

TBD
Awaiting results of Part I

38.II-6 - Content Migration for Giza

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

Final Call

Purpose

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

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

Scope of Work

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

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

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

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

Grading

38.II-7 - User Friendly API Guides

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

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

Purpose

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

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

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

Scope of Work

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

Reward Distribution

1-3 $60 each
4 $120

Grading

  • @l1dev - $260
    • https://testnet.joystream.org/#/forum/threads/870?replyIdx=9
    • SOW 1: Complete - $60
    • SOW 2: Complete - $60
      • There was one minor mistake
        • If the handle is known: members.membershipById should rather refer to members.memberIdByHandle
      • Did not include a way to check "How much a worked has staked by workerId"
    • SOW 3: Partially complete - $50
      • Although it did not cover the exact examples provided, it included enough basic information for a user to get started.
    • SOW 4: Partially complete - $90
      • It did not include How to create a new "Council Tokenomics" report step-by-step

Section III - Working Groups

38.III-1 - New Working Groups

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

Purpose

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

Three new Working Groups will be created:

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

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

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

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

Scope of Work

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

Reward Distribution

Weighting:

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

Grading

38.III-2 - Existing Working Groups - Storage

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

Purpose

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

Scope of Work

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

Reward Distribution

Weighting:

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

Grading

38.III-3 - Existing Working Groups - Curators

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

Purpose

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

Scope of Work

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

Reward Distribution

Weighting:

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

Grading

38.III-4 - Existing Working Groups - Operations

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

Purpose

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

Scope of Work

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

Reward Distribution

Weighting:

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

Grading

Section IV - Bounties

38.IV-1 - Bounty Managers

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

Purpose

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

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

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

Some general information can be found here.

Scope of Work

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

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

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

Reward Distribution

Weighting:

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

Grading

  • No work submitted, no rewards.

Working Group KPIs

38.CC-1 - Content Migration

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

Purpose

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

Scope of Work

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

Grading

38.SP-1 - Content Directory Status

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

Purpose

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

Hint: Requires using the query node playground.

Scope of Work

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

Grading

  • No work submitted, no rewards.

38.OP-1 - Giza Testing - Final Round

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

Note
We will finish this soon finally :)

Purpose

Ensure the new network works!
$25/h

Grading

KPI 37

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

Notes

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

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

Grading

CMs

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

WGs

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

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

Fiat pool growth: -$22.5.

Section I - Council work, Proposals and Bureaucracy

37.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

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

37.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

37.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

37.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

37.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

37.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

37.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

  • No work submitted, no rewards.

37.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

37.II-4 - Investigate Validators - Part I

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

Still not clear if (fully) done

Purpose

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

Note Based on proposal #881.

Scope of Work

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

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

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

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

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

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

Reward Distribution

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

Grading

  • No work submitted, no rewards.

37.II-5 - Investigate Validators - Part II

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

TBD
Awaiting results of Part I

37.II-6 - Content Migration for Giza

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

Purpose

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

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

Scope of Work

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

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

Reward Distribution

Individual grading, but collaboration is encouraged.

Weighting:

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

Grading

  • No work submitted, no rewards.

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

37.CC-1 - Update Featured Categories

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

Purpose

Scope of Work

Reward Distribution

Grading

37.CC-2 - Update Featured Videos

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

Purpose

Scope of Work

Reward Distribution

Grading

37.CC-3 - Content Migration

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

Purpose

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

Scope of Work

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

Grading

  • No work submitted, no rewards.

37.SP-1 - Content Directory Status

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

Purpose

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

Hint: Requires using the query node playground.

Scope of Work

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

Grading

  • No work submitted, no rewards.

37.OP-1 - Giza Testing - restarting

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

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

Purpose

Ensure the new network works!

Scope of Work

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

Grading

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

KPI 36

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

Notes

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

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

Grading

CMs

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

WGs

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

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

Fiat pool factor +$17.55.

Section I - Council work, Proposals and Bureaucracy

36.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

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

36.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

36.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

36.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

36.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

36.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

36.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

36.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

36.II-4 - Investigate Validators - Part I

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

Not clear if done

Purpose

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

Note Based on proposal #881.

Scope of Work

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

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

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

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

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

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

Reward Distribution

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

Grading

36.II-5 - Investigate Validators - Part II

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

TBD
Awaiting results of Part I

36.II-6 - Community Cohesion

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

Open for all CMs

Purpose

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

Scope of Work

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

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

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

Reward Distribution

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

Grading

Section III - Working Groups

Section IV - Bounties

Working Group KPIs

36.CC-1 - Update Featured Categories

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

36.CC-2 - Update Featured Videos

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

TBD

36.OP-1 - Giza Testing - restarting

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

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

Purpose

Ensure the new network works!

Scope of Work

New testing notes/setup TBD.

Grading

NA

KPI 35

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

Grading

CMs

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

WGs

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

Payouts made on blocks #3,784,223.

The fiat pool shrank by $12.45.

Section I - Council work, Proposals and Bureaucracy

35.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

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

35.I-2 - Council Secretary

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

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

35.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

35.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

35.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

35.II-1 - Discord Channel Management

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

Purpose

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

We are making some small changes to this one!

Scope of Work

For each of the above groups:

  1. Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!
  2. Instead of having the individual CMs adding their contributions to the Term Summary, the KPI Manager will propose a reward distribution in said Term Summary.

Reward Distribution

Grading is individual.

Grading

35.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

35.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

Grading

35.II-4 - Investigate Validators - Part I

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

Purpose

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

Note Based on proposal #881.

Scope of Work

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

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

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

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

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

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

Reward Distribution

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

Grading

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

35.II-5 - Community Call #4

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

Purpose

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

Scope of Work

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

Grading

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

Section III - Working Groups

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

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

Not clear if done or not...

Purpose

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

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

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

Scope of Work

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

For 1 and 2:

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

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

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

For all:
Disregard workerId 19 (no metadata).

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

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

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

Reward Distribution

Weighting:

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

Grading

  • This was already completed and graded within KPI 34

Section IV - Bounties

Working Group KPIs

35.CC-1 - Update Featured Categories

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

  • No work submitted, no rewards.

35.CC-2 - Update Featured Videos

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

  • No work submitted, no rewards.

35.OP-1 - Fix Opening Rendering

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

Purpose

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

Hopefully, the same is true for the Openings!

Scope of Work

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

Grading

  • This was already completed in a previous term

35.OP-2 - Giza Testing - restarting

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

Purpose

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

Scope of Work

Scope will be added in time.

Grading

:(

35.OP-3 - Runtime Upgrade Test

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

Purpose

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

A technical guide can be found in this issue.

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

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

Scope of Work

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

Grading

KPI 34

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

Notes

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

Grading

CMs

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

WGs

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

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

Fiat pool increased by $15.

Section I - Council work, Proposals and Bureaucracy

34.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

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

34.I-2 - Council Secretary

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

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

34.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

34.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

34.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

Section II - Community Management

34.II-1 - Discord & Telegram Channel Management

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

Purpose

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

Note

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

Scope of Work

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

Reward Distribution

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

Grading is individual.

Grading

34.II-2 - Create new KPIs

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

Purpose

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

Scope of Work

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

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

Reward Distribution

All CMs and WG Leads can contribute.

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

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

Grading

34.II-3 - Council Term Summary Videos

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

Purpose

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

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

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

Scope of Work

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

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

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

Note

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

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

Reward Distribution

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

Weighting:

  1. $200

34.II-4 - Community Call #4

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

Purpose

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

Scope of Work

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

Grading

Section III - Working Groups

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

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

Purpose

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

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

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

Scope of Work

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

For 1 and 2:

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

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

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

For all:
Disregard workerId 19 (no metadata).

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

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

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

Reward Distribution

Weighting:

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

Grading

Section IV - Bounties

Working Group KPIs

34.CC-1 - Update Featured Categories

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

34.CC-2 - Update Featured Videos

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

Purpose

We want to change these every day!

Scope of Work

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

Grading

34.OP-1 - Fix Opening Rendering

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

Purpose

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

Hopefully, the same is true for the Openings!

Scope of Work

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

Grading

  • Done, graded last term.

34.OP-2 - Giza Testing - Restarting

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

Purpose

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

Scope of Work

Scope will be added in time.

Grading

  • No scope included/TBA

34.OP-3 - Runtime Upgrade Test

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

Purpose

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

A technical guide can be found in this issue.

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

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

Scope of Work

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

Grading

KPI 33

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

Grading

CMs

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

WGs

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

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

The fiat pool shrank by $67.

Section I - Council work, Proposals and Bureaucracy

33.I-1 - Proposal Clearance

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

Purpose

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

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

Scope of Work

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

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

Without going in too much detail:

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

Reward Distribution

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

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

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

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

Grading

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

33.I-2 - Council Secretary

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

Purpose

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

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

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

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

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

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

Reward Distribution

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

Grading

33.I-3 - Deputy Council Secretary

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

Purpose

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

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

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

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

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

Reward Distribution

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

Grading

33.I-4 - Council Minutes

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

Purpose

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

Scope of Work

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

Previous Council reports can be used as a guideline.

Reward Distribution

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

Grading

33.I-5 - KPI Manager

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

Purpose

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

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

Scope of Work

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

Reward Distribution

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

Grading

33.I-6 - Council Insight

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

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

33.I-7 - Review New Incentives Draft

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end - 4 days
    • Start Block: #3328000
    • End Block: #3430800

Over time, the KPI scheme has seen many iterations. We think it's gotten better over time, but as many of you have pointed out, and we are fully aware of, there are still quite a few flaws. With the growth in participation and activity, this is becoming more and more of a problem.

The new system will attempt to get us closer to this "world", provide more opportunities for everyone, not just CMs, to learn about the system and/or perform valuable JOYtasks for the platform, while earning FM points and some fiat along the way.

A draft of a new system (which may have nothing in common with what we end up doing), is roughly outlined here.
Note that this is very much a WIP, and the draft may be updated "in flight".

Note
SoW 1 and 2 is presumably done, so only 3 is remaining. Unless you already started, you probably shouldn't ask for this one...

Scope of Work

  1. For each CM, review the draft, and write a short summary of your thoughts, questions and comments. Share this with the KPI Manager, or, whoever the KPI Manager "assigns" the (rest of the) KPI to.
  2. Generate some feedback from the Community at large, and the Leads (especially) and Workers (preferably) in each WG. Here, it's enough if they review their "own" WG and the "JOYtask Participant" section. Feel free to create a survey, and even a Q&A to establish whether they actually read it :)
  3. Gather all the results in a single document, where:
  • Each persons feedback is included, with (either) their Handle/Member Id/Role, or only their role (if any).
  • An overview containing the most common (objectively) or the most valuable (subjectively) feedback.
  • Create a "payout" list based in line with * below (memberId,accountId,role,dollarAmount).
    Share the feedback summary with me, either as a comment to the gist, an issue/PR to the Community Repo, or in discord.

Reward Distribution

Weighting

  1. Everyone on the Council* gets $20. Capped at $100.
  2. The Leads all get $10, Workers all get $5.* Capped at $100.
  • Top 5 "valuable" comments gets $20 each
  1. $150 (including organizing 2)
    * Only applies if there is any feedback. We won't set a min_text_length constraint, but comments like "it looks good!" won't receive any rewards.

Grading is individual.

Grading

Section II - Community Management

33.II-1 - Discord & Telegram Channel Management

  • Reward: $75
    • #validator
    • #storage-provider
    • #content-curator
    • #content-creator
    • #tech-support
    • #council
    • #proposal
    • #bounties
    • #general
    • #welcome
    • #introduce-yourself
    • #faucet
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

33.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

33.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3488400
    • End Block: #3618000

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

33.II-4 - Council Term Summary Video Reviews

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 2 days
    • Start Block: #3488400
    • End Block: #3618000

Purpose

The "Council Term Summary Videos" KPI has been running since round #23. How are they working? Who is consuming them? How can they be approved?

Scope of Work

  1. Watch all the videos that's been made, with an emphasis on the later ones. Before you proceed to SoW #2, dm me:
  • What is good?
  • What is not good?
  • What would you like them to include, but is missing?
  1. Part of the SOW when making these videos, was to get feedback using the forum. To save some time, open the current and old KPI pages, search the page for all the KPIs of this kind, and find the forum posts (if made, they can be found in the linked term summaries in the grading).
  • Create a document with a link to all videos and the forum feedback page.
  • For all videos, grouped by the same creator(s) and parse the feedback.
    • What is the most frequent sort of feedback?
    • Having (re-)watched the videos, was any of the feedback "fixed" in future videos?
    • Does any of the feedback strike a chord with you - meaning: "I should have written that"? If so, what is it?
  1. Engage the community, and ask them:
  • Do you like the concept of "Term Summary Videos"?
  • If yes:
    • What do you think they should contain/hightlight?
    • How long should they be?
    • Who should be part?
  • If no:
    • Are there any other Community driven "News" series that you'd want instead?

Reward Distribution

Weighting:

  1. 100
  2. 100
  3. 100

Grading

33.II-5 - Community Call 1 Subtitles

  • Reward: $100
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3387600
    • End Block: #3488400

Purpose

Ref KPI 32.II-4 - only SoW #5 remains.

Scope of Work

  1. Create russian subtitles for the video from from SoW #4 of the "old" KPI, using the .srt, or other "widespread" format.

Reward Distribution

NA

Grading

33.II-6 - Pay the Community Rewards for the Maze Test

  • Reward: $175
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term - 4 days
    • Start Block: #3387600
    • End Block: #3430800

Purpose

We got plenty of responses - now is the time to pay them back!

Scope of Work

  1. Once assigned by the KPI manager, DM me (@bwhm#6514) on Discord, to get the incomplete* payout list. Pay each of them in tJOY, and after getting re-imbursed, pocket $25.

Reward Distribution

If you round down too much (eg. verifiable complaints re exchange rate), you will not get re-imbursed!

Grading

  • unclaimed

Section III - Working Groups

33.III-1 - Follow up the Storage Working Group

  • Reward: $300
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

Our dear leader Bedeho, has pointed out that playing some videos from Atlas is rather slow at the moment. We need to know which ones.

For all tasks, use the Hydra Playground, with the following query:

query {
  videos (limit:1000000, orderBy:createdAt_DESC){
    id
    title
    updatedAt
    createdAt
    createdInBlock
    mediaDataObject {
      joystreamContentId
      liaisonJudgement
      ipfsContentId
      liaison {
        workerId
        metadata
        isActive
      }
    }
  }
}

Scope of Work

  1. Does all nodes have what they should have?
  2. How fast is downloading an asset from each worker?
  3. Get liaison statistics for all the workers, and parse the data.
Hints

For 1 and 2:

  • Get all the active workers. (using pioneer OR the QN), so you have their workerId and the worker metadata (URL).
  • Take 6 different assets (eg. their joystreamContentId), chosen pseudorandomly.
    • Avoid a very small one (say <20MB)
    • Two of the "oldest"
    • Two of the "newest"
    • Two in the "middle"
  • For each metadata and each joystreamContentId, either paste <metadata>/asset/v0/<joystreamContentId> in the browser, and "save video", or better yet: wget <metadata>/asset/v0/<joystreamContentId>.
    Log the following:
  • videoId/joystreamContentId
  • workerMetadata
  • Did they have the file?
  • Download speed
  • Download time
  • Ping (between you and the SP)
    Make sure you only do one at the time! wget + a script will make this rather easy :)

For 3:
Export the data, and make a script that displays how many times each SP was the liaison for a video. Not all Storage Providers has been active the entire time, meaning they can't have been able to receive the same amount of uploads, simply for that reason. Create some more datasets, where you only include videos that was uploaded after:

  1. The last time an active SP was created
  2. The last time an active SP was updated
  3. The first time all active liaisons had been a liaison at least once.
    If one of those happened within the last 2 weeks, use the second to last (first for 3) instead.

For all:
Disregard workerId 19 (no metadata).

Lots of info can be found using the wonderful joystreamstats. storage page. Here however, you need to perform your own checks first.

  1. Compare (where applicable) to the data in the aforementioned joystreamstats.
  2. What does this mean?

The deliverable is not a pure dump of data, but:
1-2: A single spreadsheet or markdown table showing both the individual results, a sum (for each provider), an average (for all providers), and distance from the average (for each provider).
3: Are there any SPs that appear to never be liaisons, or has long stretches where they were active, but didn't? Which ones, and in what range?
Get a list of all instances of a video where "liaisonJudgement": "PENDING",, and for each case a Worker appears to not have been a liaison, provide relevant timestamps where the video is PENDING.
4. Eg. If one or more providers appears to have been slow to download from, is that corroborated by the data in joystreamstats? Could it have been latency, or just "bad luck"?
5. Should the Storage Lead take action towards a Worker? Should the Council take action towards the Lead?

Reward Distribution

Weighting:

  1. $50
  2. $100
  3. $100
  4. $25
  5. $25

Grading

33.III-2 - Follow up the Curator Working Group

  • Reward: $50
  • Fiat Pool Factor: 1.0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3394800
    • End Block: #3481200

Purpose

The Curator Group is getting plenty of recurring tasks in this KPI. Assist, and make sure they succeed!

(No Curators can get rewarded for this task.)

Scope of Work

  1. Check in on them on a daily basis and report their progress to the Council. If they have any issues, make sure these are dealt with.

Reward Distribution

NA

Grading

Section IV - Bounties

Working Group KPIs

33.CC-1 - Update Featured Video Hero

  • Reward: $150
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

This should be replaced pretty regularly, and it's been a while since the last time!

We want to start changing these every day!
Feel free to look for information in the joystream or atlas repos (especially #4).

Scope of Work

  1. In line with the process established in a previous KPI, propose 2 or 3 alternatives for the featured video to Jsgenesis. The proposal should be the finished json with all data required.
  2. We want to start updating these on a daily basis. Create a catalogue of 5 videos (not used before), and 5 videos (re-use allowed).
  3. Come up with an estimate how many videos would be "good enough" for this already,
  4. Write step by step guide on all the actions needed, with examples, on how to "Update Featured Video Hero". Publish it to the Community Repo.

Reward Distribution

  1. $30
    2-4. $120 (combined. All must be completed!)

Grading

33.CC-2 - Update Featured Categories

  • Reward: $280
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

We want to start changing these every day!

Note that tomato is likely needed for this task. The CC Lead decides how much of the reward they should earn. Some inspiration for the future can be found here. Feel free to look for information in the joystream or atlas repos.

Scope of Work

  1. Come up with a routine to change these on a daily basis. As we can't rely on tomato being available every day, look into creating a script for this. If required, ask the Operations group for assistance.
  2. There are currently 12 videos (with 3 clips) in each category, and 9 more video clips created (but not uploaded). Assuming we want a new top video for each category every day, it's currently possible to have 12 (11 left) permutations without finding more videos. Example for category 1:
  • Day 1: [[0,1,2],[3-11]]
  • Day 2: [[3,4,5],[0-2,6-11]]
  • ...
  • Day 5: [[1,3,6],[0,2,4,5,7-11]]
    Create a schedule for the next 12 days.
  1. Deploy the script that does this. Before it's done, change them manually (must be done at least once before the next term). Make sure to run the script manaully the first few times before it's set to start automatically.
  2. Publish the script, and write step by step guide on all the actions needed, with examples, on how to "Update Featured Categories". Publish it to the Community Repo.
  3. Before block #3500800, source at least 7 more videos to each Category, and create clips.
  4. Note that we can start rotating some of the old ones back in at some point. For this reason:
  • create a database of which videos was featured when, and in what "position"
  • give each of video a single score to indicate how well it works (eg. good clip/video, and relevance to the category)

Grading

  • No work submitted, no rewards

33.CC-3 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3358800
    • End Block: #3589200

Note
Continuation of 32.CC-X

Purpose

This should be replaced pretty regularly, and it's been a while since the last time. We want to start changing these every day!

Scope of Work

  1. Change the Featured Videos on chain, using the CLI. Make sure your changes works, and that there is:
  • no overlap with the Featured Video Hero
  • no overlap with the videos with clips in Featured Categories
  • little overlap with the other (without clips) videos in Featured Categories
  1. Plan a schedule of which videos should be featured for the upcoming Term, including which Curator should make the changes. Test to make sure they have the permissions, as I don't remember whether it's Lead only, or if the Lead can delegate this with groups.

Grading

  • No work submitted, no rewards

33.OP-1 - Fix Opening Rendering

  • Reward: $100
  • Fiat Pool Factor: 0
    • Start Block: #3387600
    • End Block: #3589200

Purpose

Both the forum, and the proposals page was very slow to render. This was fixed recently, with very little effort.

Hopefully, the same is true for the Openings!

Scope of Work

  1. Make a PR to the Joystream/joystream repo, fixing the issue

Grading

33.OP-2 - Giza Testing - Restarting

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3387600
    • End Block: #3690000

Purpose

Testing will continue late this week. See KPI 32.OP-1 for more info.

Scope of Work

Scope will be added in time.

Grading

  • This KPI was never announced fully

33.OP-3 - Runtime Upgrade Test

  • Reward: $250
  • Fiat Pool Factor: 0
    • Start Block: #3428000
    • End Block: #3790800

Purpose

Among other things, we want to adjust the Validator Staking Rewards through a runtime upgrade. We did this with the Constantinople runtime upgrade, so we know it was "safe" on previous versions of substrate. Let's confirm it works on this version as well, alongside some other changes.

A technical guide can be found in this issue.

Note
The deliverable will be graded very strictly. This may seem unfair if you do all the work and get a low reward, but the work will be used for the next testnet. If we can't easily trust and verify your work, it has no value as we will have to do it again myself, or spend even more time to investigate.

The reason we're asking the community to test this, is simply because they will need to know to build and deploy networks for testing purposes. Although we're finalizing a tool that will take care of most the steps, you need to know the actual nitty gritty if that is to be useful instead of dangerous, and to maintain it in the future.

Scope of Work

  1. Build a runtime based on the Sumer branch. Make sure the nodes are configured so you can access, and use pioneer. (This is not really "safe" with a node that is running a validator, but for testing purposes, it should be fine).
  2. Add more stake to the validators/add more validators.
  3. Note down the EXACT stakes and issuance for a couple of eras, then change the values (sudo can create and destroy tokens with sudo.setBalance). Ideally use "easy" numbers - eg.
  • 10k/100k
  • 30k/100k
  • 50k/100k
  • 100k/100k
  • 0/100k
    The key is to test with a stake ratio lower, higher and at the ideal one.
  1. Upgrade the runtime, and re-do 3.
  2. Let the chain for a couple of days, and try to:
  • make changes to the validator set
  • add a couple more validators, then turn off two, and have them kicked out for a couple eras before restarting them
  • make some random transactions (balance, forum, content, etc.)
  1. The deliverable is a document with:
  • All steps so that it can be easily reproduced
  • All results, in table format with blockheights, issuances, stakes, stakers, actions, rewards, eraIndex, etc.

Grading

KPI 32

  • KPIs: 17+4
  • Total Possible Rewards: $3875+$505
  • Max Fiat Pool Difference: $355
  • Council Elected in Round: 34
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3286800 / 23.11.21
    • End Block/Date: #3387600 / 30.11.21
  • Deadline to Submit Summary: #3416400 / 02.12.21

KPIs:

Added on the 26th of November, 32.CC-1 - Update Featured Video Hero revised.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
1305 joystreamstats 3 105411
2194 ilich 215 7554478
644 lkskrn 4 140548
361 blackmass 11 386508
515 l1dev 54 1897404
2096 svasilenko 317 11138463
2531 nanapa6otaet 33 1159525
2697 ardashoff 162 5692212
1962 nkhlghbl 0 0
321 freakstatic_council 10 351371
3029 oxygen 153 5375978
1345 kadyrovs 43 1510896
2 tomato 314 11033052
1997 marinag_mary 208 7308519
2329 laura 430 15108957
2836 art_khabibullin 37 1300073
319 sparky 0 0
1048 igrex 191 6711188
2435 zazik 231 8116672
2154 marat_mu 150 5270566
SUM 20 3246 90161821

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 180 6324679
2098 0x2bc 125 4392139
515 l1dev 375 13176416

Payouts made on block #3,469,791. Payouts for participants of 32.I-8 - Review New Incentives Draft will be done tomorrow.

The fiat pool shrank by $5.

Section I - Council work, Proposals and Bureaucracy

32.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
1305 joystreamstats 5 20 3
2194 ilich 29 107 15
644 lkskrn 8 32 4
361 blackmass 22 82 11
515 l1dev 26 104 14
2096 svasilenko 27 99 14
2531 nanapa6otaet 14 56 8
2697 ardashoff 23 89 12
1962 nkhlghbl 0 0 0
321 freakstatic_council 18 69 10
3029 oxygen 7 25 3
1345 kadyrovs 24 95 13
2 tomato 23 101 14
1997 marinag_mary 23 90 13
2329 laura 28 110 15
2836 art_khabibullin 13 49 7
319 sparky 0 0 0
1048 igrex 31 130 18
2435 zazik 28 112 16
2154 marat_mu 19 70 10
SUM 20 368 1440 200

32.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • request Jsgenesis review for all PRs that require their attention
      • merge the PR, under the conditions that the PR:
        • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
        • does not violate any license
        • does not introduce any code users can run
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

32.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

32.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3387600
    • End Block: #3502800

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 30th "official" Council #3085200-#3186000 produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

32.I-5 - KPI Manager

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

32.I-6 - Council Insight

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

32.I-7 - Joystream Node Issues

  • Reward: $250
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Final Call:
Will not be renewed (or reviewed) if not completed by end of this term.

Purpose

A while back, we had an unfortunate event where some of our RPC and Bootnodes had gone down.
We have, and continue to, look into exactly what has happened to them, but thus far we have yet to solve the issue.

Information:

  • The nodes are running different versions. At least one was running joystream-node-5.1.0-9d9e77751.
  • The problematic seems to be #2661218, with hash 0xf5a468e133149fc094bdfa9d8842610a82fbdae10d57a4d5e980093d4691bbbc.
    • Note that this block was re-orged in (common occurance), replacing 0x7c1e11029ada770a98100f4aae3a4d4c23192343eaaf879ab57b888ae18dd841
    • Also note that it's the first block in a new era (4458)
  • One node stopped finalizing at this exact height, whereas some other continued for a little while before halting.
  • At some point, all failing nodes (that is running with --log runtime) will show:
INFO 💔 Invalid justification provided by 12D3KooWFkZZ23LoeyrpFpsDWEQwwRSWx9VaG6bwiz6jL8AE8HfS for #0x2e04…620a
  • The block in question being #2661813 with hash 0x2e04e790f04d336e2d58efb705e4773782d15041de776f755034b6355100620a
    • This happens to be the first block in a new era (4459)

Note that the "old" part 1 was completed last term.

Scope of Work

  1. Get ALL events that has to with slashing, eg. imOnline.SomeOffline, and offences.* starting from block #2000000 up until the current height. Create a dataset and chart the development of occurrences.
    (If you also get all the blocks with the event staking.payout, 3 will be significantly easier.)

  2. How many validators were there in each era, starting from #4457 up until now, and what was the set of validators? It's sufficient to check a single block in each activeEra. Provide:

  • the full validator set
  • number of validators
  • blockheight
  • era (activeEra and currentEra)
  • validator points for each era
  1. Having the data from 1 and 2, see if there is any reason to believe it implies anything "bad" happening around the problem blocks listed above.

Reward Distribution

Weighting:

  1. $100
  2. $100
  3. $50

Grading

32.I-8 - Review New Incentives Draft

  • Reward: $450
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3328000
    • End Block: #3387600

Added 26.11.21

Purpose

Over time, the KPI scheme has seen many iterations. We think it's gotten better over time, but as many of you have pointed out, and we are fully aware of, there are still quite a few flaws. With the growth in participation and activity, this is becoming more and more of a problem.

The new system will attempt to get us closer to this "world", provide more opportunities for everyone, not just CMs, to learn about the system and/or perform valuable JOYtasks for the platform, while earning FM points and some fiat along the way.

A draft of a new system (which may have nothing in common with what we end up doing), is roughly outlined here.
Note that this is very much a WIP, and the draft may be updated "in flight".

Scope of Work

  1. For each CM, review the draft, and write a short summary of your thoughts, questions and comments. Share this with the KPI Manager, or, whoever the KPI Manager "assigns" the (rest of the) KPI to.
  2. Generate some feedback from the Community at large, and the Leads (especially) and Workers (preferably) in each WG. Here, it's enough if they review their "own" WG and the "JOYtask Participant" section. Feel free to create a survey, and even a Q&A to establish whether they actually read it :)
  3. Gather all the results in a single document, where:
  • Each persons feedback is included, with (either) their Handle/Member Id/Role, or only their role (if any).
  • An overview containing the most common (objectively) or the most valuable (subjectively) feedback.
  • Create a "payout" list based in line with * below (memberId,accountId,role,dollarAmount).
    Share the feedback summary with me, either as a comment to the gist, an issue/PR to the Community Repo, or in discord.

Reward Distribution

Weighting

  1. Everyone on the Council* gets $20. Capped at $100.
  2. The Leads all get $10, Workers all get $5.* Capped at $100.
  • Top 5 "valuable" comments gets $20 each
  1. $150 (including organizing 2)
    * Only applies if there is any feedback. We won't set a min_text_length constraint, but comments like "it looks good!" won't receive any rewards.

Grading is individual.

Grading

33.I-9 - KPI Presentation - Part 2

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

There's been plenty of feedback on the rather crude way the KPI's are presented, and how it negatively impacts several aspects of the KPIs.

  • It's very hard to read and parse, scaring people away from even trying
  • There are often errors in the ToC and formatting
  • It's very hard to read and parse the results
  • The page is infinite

I'm sure I could go on, but let's instead focus on how to improve it.

Part 1 of this was mostly completed in 26.I-5 and 27.I-5. Lets finish this!

Scope of Work

  1. Go through the work, with emphasis on what to include, design briefs and wireframes in the aforementioned Part 1 (follow the links above), and provide a quick summary:
  • Does the "what to include" cover the basics needed?
  • Is the wireframe(s) and/or design brief(s) cover the above?
  • Can the best wireframe be implemented?
  1. Although not part of the Scope in Part 1, complete json files for some older KPIs was created an merged here. This would have been some of the scope for Part 2, so it'll be retroactively rewarded!

  2. Does the json in 2 contain all the data needed to work as the backend for the design? If yes, make a PR:

  • That moves the file to a reasonable place in the repo (similar to the bounty-status.json and bounties.schema.json)
  • Adds the latest KPI info in to the file
  • Create a json.schema to validate the json
  • Write basic instructions for updating the json, so that it can be done frequently by the KPI manager
  1. Have the operations group implement the design, and make it a part of joystreamstats.live (or some other website accessible for the community).

Reward Distribution

Parts 1-3 must all be addressed (not necessarily by the same person) for this to be graded.

Weighting:

  1. $50
  2. $125
  3. $75
  4. $50

Section II - Community Management

32.II-1 - Discord & Telegram Channel Management

  • Reward: $75
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

32.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

  • No work submitted, no rewards.

32.II-3 - Council Term Summary Videos

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #3387600
    • End Block: #3517200

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount. Note that the reward was reduced a bit, as the videos has tended be quite short, ie. perhaps too good of a reward :)

Weighting:

  1. $200

Grading

32.II-4 - Community Call 1 - Part 2

  • Reward: $800
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Final Call:
Will not be renewed (or reviewed) if not completed by end of this term.

Purpose

The Community call has been successfully held, and the raw video was uploaded here.

A little follow up work (editing, translating, etc) is needed!

Note

The reward has been reduced a bit, as these kind of videos needs to go out quickly to get the best value. Remember for next time!
(The tasks that was completed by the end of the last term will be graded with the "old" rewards)

Scope of Work

  1. Create a spreadsheet with:
  • index of the question (1, 2, etc.)
  • each question asked written in English
  • the timestamp of when the question started, in hours, minutes, seconds, milliseconds, eg. 00:20:30,4000
  • the timestamp of when the answer was finish, in hours, minutes, seconds, milliseconds, eg. 00:21:31,4100
  • if two (or more) subsequent questions are linked, such as a follow up question, make a note of it.
    Chit chat, off-topic, pauses, etc- in between questions should not be included, meaning the timestamp of the end of question 1, should in most cases not be the same as the timestamp of the start of question 2

Then, With the list from above, do an informal poll among the community, and find out which 3-10 questions is considered most interesting/important. Note that this doesn't (necessarily) mean the best question. The entertainment value is the most important element:

  • If the answer isn't very interesting, the clip won't be either!
  • If a question spurred further conversation, even if somewhat off-topic, it might still have been more interesting to watch.
  1. For each of the 3-10 "questions" from 1, create a "teaser" for each video. These should all be in the same style. Examples:
  • 2/3-off, 2s-5s clips enticing the prospective viewer to wathc the video, edited in a "nice" way
  • a concise, short "version" of the question spelled out
  • soft (license free) music?
    Note that the above are just suggestions - we hope someone in the community knows how to create engaging videos, and grow a base better than we do :)
    (Let me know if you want the chatlog!)
  1. Create a text based FAQ based on the questions that was asked. Both the question and answer needs a rewrite to make it suitable as an FAQ. This may even mean creating your question, if something interesting was said, that wasn't spurred by a direct question.

  2. Create a condensed version of the video, keeping more than the just the top rated above, but removing section that seems less interesting. How much to keep is up to you!
    (Let me know if you want the chatlog!)

  3. Create russian subtitles for the video from 2, using the .srt, or other "widespread" format.

Notes

For all videos, subtitles and artwork, you are free to upload yourself, but it has to be "CC0", and jsgenesis will likely re-upload.

Reward Distribution

For 1, only the first "good" submission will be rewarded.
For 2-3, only the best submission will be rewarded.
For 3, we are thinking it may be an iterative process, where we (may):

  • want to combine the work of two people
  • potentially request small changes/fixes
  • if/when we get something that looks great, we would want that team or person create more of these (paid) in the future
  1. $125
  2. $275
  3. $150
  4. $75
  5. $75
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

32.II-5 - Community Call 2 - Part 2

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3286800
    • End Block: #3387600

Purpose

As we are getting trying out how to best share/present the recordings of these calls after they've been made, and the first is taking some time to finish, we're trying out a simpler approach for the second call.

Scope of Work

  1. A new blog post has been published. Review the blog post, and give some constructive feedback on:
  • the format (what it contains)
  • the presentation (is there a better way?)
  • the selected highlights (is there something else you think is more important?)
  1. Create a video containing only the hightlights (if you disagreed with the hightlights Jsgenesis chose, use your own!)

Reward Distribution

  1. $50
  2. $50

Ideally, two different groups/individuals tackles this KPI - one group/person that was there, and one group that didn't (and hasn't seen it yet). Both can earn the full reward.

Grading

Section III - Working Groups

32.III-1 - Follow up the Storage Working Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Lead tracking of the performance of each node at regular interval? If yes, is there a carrot/stick system in place?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

32.III-2 - Follow up the Content Curator Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. What is the Curator Groups system/approach for reviewing/approving each new video as they are uploaded? Are they all checked, or is that done for Bounties only?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

* @ardashoff - $150
	* https://pioneer.joystreamstats.live/#/forum/threads/783?page=1&replyIdx=8
		* https://testnet.joystream.org/#/forum/threads/775
			* Included all information necessary and was quite in-depth.

32.III-3 - Follow up the Operations Group

  • Reward: $150
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3294000
    • End Block: #3380400

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Operations handling their "basic" workload as defined in the helpdesk repo?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

Section IV - Bounties

Working Group KPIs

32.CC-1 - Update Featured Video Hero

  • Reward: $150
  • Fiat Pool Factor: 0.2
    • Start Block: #3286800
    • End Block: #3488400

Revised 26.11.21, SoW 2+

Purpose

This should be replaced pretty regularly, and it's been a while since the last time!

Addition
We want to start changing these every day!
Feel free to look for information in the joystream or atlas repos (especially #4).

Scope of Work

  1. In line with the process established in a previous KPI, propose 2 or 3 alternatives for the featured video to Jsgenesis. The proposal should be the finished json with all data required.
  2. We want to start updating these on a daily basis. Create a catalogue of 5 videos (not used before), and 5 videos (re-use allowed).
  3. Come up with an estimate how many videos would be "good enough" for this already,
  4. Write step by step guide on all the actions needed, with examples, on how to "Update Featured Video Hero". Publish it to the Community Repo.

Reward Distribution

  1. $30
    2-4. $120 (combined. All must be completed!)

Grading

  • No work submitted, no rewards.

32.CC-2 - Update Featured Categories

  • Reward: $280
  • Fiat Pool Factor: 0.2
    • Start Block: #3328000
    • End Block: #3500800

Added 26.11.21

Purpose

We want to start changing these every day!

Note that tomato is likely needed for this task. The CC Lead decides how much of the reward they should earn. Some inspiration for the future can be found here. Feel free to look for information in the joystream or atlas repos.

Scope of Work

  1. Come up with a routine to change these on a daily basis. As we can't rely on tomato being available every day, look into creating a script for this. If required, ask the Operations group for assistance.
  2. There are currently 12 videos (with 3 clips) in each category, and 9 more video clips created (but not uploaded). Assuming we want a new top video for each category every day, it's currently possible to have 12 (11 left) permutations without finding more videos. Example for category 1:
  • Day 1: [[0,1,2],[3-11]]
  • Day 2: [[3,4,5],[*]]
  • ...
  • Day 5: [[1,3,6],[*]]
    Create a schedule for the next 12 days.
  1. Deploy the script that does this. Before it's done, change them manually (must be done at least once before the next term). Make sure to run the script manaully the first few times before it's set to start automatically.
  2. Publish the script, and write step by step guide on all the actions needed, with examples, on how to "Update Featured Categories". Publish it to the Community Repo.
  3. Before block #3500800, source at least 7 more videos to each Category, and create clips.
  4. Note that we can start rotating some of the old ones back in at some point. For this reason:
  • create a database of which videos was featured when, and in what "position"
  • give each of video a single score to indicate how well it works (eg. good clip/video, and relevance to the category)

Grading

32.CC-3 - Update Featured Videos

  • Reward: $50
  • Fiat Pool Factor: 0.2
    • Start Block: #3328000
    • End Block: #3488400

Added 26.11.21

Purpose

This should be replaced pretty regularly, and it's been a while since the last time. We want to start changing these every day!

Scope of Work

  1. Change the Featured Videos on chain, using the CLI. Make sure your changes works, and that there is:
  • no overlap with the Featured Video Hero
  • no overlap with the videos with clips in Featured Categories
  • little overlap with the other (without clips) videos in Featured Categories
  1. Plan a schedule of which videos should be featured for the upcoming Term, including which Curator should make the changes. Test to make sure they have the permissions, as I don't remember whether it's Lead only, or if the Lead can delegate this with groups.

Grading

  • No work submitted, no rewards.

32.OP-1 - Giza Testing

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #3085200
    • End Block: #3488400

Purpose

As we have started testing of Giza, we want the Operations group to help in testing. The reward will be $25/h of testing. However, we need some continuity, and reliability in terms of the testers availability.

The Lead is free to select a subset of the group they think is most qualified. Qualifications:

  • Some familiarity with using the command line (linux) and git (for most, not required for all)
  • If possible, one or more that has been a storage provider
  • Basic english (for communication, documentation and instructions parsing)
  • Likes to try and break things :)

We will provide linodes for the testers to ssh into.

Scope of Work

Giza testing has been ongoing for a while, but we have hit a roadblock, and we ask for no one to touch anything before that has been resolved. The Lead will be contacted when we can continue!

Grading

KPI 31

  • KPIs: 17+3
  • Total Possible Rewards: $3925+$665
  • Max Fiat Pool Difference: $364
  • Council Elected in Round: 33
  • Council Members: 20
  • KPI Length: 7 days / 100800
    • Start Block/Date: #3186000 / 16.11.21
    • End Block/Date: #3286800 / 23.11.21
  • Deadline to Submit Summary: #3315600 / 25.11.21

Notes

We're seeing some signs that whenever the new KPIs are posted, some of the CMs lay claim to a large amount of them ASAP, and are then, in effect, the only ones who can work on them. This is not how the system was intended to work.

If everyone WANTS to co-operate, that's fine, but not if two CMs can claim half of KPIs each, leaving the remaining 18 to fight for the remaining half.

If the CMs would rather compete that's fine too, but in most cases, the winner will take it all.

Grading

CMs

Member ID Member Handle Reward [USD] Reward [tJOY]
2194 ilich 74 2574346
644 lkskrn 7 243519
361 blackmass 8 278308
2141 joyval 0 0
515 l1dev 216 7514307
635 xfactorus 16 556615
1843 spat_sochi 4 139154
2531 nanapa6otaet 109 3791942
1962 nkhlghbl 1 34788
321 freakstatic_council 12 417461
1345 kadyrovs 38 1321961
2 tomato 311 10819210
2137 kalpakci 9 313096
1997 marinag_mary 308 10714845
2329 laura 294 10227806
790 ururu 8 278308
319 sparky 0 0
1048 igrex 191 6644595
2435 zazik 187 6505442
2182 isonar 107 3722365
SUM 20 2140 66098068

WGs

Member ID Member Handle Reward [USD] Reward [tJOY]
2329 laura 150 5218269
644 lkskrn 90 3130961

Payouts completed on blocks 3,356,378 and 3,356,379.

The fial pool shrunk by $42.

Section I - Council work, Proposals and Bureaucracy

31.I-1 - Proposal Clearance

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Shared
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

For the governance process to function properly, all proposals must be processed effectively, and dealt with within a reasonable time frame. Although we have increased number of proposals that can be open at any time from 5 to 20, it is still important that the community gets a quick result when possible.

This means the Council should be quick to vote when possible, and ask clarifying questions when information is missing.

Scope of Work

For the individual Council Member, this means that they must check in frequently, and address each open proposal. If what is presented is reasonable and within the budget, the proposal should in general be approved.

Of course, the Councils time must be respected, in the sense that the proposal should contain all the information needed to make their verdict. If this is not the case, the proposal discussion system can be used to ask for what is missing.

Without going in too much detail:

  • Most proposals will be of type Text or Spending. Along with some of the Working Group proposals, these should also be the most straight forward to vote on.
  • If the Spending proposal is for a Bounty, make sure the formalities, (eg. ask the Bounty Manager) are in order before casting your vote.
  • If you have all the information you need, vote right away.
    • Regardless of your decision, you should also make a brief comment outlining your reasoning.
  • If you don't have all the information, or don't fully understand, check the comments to see if it has already been addressed. If it hasn't, ask!
  • If you are not sure, you can always:
    • ask in the discussion
      confer with other CMs on Discord and/or the forum
      • if so, this should be linked to or summarized in the discussion
    • vote abstain

Reward Distribution

After the Term is over, we will get all the voting data from the proposals that were open during the Term. The reward will be divided by the number of total proposals.

  • Each time a CM voted for a proposal, they earn 1 point.
  • If they voted the same as the final outcome, they earn 3 more points.
  • If they voted abstain, they also earn 3 more points - as long as they didn't vote abstain on more than 20% of the total proposals.
  • Finally, the first 2 CMs that vote, AND vote "correctly" earns 2 more points.

The CMs reward for each proposal will be proportional to their points.

Note
Once a proposal is finalized, voting stops, so if you want to "piggyback" on the others, you may find yourself not getting to vote in time.

Grading

Member ID Member Handle Voted Points Reward
2194 ilich 25 81 14
644 lkskrn 11 38 7
361 blackmass 14 44 8
2141 joyval 1 1 0
515 l1dev 25 91 16
635 xfactorus 28 90 16
1843 spat_sochi 6 24 4
2531 nanapa6otaet 23 77 14
1962 nkhlghbl 1 4 1
321 freakstatic_council 21 68 12
1345 kadyrovs 19 72 13
2 tomato 17 64 11
2137 kalpakci 14 53 9
1997 marinag_mary 13 46 8
2329 laura 28 108 19
790 ururu 11 44 8
319 sparky 0 0 0
1048 igrex 26 88 16
2435 zazik 25 93 17
2182 isonar 10 37 7
SUM 20 318 1123 200

31.I-2 - Council Secretary

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

Although this is not a formal role on the platform, having someone responsible for co-ordinating the Council is needed.

The role should be occupied by a "seasoned" Council Member that:

  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term.
Note that proposals can be created for this role as soon as a new council term begins - it is not necessary to wait for the KPIs to be announced, and that some (friendly) competition for the spot may be a good thing!

Scope of Work

This includes a variety of tasks that the Council Secretary can also sometimes assign to the Deputy Secretary if required. The tasks listed below are only a partial list of what is required to be done, and in some cases there may be additional tasks not noted here:

  • Jsgenesis
    • The Council Secretary will act as a bridge between the Council and Jsgenesis. If there are significant testnet issues, the Secretary is responsible for making sure JSG is aware of them.
    • 2 days after the end of the council term, compile all KPI term summaries into an easy to read file that includes all necessary links.
    • At the end of the Council Term, outline which tasks, if any, you assigned to the Deputy, and how the collaboration went.
  • Community Repo Management
    • For all new PRs made to the repo, the Secretary and/or deputy is expected to attach a link to an approved council proposal prior to merging. Additionally there are other things that must be followed:
      • request Jsgenesis review for all PRs that require their attention
      • merge the PR, under the conditions that the PR:
        • would not require Jsgenesis to perform any actions related to the tokenomics (payouts or pool increases)
        • does not violate any license
        • does not introduce any code users can run
  • Elections
    • Make threads for each new election as well as term summary threads.
    • Try to make users aware of how to apply for the council and about relevant important deadlines
  • Education / Assistance
    • The Council Secretary should be available as much as reasonably possible on Discord and the platform's forum to assist and support other CMs.
    • Try to answer questions about KPIs that may arise, and if needs be get authoritive answers from JSG.
  • Proposals
    • Maintain a list of proposals that are addressed to JSG and follow up once JSG has given an official reply jsg_requests.md
    • Create proposals for WG Lead term limits as required by the following file WG_Lead_Term_Limits.md
  • Bounties
    • Ensure the bounty information presented on the website is up to date
    • Maintain the file spending_proposal_categories.csv and periodically update JSG if there are several outstanding Bounty reimbursements to be made
      • Also ensure that all spending proposals, whether for OKR bonuses or non-bounty spending proposals are added to this list.
    • The council secretary is responsible for receiving payments from Bounty 18 and paying these out to users.
  • Documentation
    • Periodically reassess the documents contained in the community-repo and suggest improvements for easier navigation and help to assist users in making sure that the governance system is represented as much as possible in this repo.
      • For example: If an approved proposal changes the responsibilities of a role, the relevant file should also be updated.

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

31.I-3 - Deputy Council Secretary

  • Reward: $150
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Although this is not a formal role on the platform, having someone responsible for assisting the Council Secretary is needed.

The role should be occupied by someone who is highly motivated and willing to learn, the skills ideally required include:

  • must have been on the Council before
  • is well versed in the platform workings
  • is familiar with github
  • has high availability

This role is applied for via text proposal, which happens once per term. (NOTE: proposals can be created for this role as soon as a new council term begins, it is not necessary to wait for the KPIs to be announced)

Scope of Work

The primary work of the deputy, is to maintain Pull Requests within the community-repo and ensuring proposals are attached with their relevant PRs.

Additionally to this, the Deputy should refer to the Council Secretary KPI for a full list of tasks they may be asked to assist with.

Reward Distribution

Only a single member may be chosen for this role. If more than one proposal for the position is approved, only the first one is considered.

Grading

31.I-4 - Council Minutes

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Term end + 1 day
    • Start Block: #3286800
    • End Block: #3402000

Purpose

There needs to be some level of accountability and transparency for the Council. For each Council Term the Council must produce a report, that both summarizes their communication, covers all 'events' and generally explains what transpired during the Term.

Scope of Work

  1. The 30th "official" Council #3085200-#3186000 produces a report covering any and all "events" of interest:
  • Proposals
  • Decisions
  • Voting statistics
  • etc.
  1. The Council Produces a "Tokenomics" report (for both Council Terms) covering the quantitative aspects of the Term. Must include:
  • Issuance statistics, through:
    • Spending from proposals
    • Role rewards
    • Bounties paid
    • Validator rewards
    • Total tokens minted
    • Total tokens burned
  • Media statistics
    • Note that this should only be a superficial report. A more comprehensive overview should be produced by the Curators.
  • Membership statistics
  • Role occupants, their recurring and earned rewards, hired dates, etc.
  • Forum statistics

Previous Council reports can be used as a guideline.

Reward Distribution

If multiple reports are proposed, only the best one will be rewarded.
Ideally however, this would be a collaborative effort.

Grading

31.I-5 - KPI Manager

  • Reward: $200
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Keeping track of the KPIs is no easy task. Parts of this task has often been handled by the Council Secretary, especially @tomato, but it might have gotten a little too much in addition to other Secretary tasks.

The idea for this KPI can seen in proposals 686and 689.

Scope of Work

  1. Please check the "overall" KPI notes for some thoughts on the current status. If the Council wants to co-operate:
  • Don't let any CM select more than one KPI AND no more than 1/10 of the overall rewards in one go.
    • If a CM wants to reserve two KPIs, tell them they can only have one of them before they have submitted their work. If they want to reserve a "high reward" KPI, they'll have to find/allow someone to cooperate with, or accept competition.
  • If someone hasn't done in work within n days (KPI manager chooses, but between 1 and 3 sounds reasonable), the KPI will "re-open".
  • To avoid "KPI squatting", or simply poor work, consider requiring a "stake" for reserving a KPI. This could be as simple as requesting some amount of tJOY sent to your address, that will be released on the conditions the KPI manager sets.
    If the Council doesn't want to co-operate, let them compete!
  1. As soon as a new set of KPIs are released:
  • Review them, and look for errors, unclear sections and similar.
  • Create a forum thread for KPI Discussion in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23)
  • Ask the Council Members which KPIs they want, and create a (pinned) post on Discord (#kpis), where everyone can see who is planning to do what. Note that although it's better for everyone if CMs co-operate, and don't step on each others toes, there is no rule against multiple CMs trying to work on the same KPI.
  1. Frequently update the Discord post, forum thread (kpi x discussion) and Russian telegram as CMs announce what they want to do.
  2. Frequently check in on them and their progress (preferably not in DMs, so that discussion is public), and assist them as best you can. Each CM should ask the KPI Manager before any questions are brought on to the Council Secretary or @bwhm#6514.
  3. Periodically mention any unclaimed KPIs. You can highlight how much the KPI potentially pays when doing this to attract users.
  4. ~24h before the end of the Term, post the progress for each KPI on discord. This should include as much information as possible, including whether KPIs are partially done or are unlikely to be completed in time before the term ends. If possible, include links to relevant proposals, PRs and forum posts alongside each KPI so that the work can be reviewed by JSG. The purpose of this progress report is so that JSG can understand which KPIs have or haven't been completed, so that they can write the new KPIs.
  5. Towards the end of the Council Term, create a thread for Term Summaries in the appropriate forum area (https://testnet.joystream.org/#/forum/categories/23). This thread should include the reporting deadline which is mentioned in the KPIs. This should be linked to on Discord so users are aware of it.

Reward Distribution

Except for 1. ($50), no weighting will apply here, as doing only one or two of the above tasks would make the rest of the work obsolete. The grading for this KPI will in part be based on the feedback from the other CMs.

Grading

31.I-6 - Council Insight

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

As much of what we were trying to achieve with the "Council Dissent" KPI was already achieved, it got discontinued. With the new direction (TBA) we want to take the governance/testnet incentives/KPIs, it seems important to start rewarding the main responsibilities of the Council - creating, voting and discussing proposals. Simply clicking on one of the four options is easy. Making the "right" decision, and influencing your fellow councilors to do the same is not!

Scope of Work

  1. Simply share your insight and knowledge with the platform! Each week, every CM can present up to five "posts" made in a discussion on-chain. This means:
  • Proposal texts created
  • Replies to a proposal
  • Forum posts or threads

The point here is to not limit it to dissent, meaning any question, comment or statement may be evaluated.

Reward Distribution

  • Individual CMs are capped at $100 each
  • The whole KPI is capped at $500

Grading

31.I-7 - Joystream Node Issues

  • Reward: $250
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Two weeks ago, we had an unfortunate event where some of our RPC and Bootnodes had gone down.
We have, and continue to, look into exactly what has happened to them, but thus far we have yet to solve the issue.

Information:

  • The nodes are running different versions. At least one was running joystream-node-5.1.0-9d9e77751.
  • The problematic seems to be #2661218, with hash 0xf5a468e133149fc094bdfa9d8842610a82fbdae10d57a4d5e980093d4691bbbc.
    • Note that this block was re-orged in (common occurance), replacing 0x7c1e11029ada770a98100f4aae3a4d4c23192343eaaf879ab57b888ae18dd841
    • Also note that it's the first block in a new era (4458)
  • One node stopped finalizing at this exact height, whereas some other continued for a little while before halting.
  • At some point, all failing nodes (that is running with --log runtime) will show:
INFO 💔 Invalid justification provided by 12D3KooWFkZZ23LoeyrpFpsDWEQwwRSWx9VaG6bwiz6jL8AE8HfS for #0x2e04…620a
  • The block in question being #2661813 with hash 0x2e04e790f04d336e2d58efb705e4773782d15041de776f755034b6355100620a
    • This happens to be the first block in a new era (4459)

Note that the "old" part 1 was completed last term.

Scope of Work

  1. Get ALL events that has to with slashing, eg. imOnline.SomeOffline, and offences.* starting from block #2000000 up until the current height. Create a dataset and chart the development of occurrences.
    (If you also get all the blocks with the event staking.payout, 3 will be significantly easier.)

  2. How many validators were there in each era, starting from #4457 up until now, and what was the set of validators? It's sufficient to check a single block in each activeEra. Provide:

  • the full validator set
  • number of validators
  • blockheight
  • era (activeEra and currentEra)
  • validator points for each era
  1. Having the data from 1 and 2, see if there is any reason to believe it implies anything "bad" happening around the problem blocks listed above.

Reward Distribution

Weighting:

  1. $100
  2. $100
  3. $50

Grading

Section II - Community Management

31.II-1 - Discord & Telegram Channel Management

  • Reward: $75
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

To make the Joystream community more welcoming to newcomers on Discord, we need high availability and helpfulness there.

Note

$75 will be added to the budget ref. proposal 393, and removed from this.

Scope of Work

For each of the above groups:
Check in multiple times every day, and welcome/assist every user that posts or asks a question. You need to have some knowledge of the particular topic, or read up on it. If you still don't know the answer, tag someone else!

Reward Distribution

Also note that you will "keep" this role for 1 day (14,400 blocks) AFTER the term to allow a new CM to take over.

Grading is individual.

Grading

31.II-2 - Create new KPIs

  • Reward: $500
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

Sometimes, creating valuable KPIs for a new Term is easy, other times it not so obvious what to focus on. Let's get some inputs from the Community!

Scope of Work

  1. Draft up one or more new (Council or WGs) KPIs, that follows the format of the existing system. Additionally, place it in the applicable group (or add new ones if needed), estimate the workload and propose a reward.

  2. If specifying it completely, as in the case for 1. is too difficult, or requires JSG input, simply outline what you want a KPI to cover, and what it's meant to achieve.

Reward Distribution

All CMs and WG Leads can contribute.

If your KPI makes it into one or more future set(s) of KPIs, you'll get:

  1. $25 + 25% of the Reward JSG sets (capped at $200)
  2. $25 + 10% of the Reward JSG sets (capped at $100)

Grading

  • No work submitted, no rewards.

31.II-3 - Council Term Summary Videos

  • Reward: $300
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Term end + 2 days
    • Start Block: #3286800
    • End Block: #3416400

Purpose

Although the community is diligently creating Council Minutes in text format every week, a video platform should have video updates!

We have seen some decent first iterations, but now is the time to see if we can get some improvements!
The problems we have seen thus far:

  • Some of the English videos (especially the first few times) has been "text to speech". This makes it far less personal, and interesting.
  • The visual of the videos have, in all cases, been screenshots and screen recordings of pioneer, discord, github, etc. This makes it very tempting to skip ahead.
  • All videos are made by a single member

Scope of Work

  1. Team up with one or more community member, and make the video more of a panel discussion. If you wish to stay anonymous, that is ok, but consider concealing your face some other way than disabled camera. As far as we can tell, most of the community has no/little problems understanding English. For that reason, and for grading purposes, the video must be recorded in English.

  2. Instead of a strict list of topics, take some notes on what has happened (doesn't have to be this week), and discuss it. Feel free to request topics from the Community!

  3. After publishing the video, get feedback by the community, and for the next video, discuss it on air.

Note

After a couple of iterations, we would consider sponsoring equipment, and other costs associated with the production. Examples:

  • Improved cameras/microphones
  • Greenscreens
  • Introduction animations
  • etc.
    Note that you have to ask in advance!

Reward Distribution

More than one team can apply, and more than one team can earn the full amount.

Weighting:

  1. $300

Grading

31.II-4 - Community Call 1 - Part 2

  • Reward: $700
  • Fiat Pool Factor: 0.2
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

The Community call has been successfully held, and the raw video was uploaded here.

A little follow up work (editing, translating, etc) is needed!

Note

The reward has been reduced a bit, as these kind of videos needs to go out quickly to get the best value. Remember for next time!
(The tasks that was completed by the end of the last term will be graded with the "old" rewards)

Scope of Work

  1. Create a spreadsheet with:
  • index of the question (1, 2, etc.)
  • each question asked written in English
  • the timestamp of when the question started, in hours, minutes, seconds, milliseconds, eg. 00:20:30,4000
  • the timestamp of when the answer was finish, in hours, minutes, seconds, milliseconds, eg. 00:21:31,4100
  • if two (or more) subsequent questions are linked, such as a follow up question, make a note of it.
    Chit chat, off-topic, pauses, etc- in between questions should not be included, meaning the timestamp of the end of question 1, should in most cases not be the same as the timestamp of the start of question 2

Then, With the list from above, do an informal poll among the community, and find out which 3-10 questions is considered most interesting/important. Note that this doesn't (necessarily) mean the best question. The entertainment value is the most important element:

  • If the answer isn't very interesting, the clip won't be either!
  • If a question spurred further conversation, even if somewhat off-topic, it might still have been more interesting to watch.
  1. For each of the 3-10 "questions" from 1, create a "teaser" for each video. These should all be in the same style. Examples:
  • 2/3-off, 2s-5s clips enticing the prospective viewer to wathc the video, edited in a "nice" way
  • a concise, short "version" of the question spelled out
  • soft (license free) music?
    Note that the above are just suggestions - we hope someone in the community knows how to create engaging videos, and grow a base better than we do :)
    (Let me know if you want the chatlog!)
  1. Create a text based FAQ based on the questions that was asked. Both the question and answer needs a rewrite to make it suitable as an FAQ. This may even mean creating your question, if something interesting was said, that wasn't spurred by a direct question.

  2. Create a condensed version of the video, keeping more than the just the top rated above, but removing section that seems less interesting. How much to keep is up to you!
    (Let me know if you want the chatlog!)

  3. Create russian subtitles for the video from 2, using the .srt, or other "widespread" format.

Notes

For all videos, subtitles and artwork, you are free to upload yourself, but it has to be "CC0", and jsgenesis will likely re-upload.

Reward Distribution

For 1, only the first "good" submission will be rewarded.
For 2-3, only the best submission will be rewarded.
For 3, we are thinking it may be an iterative process, where we (may):

  • want to combine the work of two people
  • potentially request small changes/fixes
  • if/when we get something that looks great, we would want that team or person create more of these (paid) in the future
  1. $125
  2. $275
  3. $150
  4. $75
  5. $75
    (If you don't have any experience here, you'll likely be disappointed with your grading - this will be very strict)

Grading

  • No work submitted, no rewards.

31.II-5 - Community Call 2 - Part 1

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Manual
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Purpose

As announced on Discord, we will host a community call this Wednesday!

Scope of Work

  1. Gather questions and present them at least 2h before the scheduled start.
  2. Translate questions made in Russian (both written and oral) to English. Requires proficient (spoken) English, and a willingness to show your face on camera :)

Reward Distribution

1-2: $100 each.

Grading

Section III - Working Groups

31.III-1 - Follow up the Storage Working Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Lead tracking of the performance of each node at regular interval? If yes, is there a carrot/stick system in place?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

31.III-2 - Follow up the Content Curator Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. What is the Curator Groups system/approach for reviewing/approving each new video as they are uploaded? Are they all checked, or is that done for Bounties only?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

31.III-3 - Follow up the Operations Group

  • Reward: $100
  • Fiat Pool Factor: 0.1
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Core Term
    • Start Block: #3193200
    • End Block: #3279600

Purpose

It's been a while since we've had these!

Although the working groups Leads are expected to run the day to day, they must be monitored by the Council.

This requires the Curator Lead to stay on top of their group, thus the Council to stay on top of the Lead!

Scope of Work

  1. Since the current Lead was hired, how many weekly reports were created? What, in general, did each report contain?
  2. Since the current Lead was hired, how many workers were hired and fired? If anyone was fired, what was the stated reason(s)?
  3. What was the overall spending (in both tJOY and USD) at the start of every Council Term starting from the week before the Lead was hired, until now?
  4. Is the Operations handling their "basic" workload as defined in the helpdesk repo?

Reward Distribution

Individual grading, and equal reward for each task. Unless all tasks are addressed, no reward is given.

Grading

  • No work submitted, no rewards.

Section IV - Bounties

31.IV-1 - Joystream Education Series Bounty

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Note

Extended, as it's not clear if finished.

Purpose

Creating a series of explainer videos was proposed by @marinag_mary on Discord. Creating video(s) explaining in particular the Council role, and more testnet specific information was planned way back in 5.10, but never materialized. Let's try again!

Quite some topics was introduced, but I think we should start somewhere smaller and rather branch out.

As these videos:

  1. should be a series, created in the same style,
  2. will be a lot of work to get nice,
  3. will require frequent tweaking, both with feedback, and with changes to the testnet (runtime)/kpi, etc.
    I think it should be a Bounty. Who is better to write it than the Council?

Scope of Work

  1. What topics should be covered in the initial 3-5 videos? I propose:
  • How to join the project
  • What is the Councils role
  • Intro to the Joystream player
  • Intro to the governance app
    There are many other topics, and future additions should be mentioned. I think it's counterproductive to pretend like we can complete them all rather soon, if we want to uphold a certain standard. However, these four might not the be the right ones! It would be good to loop in the people doing Community Feedback, and other surveys, the AMA, etc. Anything that indicates where the pain points are really.
  1. Create a (draft) Bounty text for this series of explainer videos. Be as specific as possible, including a fairly opinionated list of:
  • What each should covered in each video
  • How they should look (animated, screensharing/screenshots, etc)
    Check out the status of the Official music theme, as that would be a nice addition!
  1. Present the draft to the council/community for approval. When approved, Jsgenesis wants to review as well.

Reward Distribution

All parts must be attempted for this to get graded.

Grading

  • (this was completed + graded as part of KPI 30.x)

31.IV-2 - Bounty Managers

  • Reward: $100
  • Fiat Pool Factor: 0
  • Reward Distribution: Individual
  • Grading Process: Automatic
  • Active: Full Term
    • Start Block: #3186000
    • End Block: #3286800

Note

Extended, as it's not clear if finished.

Purpose

Keeping track of all bounties is both too much for a single person, and it will require different skillsets. There are currently 4 "weekly" bounties, where "weekly" means that the Bounty Manager isn't meant to have this role until the bounty is completed. Instead, the Council will choose one of their own to act as the Bounty Manager for each bounty during the Term.

A new addition is to actually promote the bounties. It appears to be somewhat of a hurdle getting people to apply for, and start working on, our bounties.

The scope of work for each Bounty will vary quite a lot, depending on the specific bounty.

Some general information can be found here.

Scope of Work

  1. For all "Official" Jsgenesis created/endorsed bounties: what is the current status of the grading/payment? Is there an action on JSG?

  2. What is the status of Bounty 27? Note that OP isn't the offical text.

  3. What is the status of Bounty 21? We have heard whispers that it's completed, but would like to know more specifics.

Reward Distribution

Weighting:

  1. $20
  2. $40
  3. $40

Grading

  • (this was completed + graded as part of KPI 30.x)

Working Group KPIs

31.CC-1 - Discover Category Videos - Part 2

  • Reward: $250
  • Fiat Pool Factor: 0.3
    • Start Block: #3186000
    • End Block: #3387600

Purpose

As part of a small update to the Joystream Player, we're adding some featured videos to each category for exploring. See example of the design here. For this, we need to curators to step in. After the leg work was done in KPI 25.CC-1, we're now ready to go live with this feature!

Notes

  • A json with the current videos can be found here.
  • Note that the timestamps (in seconds) denotes the rough start/stop of the clip.
  • A guide showing how to trim the video files can be found here.
  • The Curator Lead must also read through the further instructions here to ensure there is nothing missing between what is created and what is needed.

Scope of Work

  1. Prepare a somewhere where all the clips can be stored, and accessed (eg. dropbox, google drive, etc.). They should all be ~10s long, so this shouldn't require much storage.
  2. For each video in the list, ensure once more that it doesn't violate any license.
  3. If the video is "kosher", create a clip of the video, and upload it to the destination in 1, with the title of the file being <categoryId>-<videoId>.<extension> -> eg. 1-3.mp4 for "Did An Alternate Reality Game Gone Wrong Predict QAnon?".
  4. Update a spreadsheet that keeps the following information:
  • categoryId
  • categoryName
  • videoId
  • channelId
  • ownerId
  • title
  • Exact start of the clip (in ms)
  • Exact end of the clip (in ms)
  • Rating. (Meaning how appropriate you think this is, scale 1-5 - 5 being the best, for highlighting this category)
  1. Once they're all ready, ping me (@bwhm) and @tomato on discord. This will in the future be solely run by the community. For the time being, tomato will be the only one with the key that allows setting and changing the featured vids for a category.

Reward Distribution

This should be split among many curators, to ensure it's done quickly. The payout scheme works as following:

  • If completed within block 3207600, the reward is $250
  • If completed within block 3214800, the reward is $200
  • If completed within block 3222000, the reward is $150
  • If completed within block 3229200, the reward is $100

If not completed by the end of the term, all members of the Curator group will be annihilated for the Term.

Grading

31.OP-1 - Pioneer 2.0

  • Reward: $90
  • Fiat Pool Factor: 0.1
    • Start Block: #2883600
    • End Block: #3488400

Purpose

Now that we are finally closing in on the release launching pioneer 2.0, we want to focus on something that we've wanted to for some time. Namely giving the community both an opportunity and reason to contribute.

As we've stated many times before, we wish for the community to take charge of the platform in the future, which means they have to understand the software they're working on. Starting early, on an something that's both unfinished and that will require lots of improvements and updates sounds ideal. To make things "even better", there are both developer docs, contributor guides, and a fair amount of (good first) issues to start with!

KPI 27.OP-1 had the Lead review all the (then) open issues, and assign a dollar value for grading them. These values have been set as rewards!

Scope of Work

For each of the issues below, open a PR that gets merged. Even if the PR is merged in the end, the reward may be lower than what is stated, if:

  • There are lots of requested changes
  • It takes "too long" from the review, until the changes has been made.
  1. #888 - $60
  2. #1260 - $30

Reward Distribution

Each of the issues are graded separately. No requirement to complete all.

Grading

31.OP-2 - Giza Testing

  • Reward: $25
  • Fiat Pool Factor: 0
    • Start Block: #2984400
    • End Block: #3286800

Purpose

As we have started testing of Giza, we want the Operations group to help in testing. The reward will be $25/h of testing. However, we need some continuity, and reliability in terms of the testers availability.

The Lead is free to select a subset of the group they think is most qualified. Qualifications:

  • Some familiarity with using the command line (linux) and git (for most, not required for all)
  • If possible, one or more that has been a storage provider
  • Basic english (for communication, documentation and instructions parsing)
  • Likes to try and break things :)

We will provide linodes for the testers to ssh into.

Scope of Work

Testing will likely continue throughout the week. Information has been/will be shared to those participating.

Grading

Sumer KPIs (old)

The old KPIs can be found here!

Antioch KPIs

Antioch KPIs can be found here!