Threaded discussion is ultimately too complex to survive on the public Internet?

It appears there’s a new chat threads feature. I read through most of it. Is it the same thing that people are asking for here?

1 Like

@vel, I’m not sure. I just want threading like Lemmy and Reddit have, but the description of that feature seems convoluted at best.

1 Like

First, I love the discussion format of Discourse in addition to many of it’s other carefully crafted designs but I also, for some topics really like the threaded design for delving into a specific comment a user makes. I am hoping chat threads addresses this if not already.

I understand there are issues with threads but I think in some discussions they are appropriate and if anyone can solve the issues with them I think the people here could figure that out. Specifically, I think it’s an organization preference. How do you want to organize this discussion?

My main reason, is at times, I want to see who replied to who and I want to reply to specific comments.

2 Likes

There’s some similarity, but threading is only available in chat channels. There’s currently no plan to add threading to topics.

1 Like

If that’s the case, is it possible to add support through a plugin?

1 Like

Anything is possible using a plugin, but it would be a complicated task.

One thing to note for anyone looking to try, is that we’ve just started modernizing topics to remove our custom widget system and utilize the latest version of Ember (which will probably take a couple months) — so now would be a bad time to start.

4 Likes

This has changed in recent years. When there’s a good discussion topic the threads can be helpful in organizing threaded responses.

It’s been 6+ more years since this post. Maybe the worldwide community have matured some with regard to threading? And I want to make one distinction, the sorting of first level replies used by the social media sites aren’t what I’m interested in. I’m interested in being able to reply to a specific comment and seeing that indicated and not getting lost.

I understand there are reasons someone might not like threading. Why? What are those specific reasons? Please discuss

PS I don’t think anyone’s asking for replacement but some sort of optional support (maybe in the future or by a plugin).

1 Like

Discourse is heavily focussed on Moderation activity (which is healthy for a community in general).

Posts diverging in subject tend to be moved to another or new Topic.

That’s the Discourse way.

But sure, a plugin …

2 Likes

Quoting would seem to solve that problem, largely. Also, if you click the “Reply” button on a specific post, rather on the topic as a whole, your post gets marked as a reply to that post, and you can expand those replies from the original post.

4 Likes

It doesn’t solve it for me whatsoever, @mpalmer. It certainly allows me to ascertain the context (whereas without that functionality, that is impossible, except by mere assumption) but doesn’t make following a specific conversation any easier.

2 Likes

What does that mean? There are two ways to make plugins and the original method is being removed?

2 Likes

It means the code is currently in flux, so it might be worth waiting until the refactored code has hit Production before writing the plugin or Theme Component to save you time and effort :slight_smile:

5 Likes

Couldn’t you write a plugin based on the previous version and then update it if need be?

Obviously, @vel, but why would anyone invest the work to do that when they know they’ll need to rewrite it after the update?

1 Like

I think Discourse has the idea of allowing conversations to thread themselves into new topics, I think it just doesn’t make it that easy for people to 1) create such linked topics or 2) see much detail about the linked topics.

I’ve probably said it before, but I see Discourse as like having one large conversation around the table where everyone is involved, where it goes one person by one person in a linear conversation.

Now, in real life, the large tables often fraction into smaller conversations, which I think people would call threads. Maybe the Discourse analogy is that the main table wants to stay on one topic, and so a few people jointly decide to leave the table and to go another table or another room (often a linked topic).

In real life, one can sometimes have visibility into why those people are leaving and what they want to talk about, how many people are there, what the energy of the new discussion is like, etc.

On Discourse, right now, I think the only visibility we have into the new discussion, while remaining at the current discussion, is a list of link icons with the title of the new topics:

What if that could be more detailed? Show the new topic category, tags, number of people replying to the topic, etc? Maybe also even if the topic started by someone clicking the “reply as linked topic” button within the topic vs. someone in an already existing topic posting a link to the current topic?

Right now, I have to remind myself to look at the linked topic links and honestly, each time I click them, I don’t know what I’ll get on the other side of the click besides the topic with that title.

So I wonder if it’s not about rebuilding Discourse to allow nested conversations, but rather to just highlight the linked topic feature and tweak it a little from the ease to create them and also the ease to see what exists within them.

1 Like

@vel, please go ahead and write this plugin now and you can then update it when the new code is deployed. Your enthusiasm is clear and I’m sure you are prepared to spend the time required.

1 Like

I believe that Discourse would have more customers if it had threaded support (native or plugin) (let the owner of the instance choose to use it where it makes sense).

I don’t know if it would be more work or not to work on it now versus later. It depends I guess. But, by the process of working on it, whatever one would get working one can probably reuse that code or that experience if it needs to be rewritten. By working on something now, it might be better, so that a refactor would include any API that might be needed.

I write plugins for work (over 10 years experience) so I don’t have an issue with that. But I haven’t written plugins for Discourse. I would write one if there were funds raised for it (for various reasons - I don’t want to start and get pulled away because of financial issues). Or I’d contribute to someone else writing one if it had the features I was looking for.

1 Like

@vel,

Depends upon what?

That’s dependent upon how much and what changes during the restructuring of their implementation of Ember.

That sentence is meaninglessly vague, and somewhat nonsensical anyway.


I wholeheartedly agree.

Yes. This is what it depends on. I don’t know what’s changing and what Ember has to do with it. If the plugin API stays the same then it doesn’t matter if I start now or later. If the API changes, then if I’m working on it now and they are working on a refactor now then they can receive feedback on what APIs I need.

If they are rewriting Discourse itself in the Ember SDK then no, I’m not going to spend any time on this.

1 Like