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.

Event Timeline

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.

@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!

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.

@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.

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.

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

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 triaged this task as Low priority.

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 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 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.

The author who created this task and has not edited for three months asked us a few participants of the deletion proposal discussion. We said no objections to deletion, though I said "no redirect". Shall the task be reopened, or how else shall the task be?

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.

I propose to close this task as resolved. Wikis are never really deleted (ie. the content stays at the servers), and unless the content would cause us some trouble, I think it should just stay as-is.

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.

I propose to close this task as resolved. Wikis are never really deleted (ie. the content stays at the servers), and unless the content would cause us some trouble, I think it should just stay as-is.

No objections from my side. I don't remember anything particularly problematic remaining on the wiki and it's actually nice to have those discussions on the project about the closing still available online.

I guess I'd very much love to hear @StevenJ81 's opinion too—but I'm afraid he seems to not have been around for quite a long time (I just sincerely hope he's OK). Would love to hear what @gh87 thinks as well—he did a truly marvellous job finding all those copyvios and likely has a much better idea of what state the wiki was left in after we did the final cleanup before the full lock.

I discussed this onwiki with LangCom (diff). The LangCom seems reluctant to delete the wiki at this time. The stewards couldn't do much about the articles copying other sources. I'm almost out of options. I hate to see the task closed (or indefinitely stalled), but I guess I can't persuade them any longer.

I would rather see it nuked and then started over from scratch. However, if enthusiasm for project deletion has waned, then I must move on from this.

Almost forgot: no transfer to any other project unless a project will clean up and revdel content as promised

By the way, can you ask for temp adminship and then delete the problematic content? I'll give more list if necessary. Here you go

Thank you very much, @gh87 ! I really appreciate it that you continue to take care about the problems. @Urbanecm , would it be too difficult to, say, redirect all requests for pages in the main NS to МедияУики:Sitenotice? Or maybe even all requests (obviously, without requests to the sitenotice itself, unless we want some funny recursion :D)—I'd be fine even with the discussions hidden from view. I saved the important ones in the web archive, so there is a “backup”.

By the way, can you ask for temp adminship and then delete the problematic content? I'll give more list if necessary. Here you go

That's also an option, indeed. Though, to be honest, I probably prefer simply hiding the content—if possible, of course. But maybe we could do both, too.

I'm actually most concerned about some biased or uncritical articles, like this one (and it just happened to be the first one from Special:Random ). In the past year—and what a year for the whole world—I got to fear even more the conspiracy theories. This article, for example, covers the protests against the “Norwegians trying to take our kids away and give them to gays”. While the article doesn't explicitly touch those messages and tries to keep a more “mainstream” tone, covering also some critical views of the protests, in my eyes it still remains chillingly uncritical. One technique I began to worry about in the past year was the “balanced”, “unbiased” presentation, where one gives equal weights to a conspiracy theory and its opponents.

Just to be clear: none of what remained on the wiki is outrageously bad in this regard—we did clear the things with the most serious and easily identifiable problems. And hardly many people would read those articles, anyway.

That's also an option, indeed. Though, to be honest, I probably prefer simply hiding the content—if possible, of course. But maybe we could do both, too.

No objections to hiding either