The main point here is not "poor Mailman developers", it's that we need input from users (subscribers too, although list owners are probably most important) about how to design these features. Unfortunately I don't have time or energy to fix the tone which is a little self-pitying, so please read with that main point in mind -- I'm posting because I really want to know what people need, and want.
And the bit about "re-using Mailman 2 scripts" too. I'm not sure how practical it is given the architecture changes, but we'll definitely take a look at requests.
Alex Schuilenburg via Mailman-users writes:
Yes, this is social media territory, but with the EU/UK DPA (data protection act) and record fines being issued,
Sure. It's also a pretty big ask of the Mailman developers. As you are now aware, the architecture of the application is not well-suited to this. If you're worried about paying fines, maybe a contribution of a fraction of the average fine would be good insurance? :-)
But it's not just the architecture. Even the requirements are controversial. I'm on record that it might be a good idea to remove the User (ie, the profile of PII in the database) when the last subscription is deleted, but should that be automatic unless inhibited, should it be an option offered but default to "keep", should it be an operation done only on specific request? In any of those options, since this is a major deletion of presumed unneeded but in some cases valuable data, we should provide a convenient but cautious UI. Should there be a temporary backup of the data in case the user changes their mind? Is that GDPR conformant? Maybe the user could download their profile for later upload? Maybe that could be portable across Mailman 3 sites, with some kind of semi-automated merge UI?
How about the user's archived posts? How about quotations of the user in *other's* archived posts? Just designing this is not easy, but because it might involve changes in the architecture, we do need to design in advance. This is not the kind of change where "move fast, lose user data, and break everything" makes sense.
I'm not saying we can't do it, but we also have our priorities, and limitations. Also, I don't think we can, let alone should, do that design ourselves. Even if it's not reasonable for you to contribute code or money, we do need to know the community's requirements, and because it's often pretty fuzzy stuff, I think it's reasonable to ask *why* a feature is needed -- we may be able to negotiate a change that's easier to code or less fragile in operation if we know what the underlying need is. So members of this list can help a lot by (1) answering the questions I asked above, (2) coming up with more questions (and answering them), and (3) turning the whole thread into concise requests for enhancement on the tracker.
Yes, it would be nice to re-use some of those old mm2 scripts built up over the years on mm3.
Feel free to post the scripts you want to reuse on the tracker, in request-for-enhancement issues. Without an accurate idea of what you want to do, specifically the data the scripts want to access, we'd have to reproduce the whole Mailman 2 API/UI. Some of that would be extremely tedious, such as anything that manipulates list config pickles -- they don't exist any more. But other things might be fairly easy.