Hey ! A rather short post but I figured I'd make a post to talk about it so that people are not surprised to see the changes if you don't follow the core dev meeting every month.
These past few weeks/months I've been spending more time on notifications of all sorts, with the blocktrades team we made a lot of changes some are invisible to you as it's mostly optimizations but some changes are going to be visible your way, I noticed that some notifications never make their way back to the correct user and needed fixing as the codebase has evolved over the initial release back in the old steem days. Some of those changes are already live if you decide to use api.syncad.com as api node.
New notifications
In short, you will now get community-related notifications, this is most important for mutes, I realized that when a mod/admin fill this form the mute reason never makes it's way back to the user
Which is not a great experience as I noticed a bunch of people in communities make another post/comment asking why their previous one was muted.
I'm sorry I didn't realize that this data didn't make its way to users sooner, on the bright side, this change is retroactive so all users will see notifications about their posts that got muted.
Community team size limited to 100
There are two other notifications that I am working on adding: update community properties (title/description etc) and flagging a post:
These features will be enabled soon as a notification to all team members (meaning community members with those roles: moderator, admin and owner).
In order to prevent spam, we have agreed on a new limit for how many team members you can have on a community: 100. We think this is more than enough as communities average a team size of 4.5.
Worst case we will revisit this number later.
Conclusion
Overall I'm excited to enable more collaboration and communication between community teams and the people using it. What other things would you like to see from communities ?
Howo
All downvotes should come with a comment explaining clearly why the downvote was given
I've been getting downvoted for a long time by a witness who is farming Hive hard daily with the help of blocktrades 🤔
Downvotes are kind of outside of the community sadly and part of a broader issue with hive overall. Downvotes are an essential part of making proof of brain work but getting a downvote leaves such a bigger mark than getting an upvote that it creates constant fights, so at the end of the day few people actually downvote when on other social platforms like reddit, downvotes are very common. Overall I think this needs a deep redesign of the way post reward work, we tried the social layer (eg letting 25% of downvote power to be free) and that hasn't worked all too well.
Anyways that's a much bigger topic than this change / comment and I doubt adding a reason for downvotes would help that much.
Downvotes are not outside of the community 🤔
Downvotes are clearly killing Hive 😂
It's quite stupid to keep downvoting when you have been exposed 😂 and also it doesn't look good that blocktrades supporting the biggest farmer scammer and downvoter on Hive
All downvotes should come with a detailed reason explaining the reason for the downvotes and how to stop the downvotes
Downvotes don't bother people like you because you don't get downvoted and you also know all the downvoters 😂😂
Nice developments, thank you.
In one of your earlier posts about communities, you mentioned the feature of subscribers requiring approval by an admin or moderator to join the community. This would be a welcome development, so that if you had criteria for joining, you could apply them, and also have a joining process.
I was thinking about this for a reading and writing community where I was looking for high quality writers who were already skilled as storytellers - so they would have to indicate this by submitting two or three pieces of writing to the community team in order to join the community. At the same time, I wanted to have readers (and consumers/curators) who would be able to vote and comment but not create posts unless they had passed the threshold for that. (Substack is doing this very well now).
I think there are other questions about the pros and cons of whether non-subscribers could view, vote and comment on posts (unless muted). The benefits would be the potential for wider audiences, the disadvantages would be if subscribers wanted to use the community for organising and wished their information to remain within the community. I haven't resolved these questions for myself yet, I think they need wider discussion. I know there was some concern about the inleo subscriptions where some posts from an account would only be visible to (paying) subscribers but votable by anyone including automated votes and how that fitted with the overall concepts of Hive and the potential for abuse.
The other thing that I found frustrating when I was admin for a community was that I couldn't access the whole subscriber list through the front end. It would show me a limited number, and this would contain different accounts, seemingly randomly selected, each time I viewed (I was using peakd).It would be great to have better access to this and some management tools. For example, if you learned that 80% of your subscribers had joined in the past three months, community posts could be tailored to that.