# > Josh thinks that ignores are one of lily's irritating features.  They are
# > its fatal flaw, much as "ops" are on irc.
# > Josh thinks ignores fragment the community in irritating ways.
# > FeRD says, "So does real life."
# > Josh thinks that they violate most of the concepts that make lily a good
# > CMC.
# > FeRD says, "There are people I ignore at parties, too. It's a basic fact
# > of communication."
# > damien thinks that private ignores are useful, at the least.  Public
# > ignores could be argued against.
# > Josh says, "Good point damien.  I guess I should amend my rant to include
# > public ignores only."
# > FeRD says, "I've complained about the '/ignore' output in -lily-dev at
# > least once, as has GArrow. (Since he's the expert on being ignored.) Feel
# > free to join in."
# > Josh says, "/ignore output?"
# > FeRD says, "And as for fragmenting the community, Josh, it's only if the  
# > person doing the ignoring isn't clued enough to REALIZE they're ignoring 
# > someone, and to use '/review' judiciously. 8)"
# > FeRD says, "The fact that /ignore doesn't tell you HOW/WHERE people are
# > ignoring you."
# > Josh says, "Isn't that totally pointless, FerD?"
# > Kazrak says, "Out of curiosity, was that the complaint that got him
# > depermitted from -lily-dev?  I assume he broke Christian's no-profanity
# > rule, yes?"
# > Josh says, "Ah."
# > FeRD says, "No, it's not entirely pointless. By default, I'd like to
# > not-see certain sends. However, I like having the option to retroactively
# > undo that."
# > Josh says, "I'll see if I can fix it to tell how/where you are being
# > ignored."
# > Josh says, "FeRD, that's a perfect validation of my contention that such
# > things belong in the client."
# > FeRD says, "That would be very cool, but you should find out about
# > theological objections to that first. There may be some REASON it doesn't
# > work."
# > FeRD says, "I certainly don't argue with THAT."
# > FeRD says, "Did anyone?"
# > Josh says, "I don't know :)"
# > FeRD says, "So you're just preaching to the choir again?"
# > damien finds /gag more fun than /ignore. :>   
# > Josh says, "OK, here's my statement, then :)  Public ignoring fragments
# > community.  If someone insists on doing it, let the bastids do it in their
# > client, where, presumably, they can choose to re-show the sends they are
# > omitting.  (for example tlily's %gag)"
# > FeRD mrrfs at damien.
# > Josh contemplates implementing /gag in the server :) :)
# > damien thinks that having the person being ignored able to know that they
# > are being ignored is useful.
# > FeRD says, "Agreed. Score one for server-ignore."
# > damien notes that tlily2 does not, and will not, support retroactive
# > ungagging.  Complicates the UI code far, far too much.
# > FeRD says, "(Or at least some CONCEPT of "ignore state management" in the
# > server.)"
# > Josh says, "For privates i can see that.  For publics, fuck that..
# > Ignoring someone publically is a social problem, not a technical one.  I
# > don't like the concept of standing in a public room talking to people and
# > completely ignoring ONE person.  That makes no sense.  You can choose to
# > ignore them in your brain, but such a thing should not be enforced
# > magically by the acoustics of the room."
# > FeRD can only _IMAGINE_ how much people would bitch if they didn't know
# > they were being code-ignored and thought they were just being
brain-ignored
# > .
# > FeRD says, "Are you listening to me???" "I just _SAID_ that!"  "Hey,   
# > idiot, open your eyes!"  etc, etc..."
# > Josh doesn't udnerstand why damien says that... why can't it just be a  
# > "color", which happens to mutate the characters?  It won't change their
# > layout... (/redirect -tigerlily)
# > Steve usually brain-ignores -beener altogether. :)
# > FeRD says, "Yes, well, -beener as a community expects that. 8)"
# > Josh says, "That is my point, FeRD.  Code ignoring in public rooms is
# > STUPID.  If some doof wants to hack that into his client, it is HIM being
# > antisocial, not the system."
# > FeRD says, "But code-ignoring has the bonus of making the ignoree realize
# > they're being ignored, and thus not try to get the other person's
# > attention by publicly being extra-annoying."
# > FeRD says, "See my above send about the number of "Are you listening to
# > me???" sends there would be (IMHO) without server-ignore."
# > Josh says, "So would mr. anti social saying "I have modified my client to
# > ignore all sends from you.  Neener neener.""
# > Tex neeners at Josh.
# > FeRD says, "Um, and they'd know to say that how? The ignoree would
# > REMEMBER and keep track of that how?"
# > Kazrak notes GArrow's reactions to Aragon's questions in -computer
# > yesterday, where he ranted about how stupid Aragon was and complained to
# > all that Aragon should stop ignoring him so he could get the right answer
# > and shut up sooner.
# > FeRD says, "I like the fact that I can, at any time, find out who's     
# > ignoring me. I don't want to try to remember."
# > damien sympathizes with GArrow there.
# > FeRD says, "You're using GArrow to argue a larger point?"
# > damien considers that an argument against public ignores, actually.
# > FeRD says, "Oh, it is."
# > Kazrak isn't arguing any point.  He's just pointing out the way the
# > situation stands now.
# > FeRD says, "But there are no perfect solutions here. Of course there are
# > arguments against public ignores! I don't think they're compelling,
# > personally..."
# > FeRD says, "There are arguments against income tax. I still think we   
# > should have it."
# > Josh says, "FeRD.  My point is, if someone wants to behave some way,
# > that's fine.  They can do that, either mentally or by modifying their
# > client.  But providing a mechanism for public ignores in the SERVER
# > encourages dysfunctional social structure, IMHO.  If someone is hellbent
# > to implement such a beastie, they can feel free to do so in their client,
# > in a sub-ideal way.  This is a given.  My point is that the lily server
# > defines the rules of our interactions, and IMHO it should not provide for
# > behavior that is so divisive."
# > damien says, "Hmm.  Ignores are the smaller, more personal version of
# > /depermit.  Rather than booting a person from a discussion, individuals 
# > can simply ignore that person in the discussion.  Consider GArrow, the
# > poster child for /ignore.  He can be quite vicious -- to the point that
# > there are people who have no desire to coexist in a discussion with him.
# > The choices are: a) /ignore GArrow, b) /depermit GArrow, and c) have the
# > offended party /quit any disc GArrow is in.  /ignore offers a better
# > alternative to booting people from discs (which will lead to IRC-style
# > status games over ops) or having people chased from public areas."
# > FeRD is more into the "If people are going to do it anyway, provide them
# > the ability to do it in the least offensive and intrusive way" model,
# > personally. SOME support for ignores in the server would facilitate that.
# > Client-side-only-ignores have the potential for annoying ME far more as an
# > impartial third party. I don't WANT to watch damien talk himself blue in
# > the face trying to get tanman's attention while tanman is ignoring him. I
# > want him to type "/ignore", realize his sends are going unseen, and shut
# > up.
# > Josh says, "Point taken damien, but I personally don't think that this is
# > a good thing.  If depermitting is thought of as something reserved for   
# > only the most extreme abuses, there's no threat to the abusive people."
# > FeRD says, "You're thinking in terms that are too black-and-white."
# > FeRD says, "Personally, I don't WANT to depermit GArrow from -comp. Or
# > tanman and tex from -beener, when they were going at the engineer thing.
# > However, I did NOT want to see the disucssion. Why should I have to leave
# > -beener just to avoid their stupid sends?"
# > damien says, "My point is that I don't think it would be a good thing  
# > either for GArrow to be /depermitted from -comp, or for people to /quit 
# > -comp to avoid GArrow."
# > Josh says, "Lily public discussions model public interactions.  I refuse
# > to accept the validity of a complete ignorance of a person's existance in
# > a public environment."
# > FeRD says, "Having been on the "ignoree" end of Real Life(tm), let me   
# > assure you that it happens."
# > FeRD says, "You get over it."
# > Josh says, "There's a difference between ignoring someone and not being   
# > able to percieve that they are in the room and talking to you.  That's an
# > important distinction, in my humble opinion."
# > FeRD says, "But you assume that ignoring someone online is as "easy" as 
# > ignoring someone IRL. It isn't, IMHO. It's harder to "tune out" sends on a
# > chat service."
# > Josh says, "Anyway, my point in all this is that I think i'm going to add
# > a site-admin-configurable nerd knob in lilycore to disable public ignores,
# > and leave it up to site admins to decide on the policy that makes sense to
# > them.  I think that there are adequate arguments for both decisions." 
# > FeRD says, "Find me the best solution to the problem at hand, Josh: tanman
# > and tex are rabbiting on in -beener about something I have
_NO_INTEREST_IN_
# > . My choices are: /quit... have them both /depermitted... or "Something
# > else". I'm accepting all arguments for a better solution than '/ignore'."
# > Josh finds that hard to believe, FeRD.  You could make your client color
# > them in a dark color, for example.
# > Tex is off the hook on the gater! Woo!
# > FeRD says, "Color is an unfair assumption for baseline client
capabilities.
# > "
# > FeRD's tlily right now is not in color, as he can't get Curses to work on
# > this Solaris box.
# > FeRD says, "Also, some people HATE color. Flynn comes to mind as someone
# > who mentioned that he will NEVER use a colorized client."
# > Josh says, "Whatever.  I'm not trying to make any argument about what will
# > happen on RPI lily.  I'm simply talking about the validity of a nerd knob
# > in the core for other sites to make this decision."
# > FeRD says, "Seemed to me you were arguing for the removal and banning of  
# > the feature, actually. Did I misinterpret?"
# > Josh says, "Yes."
# > FeRD says, "Apologies, then."
# > Josh says, "I was questioning its existance, not suggesting that it be
# > removed."
# > Josh says, "And suggesting that it might make sense to remove it."
# > FeRD still fails to see the distinction.
# > Josh says, "I'm talking about the core, and providing the site admin with
# > a way to make this decision."
# > FeRD says, "You SAY you're not, tho, you say you're suggesting adding a 
# > switch to turn it off. That's VERY different. I have no problem with
# > knobs."
# > FeRD says, "Right. Your first description of your proposal does NOT
# > evaluate to the same thing. Be careful how you word it. "Might make sense
# > to remove" isn't clear."
# > FeRD says, "(No, I did _NOT_ know what you meant.)"
# > Josh says, "OK.  To clarify, I was putting out a feeler to see what
# > arguments existed on both sides of this issue, perhaps so I could include
# > it in a /help for the $set option to control it."
# > Josh says, ".. if i get around to implementing it :)"
# > FeRD says, "Ah. Well, I think we covered a good part of it, at least. 8)"