I'm not Mark, but .... :-) "Plans", you ask? Hmm....
Pawel Grzywaczewski writes:
Any plans to implement message acceptance based on another list?
I think that most Mailman 2.1 features are plausible proposals for Mailman 3. While we don't make decisions based on user voting, we do care about user requests. If you want to make a formal request, post a request for enhancement (ie, issue) on our GitLab issue tracker, and post a link here so other interested people can follow it.
What about adding list1 as member to list2? In Mailman 2.1 there was an 'umbrella' feature I think it doesn't exist in Mailman3. Any plans to add it?
Same as above. I don't know Mark's plans, but he's been active on these lists. I myself hope to have some time for development later in the summer, but I've been away from the code for quite a while, and have at least two prior projects I've expressed interest in. I have no idea about Abhilash or Terri's time, except that they're always busy, and there are a couple of other developers who might drift back in at some point if something exciting starts happening.
However, these kinds of additions described above are somewhat more complicated in Mailman 3 than they were in Mailman 2. We have added the ability to identify groups of lists as domains (and therefore have multiple lists by the same name if they are each in a different domain), and the ability to identify groups of email addresses as users. This means that there are more opportunities for unfortunate things to happen.
For example, a user might have a particular address for posting to a particular list, and be unhappy if they were accidentally "unmasked" when they posted by a different address, and that post was accepted because those addresses are both owned by the same user. Whether you think this one is a "real problem" or not, we need to do more than a little thinking about such things as we improve Mailman.
We missed the window for GSoC this year. We've had excellent success in getting students (I don't think we were ever denied a slot we asked for), so prospects for next year are good. I myself am looking at mandatory retirement in a couple of years, and am planning to ramp up development/consulting activity over this period. So I know a year is a long time, but we are actively supporting existing features, and intend to continue development for the foreseeable future.
Finally, Brian Carpenter and EMWD are actively developing alternatives to Postorius and HyperKitty. (Affinity and Empathy, respectively; I believe Affinity is already in beta, Empathy I don't know about status). You can find out more about them in the Mailman Developers <mailman-developers@python.org> archives and in the archives of this list. These are independent friendly projects, not hostile forks. You may find them to provide more straightforward access to configurations you want, although they do depend on Mailman core for much "back office" functionality, and obviously they're less mature than Postorius and HyperKitty. But they have the advantage of targeting a much more mature Mailman core, so they'll catch up fast. EMWD hosts a lot of Mailman lists and hosts, so I for one would consider a request for features from Affinity developers to be representative of many list owners.[1]
Footnotes: [1] Not to deprecate Empathy, but the relationship between core and any archiver is pretty much "arm's length". Archiver features are mostly independent of the core.