Adding as subscribers the people who created the currently-open "Archive <extension>" tickets (please either add anyone I missed, or yell at me for unnecessarily adding people =) ).

Coming from T102920 there is https://www.mediawiki.org/wiki/Gerrit/Inactive_projects already.

I use the criteria Andre mentioned and some common sense as well. Thanks.

Personally, and this applies mostly to extensions that never were in any Wikimedia source control (storing extension code on-wiki), anything pre-2010 that hasn't been updated qualifies. I think for extensions/skins it matters mostly how compatible they are. Skins that weren't updated after 1.24 quickly loose compatibility (if they aren't incompatible yet), and extensions that aren't updated after major changes, such as 1.27 auth replacement, 1.17 ResourceLoader will not work on supported versions of MediaWiki. If the extension hasn't been updated for (a) year(s) after these changes, I think it's safe to assume they can be archived. Anyone who wishes to revive the extension with adjusted code can do so easily. Unfortunately, this doesn't offer clear criteria, because they are extension dependent. If I had set a number of years, I'd probably pick 2, because that's how long LTS releases of MediaWiki are supported.

In T198059 @Dinoguy1000 wrote:

If an extension/skin was never migrated to Git, or its maintainer(s) refuse to put it there, does that count in favor of archiving?

rSVN is already archived, so I'd say that if they don't want to migrate, their extension is already archived, and we can only let our users know the same. Additionally, I doubt there is any extension in rSVN that will still work with supported MediaWiki versions.

In T198059#4310747, @Aklapper wrote:

Coming from T102920 there is https://www.mediawiki.org/wiki/Gerrit/Inactive_projects already.

That's very useful as well. I think the least we can do is link to that page on Projects-Cleanup.

In T198059#4310747, @Aklapper wrote:

Coming from T102920 there is https://www.mediawiki.org/wiki/Gerrit/Inactive_projects already.

I did some looking around before filing this ticket, but didn't find that page; thanks for the pointer. =) And per Mainframe98, that should definitely be linked on Projects-Cleanup.

@Dinoguy1000 don't worry about missing an existing document. We have a lot of doc everywhere, thankfully we are in a collaborative space and what one miss is caught by others \o/

I have recently requested a few extensions to be archived and try to write a meaningful explanation for each request. The trend I noticed were one or more of:

• Fatal error on MainPage or Special:JavaScripttest
• Database cant be installed on MySQL
• update.php or install.php --with-extensions fails
• No meaningful code update for the last 2 - 3 years
• https://wikiapiary.com/ showing only a few wikis, some unrecheable and others terribly outdated
• Supports a tech that no more exists
• Lack of page on www.mediawiki.org

We can probably look at the last tasks that got filled for Projects-Cleanup and find other reasons.

Side note: members of the Projects-Cleanup project have access to a form to easily generate the extension/skin archiving task ( https://phabricator.wikimedia.org/maniphest/task/edit/form/33/ ). Although I could just archive anything given I have admin rights, I made a point of filling such requests to have at least one other person to shim in.

Note: some extensions might still be working just fine with 1.27 which is supported until June 2019. So although they might not work anymore with 1.31, maybe when people upgrade to 1.31 they will have an opportunity to fix the extension for 1.31.

Although this work looks to address things that might be outside of the scope of the Code Stewardship Reviews[0] (which is focused primarily on un/under maintained orphaned code deployed to WMF production). There's a rubric that we created to help use evaluate and propose what to do with these areas of code. Might be worth taking a look to see if there's some stuff we could leverage either way. Note, archiving/sunsetting of code is only one of the possible outcomes for the Code Stewardship Review process.

[0]https://www.mediawiki.org/wiki/Code_stewardship_reviews

In T198059#4313551, @hashar wrote:

Side note: members of the Projects-Cleanup project have access to a form to easily generate the extension/skin archiving task ( https://phabricator.wikimedia.org/maniphest/task/edit/form/33/ ). Although I could just archive anything given I have admin rights, I made a point of filling such requests to have at least one other person to shim in.

I don't have permission to access that form, which seems a shame. Are forms in general only usable by members of the associated project, or was this one specifically configured that way?

In T198059#4313559, @hashar wrote:

Note: some extensions might still be working just fine with 1.27 which is supported until June 2019. So although they might not work anymore with 1.31, maybe when people upgrade to 1.31 they will have an opportunity to fix the extension for 1.31.

This is an interesting point. Should support for a currently-supported version of MediaWiki be an explicit criterion here, or is it too likely to just duplicate other criteria?

I don't have permission to access that form, which seems a shame

There's nothing shamely about that. You just have to be a member of Projects-Cleanup. You can become one at https://phabricator.wikimedia.org/project/members/2829/ yourself.

Forms can be set to be displayed or usable in many ways. In this case the administrators though that people outside the Projects-Cleanup project would not benefit from seeing a "create an archival request" link in their "create a task" dropdown every time. Not sure if it can be configured to be used by accessing the form's URL without being a member of the project yourself. I guess @Aklapper and @mmodell will know.

Regards.

In T198059#4313167, @Dinoguy1000 wrote:

In T198059#4310747, @Aklapper wrote:

Coming from T102920 there is https://www.mediawiki.org/wiki/Gerrit/Inactive_projects already.

I did some looking around before filing this ticket, but didn't find that page; thanks for the pointer. =) And per Mainframe98, that should definitely be linked on Projects-Cleanup.

Alright, I linked to that page from https://phabricator.wikimedia.org/project/manage/2829/ now.

I'd be satisfied with some easily-discoverable, reasonably clear rules of thumb; I think it would probably be pointless to try to define hard criteria for this (unless the WMF as an organization wanted to draw a line in the sand, which might not be unreasonable depending on what they're after as far as custom extensions/skins are concerned).

Is it fair to say that in general, archival should be done in cases where it's unlikely that a given extension/skin will be maintained (whether that be because it's grossly out-of-date, the maintainer(s) has vanished, the source code has been lost, etc.)? If so, this can be documented while also leaving open the possibility for archivals for other reasons, such as planned sunsetting of WMF extensions.

In T198059#7624025, @Bugreporter wrote:

• What about extensions hosted at GitHub? When Wikimedia moved to GitLab the process may be changed as you can host your own extension at your personal repositories

This isn't unique to GitLab; there's nothing stopping someone from hosting a published extension on their personal GitHub account either. UIAM the current practice is to just ignore these repositories when archiving an extension.