[Mailman-Developers] Dynamic sublist implementation for GSoC 15 - queries

[Pranjal Yadav]

Hello

I followed ideas page for GSoC 2015 and I found Dynamic sublists (
http://wiki.list.org/DEV/Google_Summer_of_Code_2015#Dynamic_Sublists )
a very interesting and apt project according to the to-do list for mm 3.0.
I have had my discussions with Terri on this and we agreed on following
points :

1. Primary goal would be to cleanly implement Dynamic sublists effectively

2. Following up (If time allows) I can move on to my recommendations.

So I would like to discuss here my viewpoints and research for this very
project.

Starting with the work that was done by Systers 6 years back for
Mailman-2.1.10 version

ref : http://wiki.list.org/DEV/Dynamic%20Sublists

>>
I would like to add here that there will exist a disadvantage even after
Dlist implementation and that is every user is bound to receive first
message
for every new conversation. I do have an idea to solve that however I would
like to discuss that in more details.
================================================================================================================

*Solution*: If we can generate a log from MM API or inside postorius then
we can facilitate user with filtered first messages which will be from
users in
a list of top x (subscription based)

*Example*: Say users A and X both send approx 10 new threads a
day(hyperactive mm developers :))

I'm subscribed to list l1,l2....ln, in which user X has relatively higher
number of posts and replies as compared to user A, then based on statistical
thresholding first messages from A can be chucked out from my new mails.

*Test-case*: If user A do post something important to me then I will not
miss it as the same will be provided in the digest by default, however if I
may
choose to select "Apply threshold filtering" for digest I'm myself calling
to remove A from my digest as well.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>>

Alias option is also provided for users who do not wish to indentify
themselves yet post messages on list, however is tha is the case then I
would

like to discuss the vulnerabilities here.
================================================================================================================

*Case1*: (Mid level/moderator)
What are the control points for such aliases? Do we allow moderator to
check before proceeding the post to be displayed in the list?

*Case2*:  (User)
Do we allow these aliases to be completely anonymous or we provide a mask
for registered user to act anonymous on list? Which

means changing the idea of aliases with masking options for mails

*Case3*: (End-user)

If any post is posted as anonymous then is there a need to tag/classify
that particular post on mailing list as well as digest? I believe

the major utility of this feature is to provide classified info/complaints
without identifying self, in such case it is a must that subscribers

get a greater attention for that post.

*Test-case1*: If anonymous posts are moderated then the user losses the
freedom to utilize this feature however if there is no control point

then anonymous posts will affect the end-user

*Test-case2*: If we mask a user then we already know who the user is and we
save on adding random aliases to our database but this

changes the idea for the user to be completely anonymous. If we can manage
to mask a user without revealing the identity to admin level

we can make this work and as a safe-gaurd a root user(above admin) can be
accessed in an urgency to unmask.

*Test-case3*: If we provide an alert for all anonymous post then a spammer
or attention seeker will use this to his/her advantage, to counter

this subscriber must have an option to block anonymous user and is an
aliases is requested to be blocked by threshold subscribers then

that alias can be permanently banned

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

IMPLEMENTATION

ref : http://wiki.list.org/DEV/Brief%20Technical%20Details

ref : http://systers.org/systers-dev/doku.php/systers_database_in_postgresql

I'm still struggling with Queues and Runners and will post my queries soon
for that part, I think this info is in-complete
"In global pipeline we insert Dlist handler beforeCookHeaders
<http://wiki.list.org/CookHeaders>. (Mailman/Handlers/Dlists.py) " or
at-least the link is broken.

This database schema (
http://systers.org/systers-dev/doku.php/systers_database_in_postgresql ) is
well structured and quite easy to

understand but we can revise it after discussing above doubts.

PS : Doubts I have mentioned above are only related to understanding
dynamic lists' working/expected-working and any assumptions or

suggestions made which seems futuristic are not part of my GSoC proposal
but a part of my understanding of the overall scope for Dlists.

-- 

*Pranjal Yadav*

*IIT Kharagpur*