Policy Parameters for a Community Bot
Yesterday I drafted a Governance Model for a Community Bot but that was just the first part of the Framework that I think is needed to run a Community Bot transparently, effectively and in the continued best interests of its Community. The second part is what I am going to call the Policy Parameters, which is about some of the more flexible and community specific configuration options that each community would need to decide for themselves. So while I would consider the Governance to be pretty set in stone and not intended to change, the Policy Parameters ARE intended to change according to the needs and wants of the community that it serves.
Source
Here is a list of Policy Parameters that I think a community would need to collectively agree on to be able to run a Community Bot transparently and effectively. I will try to explain each of them where it is not obvious what I am talking about. You could consider this list to be a bit of a Glossary of Terms :-
Target Voting Power & Daily Voting Budget : These 2 things are directly related. The Target Voting Power is the intended equilibrium of the Bots Voting Power. Frequently Bot Operators like to keep this at around 90% but it can be anything. The Daily Voting Budget is the amount of vote weight that can be cast by the bot and be sustainable at the Target Voting Power. You can calculate the Daily Voting Budget by using the formula Daily Voting Budget = 100,000 / Target Voting Power. So with a 90% TVP you have a 1111% DVB.
Contribution Methods : This details how the community is going to contribute to the bot. It could be via Delegations and/or Liquid STEEM payments and/or Upvotes.
Contribution Weightings : This explains how contributions will be valued if the bot is going to reward heavier contributors (see below) and accept more than 1 Contribution Method. For instance a 1,000 SP Delegation might be the equivalent of 50 Liquid STEEM. So the Contribution Weighting of Delegation to Liquid STEEM is 50/1000 = 5%
Non-Contributor Budget : This is the amount of the Daily Voting Budget which is going to be allocated to members of the community regardless of the members Contribution. There can be more detail here if there is some complexity in the community membership model but at the minimum this should be represented as a percentage of the Daily Voting Budget.
Contributor Budget : This is the amount of the Daily Voting Budget which is going to be allocated to members of the community who have directly contributed to the Bot via one of the established Contribution Methods. There can be more detail here if there is some complexity in the community contribution model (such as membership tiers) but at the minimum this would be represented as a percentage of the Daily Voting Budget.
Vote Frequency : This determines how frequently the Bot can vote for an individual member. For example - One Upvote per Day per Member.
Power Down Threshold : The STEEM POWER level at which a Power Down needs to be initiated to return funds back to the membership (as outlined in Governance articles vi. and vii.)
Active Key Allocation : Who within the community is going to be allocated the Active Key and whether the Allocation is for safeguarding funds or managing funds directly (and how).
Posting Key Allocation : Who within the community is going to be allocated the Posting Key and whether the Allocation is for making Posts on behalf of the Bot or making up for missed Upvotes if there are technical issues with the Bot.
Posting Guidelines : Detailing how the Bot is going to Post. Such as technical information on how the Bot is running, community promotion, parameter changes or other Proposals For Change initiated by the members etc. Also guidelines such as not using profanity or making personal attacks on members or non-members within the Bots posts or even not showing favouritism to any individual members etc. These guidelines might also outline a desired frequency of these Bot posts such as one technical update per week etc.
Self Voting Guildelines : Detailing if the Bot is going to Upvote itself, at what strength and at what frequency. Possibly even for how long. For instance, it might self-vote to get started and build awareness in the community and then scale back. This Self Voting expense should be included in the Daily Voting Budget.
Extra Voting Contingencies : Detailing any extra votes that the bot would make (if any) that are outside of its normal purpose of directly supporting the members of the community. NOTE - These would also need to be Budgeted for so that they do not affect the Target Voting Power negatively.
Extra Expense Contingencies : Detailing any extra expenses that could cause a drain on the Bots resources. Such as Delegation Lease renewals or use of Promotional Bots.
Obviously this is not an exhaustive list of possible Policy Parameters but I think it would be a reasonable start. As a bit of a technical propeller head sometimes I would feel personally that it would be possible to at least initially configure up a Community Bot if the community agreed on the information detailed above about how the community wanted the Bot to work.
Source
As I mentioned previously, this is a currently a hot topic for a community that I am involved in so any and all feedback would be greatly appreciated.
https://insidesmallbusiness.com.au
https://www.nicklitten.com
This is very clear and very good! Thank you for providing a framework and a clear separation of separate ideas. I do think your fine ideas could be built into a general Charter for Steemit, with applicable ammendments for specific groups such as ssg. This is great! Well done
Thanks mate, I appreciate that. Hopefully something good comes of all this :)
Actually I think that this framework, that you have outlined, should be set out as Blue paper for the larger Steem ecosystem. I'm on a bunch of communities and think that what you have compiled is a applicable to this community but also to any community contemplating the same sort of guidelines or community account/bot. It would be another forward thinking contribution by the ssg community to the overall health and well being of Steem. Well done.
Thank you. This is an awesome comment and I'd love to see this framework get some traction beyond SSG. At the moment I'm just focused on getting the framework right and seeing if it can work here for SSG but if it does and other communities are interested down the track then I'd be happy to help.
Wow, I would have to say that I am more impressed today than yesterday and yesterday I was pretty impressed. I diffently can see this as a doable true community bot, that is transparent to the entire group. I would also like to be able to figure out what exactly the power would need to be for there to be a brake even or a small ROI for investors. Pretty amazing @buggedout. Once again nice job.
Thanks mate. I really means a lot coming from you. I guess one of the next steps for SSG is to start putting some numbers in there and see how it looks.
we need something like this in the Steemit community so bad... I just posted a topic on reward pool rape that has really got me so sick of the self voting circle jerks going on.. Its almost enough to make someone want to just power down and give up..
Totally agree and I was close to that Power Down button myself. If an idea like this can get some traction though then maybe the communities can have an answer to the circle jerks and the for-profit bots that seem to be dominating the landscape.
Wow brother you have really broken down many options. Thank you, i think that this could work out well for the community. Thank you for all of your hard work.👍
Thanks and you're welcome. If it all works out for the community in the long run then it'll all be worthwhile.
No doubt, but I’m glad we have someone that understands this stuff because it’s sure as hell not me.....
What I took from reading your post was that STEEM needs to implement a multi signature account for the purposes of a community bot. Ideally 2 of 3 signatures need for any power down, code changes etc. Any solely owned bot could be abused by the owner at a loss to the community.
That would be great. Not sure if we can expect it any time soon. One of my other commenters suggested a smart contract could do the trick so maybe a technical solution is not too far away. Until then this will have to do?
Another very detailed and correct article, just like yesterday's. We have a long way ahead and I am sure that the basis that you just defined will be the root of a healthy community bot. Thank you for your effort and for the ideas.
Way to go man! Excellent ideas moving forward
Sounds good. Way out of my league. I wish i could add something to the conversation. I'm with whatever the experience guy's want.
It all looks really good, but I have a minor issue with the DVB, even though it WILL WORK and is a more conservative calculation, as long as a potential Bot Operator is aware and does not fall into the same circumstances that befell STAX, apparently...
It seems this formula is an approximation rather than a direct measurement. I took direct readings of "VP Expended" when using a series of 100% up-votes. The progression is not Linear, but an Asymptote. Meaning a "number trending to zero but never equaling it". So your first 100% UV is the largest, your next is a bit smaller, and the third is a tiny bit smaller yet. As far as the upper ranges of the VP goes, this will be "close enough" and actually conserve the VP a little better than a more exact calculation. The number my method gave was a bit higher than 1111, (1123 iirc) and even more of a gap above the number Phil told me at one time. In fact, the March Spread Sheet shows 1162.5 being the figure used, except it does not include the self votes or the swaps. Link to the March sheet:
https://docs.google.com/spreadsheets/d/1X7gkutia1lnBA44NS-IhEwNpPj533Jq8iqF6vpS7vuE/edit#gid=0
In my experience with my main bot @minnowbootcamp, I calculate my DVB with a flat 1100% figure and I use the "extra vp" to reward those that interact with bot's update and policy posts. I also have a MOTW (minnow of the week) award that nets the winner a 100% UV as a bonus. I suspect in SSG we will just want to figure it closer than that, and not have "excess VP to Burn Off" so to speak. But there are ways to do it, which should be in writing to avoid conflicts...
Very, VERY Well Done, @buggedout! Regardless of minute differences in figures, it will work. It might just generate a bit more "excess" than we expect, and then again ALL these formulae "assume 100% posting participation" so there will always be excess VP no matter what. Going upwards to a DVB of 1200 or more is dangerous ground, because the dynamic of a large community and varying posting habits can break the bank in a single day. It might work well for a week or so, then BAM!
I know these things are obvious to you, I am stating them for those less experienced in BOTTING.
I call it the Daily Vote Budget because it is intended to be a Budget. Most businesses and households ACTUAL spending can fluctuate either side of the Budget and it’s just supposed to be a guide. It’s not an exact science.
I trust the design of the system. When doing a 100% vote the formula is New Voting Power = Old Voting Power * 0.98. It is actually designed to be non-linear and it ensures that any vested SP can only dish out a certain fixed amount of rewards over time. It’s actually quite brilliant and I may write a post just on this topic alone because it is so poorly understood by many Steemians.
The Target Voting Power could be 50% and the community would not lose a single cent because the formula adjusts the value of a 100% vote and you can make more of them. A TVP of 50% is actually easier to manage because you have more room for error and it can fluctuate. As long as VP never hits 100% there is never wastage. The reason why many like to keep a high VP is to preserve the absolute value of a 100% vote but if you’re spreading it amongst 100+ people and not trying to keep a 100% vote for yourself then it really doesn’t matter. An equilibrium will be found for votes cast at any VP.
Anyway, I am aware that some users will post daily and others will not and this needs to be accounted for in the budget as it can cause a surplus of VP (or "excess" as you put it). I can get access to SteemSQL and profile the voting behaviour of the community as I have done in the past. I think I can manage that aspect with a bit of room for error and tolerance from the community that I’m doing by best. Nobody can really predict how many posts will be made by community members on any given day.
Excellent Grasp of the mechanics of the system, Bug! I've actually learned quite a bit here myself.
I was aware of the range thing, you can make the target anything you want. I have read some fine posts on that exact thing, but the writer was actually just using anecdotal evidence rather than the actual facts as provided by Steemit Inc. Is all of this found in the white paper? I suspect it is but I have not had time to dig thru it in that much depth. Good Stuff!
I do like the Target at 90%, that being the median of maximum vote weight for the recipients. I think most SSG Folks will too ;)
Thanks for the detailed reply.
I don't think it's detailed in the White Paper. It's a specific thing that was introduced in Hard Fork 19. I did a spreadsheet a while back to prove it and understand it myself, but if you want the documentation look for details of the voting changes made in HF19.