On 18/9/21 7:10, Stephen J. Turnbull wrote:
Guillermo Hernandez (Oldno7) via Mailman-users writes:
But? I'm talking about a moderator can put a member mails in hold when it is marked to accept. To prevent putting more gas in the fire.
Not sure what you want here. I don't see how this is supposed to work -- if a subscriber is set to accept, the moderator will never see the posts until they're distributed to the subscribers.
I'll try to explain:
In my experience, the most useful tool to cool down a thread that has converted in a flame is to stop free distribution (hold) new mails coming from some suscribers (the most infuriated, or maybe the more infuriating -I don't know if this word, infuriating, makes sense in english-). You need to slow down the interchange of burning mails, and perhaps discard some of them. Make announcements to the rest of the suscribers and try to reconduce the waters. Yes: it can be done by the owner or the list or administrators. But this admin capability cannot be done by a so called "moderator". The moderators, in mailman, cannot moderate the flux of a overheated list.
I'm talking about lists that otherwise have a normal and pausated exchange of mails, but some subject becomes a battlefield, and in a period of minutes you have hundreds of mails...
And the admins are sleeping (because in their timezone are 03:00 am) and the moderators that are awake have their hands tied.
A moderator doesn't have to be capable of configuring lists, but they would have to be capable to moderate the flux of mails when it's necessary.
The rest of your post is very appreciated, as always.
Thanks a lot.
But that inspires a short rant ;-) a little about the implied feature request.
First let me point out that there are a lot of lists out there where the owner is relatively laissez faire, and some moderators are a lot more activist. In the modern environment, it turns out to be important for many lists to vet new subscribers' first posts, and moderators basically function to give prompt response to non-spam first posts. So I don't want to just give moderators the same privileges as owners here, because they'll impose restrictions that the owner doesn't want, and the current low-privilege moderators seem to work just fine for a lot of lists.
I don't object in principle to allowing *owners* to give moderators more privileges. On the one hand, it's often case that owners trust their colleagues with owner-level privileges. So that's an option we already have -- no moderators, all owners.
So maybe you *don't* like the all-owners strategy (and it's obvious why many owners won't, no need to bend my ear on that). The design problem is that there are a lot of capabilities, and it's not obvious to me that there's a specific collection of them that owners want to grant to their moderators. Maybe we can get rough consensus on that list, and then it's not hard to get to working code. I'm not going to start the conversation here (I don't personally have such a list), but I'm happy to listen, and provide advice to anyone who wants to submit a merge request.
If there isn't consensus, then we're going to need a framework for moderator capability management so that owners can pick and choose. That's something I'd be interested in working on myself if there's user demand for it. (There's a long list of things I'm interested in, and not a lot of work actually done recently, so no promises. But it could happen! ;-) It could also end up on the GSoC idea list for next year. :-)
Another capability I have an interest in is closing replies to specific posts and to whole threads. Again, that's going to require some thinking about the administration interface. It's easy enough to do the basics if there's an archive (allow the moderator to click on a post, and either disable replies to that post or replies to all thread descendents), but I can imagine lots of related capabilities (reenable replies for "sane" subthreads, automatic expiration of the restriction, ...).
And of course all of the above (except unconditionally granting moderators the capability to apply a HOLD to users) requires REST updates, I suspect.
As always: code contributions welcome.
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
--