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* _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
