Tejas Pavan B via Mailman-Developers writes: > I read Stephen's reply to Tanmay's question about the Dynamic > Sublists architecture. The suggestion to derive a sublist interface > from MailingList components makes sense to me. I started tracing > through mailman/model/mailinglist.py and noticed membership is > managed via ISubscriptionManager, my question is: would sublist > membership be best modelled as an extension of > ISubscriptionService, or does it warrant a new top-level interface > entirely, given that sublists would need to inherit and filter the > parent list's member set rather than manage their own?
If I remember correctly, in Google Summer of Code, design at that level is our responsibility. However, to do a good job of implementing a design, you need to believe it is correct and understand it. So I'd like to ask you to think about it a bit more and explain how you think the parts should fit together, and why you think that's good. Please keep the discussion on-list. First comment, I think the insight that a sublist filters the parent's member list is a good one. That's a good starting point. However, at that point you need to ask, is the sublist *exactly* a filter on the parent's member list? What does that imply about the structure of discussion? Consider that the original design was tuned to an organization that basically used the Dynamic Sublist feature as today we would use an issue tracker: people would discuss a task for one of their projects at a high level on a mailing list, then fork off a sublist with a single post to the parent list. People who want to work on that task subscribe to the sublist (note: opt-in, not opt-out). They can subscribe by replying to the post. But what if you're a new member and want to work on the issue, but didn't receive the post? How about sublists of sublists? Are there other use cases for this mechanism? The "issue tracker" use case suggests a tree structure on the sublists is not too constraining. What about other use cases (user stories)? Besides dynamically creating and subscribing to a sublist, what affordances should be available for the sublists, and how would they be implemented? I think I'll stop here for now. I think I can see how this task may factor pretty cleanly into parts, for Mailman core, Postorius, and HyperKitty. I think the Postorius component is pretty straightforward, from the point of view of subscription management "sublist" is a simple object. HyperKitty's would depend heavily on the core design, so whether we go into adding sublist support to HyperKitty at this time or not, we should be sensitive to applications like search and browsing the archives. I haven't thought deeply about it; it may not be that hard. -- 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
