reserve_vote_weight configuration option.This will allow flexibility when using bots that also vote on other things. It will reserve a specified amount of voting power in each batch. If you specify 10.00 %, then it will calculate the batch starting at 10.00 % utilization. The highest bids will still get the same payout, but lower bids will not be processed.
In this example, you can then use up to 10.00 % per voting window to vote on other things.
rake bounce_stream which will return bids immediately, if they are invalid.If enabled, this task will return bids if they cannot be voted on, for example, if someone bids on an article that is passed payout.
More of the functionality has been added to tests, which guards against regression.
Logging to the console is now less verbose. Debug messages are now written to drotto.log instead.
Prior to this fix, all bids were being evaluated, even if voting exceeded the batch limit. This would slowly reduce voting effectiveness over time.
Voting queues asynchronously, but actual voting only happens one vote at a time. This speeds up performance and reduces memory usage.
The queue is scheduled with staggered threads.
rake run_once for better flexibility.The run_once task votes on each window once, then terminates. This allows admins to use an external script or cron to schedule voting, rather than rely on the run task internal scheduler.
bounce tasks now avoid the current timeframe; uses a single transaction.When using bounce tasks, the current timeframe is left unprocessed so that the main run or run_once tasks can work without worrying about a race condition.
All bounce operations are submitted in one transaction per window.
If multiple bids come in for a single post, they are stacked into one larger bid.
The biggest reference implementation for Dr. Otto is 
@booster FAQ@booster be used for downvotes?Original Announcement: Dr. Otto: Vote Bidding Bot