As my group and I use it now: Yes it is error prone. But if you could choose the group from a dropdown menu like the aspect-dropdown, tag could be automatically placed in the bottom of the post - like the right aspect could automatically be chosen.
I think it could be useful to take what is already there: tags (whichs create a stream only consisting of concerned posts) and aspect/public (targeting only concerned users), instead of reinventing a lot of stuff. I already use a combination to create a group, and it is working.
What I do see as a problem is having tags that are not used by someone outside the group. This would pollute the group stream with irrelevant posts. I have solved this by choosing a tag that I anticipate will not be used by others. I do not know if you could reserve a special kind of hashtag like the ## and ### i propose above to groups, maybe someone else with a better understanding of the code can enlighten us.
A sort of oldish newbie here. I know thatâs the contradiction/irony there but thatâs life as we know it . Forgive me but from what I understand it, aspects is a label we make on people. Say I know few friends who like football and so I can publish it only on those aspects. This somehow feels restricting the conversations.
In Groups the conversation is usually more informal and more interaction takes place. In a federated environment, this would be more interesting and dynamic as well. The possibilities are endless
A group based on tags has no moderation capabilities.
I realize that specialized tags is much easier because it is already here - but I do think moderation of a group is a desired feature.
@shirish You can have people in many aspects at a time. For a closed group you would post to a group-aspect, in an open group you would post public âŚ
@Birch Moderation as in throwing people out? If so that would happen in the group aspect Taro and Johannes talked about. Removing posts ⌠maybe could be a problem.
It is the combination of tag and aspect that gives group-like functionality, and most of the complex stuff would be in the aspect ⌠as I see it.
To long since I was in a Facebook group. What does group moderation imply.
This may/will borde on censorship. If there are people who form a group say about sexuality or bestality or nazism or something which may be obnoxious to large number of people, you will throw them out ? Wouldnât that be majoritism?
I do hope that censoring or moderation is the rare thing (the lightest touch) rather than what is being talked about here.
@shirish Moderation within the group. That means that if you create a group, you (or other designated moderators of that group) can moderate: delete posts or ban users from the group. Itâs censorship, but if you donât like how a group is being run, you are free to start your own.
@Brent, oh, for some reason I didnât get that. Thank you for clarifying. In that case Iâm for having moderation within a group BUT with the caveat that an admin could have a group with no moderation at all . If that is also possible then have no objection at all.
There once were groups on Diaspora : it was only one one pod maintained by pistos who had added a group feature to D* : has the code changed too much to add the "pistos code "? Or is this code not usable because of too much change ?
@loelousertranslato the code changed a real lot, rewriting is much less effort. And if it werenât that way, he implemented local groups only, we would want them to work across pods.
@Loelo TBH, I donât remember how Pistosâ groups were any different from hashtags. Maybe there was moderation? The implementation looked similar to GNU Socialâs. (Posts to the groups are marked with a ! instead of #.)
They also had an actual group page and you could log into that account as admin. And it showed up in its own drop down and you could search groups specifically.
It seems like everyone agrees that D* needs groups in some form. I would like to take this up (as final year project). Are tasks/bugs âassignedâ to a contributor in D* dev or you tackle the problem and finally make a PR saying that youâre done?
I am very happy many people got involved in this discussion after I re-activated this thread. Iâd like to summarize my opinion base on everybodyâs discussion:
Implement group functionality independently (not based on aspect/tag).
At the beginning, the implementation based on aspect/tag maybe OK and quick, but after that, for me itâs obvious that we will want to add many many features exceeding capabilities of aspect/tag. It wonât be sustainable. Also, itâs not seamless if we decide to remake it as independent function later.
Quickly implement as local function with perspective of seamless upgrade to federated one in the future. Yeah, I totally agree the ideal (every communication should be federated in D*) is paramount, but also we should realize the fact we are loosing oppotunitiy of attracting users without group function. If the local group is seamless with federated one of the future, itâs not problem.
(However, if recognized skilled developer declares his/her commitment for federated function as quick as local one, starting with federated one is of course better.)
Hi @kevinmartin, itâs great that youâd like to code for Diaspora.
There isnât an open issue that I can see in Github for the groups feature. There is this closed issue which basically attempted to port some very old groups code which was created for one pod, but which wasnât finished as Diasporaâs code base is now so different that it wasnât really workable. Still, it might inspire a point to start from.
Have a look at our wiki article on starting to contribute, and do ask any questions you have on the #diaspora-dev IRC channel. Once youâre ready, you can âclaimâ the issue in Github by opening an ticket for it, or making a pull request once have some code.
Good luck, and look forward to seeing the results of your work!
Also for such a big feature I would love to see some interaction designs being posted and discussed here first, the specifics should be laid out and maybe even prototyped before too much work on code is spent.