Page MenuHomePhabricator

Close and Delete/Redirect Bulgarian Wikinews
Open, Stalled, LowPublic

Description

This is not a final decision yet, so I plan to immediately place this task on hold. However, I want to start understanding the best way to go through some of the steps of this, because if the decision actually goes final, we are going to need to do this in stages. In particular:

  • Stage 1 (as early as today): We stop general editing access to the wiki. Before things go further than that down the road, though, we have one contributor (currently a sysop there) who will delete certain pages per a previous RfD, as well as some other pages that are either probable copyvios or out of scope. The reason this needs to be done, even given a future deletion/redirection, is that Russian Wikinews is talking about incorporating at least some of this content. So if they wish to do that, I'd like the content to be reasonably policy-clean first. I don't know whether the best way to do this is (a) have stewards full-protect the entire project and withdraw sysop rights from everyone except the one sysop who will do the corrections, (b) close/lock the project from here, but leave sysop editing access intact, and have the stewards withdraw sysop rights from everyone except the one sysop, (c) close/lock the project from here outright, but have the stewards grant the one user rights to edit over the lock (local steward right, interface admin, whatever), or (d) close/lock the project from here, and have the one user instruct the stewards as to what to do there (less efficient, but perhaps resulting in fewer "unusual" exceptions to be made).
  • Stage 2: As soon as that is done, fully close the project and create an xml archive.
  • Stage 3: Reasonably soon after that, as soon as any lingering issues are known to be resolved, redirect all url's within the project to a single landing page containing only the closure notice, with the rest of the project effectively hidden from the outside world.

Details

Related Gerrit Patches:
operations/mediawiki-config : masterFully close bgwikinews
operations/mediawiki-config : masterClose bgwikinews, but allow sysops to edit

Event Timeline

Restricted Application added subscribers: kerberizer, Aklapper. · View Herald TranscriptSep 19 2019, 3:30 PM
StevenJ81 changed the task status from Open to Stalled.Sep 19 2019, 3:32 PM

Placed on hold, as noted above. If the decision goes final, I will change the status back to "open". If the Board decides to close but not delete, I will change the status back to "open" and move this to the other task board. If the Board disagrees with closure entirely, I will change status to "invalid".

StevenJ81 changed the task status from Stalled to Open.Sep 23 2019, 1:59 PM

Board allows LangCom decision to stand. See https://lists.wikimedia.org/pipermail/langcom/2019-September/002426.html. First thing that needs to happen, pretty much as soon as possible, is for access to this wiki to be limited. Please see my question up top as to how to best to execute the first step. We'll go on from there.

kerberizer added a comment.EditedSep 23 2019, 2:38 PM

@StevenJ81 seeing how there has been very active editing as soon as half an hour ago, I could possibly, as a very first step, fully protect all pages on the wiki (via the API) with some appropriate comment in the protection message?

As nobody on the project seems to care about the Board's decision, happily continuing to edit, I decided to exercise my still valid sysop privileges and sysop-protect all existing pages with the following message:

This project is being closed per WMF LangCom's recommendation to the Board of Trustees. For details, see: https://meta.wikimedia.org/w/index.php?oldid=19405704 and https://phabricator.wikimedia.org/T233322

Hmm. Is not an edit filter a better temporary solution?

kerberizer <no-reply@phabricator.wikimedia.org> schrieb am Mo., 23. Sep.
2019, 17:09:

kerberizer added a comment. View Task
https://phabricator.wikimedia.org/T233322
As nobody on the project seems to care about the Board's decision, happily
continuing to edit, I decided to exercise my still valid sysop privileges
and sysop-protect all existing pages with the following message:
This project is being closed per WMF LangCom's recommendation to the Board
of Trustees. For details, see:
https://meta.wikimedia.org/w/index.php?oldid=19405704 and
https://phabricator.wikimedia.org/T233322
*TASK DETAIL*
https://phabricator.wikimedia.org/T233322
*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
*To: *kerberizer
*Cc: *MarcoAurelio, jhsoby, MF-Warburg, Aklapper, kerberizer, StevenJ81,
Dibya, 94rain, DannyS712, Guilhermebm, Jony, JunaidHafeez, Jayprakash12345,
Zoranzoki21, DatGuy, Devwaker, Niklitov, Urbanecm, JEumerus, Ananthsubray,
Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, Snowolf, Dcljr, Koavf,
Rschen7754, Jdforrester-WMF, Matanya, Mbch331, Rxy, Jay8g, Krenair

Hmm. Is not an edit filter a better temporary solution?

You're absolutely right. No need to spam the logs. Thanks for the idea!

kerberizer added a comment.EditedSep 23 2019, 3:26 PM

Completely forgot how AbuseFilter could also prevents deletions, which may be also desirable at this moment, and restricts even the sysops themselves. So, excellent idea, indeed, thanks again!

Here's the filter: https://bg.wikinews.org/wiki/Special:AbuseFilter/1 Hopefully it should work as expected with the very simple rule action in ['edit', 'move', 'delete', 'upload'] and preventing the action with this message.

FWIW, I've also removed the previous sitenotice, which I had put to warn the users about the ongoing discussions and the possible closure of the project. I won't be posting anything in its place, until (possibly) instructed to do so.

Hello everyone,

I'm a bit surprised that the project is "closed" using a filter. if this is that urgent so it can't wait a while, feel free to ping me at #wikimedia-tech IRC channel, I'd be happy to introduce the restriction quickly.

Now, I'm wondering what's the required next step from the sysadmins: properly close the wiki? Restrict editing to just admins?

Martin

Hello everyone,
I'm a bit surprised that the project is "closed" using a filter. if this is that urgent so it can't wait a while, feel free to ping me at #wikimedia-tech IRC channel, I'd be happy to introduce the restriction quickly.
Now, I'm wondering what's the required next step from the sysadmins: properly close the wiki? Restrict editing to just admins?

My personal concern is about the many controversies surrounding the project, including possibly problematic content. The number of edits has suddenly gone so high these last days, that I find it difficult to even follow what's going on (well, not without completely abandoning my day job, anyway). That being said, if there's any strong opposition to the abuse filter, I'll turn it off.

StevenJ81 added a comment.EditedSep 23 2019, 3:59 PM

@Urbanecm , "'closed' using a filter" is only intended very briefly, and if you prefer doing this a different way we can manage it.

Effectively, what we need is for everyone except @kerberizer (User:Iliev)—including the other sysop (User:Григор Гачев)—to be prevented from editing. kerberizer will do some cleanup on the contents, and then the sysadmins should properly close the wiki, with the usual "except stewards, and sysadmins". But this first step should happen promptly now.

As far as I'm concerned, if you do it that way, then as long as the stewards pull User:Григор Гачев's sysop flag, we're fine. Or it can be done by a filter not allowing anyone except Iliev. I'm not the expert on the mechanism.

StevenJ81 added a comment.EditedSep 23 2019, 4:20 PM

Contacted Martin at IRC. Wiki will be closed except for sysop. Placed request to desysop Grigor at SRP. I am holding off on the sitenotice and on posting the close at Meta until the desysop is complete.

Change 538662 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Close bgwikinews, but allow sysops to edit

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

Change 538662 merged by jenkins-bot:
[operations/mediawiki-config@master] Close bgwikinews, but allow sysops to edit

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

Mentioned in SAL (#wikimedia-operations) [2019-09-23T16:26:03Z] <Urbanecm> mwscript createAndPromote.php --wiki=bgwikinews --sysop --force 'Martin Urbanec' - temporary (T233322)

Thanks @StevenJ81 for your clarification. I'll close the wiki ASAP.

Mentioned in SAL (#wikimedia-operations) [2019-09-23T16:27:46Z] <urbanecm@deploy1001> Synchronized dblists/closed.dblist: 84afa44: Close bgwikinews, but allow sysops to edit (T233322; 1/2) (duration: 00m 58s)

Mentioned in SAL (#wikimedia-operations) [2019-09-23T16:29:15Z] <urbanecm@deploy1001> Synchronized wmf-config/VariantSettings.php: 84afa44: Close bgwikinews, but allow sysops to edit (T233322; 2/2) (duration: 00m 56s)

Mentioned in SAL (#wikimedia-operations) [2019-09-23T16:33:10Z] <Urbanecm> Remove my temporary adminship on bgwikinews (T233322)

The wiki is locked for admins and stewards now.

Urbanecm changed the task status from Open to Stalled.Sep 23 2019, 4:34 PM

I've also removed the abusefilter, for admins, it wouldn't be really working anyway (they can easily turn it off), and ordinary users will be already affected by my config change. Stalling until further change is required.

Thank you very much, @Urbanecm!

Happy to help!

@MF-Warburg, can you please go over to SRP and confirm the desysopping. Thanks.

kerberizer added a comment.EditedSep 23 2019, 9:08 PM

As I wrote on my talk page on Meta, I'm basically ready with the cleanup, so I guess the wiki could be further locked, but this is really up to @StevenJ81 to decide/request.

Just a note about Stage 3, before I forget: it would be great if the village pump and the voting page can easily remain accessible—including for diff and oldid links—even after all other pages are redirected to the single landing page with a closure notice.

There are many links to them from the discussions on Meta (both to anchors and via diff links, probably also oldids) that would otherwise get broken. It's possible to just copy those pages elsewhere and rewrite the links, but it'd require some effort.

@Urbanecm: cleanup is finished. Wiki can be fully locked.

StevenJ81 changed the task status from Stalled to Open.Sep 23 2019, 9:15 PM

Mentioned in SAL (#countervandalism) [2019-09-23T21:40:03Z] <hauskatze> Drop bg.wikinews from CVNBot10: project locked, soon to be deleted # T233322

Just a note that once the wiki is fully locked ("Closed"), there are a few items to discuss before we go to the effective deletion (by redirection).

Urbanecm claimed this task.Sep 25 2019, 7:14 AM
Urbanecm triaged this task as Low priority.
Restricted Application added a project: User-Urbanecm. · View Herald TranscriptSep 25 2019, 7:14 AM

Change 539029 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Fully close bgwikinews

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

Urbanecm moved this task from Backlog to To deploy on the User-Urbanecm board.Sep 25 2019, 7:16 AM

@Urbanecm Don't have much experience with MW, so sorry if it's a stupid remark, but wouldn't this patch also remove the stewards' access? I think @StevenJ81 might possibly want them to still be able to do some additional cleaning.

No remark is stupid :). In [my previous patchg(https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/538662), I've added bgwikinews to closed.dblist, which is used - among other places - in groupOverrides. My patch basically means that instead of my custom configuration (that allows sysops to edit, not just stewards), the default configuration for closed wikis will be used.

No remark is stupid :). In [my previous patchg(https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/538662), I've added bgwikinews to closed.dblist, which is used - among other places - in groupOverrides. My patch basically means that instead of my custom configuration (that allows sysops to edit, not just stewards), the default configuration for closed wikis will be used.

Oh, indeed, completely forgot that there must be a default config, sorry. Thanks a lot for the explanation! :)

Change 539029 merged by jenkins-bot:
[operations/mediawiki-config@master] Fully close bgwikinews

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

Mentioned in SAL (#wikimedia-operations) [2019-09-25T11:07:53Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: 127485c: Fully close bgwikinews (T233322) (duration: 01m 06s)

Urbanecm removed Urbanecm as the assignee of this task.Sep 25 2019, 11:12 AM
Urbanecm removed a project: User-Urbanecm.
StevenJ81 changed the task status from Open to Stalled.Sep 25 2019, 1:05 PM
StevenJ81 claimed this task.

I'm going to take ownership for the moment, and set the status to "stalled". We're looking into just a little further steward cleanup here on possible copyvios. When that is finished, I will create a subtask for the redirect.
https://phabricator.wikimedia.org/T233322
phabricator.wikimedia.org
crawl=CC-MAIN-2019-51
218264
application/http; msgtype=response
sha1:KGDGTXCPAV2N4I2JKER5K3WLPWOU32PM
<urn:uuid:f3467c94-6ef3-460b-abf4-43fbe1200109>
2019-12-09T21:18:06Z
208.80.154.224
text/html
sha1:MKPMIBGAFUPLI37RJI7CVSTJEPDF5HV5
<urn:uuid:5aa60887-ff1f-444b-a12e-1c255f565429>
https://phabricator.wikimedia.org/T233322
response
<urn:uuid:f1105f4b-c16a-48aa-99b4-8cab70768070>
isPartOf: CC-MAIN-2019-51
publisher: Common Crawl
description: Wide crawl of the web for December 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-37.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/