One thing to consider for some of the community features indicated in your post is if it will be a Json transaction that an admin can do or if it will need the account owner to put the info into the community account metadata with an active key. Or mix of both.
For example we will have a couple features coming up that we are doing this method with the account metadata even though letting the admin make changes sure would be nicer for user experience specially if it's something that needs to be edited often.
Also community stats that deal with comments or rewards are problematic because it is largely a reflection on the individuals following and their ability to bring in comments and rewards and it is uncertain what the community had to do with it. Not saying we have to get rid of those stats but given better options those ones should be related way down in the list.
So I am in favor of stats that show a user what the community is actually doing.
- lifetime number of content posts
- recent number of content posts
- number of unique users posting content
Those seem to be directly related stats to what the community experience. It also indicates to the new user what they can expect after they follow the community (what will happen to their follow feed)
I'm not sure what you mean, are you talking about the beneficiaries or the TEXT vs jsonb thing ?
on the stats I agree, we will open the discussion more broadly on what we want + what we can do when we get to implement them, I'm sure there are a ton of them that are easy to do and bring a lot of value.
When a community member with the role of admin wants to change something on the community they publish a Json and that makes a change to the community in those specific fields like description, community name, Rules and additions of moderators or muting.
I'm saying we could add a couple more things there OR just add it to the @hive-xxxx account metadata which can only be edited by the owner of the hive-xxxx account.
Ah I see, It will be done on with the json props operation (publishing json), it makes more sense to bundle everything under the same communities operation
Well it's obviously nice but of course it's work so i wasn't assuming.
I should probably mention that we will be adding two more aspects to community we have planned to add them to the hive-xxxx account metadata. Assuming if they get used a lot we thought maybe they'll switch specially if other interfaces start to use them.
Preferred-Topics ... these are names of topic-tags (on posts) that the community wants to see the most and that interfaces can help the users zoom in on and consume. It's basically a way of filtering the content in a community. But will also be presented to the content writer when writing a post as what is preferred for tagging. So the admins would basically just present an ordered list of #tags.
The other is a short list of the actively used community titles (labels) or whatever they're called. they could help sort community members and communities could use these titles in all sorts of ways including hierarchal achievements.
Eventually we believe those labels will be more useful when communities can add in a BOT that automatically approves any user who selects a community title from the communities approve list of titles and essentially it moves to users deciding their own titles which you see a lot on reddits like sports reddits with only some of the labels active.
But the question is how often would these be changed and is account meta-data sufficient. I'm guessing while not often they may be changed more than some of the other data that admins get to change there.
cc @asgarth
Hmmm I feel like all of these should be done at the hivemind level, It's basically a way to change the sorting/viewing algorithm, and approving posts make little sense when we could instead make the algorithm show the posts (or not) automatically.
If you haven't started working on it, if I were you I would be enclined just look at the hivemind code and implement them there, the code is pretty straightforward, but I do get that it would be much faster to just implement them at peakd's level.
How often these would change would be pretty rare I would assume.
As of yesterday can actually go to beta.peakd.com and see how we are looking at doing the proffered topic list on account metadata (community settings option)... it will be easy to transfer the info to hivemind.
But I'll cc @asgarth and see what he thinks
And as I played with this list yesterday with one of my communities I actually changed the list a bunch of times but maybe once I get it set then I would rarely change it.