Some topics, like a call-for-bug-reports or a new Howto, will receive a lot of replies that go stale shortly thereafter because the appropriate fixes/edits were applied as a response. When closing or marking as solved doesn’t make sense, the best solution to date is to delete these replies.
The act of deleting genuinely helpful replies really bothers me. A human “thank you” covers it pretty well, but if Discourse could do a better job as a record-keeper I think it should, and the core functionality for this appears to be in place already.
How manual summaries would work
Click moderator wrench
Click select posts and select the ones you want to show in the summary
This forces a summarised view of this topic by default. You get pretty much the exact same effect as you get from deleting posts, except the “public record” of helpful replies is maintained.
To view all replies, you simply click the “Show all posts” button.
p.s. This is a fairly legit core feature, but I think it makes just as much sense as a plugin since it adds more admin panel options & moderator UX that most admins/mods shouldn’t have to concern themselves with.
It would be helpful if when a thread like that is closed, the moderator that closes it was able to do some tidy up.
I think your spec improves on my request here:
You haven’t specified how one would go about creating the summary, but I’d assume it’s the standard “select posts” by checkbox UI.
As an aside, I appreciate the commitment you have here on meta.discourse to moderation for maintaining a usable community. For context however, I don’t think deleting comments is something that can be taken as lightly on our own forum. Since we’re dealing with people who may be upset, removing their comments could be seen as covering up complaints, and may even have some legal repercussions. That’s why I love this feature request, as it allows us to make the most important information readily accessible within those constraints.
I didn’t? I thought that’s what I did under “How manual summaries would work”. The flow is the same as when you as a moderator select multiple post and get the choice to delete or move them, except now with the addition of creating a summary.
Hmm… would you really bother manually summarizing that topic though?
For how-to and other wiki or wiki-like topics, maybe it’d make more sense to be able to “mark as resolved” any reply which would then hide it by default with a single click? (Along the lines of how Google Docs handles comments…)
Doesn’t bother me in the slightest, so I’m not sure how much support this will get internally… remember those “helpful replies” were resolved and summarized in the first post, so it’s not like the feedback was ignored.
I think the distinction here is that these (at least, the way I am thinking of it) are temporary topics representing a brief, transitory moment in time, and rapid changes, after which the topic will be basically obsolete, minus a manually composed summary of what changed.
That’s what I recommend in this case: edit the first post to summarize. This is already possible, and a superior solution in every way.
Otherwise this becomes a painful exercise in manual curation which just seems so unlikely to actually happen in practice, and on top of that, if you are going to spend the time manually curating it would be a far better use of that time to edit the first post – which is all most people will ever read anyhow. Very, very few people are going to take some manual action (even if it’s just “click this button to summarize”) versus passively scrolling through the first post at the top.
TL;DR I am kind of strongly against this on a lot of levels.
Well we’re just talking about different aspects of the same feature. In a topic with with 100 replies among which only 3 are relevant, you’d want to hand-pick which replies to feature in the summary. In a topic with 10 replies among which 4 are relevant, your approach would be easier.
The real key feature here is to be allowed to manually do either of these things (as opposed to the 50+ replies requirement and algorithm-based picking), and to have it be turned on by default.
Even in this case, it might be easier to “check them off” as they are resolved, assuming they are addressed in separate edits over some period of time.
I love this idea, but for a very different use case.
My favorite use of forum software is with online text based storytelling (role playing in character). It’s often done in play by email games for the diplomatic aspect of the game.
Often times the story goes on for a long time in a thread. Conversations are supposed to be in character, but sometimes folk get distracted and go out of character and sometimes there is a long subthread where folk with a lot of time on their hands get a bit wordy.
When they go out of character they should be deleted, but if they are plodding through something in character, whether in an unentertaining way or in an entertaining way that doesn’t move the plot forward, it’s important to be able to look at the details of what happened in the actual words of the original authors, but be able to de-emphasize the noise and just focus on a half a dozen posts that summarize the results in a non-destructive way so that folk that are new to the game can get caught up with what happened without having to read the whole thing.
Just something to consider as I hope discourse will become the vehicle for this sort of game in the future.
From a forum “guardian” view, I like the idea of being able to “collapse” or “demote” certain posts to improve the reading experience for others .
But I’m wondering how members might feel if they had a post “downgraded” as it were.
As it is now the Summary is automatic so that gives an out to some extent.
But if it were done by forum Staff, needing to justify the editorial decision could be a bit sticky. eg.
Your post wasn’t really bad enough to delete outright, but we think it’s low quality so it’s been taken out of view unless someone explicitly wants to see it.
Hey Correct me if i’m wrong but can’t we use Natural Language Processing Based Automatic Summary Extraction Using various techniques like (TF-IDF,TextRank,LexRank) from the replies selected and also using some context features(like upvoted replies).
We can used Python NLTK in rails code for summarization purpose or something like http://stanfordparser.rubyforge.org/ which is ofcourse less powerful than NLTK.
Firstly, algorithms aren’t relevant to this spec, since this is specifically about manually creating summaries.
Secondly, even as a feature for the automated summaries that we already do, Natural Language Processing is way out of scope for us (and I’m not convinced it could actually work well for our diverse use cases).
How would it be any different than the existing Summarize button which works automatically (feeding off likes, read time, link count, bookmark count, etc) and requires zero time consuming human moderation?
Not to mention that this sort of human summarization is already 100% possible with the existing systems we have in place without building Yet Another System that someone has to implement, understand, and maintain.
The more I look at this spec, the less I like it. And I did not like it much to start with.
No, no. Jeff. I was agreeing with you, or I suppose, retroactively agreeing with you.
I always look at how someone’s proposed feature may benefit or be used by most communities using Discourse, but I do not say it always to mean “I support 100%”. I say it so others may decide if it be worth to rally behind a proposed feature if they want that benefit; said benefit(s) I pulled from some swift thinks.
For massive posts deemed “historic” one can lock the topic, tag it or move it to a category for these types of topics (yes, for my community, this was how it was done). Manual curation can be as simple as a note edited in/wiki’d onto the OP.
Staff Note: <note>
I look at everyone’s side and state it, even if I necessarily do not agree with them and their whys. Inhuman humanitarian. Or, I just allergic to BS, even my own.
In short: I agree. The summarize topic feature plus edited-in note to OP plus lock-thread and move/tag should suffice.
