[02:55:01] what wiki prenium link? [03:48:57] What do you mean? [03:59:19] I'm pretty sure they're asking for the link to WikiForge, which appears to be down right now [04:01:46] down? [04:01:53] it's rarely if ever down [04:03:53] WikiForge is not down. [04:04:18] Guess I'm trying the wrong domain then [04:04:34] wikiforge.com and wikiforge.net don't work for me [04:05:22] wikiforge.net works [04:05:26] wikiforge.com we don't own sadly [04:06:14] I forgot that the meta wiki for WikiForge wasn't at meta.wikiforge.net [04:06:25] it is hub.wikiforge.net [04:07:10] That's the domain I was trying [04:07:24] It works for me [04:07:45] @agentisai is a cp down so only some locations are down? [04:08:09] shouldn't be, otherwise gdnsd would mark it as down [04:09:44] hub.wikiforge.net is not; meta.wikiforge.net was the domain I was referring to [04:10:03] oh lol makes sense [04:10:16] ah [04:10:25] we should probably redirect meta. to hub. in that case [04:14:51] Yep, meta is deprecated at this point, so not loading would be expected. [10:45:00] [1/4] also writing this for anyone particularly interested in helping miraheze get back up to speed [10:45:00] [2/4] https://meta.wikitide.org/wiki/User:Raidarr/Miraheze_Triage [10:45:01] [3/4] Feel free to address if you think you've got it on the miraheze side (plenty of items non-stewards can deal with), but the only completely done section is rfrw, the sn sections are under heavy construction. Or maybe forward to miraheze people who will proactively handle it, up to anyone. The hope is to wipe out the stuff stewards simply don't need to look at and make the job as simpl [10:45:01] [4/4] e as possible for them to finish off. [10:54:19] https://github.com/miraheze/mw-config/pulls [10:54:58] regrettably I am useless on the git/phab/overall technical end [10:55:19] which is where the majority of wt personnel have been looking at/dreading the backlog for [10:56:48] my initiative would only thrive with a handful of stewarding exclusive eyes to look at it really but for however long that takes, I measure a good month before that's even remotely in order on a good time, we're stuck with community softening the pad for tech-buried stewards to look at mundane community as secondary [14:19:23] [1/2] i still have my original wiki up on miraheze and my more updated wiki on wikitide...wonderin' what i should do between the two of them with the recent rfc! should i close the old one? poke it every time it goes inactive? update it to match the more recent version on wt? [14:19:23] [2/2] options, options [15:27:38] long term I imagine the wiki would merge back to miraheze with little input required on your part, so really whatever is more clean/path of least resistance - close/private the old one can deprecate it in favor of the new version. [15:28:04] I do know having both live can result in end-reader confusion and seo penalty [15:34:42] Does this mean the merger was the decision made for that community? [15:47:26] I'm giving you what's basically my best prediction on what will happen next: it is not finalized but it is winning by miles, therefore I believe it would be most responsible to plan with that outcome in mind [15:48:02] I could well be wrong and I neither represent miraheze nor wikitide however [15:49:03] as for what you quoted I mainly meant that for people who overlap with the miraheze community and have a proactive interest in reducing its workload, even with the merger it will be a massive amount of work [15:51:45] im not helping miraheze after all they did, and all the drama they caused [15:53:22] you are free to do whatever you want but I will be straight with you, you have spent a considerable amount of your miraheze time contributing to hysteria and making marginal improvements from that state. Miraheze must do what it needs to survive regardless. [15:54:25] though miraheze is not and has never been a hivemind, it has always been at the mercy of not just volunteers, but volunteers with good judgement, skills to communicate with each other, and the willingness to step in even when there is adversity if they can fulfill the first two conditions [15:54:54] much of its current condition was a total failure of communicating or stepping up, and poor judgement on all sides knocking the cards over [15:57:26] Got it, thanks for the info 👍 [16:10:48] im starting my own independent wiki farm [16:33:57] good luck then, I'm on your side (just for learning and stuffs) [16:39:25] its easy and im giving everyone full perms to there own wiki [16:59:01] pray you do not encounter someone with ill knowledge [16:59:59] lol [17:04:33] I will say there should be a review of more restricted access and some of how miraheze tries to process things 'democratically' is not all that practical [17:05:33] again off the top of my head I would consider interwiki table abuse and javascript access to be equal threats - something perhaps to streamline under 2fa access and a certain amount of global participation before they can be granted, to rule out accounts created expressly to abuse these sensitive features [17:06:38] bigdelete, in a similar vein unless there's a performance aspect [17:08:49] [1/7] To clarify, nothing is fully decided, and any final decision is still pending negotiations with MH LTD. We have no intention to change the URLs of WikiTide wikis and nothing will be changing on a day-to-day basis for our users. [17:08:49] [2/7] Why we're even entertaining merger (where WT acquires MH): [17:08:49] [3/7] * we're able to operate independently today but see a large potential benefit in bringing the two technical teams together to ensure faster response times to incidents and greater stability for both communities. [17:08:50] [4/7] * MH has its own funding, and, if properly applied, could live much more efficiently within its current donation levels -- as former MH volunteers, we want to see that project succeed and thrive, this is something we can help them do. [17:08:50] [5/7] * MH is a storied, long-lived community project that hosts thousands of wikis, with an equally large bench of technical folks happy to share their knowledge. [17:08:50] [6/7] * As much as we've built a community of best practice in community helping community, combining those communities will further what we can all accomplish together. [17:08:51] [7/7] Nothing else to report for now, but we'll continue to keep folks apprised as things move forward. [17:16:19] Technically everything that can be done with interwiki table abuse can be done with other means anyway and those other means are potentially a lot harder to detect and moderate than a suspicious interwiki table entry [17:24:09] I would not be particularly bothered if the interwiki thing just became a normal default option [17:24:18] it's always been a bit of a sore thumb [17:24:28] Yep, the limited risk of IW entries is why we don't police them as strongly as MH, so far that experiment's gone well. I'd like to see that carry back to MH [17:25:35] I've never seen bigdelete be a problem as far as when it was desired to be used (though I guess maybe barrier to entry adds to that), and miraheze is the experiment in which wiki-wide javascript is the threat and yet I've very rarely seen that result in issues [17:26:27] though it is a reason I don't necessarily leave scripts enabled for miraheze even though it's generally one of the most trustworthy sites on the internet to have scripts enabled on [17:57:53] BIGDELETE is particularly an issue as it has the ability to hang MediaWiki servers or lag the jobqueue if done too many times [17:59:27] I wondered about the technical aspect, so that is sound [19:48:25] @jeb_cc your commit is failing the test so cant be merged even if someone was available to do it. [23:23:38] Thanks, although that's not my commit. [23:25:14] Redmin is R4356th I believe. [23:49:34] Pretty sure R3456th is Redmin's old username [23:50:29] It is on MH, it is still their current username on GH