Topic: Creating a tag for slurs/extreme harsh language

SnowWolf said:
Well... I'm sorry if I wasn't clear enough. In retrospect, I was a bit vague... though it still seems clear to me. *shrugs* Perspective is a hell of a thing.

(I find the psychology of subtlety to be fascinating. Two people communicate and one person says something that, to them, is clear as day and the other doesn't see it at all.)

No argument there :)

Well, my point THERE was mostly "let's not shit on an idea, just because it hasn't already been discussed for the project in question" as you seemed pretty determined to tell clawdragons "This isn't a good idea"

That isn't at all what I intended. I have no objection to the idea that it would be nice to be able to blacklist using transcript:, or to Clawdragons on any personal level.

What I intended was: "That assumption is wrong."
(in the case of 'if we get transcript:, it follows naturally that we will be able to blacklist it')
and "that proposition is incomplete/ambiguous." (in the case of wildcards, as Regsmutt illustrated). AFAICS, these two errors actually do need to be resolved in the course of discussing any such feature. Clawdragons' replies went some way towards that.

EDIT: To clarify the intent, this is my experience with bug and feature tracking systems: If the request unpacks all its assumptions explicitly, and it is reasonably well grounded in the current system, that maximizes the chance it will actually get to the point of being implemented. IMO that's because it's essentially been made as approachable as possible. So, that's what the aim was : "I'd like to see something like this implemented, let's fix the flawed formulation". (The implication that "we'll be able to get this easily" is particularly troublesome IMO, because it suggests that no further problem solving is needed)

This is because you interpreted clawdragon as assuming that having transcription feature would mean it would be blacklistable.

Whereas, my interpretation of their post was "This could be an interesting addition to this potential feature."

I agree that Clawdragons' original post was open to interpretation. OTOH I consider Clawdragons' subsequent replies to indicate something more clearly like 'if we get transcript:, then it is a relatively small step to get transcript: blacklisting'.

And again, from my perspective... what existing system?

  • The basic way that the blacklisting system works (ie. it runs client side, so it only gets access to whatever data the server has already returned.)
  • The need to rapidly return results for /post/index/*
  • The way metatags work (affects blacklisting code, tagging code, and searching code.)

This does not seem to me to indicate it's impossible. For example, possibly the blacklisting code could use some new/updated API to fetch transcript data (and cache it, thus mitigating server load) after the page loads, and finally use that to apply complete blacklisting. Since a majority of posts would have no/empty transcript, that could be an efficient strategy.

This would be a notable change to the current design (blacklist code doesn't talk to server, hence it's relatively fast) and would warrant discussion, though.

Updated by anonymous