If you've been submitting Utopian contributions lately you might have noticed we have been having trouble keeping up with the amount of contributions. The amount of voting power (or mana, I never know which) used is more than can be recharged in a day, which of course eventually became a problem. Because of this 
New behaviour
Instead of upvoting one contribution and review comment at a time, we will be moving to batch voting and trying to use exactly (or as close as possible to) 20% voting power per day. The bot will start voting once it hit 100%, and will first vote comments, then contributions and then finally all trail posts (e.g. 
Upvoting comments
To upvote all comments the first thing the bot will do is find out which comment, that hasn't been upvoted, is the oldest. Once it has found this comment, it will then get all comments made in the 24 hours following that one, as long as they are older than 2 days. It will then calculate the weights that will be used to upvote each comment, depending on the category it's in, as seen in image below.
Example of the voting weight that will be used for each comment per category
If the amount of voting power used to upvote all of these comments exceeds a certain amount (currently 3.2%), then each weight will be multiplied by a constant so that the used voting power is exactly this amount.
A category's share
After voting all our moderator's comments it will start voting the highest quality (determined by its score) contributions currently pending. There are currently 14 categories that we review. Some of these categories have a lot more activity than others, which in turn means that the majority of
Category activity
| Category | Reviewed | # active moderators | Reviews per moderator |
|---|---|---|---|
| all | 197 | 46 | 4.3 |
| translations | 89 | 24 | 3.7 |
| development | 30 | 5 | 6.0 |
| blog | 20 | 2 | 10.0 |
| graphics | 17 | 2 | 8.5 |
| tutorials | 13 | 3 | 4.3 |
| iamutopian | 7 | 2 | 3.5 |
| analysis | 5 | 2 | 2.5 |
| anti-abuse | 4 | 3 | 1.3 |
| video-tutorials | 4 | 1 | 4.0 |
| ideas | 3 | 3 | 1.0 |
| social | 2 | 1 | 2.0 |
| task-development | 2 | 1 | 2.0 |
| bug-hunting | 1 | 1 | 1.0 |
To give an equal chance to each category it has been decided that each category will get an even share of the allocated voting power for contributions (currently a minimum of 14.8%). If upvoting all contributions of a certain category doesn't use up its entire share, then the remaining part of its share will be distributed to the categories that need it. An example of the initial share per category is given in the table below.
Voting power share per category
As you can see in this example a total of 15.73% voting power is allocated to upvote all the highest quality contributions in the current voting round. Taking all of the currently pending contributions and calculating the amount of voting power that would be used to upvote all of them results in the table show in the image below.
Voting power usage per category
Some categories use much more than their share, while others don't even use it entirely. The total amount of voting power used is also much more than has been allocated to the contributions. As I mentioned earlier the bot will distribute the voting power over the categories that need it and then use that to upvote everything. This results in the following image, which shows each category's new share.
Each category's new share of the allocated voting power
The bot will then start upvoting the contributions after sorting them by score. For each contribution the voting power usage is calculated and subtracted from the category's share. If the voting power usage exceeds the this share, then no more contributions of that category will be upvoted in this voting round. Obviously this means that it might happen that a contribution won't be upvoted if its score is not high enough compared to other contributions in the same category. This also means it creates competition within the categories themselves without affecting the contributions in other categories.
I am Utopian
This part is only really relevant for moderators and managers of Utopian, so you can skip this if you aren't. Before this change the #iamutopian posts were upvoted manually by iamutopian, analysis, utopian-io will result in it being submitted to the iamutopian category. Using the tags utopian-io, analysis, iamutopian will result in it being submitted to the analysis category. I hope you get my point.
My misunderstanding
An example of the unused voting weight multiplier
In my eyes the biggest problem I had to solve was to make sure everything that gets a positive review should get upvoted. I thought of a way to make sure that every contribution in a category was upvoted without it affecting the voting weight of contributions in other categories. To do this I calculated the voting power usage per category, and if it was more than their share, then each contribution in that category's voting weight was multiplied by a constant (calculating a way to do this was surprisingly difficult). This made sure that each contribution was upvoted, while using exactly the amount of voting power that was allocated to the category. After last week's voice meeting it became clear that this is not what
The trail
After finishing the bot I was asked to also add the trail functionality to the bot. This was initially implemented in JavaScript in another repository, but of course it would be better to keep all voting functionality in one place. So I set out to port it to Python so it would work with the new bot! I didn't really use much of the code from the JavaScript bot, so I will describe pretty much everything about it below.
Configuration
Example configuration
For each trail it's important to define some behaviour for the bot:
- If it should follow self votes
- If a post's context should be checked with IBM Watson (more on that later)
- What the minimum voting weight for following the trail is
- What the max voting weight and weight multiplier is
- What the weekly upvote limit is
- If the trail should be prioritised above others
Putting together the trail's batch of posts
Once the behaviour has been defined the trail's batch can be formed! It first of all creates a list of posts that it should potentially upvote by checking the vote history of the trailed accounts (48 hours). If the votes are above the minimum weight then the post is taken into further consideration.
What I mean by this is that for some trails the context of the post is checked using IBM Watson, which returns certain labels under which the post is categories, like "/technology and computing/operating systems/linux". If IBM Watson is sufficiently confident that this is the case (score > 0.67), then the post is added to the batch. While doing this the post's voting weight is calculated by using the weight multiplier and the max weight (if applicable)
Some trails are also prioritised above others, and this is indicated at this time as well. Of course if a post has already been upvoted by
Upvoting the trail
After upvoting all comments and contributions submitted to Utopian, there will be a certain amount of voting power left over (minimum of 2%). This is used to upvote all the posts in the trail's batch, sorted by priority and voting weight. If the voting power of
Some words
It took quite a long time to implement everything, especially the reward multiplier which didn't end up getting used anyway. A lot of people provided some form of help, either by sharing their thoughts and ideas, testing stuff, solving problems and pointing out mistakes in the code and much more. I would especially like to thank 
I did my best to explain how everything will work from now on, but if you are still confused or have some questions, then please don't hesitate to ask for clarification. I'll do my best to answer any questions to the best of my ability - however it's my girlfriend's birthday today so I probably won't respond immediately.