This has been on my mind for a couple of weeks now and this post from @stoodkev finally triggered me to share it with the community.
Outline
- The Issue
- The Proposed Solution
- Working Asynchronously
- Foreseen Short-term Challenges
- Keeping Track
- Keys to Making it Work
1. The Issue
For those who follow me, I keep track of @utopian-io's growth in my analyses. And one issue I identified in monitoring it was the maximum contributions that the bot can up-vote.
How many users, contributions, and projects is Utopian aiming to reward? How many open-source projects are out there? And how many contributions are we expecting 1 to 3 months from now?
These are just some of the questions I've been pondering on.
2. The Proposed Solution
Right now, we have @utopian-io voting on all of our contributions across all categories. What this contributor is suggesting is to have separate voting bots for each category - one bot for each category.
Example:
@utopian-io-suggestion
@utopian-io-sub-project
@utopian-io-development
@utopian-io-bug-hunting
@utopian-io-translation
etc.
Then each of the bots will have it's own delegated STEEM Power (SP).
This comes with it the need to request for the delegators to distribute their delegation to these bots.
The Utopian community or moderators will discuss how much they think they need or will distribute this SP to the different bots and will request the delegators to distribute it as such.
2.1. Working Asynchronously
The effectiveness of this solution lies in it being distributed. Each of the bot will then be able to recharge at different times and be able to offer it's reward across more contributions.
Given the past performance of @utopian-io of up-voting a current best of 318 contributions, creating one bot for each of the 12 categories can potentially give us 3816 contribution up-votes.
Depending on the number of contributions up-voted, each of the bot will then be able to recharge at different times. The bots don't need to use 20% max of it's voting power at the start of the implementation, but in the long-term, this 20% will be reached depending on the number of contributions on the category it's assigned to.
If we want the bots to start voting synchronously, we can have an API for that. But again, I don't think this can be called distributed if they have to wait for each other before starting to vote (just this author's opinion).
2.2. Foreseen Short-term Challenges
As mentioned in the previous section, in the short-term, while the number of contributions on each category is small, the number of contributions that need to be up-voted on will also be small and the bot's full 20% voting power may never be used. Or if it must make use of it's full 20% VP, then it may result in the contributions to be overvalued.
For reference, as of December 8, this was how the rewards for each category were distributed and how the contributions per category grew over time.
 |  |
Again, the community can use the bot's past 2 to 3 month's data to guide this decision.
In the long-run, this author looks at the scenario wherein the number of contributions on each category will reach its max and the 20% VP will be used.
2.3. Keeping Track
The third principle is that the community produces products to serve its members. This principle is
exemplified by credit unions, food co-ops, and health sharing plans, which serve the members of their
community rather than sell products or services to people outside the community. -- Steem White Paper
This requires the need to keep track and measure each of the bot's performance and tweak them so that the SP delegated to them will be equal to the rewards the community or moderators think or believe the contributions in such category deserve. This also needs to be directly proportional to the contributions each category receives and up-vote.
3. Keys to Making it Work
More SP is not really better. Before we ask for more, it's better to find ways to make better use of what we have.
The critical thing to make this work, besides the implementation, is the request or movement of the delegated SP. Currently, @utopian-io's SP comes from delegation. If we were to make this solution work, it may entail a lot of movement of delegated SP from one bot to another, until a balanced distribution is reached.
As such, it may need work on talking with the delegators and requesting them to move their delegated SP from one bot to another, which I don't think the delegators are willing to do.
Again, this is just an idea being put out into the community to peruse.
Posted on Utopian.io - Rewarding Open Source Contributors