[Mailman-Developers] Query regarding plugin integration with mailman3

[Stephen J. Turnbull]

Aanand Shekhar Roy writes:

 > Banned word plug-in, which was also then added to the wiki page of idea
 > lists)

As you know, I'm not a fan of this one.

 > and then if the time allows I will work on others like "Timed
 > Vacation", since I am willing to contribute to mailman even after
 > Gsoc .

This one I like, actually, except that the probable code size is
small.  It's obviously useful, it will be obvious to users how to use
it, it's obviously quite self-contained.  It's a winning feature.

 > Is that ok or do i increase or decrease the no. ?

I'm going to need to ask Carol about number.  As I understand it, GSoC
is supposed to be one "summer-sized" project to give the interns a
taste of what it's like to work on a project that can't be done in a
single all-night sprint.  It also has the benefit of being a lot more
interesting for the mentors.

That is, if you write 5 bite-sized plugins, most of your code will be
API and testing boilerplate, repeated 5 times.

 > Though it depends more on the complexity of my idea but since every
 > setting we make in mailman needs to be reflected to web UI too so I
 > guess it will be big enough for Gsoc.

If the Postorius folks are doing their job that's not a big deal,
*much* smaller than writing documentation, let alone tests.

 > Since following up this idea wouldn't be as great. Can you guide on
 > "Auto moderation system for limiting posts on a particular thread
 > posted by a user" Like first 5 post will reach immediately, later 5
 > will be after 1 hour delay and so on.

As a project it has quite a bit of flavor.  There are some interesting
issues having to do with the impact on message queues, and whether it
could present an opportunity for DOS attacks on the server (note that
even if you don't fill the disk, you could end up with a lot of
messages queued for delivery all at once sometime next week).

It might be interesting to think about alternative triggers for
delivery, such as having a don't-post-before attribute in msg_data,
and instead of running the queue at a specific time, just wait until
the next time the queue would normally be run, and if the current time
is greater than don't-post-before, post.

Note that there's no guarantee that messages will be delivered at a
given time in any case.  You can only ensure a minimum delay, but if
an MX goes down in the meantime, a 1 hour delay could turn into days.