There are a few existing bug reports about the "failure to deliver when target list is too big" issue, but it's a bit of a mess that I don't have time to untangle right now.
TLDR, we think the primary underlying bug might be T232392: EventBus extension must not send batches that are too large.

@Ilario Per https://meta.wikimedia.org/wiki/Mailing_lists#Create_a_new_list please add to the description above:

• (x3) description of the list for the list info page (should include even if private list so ops and mailman admins know why it exists.)

I.e. please write out exactly what text should be included at the top of page, for each list, at their equivalent of (for example) https://lists.wikimedia.org/mailman/listinfo/otrs-zh
Ideally, write it out in both the list-specific language, and in English. You'll be able to edit the text afterwards via the interface of course, but it's best to start out with something there. Thanks!

To be closed via T31079 once resolved. :)

@Tgr @bd808 @Addshore (@AM?) - Are there any followup actions that need to be taken, from this session's notes and Anomie's comment?
If yes: Please comment or file tasks as needed.
If no: Please boldly Resolve this task.
Thanks!

Looks good to me. Thanks all :)

For context: I do not expect that any new addresses will ever need to subscribe to the archived-list. I mainly want to confirm that the archives will be available indefinitely (partially because burning archives is inherently bad!), in the hopes that future versions of Mailman will make it easy to search archives like this, for anyone in the future who is trying to find related information that is stored within.
IIUC, the standard disable process should be fine.

Projects-Cleanup (https://phabricator.wikimedia.org/project/profile/2829/) is just regarding cleanup for Phabricator tasks and projects.

In T216525#5954060, @fdans wrote:

This is a minor change, but can we have a reason why this is needed? We're wondering who's interested in this data.

or at least to tell you how to do it

Essentially, you need to move the individual translated-pages one-by-one.
You Must Not move the parent page first, because the translations of the subpages will not be moved along with it. (However, I believe this is now already impossible to mess up, due to T114592: A translatable subpage page should not be messed while moving subpages being resolved, which should block the parent page-move from happening IIUC, but I haven't tested it personally.)

Support. JJMC89 has been regularly flagging pages for deletion on wikitech for a couple of years (thanks again!), which I usually end up deleting. They're an admin on Enwiki, and also have a bot-account with admin-rights on Enwiki, and has signed the OTRS users confidentiality agreement - i.e. trusted and knows to be careful.

We are not considering any font changes via the Desktop Improvements project. That would be a massive research project to do again, and we cannot do that simultaneously with the already known workload. With that in mind, we are going to untag Desktop Improvements from these tasks.

@Demian Hi. Briefly: (1) Please don't assign tasks to other people yourself! Thank you. (2) This task is a duplicate of T91201. I will merge it in, next.

@mrjohncummings I'm not deeply familiar with the technical usage of the extension, sorry. I'd suggest asking at https://www.mediawiki.org/wiki/Extension_talk:GuidedTour

HTML (rich text) formatting is purposefully disabled on almost all our
mailing lists, just as are email attachments, partially for security
reasons. This is to prevent obfuscated links that might not lead where a
reader expects, and script injection vulnerabilities which some email
clients have.
It also reduces the accessibility problems that occur when an email sender
tries to force a specific font or a specific color typeface.

That sounds correct to me. Resolving. Thanks all!

@Mrjohncummings In the sidebar at right,

1. click "Edit related tasks" and then click "Close as duplicate"
2. in the box, paste T242489
3. click "Merge"

:)

I believe this configuration is used in 3rd party wikis. Perhaps Izno can provide specific examples or further details?

John asked here, which has the complete details. :) https://www.wikidata.org/wiki/Wikidata:Project_chat#Is_there_documentation_for_how_to_create_Wikidata_Tours%3F (permalink)

Hi Nav and John. Is this proposal intended to supplement, or to replace, the existing Item Tour listed at https://www.wikidata.org/wiki/Wikidata:Tours ?
Or intended for some other use-case or demographic, perhaps offline instruction?

I suggest looking at Frwiki's main page. They overhauled it a couple of years ago, and it's responsive, and I believe (but not sure) it has been checked for accessibility. Here are the links I can find, but I'll ping @Trizek-WMF in case he knows of further links.
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Refonte_de_2017_de_l%27Accueil_principal_(FAQ)

@DannyS712 How would you summarize this new feature for Tech News? IIUC, something like...

Changes this week:
If you try to move a page to a title that already exists, there will now be a direct link to that existing title.

Re: user-notice - please help drafting a 1-2 sentence simple summary for Tech News. IIUC it would be something like this:

"[[Special:NewPages]] has a new drop-down menu interface for selecting the Tag filter. You do not need to type the tag from memory anymore."

(corrections welcome!)

@DannyS712 Yes to everything else (as far as I understand it), but I suggest removing/rewriting the part of the description that says "... merging with local stewards ...", because there is still a hope/plan to make wikitech part of SUL someday (T161859 et al), in which case that merge would cause an additional & unnecessary complication.

Is this feature available and enabled? I can't see the link in the English Wikipedia's sidebar Toolbox.
If not, should we re-open this task, or T222360: Add new "button" for Wiki URL shortener in the menu in Wikipedia instead?

In T140703#2693831, @Esanders wrote:

How about a dialog that says "VE is not supported on this page, switch to source editing: [OK] | [No, I want to try VE anyway, even though there be dragons]"

It was updated a couple of hours before this was filed! cf T240491: [SPIKE] Update the Compatibility#Mobile table
Oh, but I see no edits were made directly to the table in https://www.mediawiki.org/wiki/Template:Compatibility_browser/mobile so yes that still needs updating.

You've got that address listed in the "List of non-member addresses whose postings should be automatically accepted." section ("Lista adresów osób nie będących prenumeratorami, których wiadomości powinny być automatycznie akceptowane."), hence this is working as expected.
Re: How it happened: I would guess that a list-moderator simply selected the wrong checkbox in the moderation screen, in the past. An easy mistake to make.
I have not changed it, or anything else, but it looks like there might be other entries that perhaps should not be listed there?
I suggest you take a close look at the entries in this page: https://lists.wikimedia.org/mailman/admin/wikimediapl-l/privacy/sender

Additional notes on gadgets: