[Mailman-Developers] Approach for Auto moderation system

[Stephen J. Turnbull]

Aanand Shekhar Roy writes:

 > Hi, Does the following approach for auto moderation sound fine or
 > am I on the wrong path ?

I wouldn't call it "automoderation", I would prefer "post throttling".

This is more suggestive of what is actually happening (moderation
usually involves filtering on content).

 > 
 > I think we neet to make changes in handler to_outgoing.py in method process.
 > 1) We need to make two databases :
 > Table1 Schema->  [ user_id | Thread name | list_id | count |
 > last_msg_posted_at ]
 > user_id, list_id, Thread name together act as primary key.
 > It stores the count of number of posts of a user on a particular thread
 > and the time corresponding to the last post.

I think you should provide an option to just throttle the user on a
given list, too.  Possibly with different default throttling
parameters.

 > Table2 Schema->

I don't see why you would have a separate table for messages.  Just
add the post_after_time attribute to the message's metadata.

 > [message_id | user_id |Thread name| list_id |don't_post_before_time] here,
 > don't_post_before_time=(last_msg_posted_at)+(count/10)*d

I think you probably want count//10 here IIUC.  I'm guessing you want
the delay to be zero until the poster hits 10, right?  In Python 2,
5/10 == 0, but in Python 3 it's 0.5.  5//10 == 0.

 > where, "d" will be delay set by list-admin, eg 3 hrs.
 > 
 > 2) The count variable is accessed from Table1.
 > 
 > 3) When process is called and a new message entry comes:
 >    a) case 1: It is the first post by user on that thread then we create a
 > new entry in Table1 with count 1 and last_msg_posted_at_time = posting
 > time of that message. Then the corresponding entry is made in Table2
 > with new count and calculated don't_post_before _time.
 >       case 2: It is not the first post implies there is already an entry
 > in Table1 then we increase its count by 1 and we calculate
 > don't_post_before_time using count and last_msg_posted_at_time.
 > After making the corresponding entry in Table2 using values just
 > calculated we update last_msg_posted_at_time in Table1 with the value of
 > don't_post_before_time of this entry

 > b)Now we iterate over all entries in Table2 and whoever has
 > don't_post_before_time < current_time we remove the corresponding entry
 > form Table2 and enqueue it in outgoing queue else it stays in the
 > database.

In my proposal to put it in metadata, you would just enqueue the
message in outgoing and have OutgoingRunner check for post_after_time.
If not present or present and expired, post the message, otherwise
leave it in queue.  If you do it your way, you need to have a separate
queue (storage) for messages waiting for their post_after_times.