I've updated the task objectives to attempt to make this task clearer.

Remove Actions (Delete, Move, Protect) from all Community Configuration related pages (dashboard, configuration forms, history pages, and .json pages). No changes needed for the Discussion (talk page) Actions.

@Trizek-WMF, will you double-check to make sure I'm not missing something? (My guess is that many of the General tools aren't especially useful on these pages, but I don't know if it makes sense to actually remove them).

Remember this wiki (can't remember which one) where they deleted the pages because they didn't like them? We should remove the links and also the matching actions triggered by URL (action=delete & al.).

Why shouldn’t people be able to delete pages? If a MediaWiki message is deleted, that means that the default value (shipped in the en.json file of the extension) takes effect again; the same happens at the old title if the page is moved away without leaving a redirect. This may be disruptive (e.g. if mentorship gets turned off despite there being active mentors), but not less disruptive than manually setting those default values.

This functionality is atypical for special pages, as other essential special pages like Special:RecentChanges, Special:Watchlist, and Special:Contribute do not offer these options.

This is typical for special pages closely related to non-special pages. https://en.wikipedia.org/wiki/Special:WhatLinksHere/Massachusetts_Avenue_Line has them, https://en.wikipedia.org/wiki/Special:RecentChangesLinked/Massachusetts_Avenue_Line has them, even https://en.wikipedia.org/wiki/Special:MovePage/Massachusetts_Avenue_Line is a special page that has them. (The special pages you listed of course don’t have these options: special pages themselves cannot be moved or deleted, so the options wouldn’t make sense there. They do make sense on Special:CommunityConfiguration.)

In T365504#9828717, @Trizek-WMF wrote:

Remember this wiki (can't remember which one) where they deleted the pages because they didn't like them? We should remove the links and also the matching actions triggered by URL (action=delete & al.).

That would be Lithuanian Wikipedia/T344013. But I agree with Tacsipacsi that there's no reason to manually interfere here rather than assuming admins know what they're doing, as they did in that situation.

Thanks for the feedback, @Tacsipacsi & @Pppery, I appreciate the additional perspective here.

I can see that perspective that we should avoid removing an action that might have a legitimate use case. I'm just trying to limit the possibility that a deletion might happen by mistake. I think especially on smaller wikis where documentation isn't translated, and admins might not be as well-vetted, mistakes are more likely to happen. And to be clear, even if we removed the Delete action, we wouldn't actually prevent the page from being deleted.

Do you have thoughts on Growth pursuing one of the following options:

1. Do not display the Delete/Protect links in the form, but show them in the MediaWiki page itself
2. Do not display the Delete/Project links in either place, but do not prevent users from manually constructing the deletion URI

In both situations, admins who really want to delete the page will be able to do so. In the second situation, we can be very certain the deletion is done by someone who knows what they're doing (as they would need to create the deletion URI themselves).

I'm fine with 1. 2 is still needlessly interfering with the standard way MediaWiki works in my opinion.

Change #1031756 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Improve navigation link handling in CommunityConfiguration

https://gerrit.wikimedia.org/r/1031756

In T365504#9840522, @KStoller-WMF wrote:

I can see that perspective that we should avoid removing an action that might have a legitimate use case. I'm just trying to limit the possibility that a deletion might happen by mistake.

The core of the wiki principle is that it should be easy to fix mistakes, not hard to do them. While it applies to administrative actions to a lesser extent, I think it should still be the starting point.

I think especially on smaller wikis where documentation isn't translated, and admins might not be as well-vetted, mistakes are more likely to happen. And to be clear, even if we removed the Delete action, we wouldn't actually prevent the page from being deleted.

But it would practically prevent it on those smaller wikis, whose admins likely don’t know how to access a hidden action (or that they can do so at all).

Do you have thoughts on Growth pursuing one of the following options:

1. Do not display the Delete/Protect links in the form, but show them in the MediaWiki page itself
2. Do not display the Delete/Project links in either place, but do not prevent users from manually constructing the deletion URI

In both situations, admins who really want to delete the page will be able to do so. In the second situation, we can be very certain the deletion is done by someone who knows what they're doing (as they would need to create the deletion URI themselves).

I find #2 a no-go, since we practically prevent admins from doing those legitimate deletions. (Unless they find another way to access the deletion page (e.g. Navigation-Popups-Gadget includes a delete link) – in which case they aren’t warned at all.)

#1 is less bad, but still not good.

A good solution would be not hiding anything but adding a warning on the deletion page itself: this would ensure that the delete action is discoverable without any gadgets or knowing how to construct the URL and at the same time ensure that admins are warned regardless of the way they used to reach the deletion page. Unfortunately, I couldn’t any hook to implement this, but since MediaWiki core is also developed by WMF, nothing prevents us from adding a new hook.

Change #1038843 had a related patch set uploaded (by Sergio Gimeno; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@wmf/1.43.0-wmf.8] Improve navigation link handling in CommunityConfiguration

https://gerrit.wikimedia.org/r/1038843

Change #1031756 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Improve navigation link handling in CommunityConfiguration

https://gerrit.wikimedia.org/r/1031756

Checked in eswiki beta

• Special:CommunityConfiguration (and Special:CommunityConfiguration/Mentorship and other subpages) cannot be deleted/moved
• pages in MediaWiki namespaces (e.g. MediaWiki:GrowthExperimentsHelpPanel.json) have the options to be Moved/Deleted/Protected

Deleting/moving MediaWiki json pages seems not to be affecting the how the modules on Special:CommunityConfiguration function. Protect action works as expected too.

Change #1038843 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@wmf/1.43.0-wmf.8] Improve navigation link handling in CommunityConfiguration

https://gerrit.wikimedia.org/r/1038843

Mentioned in SAL (#wikimedia-operations) [2024-06-06T20:22:12Z] <urbanecm@deploy1002> Started scap: Backport for [[gerrit:1039729|[mswiktionary] Rename namespace "Wiktionary" to "Wikikamus" (T366549)]], [[gerrit:1038843|Improve navigation link handling in CommunityConfiguration (T364938 T365504 T360954)]], [[gerrit:1038714|Drop logging level for unsupported providers to DEBUG (T366519 T360954)]]

Mentioned in SAL (#wikimedia-operations) [2024-06-06T20:24:30Z] <urbanecm@deploy1002> urbanecm and sgimeno and gergesshamon: Backport for [[gerrit:1039729|[mswiktionary] Rename namespace "Wiktionary" to "Wikikamus" (T366549)]], [[gerrit:1038843|Improve navigation link handling in CommunityConfiguration (T364938 T365504 T360954)]], [[gerrit:1038714|Drop logging level for unsupported providers to DEBUG (T366519 T360954)]] synced to the testservers (https://wikitech.wikimedia.org/wiki

Mentioned in SAL (#wikimedia-operations) [2024-06-06T20:41:54Z] <urbanecm@deploy1002> Finished scap: Backport for [[gerrit:1039729|[mswiktionary] Rename namespace "Wiktionary" to "Wikikamus" (T366549)]], [[gerrit:1038843|Improve navigation link handling in CommunityConfiguration (T364938 T365504 T360954)]], [[gerrit:1038714|Drop logging level for unsupported providers to DEBUG (T366519 T360954)]] (duration: 19m 42s)