Thanks @Aklapper!

25 open tickets:

• Stakeholders territory: 76902, kind of 951,1113?
• If Release-Engineering-Team also covers tarball releases (and "mediawiki/tools/release" in Git) nowadays, that's 532,533,536,78053,949,529,974,534,993, maybe 954,1113?
• Engineering-Community: probably 536
• There are four "Contact Foo" tasks (1029-1032), no idea what to do about them.
• IDs not mentioned before have at least one other project assigned which felt sufficient.

You could add "T" in front of the numbers... :)

I dislike triggering all those notifications automatically and there's a link to all items in the first line. :)

Now down to 17 in this search.

I added RelEng or the appropriate other project and removed wiki-release-team from:

• T78607: Update from 1.19 to 1.23 fails: Error: 1054 Unknown column 'page_content_model' in 'field list'.
• T949: update make-release to refuse to work if tag != $wgVersion
• T529: Automate patch application for tests for QA part of make_release
• T974: Automate Testing of MediaWiki Tarball releases
• T78053: $wgThumbnailMinimumBucketDistance and $wgThumbnailBuckets not documented in RELEASE NOTES
• T85327: Link to anti-spam measures from the default mainpage
• T76264: User::$mCoreRights made protected in 1.24, breaking stuff
• T84918: Use the modernized reCaptcha API, which hopefully allows for intervention-free verification

I propose to close (or move to the stakeholders group):

• T532: Research Docker as a new format of distribution
• T533: Research Puppet as a new format of distribution

Questions/not done/suggestions:

• T993: Merge Version_lifecycle and Release_timeline into the same page or (at least) point them at each other.
  • Pinged M&M via email.
• T56425: Provide an opt-in ability to register the user's MediaWiki installation
  • has release team, installer, and 1.25 release projects. I suggest just leaving the installer project (removing the others). I suggest not 1.25 project because there is no time budgeted towards that at this point for 1.25 (from RelEng, at least).
• T1113: Link to survey on 1.24 installer
  • This was in support of the environmental scan deliverable from M&M, so either move to stakeholders or close as decline.
• T536: Take DumpHTML as a use case of 3rd party extension that MediaWiki maintainers cannot ignore
  • We are in the process of making a Jenkins pre-merge job that runs all of the WMF deployed extensions unit tests for a commit in either MW Core or any of those other extensions (see T69216). Lobbying for another extension to be added to that group should be made on a case-by-case basis. I move to close this task as "decline" and move forward more positively.
• T534: Create a List of Requirements for Extension Management
  • Should probably go to either the yet-to-be-created stakeholders project and/or whatever project is the home of the "extension management" work.

That should be all that are in my team's bailiwick.

IMHO done here, only waiting for T88965 whether to reassociate or decline T532,T533,T536,T951,T1029,T1030,T1031,T1032,T1114

Still 5 tagged open tasks...

In T88263#2547969, @Danny_B wrote:

Still 5 tagged open tasks...

Which are all also tagged with MediaWiki-Stakeholders-Group, so we're fine/done still. There's no point in removing the tasks from the archived project.

To be clear: there is nothing else to do here, please don't remove those tasks from that archived project.

That's what I expected, hence why I didn't reopen it, but only left a note just in case... ;-)

I just came across this again. It looks like the remaining tasks are all assigned to MediaWiki-Stakeholders-Group, which is good. Thanks for helping out. In particular, T88265 and T56425 are taken care of. T534 is being discussed (last at the Wikimania Hackathon in Esino Lario). It looks like T532 and T533 are not in focus right now, but it's ok to keep them in the Backlog.