Archie Singh via Mailman-Developers writes: > For the *Dynamic Sublists (Conversations) project idea*, it would > be great to convert mailman into an opt in model from a broadcast > model (like currently there is some inbox flooding for those > working on a project idea who are getting conversations of other > projects, like there should be something for them to opt out of > some threads based on their area of interest)
If you mean this mailman-developers list, I disagree. Most of the time there's not much activity. During GSoC it gets loud, but as a new developer your area of interest should be *Mailman in general*. If you don't have at least some interest in "all things Mailman", you may be applying to the wrong project. (Everybody's different, that's a generic you, not you in particular.) Among other things, Mailman really is a single purpose tool, so all the parts interact, and there are common themes (such as the interface/model relation, the chains and pipelines, the app lifecycle, etc). The only really distinct application is HyperKitty, but at least this time there's been limited interest there, so not creating a lot of noise. > I have not currently finalised some aspects of the architecture > (and even the time required, This is wrong way round. You should decide what work is required to implement the feature in your opinion, and provide a plan to accomplish it with the time you think is required. Only then if the time doesn't match GSoC's schedule you should bring that up and negotiate it. > - does the “additional functionality” (for the 350 hour work > progress) you are referring to involve integrating the web ui via > hyperkitty and modelling the rest api endpoints while the earlier > 175 hour implementation only involve core backend? And what > should I be feasibly aiming for? The original Dynamic Sublists feature was entirely controlled by email, so that is the required part, and involves only core, except that Postorius should get a list owner option to enable the feature. Depending on how this is implemented internally, it may have implications for Postorius and HyperKitty (proliferation of lists in the list of lists pages, for example). For the base task, if those seem to be issues that users or admins won't like, documenting them is good enough. The extended functionality, I haven't thought deeply about it, but some collection of - collapsing the sublists into the main list in list of lists pages - configurable filters of sublists (eg, if they're inactive for a month don't display in list of lists) - user join or leave sublists in Postorius - not sure what features you might want in HyperKitty I doubt that the extended functionality just mentioned would get you all the way to 350 hours, that would have to negotiated based on the proposal. > - regarding database modelling, in my proposal i have suggested (a > new sqlalchemy model) to use a root message-id for each of the > threads, to track a user’s subscription to that > thread/conversation, I think you are way ahead of yourself. First you need to understand the mailflows, and think about the user experience (UX). For example, Mailman 3 core and Postorius don't have threads. Not lightweight threads linked by In-Reply-To and not sublists (or alternatively topics). Just messages ... and those are emphemeral, they last a few hundred microseconds in the queues (except out, where they can sit for minutes on a big list). While I have not thought deeply about this aspect, it seems to me that the sublist concept is a very "shallow" derivative of the list concept. Just a list, where a sublist is recognized in the database by a non-NULL parent id. (This is why I say elsewhere that I see Dynamic Sublists as creating a tree structure on lists.) I would assume that it inherits most of its configuration from the parent list, except its identities and > do you suggest that i link the conversation thread It's not a "conversation", nor is it a thread. It's a sublist whose posts can participate all of the structures that an administrator- created list does. > directly to the user object or the (email) address object (as one > user can hold multiple addresses although they might be using > different addresses to start different conversations as a form of > pseudonym (i thus believe linking threads to addresses is a more > practical choice)). But I would still want your input on this… This has to look a lot like a MailingList so Postorius and HyperKitty can exploit the common features in their respective UIs, and users get a sense of familiarity with the new feature. I suggested (VERY tentatively) above that a sublist could BE a MailingList (with a new field that all MailingLists would have, or as a very slightly extended subclass). So the relation between a sublist and its subscribers pretty much has to be (address, list, subscription configuration). > - as the email passes through different handlers, there are many checks > assuming spam check moderation, recipients (where the email addresses of > every single person subscribed to the list gets their email addresses > extracted) etc. although for this project regarding conversations, if > someone replies to a thread the email should not be going out to all the > people but only the people who are following this conversation. I think your model here may be a social network platform's algorithm, and email just isn't that. Mailing lists are social networks, but the model is broadcast list traffic to subscribers. And it's single- channel: the only way to communicate with other subscribers is to send an email. There are no retweets or quote tweets or likes (OK, there's some voting in HyperKitty, but I've never seen it mentioned on the users' list), and the culture strongly discourages that kind of behavior. > So, there should be a custom handler (to overwrite the recipients > dictionary) that is injected in the middle of the pipeline; now the > problem I am thinking of is, if the custom handler is added too > early it might bypass some safety or spam checks, and if it’s too > late then the mail would already be sent out…so a consequent > question arises, is there a preferred stage in the delivery > pipeline where I should be placing this custom handler? I think it > should be placed before the handler to_outgoing (which basically > just takes the email, checks the recipients of the mails dict and > sends the emails out), this being after all the safety checks have > passed. I think the answer to that is "it's just handled like a list". If you're thinking that the membership should be a subset of the parent list's (not sure I think that's a great idea, but as long as it's an admin option that defaults "off" you could try it), that would be implemented at sublist subscription time (and possibly unsubscription time from the parent list). -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
