I've heard anti-spam as a given reason before, was never really convinced though.

All the below is my viewpoint, no an official viewpoint of anyone else.

Just to clarify, this seems like the request is purely on a 'make more info transparent' principal, and there are no technical reasons for making the lists public. The operations team can generate a listing of all lists (public and private) for their own maintenance work.

If a list name is public, then it can result in more requests to join the list, or more moderated spam messages. If a list is a private list, I'm not sure why it should be publicly listed.

I think moving forward on this task would require one of two methods of approval:

• Someone in upper management in engineering at WMF would have to state this should/needs to happen.
  • I think this would likely result in ill-will from many affected lists and list members. When their list was created as private, it had all the expectations that I would think most previously assumed it entailed, such as not being listed on the listing of all lists on the server.

• A direct 'buy-in'/approval from the list administrators of all affected private lists.
  • Ops can determine which lists are private and the list owners. However, since that info is in itself private, I'm not willing to even hint at how many there are or paste that info into a public task.
  • Alternatively: At least an announcement of the impending change well in advance. An email to list owners in addition to a list announcement for the owners list would be ideal, as then those private list owners wouldn't have any reason to confuse the email with general list traffic/emails.

I think the latter option(s) with announcement of the change, and a full reasoning for why, would be the best course of action, if this task were to be approved. I'm personally not sold on the idea, having some lists as private seems fine to me.

Just my two cents =]

I volunteer to email all the list owners of such lists to warn them of the change (and offer an opt-out for those who have reasons?). Of course I'll need a list of the affected lists. :)

I think secret lists are just a practical problem. In T270977 and it's previous iterations we just dumped a list of lists on the task without any concern whether they were listed or unlisted. We're going to be migrating archives to mailman3, we'll probably keep a list somewhere of which have been migrated and which haven't. If some of that list is in a private task, that'll be annoying.

Anti-spam is probably a real concern, I hope that in mailman3 we can make up for it that making all lists publicly listed does not increase moderators/admins work or annoyance.

There are 256 unadvertised lists out of 711 total or 36%, a significantly larger number than I was expecting. At least 41 of those are disabled/renamed/obsolete lists (I looked at settings set by our disable_list but that's a relatively new script, and not all lists have actually been disabled despite being obsolete), others are publicly known but not listed (at least I knew of the lists' existence before looking into this), others appear to look like private lists (judging based on listname alone).

Anyone with shell access to lists1001 can run sudo python3 /home/legoktm/config_grep.py | grep "advertised = 0" to get the list of unadvertised lists (will puppetize/publish the script later).

I understand the reasoning not to advertise a mailing list (spam etc.) in mailman2 given its perfect, most usable interface (specially for a person who is not familiar with spam fighting and not familiar with the jargon like DMARC, spamassassin score, etc) but:

• Not being advertised doesn't mean its existence is private and bound to NDA. It means it's just not advertised
• We definitely should revisit this with mailman3 as its interface is much more usable.

We definitely should revisit this with mailman3 as its interface is much more usable.

Indeed. Out of 256 mailing lists, I expect a vast majority to be set to unlisted due to legacy recommendations on how to handle spam and so on, not for a real need to be secret. It's up to you and your current capacity whether to handle this matter before or after the migration. If it makes the migration easier for you, it might be fine for instance to do some variant of this:

• send a private notice to all owners [and members?] of the affected lists that their list will be reset to advertised = 1 at some specified day X before the migration;
• ask them to set the list again to unlisted by day X+7 if they want it to stay unlisted for now;
• ask for comments on this task (or some Meta page?) on what the policy should be in the future.

If there are some lists whose very existence is such a big secret that it can't be revealed even for few hours or days, then you might need some kind of manual opt-in or opt-out process, but otherwise it's probably better to apply the KISS principle. If that's not possible either, just delay until the mailing lists are settled in their new home...

In T124324#6979583, @Ladsgroup wrote:

• Not being advertised doesn't mean its existence is private and bound to NDA. It means it's just not advertised

Thanks for phrasing it this way, I agree with this.

In T124324#6980039, @Nemo_bis wrote:

• send a private notice to all owners [and members?] of the affected lists that their list will be reset to advertised = 1 at some specified day X before the migration;

I suspect we will have other action items for list owners to do either before or after their list is migrated, we can add this to that.

@Ladsgroup @Legoktm is this something that can be / has been done with the migration to mailman3?

This is not done as part of migration, technically it's possible to do in both mm2 and mm3 (maybe easier in mm3 though) but the problem is the social part. It requires communication, giving a grace period for objections/concerns/etc. plus making sure admins are comfortable with mm3 system first (how to fight spam, etc.). after that we definitely can do it.