Rationale
After 11 weeks of KPIs, we at Jsgenesis are of the impression it's not working the way we had hoped. Though there are many smaller issues that may have contributed to the failure of the current system, we think the biggest problem is simply that incentives for KPIs are not calibrated correctly.
As the KPIs reward all token holders based on their proportional share of the tJOY issuance, it would only makes financial sense for true "whales" to participate without a substantially larger fiat pool. Even then, the "free-rider problem" could come in to play.
Our hope was that these issues would be mitigated through funding proposals and competition for Council spots, but that has proved to be incorrect.
Our main objective for the KPI system continues to be attracting and training contributors to the project, while simulating the economic system we envision the mainnet platform will run on. At this stage, all improvements to the platform (in the form of code, marketing, hiring etc.) will need to be funded and executed by the platform independently.
It is to serve this ultimate goal that we have suggested some enhancements to the KPI system, which are outlined below as a proposal which we hope the Council will carefully consider.
Description
An executive summary of our proposal to improve the system are as follows:
- KPIs will be split in to "Council KPIs" and "Community KPIs".
- Council KPIs:
- These KPIs will typically focus on short terms goals, like network stability, platform operations and allocation of resources.
- They will always follow the Council term (i.e. they will last for seven days)
- The rewards for achieved Council KPIs will be distributed to the Council and their backers (voters) only.
- Community KPIs:
- These KPIs will typically be producing a deliverable or performing some task for the community or Jsgenesis.
- These can be more long-term oriented, and require more work and some skills in a specific domain.
- The reward structure will work similar to todays KPI system, but with a clear workflow, and with Jsgenesis providing a guarantee for the contributors.
- Both of these KPI types will require more involvement from the Council, thus requiring better incentives for them to be active.
- Jsgenesis will take a more involved in the election cycle, to avoid complacency and "free-riders".
More details below:
Definition of Terms:
- "Applicant" - A person that wants to to do the work for a KPI
- "Assignee" - A person that, after being an Applicant, gets approved, and may be given some privileges in line with agreed terms
- "CM" - Council Member
- "Deliverable" - Any item submitted either to the Council or Jsgenesis, with the intention of achieving the KPI.
- "Submitter" - A person that submits a KPI deliverable to the Council
Council KPIs
Recurring KPIs, such as "Block Production", "Proposal Clearance" and "Council Reporting" are good examples of potential Council KPIs. Alongside managing the working groups and the platform finances, this constitutes an important part of the Councils main responsibilities.
The common theme is that these KPIs either directly or indirectly require the Council to monitor the network and Working Groups' performances, the platform finances, and pay attention to Proposals and discussions.
Suggested Changes
The Council KPI rewards will go to the "successful" election (governance) participants, ie. elected CMs and those that voted for them, proportional to their stakes.
As perhaps the most critical role at this stage of our testnets,the CMs will now earn rewards in two ways. A fixed and predictable reward for getting elected in the first place, and a performance best bonus for doing a good job.
Finally, Jsgenesis will take a far more active role in the voting process, and scrutinize the voting history and activity level of each applicant. The main purpose of this is to counter the "free-rider problem", by voting out CMs that doesn't perform their tasks satisfactory. Note that Jsgenesis voting will not count as "stake" wrt. to the KPI reward distribution.
Community KPIs
KPIs such as Content Creation (e.g. KPI 2.3) and the recurring Telegram Bots are good examples of a Community KPI. These KPIs can address issues outside of the platforms day to day operations, and focus on longer term goals such as development, community building, creating useful tools, etc. In general, these are perhaps better understood as bounties and/or competitions, so a name change could be in the cards.
Our thinking here was always that community members would try to attack these sorts of KPIs themselves, then through a series of Text and Funding Proposals, perform the work, and claim a reward.
This has worked slightly better than for the Council-style KPIs, but it is still far from perfect. All of the factors below deserve some of the blame:
- These KPIs have not been promoted sufficiently, neither inside nor outside of our community
- The Council has had no incentive to perform tasks themselves, nor search for people to assign them
- The funding structure we imagined have been poorly communicated - thus few know/understand it
- There was no explicit guarantee that your work would be rewarded by the Council in the end
- It requires some overhead, instead of just performing a task and claim the reward
The somewhat negative feedback loop meant that we were hesitant to put too much effort in creating these KPIs, which again made it less interesting for users.
Our suggestions below addresses most of these, but not the fifth. This is because we believe it's important to cultivate a system that mimics a workflow that is viable on mainnet.
Suggested Changes
In the new system, we rely on the increased incentives for the CMs to assist in setting the rules, creating a clear workflow and act as Project Managers. They are also the ones that decides what is submitted to Jsgenesis to be graded and rewarded. Note that Jsgenesis can overrule their decisions in situations if the "rules" are not adhered to. Especially in cases where a user spent time and resources in to something, without getting rewarded due to some mistake made by the Council.
Community KPIs may not have a deadline, but the prize and complexity may be adjusted if deemed necessary.
Rules
As the Community KPIs will vary in size, scope and reward, each time a new Community KPI is made, the Council must agree on the specific rules (this will be part of the Council's KPIs).
Reward Distribution
The Council decides how much of the total KPI reward will go to the Submitter, if the rewards should or can be split, and so forth.
Format
The format should try to optimize for the time, quality, risk and cost, associated with each KPI. The Closed, Free For All and First Come, First Served formats presented are just suggestions.
Closed
For a KPI that requires investing lots of time and/or other resources, it may be reasonable to guarantee one or more Applicants that gets Assigned some time to complete all, or some, of the work, without having someone come in and "snipe" the reward.
Free For All
For smaller, and perhaps more creative and subjective KPIs, it may make more sense to leave it as a "free for all". In this case, the Council sets a deadline, picks the best Deliverable(s), and rewards the Submitter(s) as per the rules.
First Come, First Served
For smaller, perhaps more time sensitive KPIs, one could choose a format where anyone can enter, but each Submitters Deliverable is reviewed by the chronological order they are submitted. The first acceptable Deliverable(s) is granted the reward(s).
Further
In addition the varieties outlined, other formats can be defined and chosen if they are more appropriate for a specific KPI.
A "new" Council must honor any agreements and rules set by their predecessors, for as long as the rules say so.
Workflow
The workflow will depend both on the Reward Distribution and the Format, and must be established beforehand.
- For "Closed" formats, an Applicant must present a bid why they should be assigned the given KPI. This should include detailed terms, such as time needed, costs, etc. If approved, this makes the terms valid.
- In some cases, it may make sense to break a KPI up in to milestones, with partial rewards at each stage. This builds trust as the Council can see the progress being made, and the Assignee can get chunks of the reward along the way.
- In other cases, the person may need some initial funding to get started.
- For "Closed" formats, the specifics of the workflow could be part of the Applicant's application for participation.
Steps
1. New KPIs Made
Although the Council decides on the rules and reward distribution, they listen for input from others in the platform forum and on Telegram. Within a reasonable time (as stated in the Council KPI), the rules for the KPI are presented in Text Proposal, voted through, and published on GitHub.
1.5. Work is Assigned
Depending on the rules chosen, there may be a step to assign the work to one or more Assignees.
This will require some back and forth through multiple Proposals, and should thus be avoided for less complex KPIs.
2. Work Happens
For a "Closed" format, it can mean a series of Text and Funding Proposals, waiting, and ongoing communication between the Assigned/Assignees, and the CMs.
For a "Free for All", it can be mean reviewing submitted Deliverables as they come in, or waiting for the deadline. How a Submitter should make the CMs aware of their Deliverable once ready (GitHub, Telegram, forum or Proposal) must be defined in the rules. A "First Come First Served" format will be similar to the "Free for All". Once one or more Deliverables are approved, the Submitter(s) should be considered as Assigned in Step 3.
3. The Work is Submitted to the Council
Regardless of format, once an Assignee, or otherwise qualified Submitter, considers their work done, they create a (final) Spending Proposal, which in total rewards them the agreed amount, links to all relevant discussion and rules, and a link to their work.
Once the Council considers the Deliverables complete, this final Spending Proposal is "approved" and successfully executed.
4. Jsgenesis Grading
After Step 3, the Submitter have received their reward, and their work now "belongs" to the platform.
Jsgenesis will then review and grade the Deliverable as such. This can result in a reward anywhere between nothing (failed), or everything (full score), and the fiat pool will be increased accordingly.
It may be that this reward is smaller than what was rewarded to the Submitter. This will cost the token holders, and one would expect the Council to be punished.
Councils Role
As seen in the workflow, the Councils role in the Community KPIs is substantial. They will work as the Project Managers, and are at the end held accountable for the quality of the Deliverable they submit for grading. These tasks may be a part of the Councils KPI directly, but the efficiency, creativity, rules, workflow, speed and outcome of the process will anyway be part of the Jsgenesis Council voting process.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
