Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Notifying each other that a commented-on issue is resolved, to produce fewer comments rather than more
I just made a comment on another Meta post because I wasn't sure whether something in someone else's answer was a typo, or if so what the correct wording should be. It turned out that my best guess was correct, and I got a comment in reply to that effect (along with the author editing the post).
I figured at this point that I should delete my own comment, as it has served its purpose. But now I see a problem, that applies generally.
Presumably, me deleting the comment doesn't send any kind of system message, so now the author's "thanks, you were right" comment is orphaned. I could flag that for removal, but it seems heavy-handed to involve moderators for something like that. On the other hand, commenting in order to convey that I deleted the first comment and that the whole thing can be cleaned up now, is... clearly counterproductive. I can imagine this getting out of hand in extreme cases, like the classic "no, you hang up" routine.
Is there a more streamlined way we could handle these kinds of situations?
(Also, just to make sure: will a comment thread disappear from the ordinary-user UI, if every comment is deleted from it?)
It is worth noting that we don't need to have the thread be deleted. Threads on Codidact can be locked and archived. Arc …
1y ago
One advantage of threaded comments is that the exchange isn't in anybody's way. If User A posts, User B comments, User …
1y ago
Go ahead and flag the whole comment thread as no longer needed. I'm a moderator on EE, and wouldn't mind receiving su …
1y ago
The exchange that provoked this question, happened on one of my answers. I wrote the response to you, to acknowledge …
1y ago
Suppose we have a post author A and a comment author B. Here's a simple proposal for addressing the problem. When B …
1y ago
5 answers
It is worth noting that we don't need to have the thread be deleted. Threads on Codidact can be locked and archived. Archived threads are still available for viewing, but cannot be commented on[1] and are hidden behind a "view more" button under the post.
Currently, only moderators can archive threads. However, we could think of letting any participant archive (and unarchive in case of further feedback - see footnote). Hopefully no one would abuse it, but restricting the action to participants and having other parties able to reverse archival would mitigate that. In addition, naturally, moderator archival would not be able to be overridden.
Codidact should ideally notify anyone following the thread when it is archived, but it doesn't right now - I've created a GitHub issue to track this.
-
Though I've proposed to change that. There is also a suggestion to add a "resolved" state, which like archived would put hide it, but leave it available for further commenting. ↩︎
0 comment threads
One advantage of threaded comments is that the exchange isn't in anybody's way. If User A posts, User B comments, User A says "thanks, fixed", and nothing else happens, no harm done. If that's the entire thread, either of them could flag a comment and say that the entire thread is now obsolete.
Comment threads under a post are shown in order by last-update time, so newer threads will push the "dead" one down and eventually out of (default) view.
Comment noise isn't as much of a problem on Codidact as it is on Stack Exchange because comments aren't a single list of top-level comments under a post. Feel free to clean up, flag, or ignore stale threads. If there are a lot of comments or comment threads on a post and the obsolete ones are getting in the way, please flag to let someone know. Mostly we don't expect this to be a problem because of the way we designed comment threads.
Go ahead and flag the whole comment thread as no longer needed.
I'm a moderator on EE, and wouldn't mind receiving such a flag. Maybe some day when site activity gets much higher that might be an issue, but not now nor any time soon.
I'd rather get the flag than have a useless comment hanging around.
0 comment threads
The exchange that provoked this question, happened on one of my answers.
I wrote the response to you, to acknowledge your helpful comment, and to notify you that you were indeed right. In addition to pointing out the typo in my post, you also said you were unsure about what I really meant. As such, I wanted to give you a ping, so you'd be notified the issue was resolved. I then flagged your comment as "No longer needed", and expected you to do the same with mine once you had read it.
Had you only pointed out the typo, and not also written that you were unsure about the meaning of my text, I would have just marked your comment as NLN, and omitted replying. Although, the correct course of action if you are fully convinced it's a typo, and what the correct text is supposed to be, is to suggest an edit to the post.
Currently, Codidact only has custom flagging reasons for comments; there should also be "spam", "rude/abusive" and "no longer needed" in addition to the custom moderator flags. This better tells the user the expected uses of comment flags, and for the case of NLN, that flags are not necessarily a harsh way to deal with content. This is the same way it works on SE. There's also the possibility that Codidact should explore another way of handling this matter. The proposed solution of this answer is merely a slight improvement over the SE way. It's not necessarily the best way, and I'm open to other ways of doing it.
It should be preferred to avoid moderator intervention for this simple matter. In addition, the volatile "thanks + elaboration" is sent to the feedback giver for a reason; it's preferable that this isn't purged before the recipient gets the chance to read it. (A "thanks" without elaboration is pointless, and shouldn't be posted in the first place).
One way to solve this, is to notify users once their comments are marked NLN. For this specific case, it would be clear from the revision history of the answer what the "elaboration" of the comment would have to be. This still requires that the user then manually deletes their own comment. Experienced users should have no issue with this, but new ones are likely to find this confusing.
Another way is to let users mark their comments as automatically deletable by NLN flags from a specific flagger, that being, the one they pinged, either explicitly, or implicitly. This would let a feedback receiver remove the feedback once acted upon, although it also allows them to misuse this ability to remove said feedback without acting on it. That may sometimes be a mild abuse, though in most cases, likely just due to a misunderstanding.
0 comment threads
Suppose we have a post author A and a comment author B. Here's a simple proposal for addressing the problem.
-
When B writes the comment, the UI offers B a checkbox to "allow A to propose resolution" to the issue.
-
If that option was chosen, when the system notifies A about the comment, it indicates the possibility of proposing a resolution by replying after making any necessary fixes. (This might include not fixing anything and replying e.g. "no, that's exactly what I intended it to say".)
-
When A makes the reply comment, there would then be an option to mark the comment as a resolution of the issue B raised. As usual, B is notified by the system of A's comment, and can thus see A's assessment of the situation along with any edit that was made to the post.
-
When this process has been followed all the way, then B would be given an option in the interface to delete both comments, simultaneously. (This might generate a system message back to A, without any corresponding new comment.)
Cooperatively extending permission like this ensures that both parties are on the same page, and can't trample on each others' rights and freedoms as a Codidact user - all without needing to get anyone else involved. This would be especially useful for comments made to indicate a problem with a question - perhaps ones that are prompted by an enhanced flag-for-closure interface.
0 comment threads
1 comment thread