Feature Discussion: Groups

(Jakobu/Katharsisdrill) #21

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.

(Jakobu/Katharsisdrill) #22

I guess the groups could actually be below the aspects, separated by a thin line in the already existing dropdown-menu.

(shirish) #23

A sort of oldish newbie here. I know that’s the contradiction/irony there but that’s life as we know it :slight_smile: . 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 :slight_smile:

(Birch**) #24

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.

(Jakobu/Katharsisdrill) #25

@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.

(shirish) #26

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.

(Brent Bartlett) #27

@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.

(shirish) #28

@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.

(Jens Nyborg) #29

Thinking about mailing list.

From the point of view of your e-mail program the mailing list is just another account, just like any other.

Similarly a (set of) group(s) might be implemented as a diaspora account that, to external pods, look exactly like any other account.

They would have to have some automated client behind them but except for the need to connect that client diaspora need not change anything.

What do you say? Are there things you would want from groups that cant be done this way?

(Elm) #30

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 ?

(Jonne Haß) #31

@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.

(Elm) #32

I see. I was expecting that answer. Thx

(Brent Bartlett) #33

@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 #.)

(Birch**) #34

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.

(Kevin Martin) #35

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?

(taro-k) #36

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:

  1. 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.

  2. 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.)

(goob) #37

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!

(Jonne Haß) #38

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.

(Kevin Martin) #39

@goob Thanks! The wiki looks very useful. I’m afraid that we cannot start right away.

@jonnehass We will definitely come up with designs and do discussions before spending too much time on the code.

Thanks a lot. I hope I can do something useful here.

(Jakobu/Katharsisdrill) #40

@Kevin Martin - Great to hear that you will try to make this happen.