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