I've updated the MM team page to list it as historical.

Thanks for that update to the page, James.

To provide further clarification:

• The "Multimedia" Team no longer exists. The original setup had the Multimedia team working on the SDC project and juggling multimedia-related tasks. But org priority changes led to that team becoming almost solely focused on Structured Data tasks. So, the staff who were on Multimedia became the Structured Data Team with a mandate to focus on Structured Data across WMF projects

• There might be another Multimedia incarnation in the future, but there are currently no solid plans for that.

• The Developers/Maintainers page should be updated, but it's not clear who should take up the mantle on some of those tasks. We (Structured Data) still try to work on those things when we can, but it is probably best to completely transition us out of that and have a more formal arrangement. I look to @dr0ptp4kt to work all that out 😺

Hi @Ramsey-WMF, thanks for your reply! Could you maybe ping @dr0ptp4kt again? :)

I filed this task as publicly available information is confusing for potential contributors outside of this team.

For example, the Multimedia team tag in Phabricator creates the wrong impression to anyone interested that such a team exists and could be contacted, pages like https://phabricator.wikimedia.org/tag/mediawiki-gallery/ state "Maintained by: Multimedia", https://www.mediawiki.org/wiki/Developers/Maintainers lists 10 projects stewarded by "Reading > Multimedia team" (heads-up to @Jrbranaa here), https://www.mediawiki.org/wiki/Reading/Multimedia/Structured_Data looks outdated, or the box on the right of https://www.mediawiki.org/wiki/Readers does not list "Structured Data".
All together this leads to people getting lost when trying to find out who to talk to and it does not feel too transparent.
Is fixing this in scope of your team? (Or is maybe a member of Community Relations involved? Asking as I cannot find recent public information who is on this team.)

I've passed this info on to Mark, who pinged Adam directly for guidance on how to move forward.

Thanks the looping me in on this discussion. As I've been hearing rumblings about the lack of code stewardship on various MM components, I'm already somewhat aware of this gap. I'll be broaching this topic with the soon to be formed Code Stewardship Review Committee. I've already had some discussions with @Krinkle on what I believe to be related issues. In the meantime if you could @Ramsey-WMF or @dr0ptp4kt, please update all the items on the developer/maintainers page that you believe the SDC (formal MM team) will no longer be supporting (mark as "Unassigned" with red background). This will help bring clarity to the specific components/extensions that are orphaned as a result of this team change.

Hi team, we've reviewed this, and here's the guidance:

The Structured Data engineering team should place all "Multimedia" team component responsibilities for MediaWiki extensions not recently worked or in the future prospective roadmap as part of Structured Data in the mode of "Non-security patches not reviewed".

Additionally, instances of the team name "Multimedia" should be updated to "Structured Data" on the component responsibilities page, Developers/Maintainers page, and other major pertinent MediaWiki.org pages and Phabricator projects .

This signals that the Foundation is not in a place to update old multimedia extensions unless there's a validated security risk that must be treated.

MachineVision will not go into the "Non-security patches not reviewed" status, as there is active work on it in the pipeline. "WikibaseMediaInfo" should be added to the component responsibilities page with pertinent information. If I understand correctly, there is also active work on it in the pipeline, and there may be complementary extensions receiving similar attention.

I forget what's the status with "DjVu", does anyone know?

@MarkTraceur would you please let this ticket know once updates are applied?

@Jrbranaa point of clarification: this is a custom SLO for the extensions. What do you recommend for the columns of "Code Stewards" and "Maintainers" given this disposition? I got the impression that it would be easier to just link to Structured Data in both columns rather than set them both to "Unassigned" or one to "Structured Data" and one to "Unassigned" depending on the state of active versus inactive development. I ask that once this is defined then @MarkTraceur update.

@Jrbranaa point of clarification: this is a custom SLO for the extensions. What do you recommend for the columns of "Code Stewards" and "Maintainers" given this disposition? I got the impression that it would be easier to just link to Structured Data in both columns rather than set them both to "Unassigned" or one to "Structured Data" and one to "Unassigned" depending on the state of active versus inactive development. I ask that once this is defined then @MarkTraceur update.

@dr0ptp4kt, if this is just a question about a lowered SLO/de-prioritized work, then I think SDC remaining in both columns makes sense. That being said, my expectation would also be that any outstanding work on the affected components/extensions would be surfaced during annual planning as a gap. Whether or not it is prioritized is a different discussion :-) In the end, we still need/want someone to monitor the ongoing needs of the code and be a point of escalation if need be.

I guess the litmus test is: if work is needed and it gets funded/resourced, would it make sense to be on SDC?

Thanks @Jrbranaa.

@MarkTraceur request to you to process the actions in my prior comment. This is just lowered SLO/de-prioritized product. If you see opportunities to decom not-really-launched product functionality, I think you should feel free to pursue decom of components, of course.

@Jrbranaa the gap is known and socialized, I'm not sure if it'll make it into the prioritized work in the forthcoming FY, of course.

As to the question of what's germane to the Structured Data team, there's a reasonable argument a good chunk of it is, although certainly not all of it.

Kewl, thanks @dr0ptp4kt.

As to the question of what's germane to the Structured Data team, there's a reasonable argument a good chunk of it is, although certainly not all of it.

Would it make sense to identify those that are not and mark them accordingly?

Would it make sense to identify those that are not and mark them accordingly?

@Jrbranaa you thinking like a new column or just some text on the component responsibilities page or something like that? I was a bit leery of trying to change the information architecture or convension mw:Developers/Maintainers.

Example of currently unaddressed production errors in the MediaWiki-Uploading component (API and wiring) which appears to be lacking a steward. These are affecting end-users but also us as their presence raises our tolerance for fatal errors and/or randomly causes deployments to be aborted or SRE alerts to fire.

• T208539: Upload failed with fatal error: Call to load() on a non-object in UploadBase.php
• T198177: Due to PHP fatal, a new version upload overwrote a file (the original is gone)
• T38587: Fatal error when uploading a file to Commons (UploadStashFileNotFoundException)
• T205567: PHP Warning "Unable to delete stat cache" from file uploads
• T204881: Failed executing job: AssembleUploadChunks "Disallowed by AbuseFilter"
• T204879: Failed executing job: AssembleUploadChunks "This file did not pass file verification"
• T187491: ApiUpload throws MWException "No specifications provided to ArchivedFile constructor"
• T228292: API uploads fatal with UploadChunkFileException: Error storing file in '/tmp' backend-fail-internal

I see that the Maintainers page mentions Structured Data Eng as steward for this component, but the above have seen no movement in 6+ months, and the linked Responsibilities page makes no mention of it.

Thanks for posting those @Krinkle. As part of our Code Health objective in Product Engineering in this forthcoming fiscal year, I'm asking that analysis is lined up on best guess higher criticality tasks of this nature for potential treatment. We'll need to work with you and @Jrbranaa to consider this aspect of code health (technical debt identification, prioritization, and remediation) in this sphere of legacy multimedia components with respect to trade offs for allocation of effort and sequencing of practices, processes, and tools in the bigger picture of the fiscal year for code health.