[02:25:33] [1/2] There is this Wikibase I have that, in a perfect world, would be hosted on Miraheze. It's goal is to build a massive bibliographic Wikibase to expand off the work already done by Wikidata. This staggeringly large scope is why I haven't proposed moving it. My question is, does Miraheze have history hosting wikis with a very high volume of page creation, and about how far can the [02:25:34] [2/2] y push it before becoming noisy neighbors? [02:26:06] And, if the setup currently wouldn't support high volume page creation very well, is this a problem that can be solved with more servers? [03:54:23] [1/2] The Immanuelle wikis did fine even when mass page creation was done. It was the other parts of our stack which scaled poorly. In the end backup dump generation brought the whole farm down. [03:54:23] [2/2] If the wiki is on MH we may also have to enable Cloudflare challenges for every visitor (_I'm under attack mode_) because wikis with lots of pages are a natural target for scrapers. [04:18:56] I hadn't thought of downstream derivation, that's a really good pointy [04:29:43] Formal petition to start calling it squeegee mode [04:30:40] +1'ing on this. [04:37:25] @reception123 would it be possible to make the default closure reason in MW inactivity instead of crat close? [04:37:45] Ohhhh, that's a good call [04:38:05] Err, hmmm... [04:38:35] If these are primarily designed for 'if the crat decides to close the wiki themselves', I think current default makes sense [04:39:03] Provided the time-based auto-closure is selecting the right reason [04:39:36] [1/2] More so just because it minorly annoys me to go to a wiki and see it defaults to that for wikis made before last week [04:39:36] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1532608645307830282/image.png?ex=6a6d7887&is=6a6c2707&hm=98c0b8e745a2046017d18ea4d496f34bcf9d58af14946ae54e68e971e556134f& [04:39:57] ¯\_(ツ)_/¯ [12:41:24] If we can figure out how to always have it set as crat closure if a crat closes [12:42:06] Since it's miraheze-restricted, they can't select the actual reason when they close so that's why I made it default [12:44:36] I'll deploy that today, CI was being weird [14:42:00] could just set a default of "beforereason" for ones made before last week which localises to "closed prior to reasons existing" and then update that in DB and then when those closed wikis go bye bye eventually remove that to clean up