Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
There are lots of "policy features" we can [should?] implement: admin should authorize joins, members can invite, moderators should authorize each post, etc.
[not necessarily good] Ideas about implementation:
IMHO, best is not to do these things hard-wired, but rather have
Group admins can grant a bot rights to change user<->group or post<->group relations (not excessive rights - or it would become a vulnerability).
The "respond with yes or no" can also be presented as GUI yes/no buttons (using post object-properties that can be understood by smart enough clients), but this is a bit off-topic here.
This is a major drawback since the migration. We were using the "koumbitstatus" group to do status updates for our network in a decentralised way, on some servers outside of our main infrastructure. This functionality is now completely gone.
While I think now that we shouldn't have relied on identi.ca for that service, I was expecting the "federation" bit to survive the migration: I post those notices from my home statusnet server, and the fact that those don't communicate at all anymore makes this a very difficult migration. This will clearly make us hesitant in using pump.io or any other federated protocol (as opposed to say: a simple html page with rss feeds) to post our updates.
I know that you have a lot of work to do, but I think groups make the difference between useful or not. We are not interested only in follow people but also in follow themes, ideas, movements... Since migration to pump.io my timeline it's no such interesting as before.
Please, make an effort to give back groups!