Stephen, Apologies for the Gmail clutter in my previous reply. I'll trim posts going forward.
> This should be `-new`, to follow the existing email commands. Understood, -new it is. I'll follow the existing subaddress conventions throughout the proposal. > In Mailman 3, both of these would be split between a chain (to > classify the message) and a handler (to do operations, including > side effects on the database). That's a helpful correction. So for the fork mechanism, the chain would classify an incoming message to listname-new@domain as a sublist-creation request, and the handler would perform the actual side effects: creating the sublist MailingList object, setting the parent reference, and initialising membership. Similarly for delivery, the chain classifies the message as belonging to a thread, and the handler determines the two recipient sets and performs delivery. Is that the right way to think about the split? > It's not obvious to me that a "sublist" needs to be treated as > anything but a MailingList to start with. This makes sense. Reusing MailingList with a parent FK keeps the model clean and avoids introducing unnecessary abstractions early. The REST API filter and Postorius visibility controls can layer on top naturally. On the open questions you raised about who can create sublists and who owns them, my initial thinking is that creation should be moderated by the parent list owner by default, with an option to allow any member to fork. Ownership of the sublist would default to the member who created it, but the parent list owner should retain override rights. Does that align with how you'd expect it to work? Tejas Pavan B https://gitlab.com/tejaspavanb https://github.com/tejaspavanb _______________________________________________ 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
