Boldly adding MediaWiki-Platform-Team to open Ruprecht tasks as https://toolsadmin.wikimedia.org/tools/id/ruprecht does not provide a dedicated issue tracking location, as https://gerrit.wikimedia.org/g/mediawiki/tools/dependency-analysis provides no hints where to track issues, and as the Core Platform Team Initiatives (Decoupling (CDP2)) team tag is archived and its parent Platform Engineering team does not exist anymore. (Please strongly consider the good practice to have a dedicated *codebase* project tag for Ruprecht, as teams (and their tags) may cease to exist while codebases continue to exist, to avoid such bugmail noise in the future.)

@daniel could you provide some context on this and the other Ruprecht tasks currently tagged with MW Engineering? - where/how does this work fit in? Are these tickets still valid? What should be the tag for these? - We've scheduled a triage meeting with MW Engineering for tomorrow. Would be great to have your input before that :-) - thanks!

In T223726#9275445, @Bmueller wrote:

@daniel could you provide some context on this and the other Ruprecht tasks currently tagged with MW Engineering? - where/how does this work fit in? Are these tickets still valid? What should be the tag for these? - We've scheduled a triage meeting with MW Engineering for tomorrow. Would be great to have your input before that :-) - thanks!

Ruprecht was an early experiment to measure the "tangledness" (opposite of modularity) of MediaWiki. The information from Ruprecht later informed the Expedition project. It's probably still useful, but it doesn't make sense to invest in it at this point. We should work on creating tools for specifically identifying component boundary violations.

So we can probably close these tasks as declined.

Would declining tasks also imply requesting to archive the code repository?

In T223726#9278202, @Aklapper wrote:

Would declining tasks also imply requesting to archive the code repository?

Done, see T350258