While recognizing that my input is probably of little or no value at this stage, I would point out that fine grained discussion permissions existed on Clover. It allowed the owner of a discussion to indicate whether people could send messages, read messages, quit the discussion, etc. These permissions were hard to implement, hard to manage and ultimately it was the coding errors related to those permissions which put rhysomme, and by extension Clover, to death.

When lily was created I opted for a more minimalist permissions architecture, which was richer than CONNECT but simpler than Clover. While they have certainly grown in complexity over these last thirteen years, the ability to ignore a particular individual in a public discussion was a frequently requested feature in its early days. This feature allowed individuals to block the messages of difficult people, while still participating in the life of a discussion. It was always a goal of lily to place conflict management and avoidance tools into the hands of each user.

Nevertheless, vesting control of public ignores in the moderators of a discussion is a perfectly legitimate change, which is well within both the intended design of the software. Unlike some of the other onerrus Clover permissions, I have no objection even though I would be unlikely to use the feature personally.

-- ChristianRatliff - 27 Apr 2006

Reasons to do this:

It is a reasonable feature, and would address the long-standing debate about the worth of public ignores.

(Can someone elaborate about why public ignores are bad?)

This may force moderators to depermit troublemakers faster.

Reasons not to do this:

"The problems" would only be compounded if the ignore was done client-side (where there is no notification to the individuals affected). Confusion would still reign, except there would be no indication why.

# -> (09:07) From tanman [benthic], to lily-dev:
# - Has it ever been considered that moderators of public discs have the power
# - to enable or disable public ignores within their discs?
#
# -> (09:08) From Coke, to lily-dev:
# - per discussion? I don't think so. I've worked on *cores* where "/ignore"
# - was entirely disabled, though.
#
# -> (09:08) From Coke, to lily-dev:
# - Given the kind of super-fine-grain control lily allows for such things,
# - though, it seems a reasonable feature request to me.
#
# -> (09:09) From tanman [benthic], to lily-dev:
# - Consider it requested, then. :-)  There's always been debate over public
# - ignores, but it seems reasonable to me that moderators should be able to
# - disallow public ignores in their discs because of the problems they can
# - cause.

 META TOPICPARENT 
 FeaturesWanted 

Let's see. We'd need a per discussion flag, settable by the admin - this probably means a new / command, as most discussion settings are not handled through a disc-equiv of /set (or $set) : This would also require modifications to "/ignore" to respect the new setting.

When this flag was set for a discussion, it would have to eliminate any ignores that conflict with this setting, and notify any users on either end of that ignore that settings had changed.

When the setting is enabled/disabled, the output for "/what" must be altered, and a notification sent to current members of the discussion to the inform them of the state change.