Are we going to point the URL somewhere, or is it just going to die?

In T203899#4569552, @Peachey88 wrote:

Are we going to point the URL somewhere, or is it just going to die?

Probably we could point it at the meta page? We definitely shouldn't let it die.

In my previous experience with creating redirects at the Apache level (alswikibooks and wiktionary to alswiki and mowiki, mowiktionary to rowiki) it required wiki deletion, not just closing (cc @EddieGP for the memories and T181923: Delete als.wik(ibooks|iquote|tionary), mo.wik(ipedia|tionary) for the checklist/issues, etc. Granted, it's a non-CA wiki with virtually nothing to be kept around afaics so this should be easier).

That said, I feel that with the rules for creating a wiki at hand, creating one to host just one page and for just this campaign was overkill, something like using a sledgehammer to crack nuts, with all due respect. A webpage hosted in a *.wikimedia.org domain would've just served the same purpose IMHO. What's done is done though.

Creating a wiki requires a lot of work. Deleting a wiki does often require far more work as there's no deleteWiki.php script to do most operations for us.

That said, the European Parliament vote to which this extension was aimed at is over. Unless you want to keep this around for the final votes in the Parliament after the Commision-Council-Parliament dialogue finishes, we can start doing this now.

Regards.

First of all, I agree with MarcoAurelio. I don't have any context here, but if the plan was to create a new wikis for a one-off campaign and delete it after said campaign is over, then you've probably found one of the most effective ways of burning wmf resources that could easily be circumvented. I'm not sure whether it's easy to create a wiki these days, but deleting it is definitely not, it requires a lot of manual work from different wmf teams, none of which are usually short on work.

That said, I tried to document everything we did in T181923, and all possible problems that occured, at https://wikitech.wikimedia.org/wiki/Delete_a_wiki . If there's anything I can help with, feel free to ping me. :)

https://fixcopyright.wikimedia.org/wiki/Special:AllPages shows just two pages. Overall the deletion won't be complicated, but it indeed requires coordination from several groups. This cannot commence until we switch back to the primary datacenter (eqiad) so keeping the task stalled for now.

Wikis using CentralAuth are harder...

This one isn't.

@CCicalese_WMF It this ready to be unblocked? The domain could e.g. redirect to a blogpost about the campaign, or perhaps to https://policy.wikimedia.org/policy-landing/copyright/.

I'm checking with Legal to see if we're ready to do so.

@CCicalese_WMF The wiki requires non-trivial long-term maintenance because it isn't a "simple" wiki.

• It has three dedicated extensions: EUCopyrightCampaign, EUCopyrightCampaignSkin, and SkinPerPage. These extensions are non-trivial with regards to exposing security-sensitive interactions under *.wikimedia.org which means it requires upkeep even during times where one would otherwise not prioritise the site's availability (e.g. now, when the campaign less active).
• It has dedicated VCL Traffic overrides, which is unusual for a wiki (T203179), and is one more thing to think about and keep working through on-going VLC upgrades, migrations, and maintenance.
• It has custom hooks in wmf-config (c/458345, which in turn make use of features that WMF doesn't use elsewhere. This means those features are now subject to higher-level of scrutiny throughout the year because they can affect production every week (as opposed to only being a priority around major releases).
• It enables a ULS feature that no other wiki enables (wgULSLanguageDetection), hence costing similar scrutiny and up-keep.

This overhead inevitably affects teams besides CPT. Also for general cross-repo maintenance for skins and extensions. (This is one of only eight WMF-deployed skins.)

We implicitly have to spend part of our time on these. Could we explore ways to reduce the on-going cost?

For example, the wiki could be undeployed/redeployed as needed, with the associated code bases, hooks, and overrides only audited and refreshed on demand.

Also, from my original review-for-deployment, note that the current skin-based implementation is fairly complicated. If it were ported to a Special page, it would require only one extension to operate (as opposed to three), the codebase would be easier to audit for security review, would require less on-going maintenance (given no Skin involvement), and would also become easier for you to quickly adapt to future campaigns :)