Comment moderation tool: disemvowelling et al

[azurelunatic]

Title:
Comment moderation tool: disemvowelling et al

Area:
comment moderation

Summary:
Introduce a reversible "mask" that may be turned on at a comment-by-comment level by a journal owner or community administrator, that initially displays a particular comment slightly obfuscated, serving as a warning that anyone who puzzles out the comment as displayed, or goes through to read the full version, that they do so at their own risk.

Description:
Current comment moderation tools involve leaving any possibly problematic (for any reason) comments in place, adding more comments, deleting the possibly problematic comment(s), screening them so only the journal owner/admins and the comment creator can see it, and disallowing any new responses to a particular comment or thread.

Missing from this toolbox is an option that leaves the comment in place, but in a way that clearly signals to a reader that while they *can* read this comment, they may not *want* to, and in a way that is friendly to the sort of fast reader who can take in a paragraph at a time before their brain has caught up with the idea that they may not want to read that, but also in a way that is friendly to someone who already struggles to read the text as presented.

Unlike similar tactics on self-hosted blogs, this would not involve actually editing the comment left by the other party. It would alter the display of the comment, with a clear notice that the display had been altered, and a control that any reader could use to view the comment as originally written.

This could be used for abusive comments, controversial/flamebait/triggery topics, and probably also spoilers and content warnings, and for comment-space games and other fun uses. (Owners might like the ability to proactively turn this mode on to set every comment this way at posting time, for entries likely to collect heated response, or for games. Commenters might like the option to self-moderate in this fashion for games and potentially triggery content.)

Options for the form of alteration could include:

Disemvowelling, where all vowels detected in the original are removed, making text that can often be puzzled out slowly without reversing the obfuscation. Can be read faster by someone who's used to it, makes hash of most HTML included. Popularized & I believe invented on Making Light, where I believe it's done by hand. Suitable for English; not so suitable for languages where vowels are implied rather than stated already; can be trivially defeated by writing in 1337 and other character-substitution methods; would need to have non-Roman vowels identified also.

ROT13, where all characters are moved around 13 places in their alphabet. (This is most useful for alphabets with 26 letters.) This makes text that most readers have to work through character by character, but some very experienced readers can read through at speed. Many existing ROT13 functions leave punctuation and non-English characters intact.

Display of a warning message without context derived from original text. No chance of something leaking through due to algorithmic shortcomings, because nothing would show; 100% chance that anyone wanting to read the comment would would have to request its display, causing a certain amount of potential extra server load.

Display of a warning message with optional context (similar to a comment edit message) to be provided by the journal owner/community admin. For screenreader users, the context should probably appear before the control to reveal the original comment.

Poll #7753 Comment moderation tool: disemvowelling et al

Open to: Registered Users, detailed results viewable to: All, participants: 67

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
23 (34.3%)

Should be implemented with changes. (please comment)
14 (20.9%)

Shouldn't be implemented.
15 (22.4%)

(I have no opinion)
14 (20.9%)

(Other: please comment)
1 (1.5%)

Comments

[axiom_of_stripe]

I'm not a big fan of trying to obfuscate text -- because no matter how complicated it is it never quite handles all of the cases -- but I wouldn't mind the ability to force the collapse of a comment with some indication given that this is different from the collapsing which occurs when comment threads go deep.

[jumpuphigh]

I like this idea. Perhaps include a cut tag so that the journal owner can indicate what the problem with the comment is.

[azurelunatic]

So like the 4th option I described?

[jumpuphigh]

Yes!

Hi, I only read the summary. :D

[existence]

This, although if we're going this route it would be nice if the commenter could turn it on themselves: it would make a effective spoiler/trigger warning and obfuscation system.

[axiom_of_stripe]

It seems to me that if commenters use this themselves, the next request will be for something like cut tags within the comment so that only part of it is hidden -- although I suppose it's easier with comments than it is with posts to have two related items, eg, "Here's my non-spoilery comment" replied to with "[hide flag: spoilers] and here's the part with spoilers."

[existence]

It would probably be the easiest way to use it if there was an ability to partially screen a comment. I would be partial to either, honestly.

[existence]

Er. Screen as in screen from view, that is, to be clear.

[archangelbeth]

I see this usage a fair amount on some forums -- "Spoiler" is a button, and then you click and the spoiler unfolds.

I also know a forum which can use "spoiler text" (I believe forums.sjgames.com calls it "fnord" text?) which auto-maps the text color to be the background color (whether it's on the forum's posting background, or quoted-text background). You read by highlighting the words, and there are blank lines there. TVTropes also does this form.

[susanreads]

This sounds like a good implementation.

[azurelunatic]

So like the 4th option?

[axiom_of_stripe]

Yes; the third option doesn't seem as useful, especially since it should be easy enough to have a "reason" field. I mentioned specifically that it could be modeled on the existing comment collapse because that shows the commenter, which is very useful for getting a sense of a hidden conversation (and then I forgot to say so, oops).

[thorfinn]

+1 Do not like obfuscation for the same reasons.

*ponder* This seems to me to be exactly like cut text, except around the entire comment/post, and able to be set by whomever has permission to screen the comment/post?

Can you cut text in comments? If you can see this without clicking, it doesn't work.

[msilverstar]

I love the idea of a cut-tag like collapse/expand option. The journal owner, community maintainer, and original poster should be allowed to set the option and label it.

[sofiaviolet]

I like the fourth variety of comment obfuscation described in the suggestion.

[ninetydegrees]

Another vote for the fourth option.

[delladea]

I like the 4th option as well.

[tamouse]

+1 for 4th option

[elf]

Much as I love disemvowelling, I can understand the problems with many languages and the fact that it's hard to reverse for comprehensibility. I do like the idea of "collapse this comment" as a journal/comm owner option; that seems a terrific way to hide spoilers or potentially offensive content without turning a conversation into swiss cheese. An ability to tag it with a warning--maybe a 25 or 50 character limit? Dropdown seems unlikely to have enough scope, but if that's a server-load saving option, maybe a small collection of options?

Ideally, the collapsed comment would be collapsed even if the thread around it was expanded & need to be opened individually, but I could understand if that took too much special coding.

[azurelunatic]

I was thinking that the "reverse" would be "view original", so nothing from the original would actually be lost.

For a warning, I was thinking the same character limit as the comment edit reason field. "Server load" in the context I meant it, was that choosing to expand the comment to view it in all its original glory (questionable though that might be) would probably have a similar cost to other inline expansion, and if the warning on the comment was written accurately, then there might be a small savings in server load when people read the warning/description, and decided that assuming that label was accurate, there was no need for them to read the whole thing, versus a comment that was collapsed with no ability to describe the reason for forcing it to collapse, so people would have to expand it to have any idea of what it contained.

It makes equal amounts of sense to me that an "expand all collapsed comments" command would open force-collapsed comments, or open only the naturally collapsed comments and require a person to evaluate the force-collapsed comments individually.

I see two solutions to that: reader-side, MORE OPTIONS! -- to include force-collapsed comments in expand-all; on page display, include an "expand all including force-collapsed" in addition to an "expand all autocollapsed" thingy. The latter actually makes sense because Not All Comment Threads Are Created Equal.

[jumpuphigh]

Do we currently have an "expand all collapsed comments" command?

[azurelunatic]

Not yet.

[azurelunatic]

Now we do! ^_^

[jumpuphigh]

LOL And I love it!

[zaluzianskya]

Voting for the fourth option, if only disemvoweling and ROT13 wouldn't really make sense for people writing in Кириллица or ひらがな.

[chagrined]

Another vote for the fourth option! :)

[deborah]

If we do implement this, please only do the fourth option. I'm pretty sure we've talked about disemvoweling before on this community, Though I can't find the entry, and I know I'm not the only person who said they find it actively hostile. Sure, those of us to do could avoid journals and communities with disemvoweling, but I don't even like the idea of implementing it.

On the other hand, a collapse of a moderator (or in this case, journal owner) voted-down comment is a fairly standard blog functionality, without any of the emotional issues of deisemvoweling.

[kate_nepveu]

Even though I use ROT13 a lot I wouldn't want the site to privilege it over a cut-tag/collapse model, which is my "as-is."

[kyrielle]

I could live with any of these but I really, REALLY like the fourth option. I'd suggest as well that if the ability to pre-collapse comments is added (as you say, for games/posts likely to grab triggery content/whatever) that the post author be able to specify a reason text for those when creating the post. So, if Joe creates a game post and turns this on, he could add "Auto-collapsed at comment time, due to nature of post". Then he could come along later, and if someone had said something that deserved a different collapse-text, change it.

If the user posting the comment can do this, need to consider: can they specify the text? (I think yes) Can they edit the comment to change that text? Can they edit that comment to change the text if the journal owner has changed the text? Things like that... Except on the first one I'm not particularly sure of the answers here.

[azurelunatic]

I would think comment poster edit the comment to change collapse text could follow comment edit rules (yes, if they can ordinarily edit comments, unless the comment has been replied to) and if the journal owner has changed it, that should override the comment poster's settings. I have seen comment screening edit wars between LJ community maintainers and entry posters, and they are not pretty, so my vote goes in the direction of person-in-most-charge calling the shots. Comment creator/entry creator is still free to delete, of course.

[ex_awakened208]

I also like the fourth option and think it would be useful for the commenter themselves to mark it with a warning if they saw fit. It may be a good idea if the journal owner/community mods have an option whether they would like a commenter to have the ability fill in context or not.

[voldsom]

Another vote for option four. I like the addition that as well as community admin/journal owners being able to flag a comment, the commenter themselves should be able to. I could have used the ability to self-flag something yesterday. :)

I can't decide if the warning should be generic (comment titles being enough to indicate why a comment might be flagged as collapsed), or whether you'd want the overhead of an additional content warning field. Probably the latter, since other comments agree with that. I'm not so sure about a comment cut tag, it's a good idea, but it feels like separate functionality, plus it's very much within the sphere of the original commenter, rather than a tool that the community admin/journal owner can use for moderation.

Sub note, the original emphasis is for external moderation, which might make this comment moot, but if it's extended to self-moderation (eg, I'm flagging this comment as triggery, so people can read it in a controlled manner) I assume that this functionality would also need to extend to e-mail and inbox notifications, as well as comment pages themselves.

[azurelunatic]

For emailed comment notifications, I still support including the whole comment, but with the warning prominently on top, and perhaps scroll space / a bit of null content so that if someone wanted to stop right there they'd be able to.

And I hadn't even considered what should be done with emailed notifications for *replies* to the comment, because there would be cases where people other than the comment poster would be getting those email replies, and the original comment is included along with the thing. (Cases include: any time someone who would have already read it once might not welcome stumbling across it again in their inbox; where the person replying is not the entry owner and the entry owner gets another copy, where the person replying gets notifications of their own comments, if someone not participating in the discussion has subscribed to the thread, individual entry, or all comments to the community.)

[voldsom]

I agree with including the whole comment in an e-mail. That makes sense, because it means that there's no immediate need to visit the site to actually read the comment.

*ponders* I'd forgotten that comment replies requoted the comment for context. In this case, would it be appropriate for the e-mail to not re-include the text, just the warning... In this instance, everybody receiving the comment reply 'should' have already seen the original comment, so there's perhaps less of a need to include it in the body of the e-mail.

[kyrielle]

Probably, except for one edge-case. I sometimes reply to entries or comments in other journals, in part to email myself a copy of them because I want to rememeber them. It's unlikely to apply to the "triggery" things but might well apply to contest or game things if they also have a fiction or poetry bent. Being sent only the warning, because I'd already seen the content, would not meet my need there.

It's not something I do often, however, and losing it in this case would be an okay compromise for me. What I don't know is if there are others who do something similar more often and might be more heavily affected.

[azurelunatic]

I do it a lot, and would not be okay with losing it.

[voldsom]

My brain is still circling around options on this, but I agree. Since there are people who use it this way, I'd rather see the content in the e-mail than excluded.

[syderia]

Count another vote for the fourth option.

[lorax]

My with changes was for the fourth option or something similar as well.

[green_knight]

I love the idea of hiding/masking comments, particularly when they're inflammatory. I have no real comment on the implementation - other than that it needs to work for all languages, which disemvovelling sadly doesn't (but it's a genial solution- it reduces exposure for trolls while not removing evidence).

[ninetydegrees]

Just noting that disemvowelling has already been suggested: http://dw-suggestions.dreamwidth.org/276646.html

The things you find while looking for something else...