[12:32:06] https://cdn.discordapp.com/attachments/443926951292567562/1525842187458449448/image.jpg?ex=6a54dac6&is=6a538946&hm=6f8a3ebe540c75085d042f623cb810bcd255e6f98be9d3b36100a733fd6ad73c& [12:42:33] @Discord Administrators [18:04:30] Interesting. Likely just minor English grammatical edits from the looks of it. IP belongs to Comcast. What's weird about it? [18:06:28] The edits looked a bit spammy, blanking pages and changing data that looks correct (like ukranin people) to "incorrect" [18:06:34] Looked weirder at the time [18:14:04] [1/3] I see what you mean. With IPv6 IPs, it helps to filter by the `/64`. https://funvasion.miraheze.org/wiki/Special:Contributions/2601:98A:A00:AA00::/64 [18:14:04] [2/3] https://funvasion.miraheze.org/wiki/Gingereena_(2004_film)?diff=prev&oldid=174726 [18:14:05] [3/3] is odd, but also odd that they appear to be edit warring with themselves 🤔 [18:17:39] Someone with a leading Poland ISP reverted that edit. In any case, the bureaucrats and administrators seem to be inactive on that wiki, so is definitely within the scope of CVT to monitor [19:34:37] Funny you mentioned that. I've been noticing that from the Abuse Logs lately. [19:42:28] @darkfawfulguy64: ack [20:37:30] at least some of these struck me as disruptive or making the pages less at a glance, but I'm marginally on the fence by nature of the wiki's overall condition [20:38:07] free hit to investigate for cvt below steward ranks if no one fully tackles it quick [20:44:11] @raidarr, the wiki itself seems fine content wise. Its chief issue, I think, is that is unmaintained by, well, any registered user. It may be a worthwhile candidate for CVT to add a local Sitenotice explaining the wiki adoption processes, to encourage someone to step up, first by creating an account [20:46:29] [1/2] that is a subject where I've long been wondering about having a boilerplate for, it just doesn't come up often enough for a standard process to form. What tends to happen in effect is, if lucky, the wiki gets visited as a pet of one of us (ie, me for reception wikis, occasionally kiju for some japanese ones) and it kind of lingers in permanent limbo like the retro windows wiki. The o [20:46:30] [2/2] verall trend has become pretty much if it comes up regularly as a problem it is closed [20:47:04] that wiki iirc has a bit of history involving some spicer aspects of the community which is part of why I've been personally frozen on it [20:48:01] a notice like that could be interesting, another thing we've done in the past is remove anon editing in cases where rare anons keep a wiki in zombie condition, in one or two cases iirc a soft close was issued which could be reversed as an adoption [20:48:57] raidarr: definitely would be a good idea to still have a boilerplate sitenotice created, yeah. Agree that it didn't happen too often. Mind you, with what 20,000 wikis, it's hard to say how many of them we have without active local administration [20:49:27] perhaps the Tech Team could run an SQL query on the database table containing Special:ActiveUsers data [20:49:42] not sure how 'expensive' that would be from a system resource perspective [20:50:15] we have a great many of them which probably de facto exist as unknown informal conservatorships or meet the standards for a formal one [20:50:32] ack [20:50:36] reception has run some numbers a few times to give that impression [20:50:59] ah, cool :) [20:55:27] would be nice if TSportal could be replicated for stewards to handle wiki suppression requests, perhaps [20:58:14] well funny you mention because I've been thinking for a while it would be nice to completely replace the steward requests system with something like a more visibility flexible tsportal either onwiki, preferable for ux integration, or as its own thing if it would not be feasible to come up with something that integrates well [20:58:40] this among many other ideas is in the den of 'sounds nice but got a pocket dev for that no oh well' [21:00:05] we mostly haven't had a problem with the sr system in practice but imo it is a little too abusable for what it is, it would be nice to have built in unspoofable designation of 'this is a steward with an official answer' vs public comment, and other aspects I feel the sr is not really adequate to process, including built in more private requests [21:01:05] though we have had incidents of people making a request and it just being gobbled into the void, the leading cause of that was incompatibility between discussiontools and hcaptcha which I do believe was resolved [21:01:53] this is a subject oasis has been leading on in fact as zippy came up with essentially what I described for that, though ai was the main assistance for it coming about in a timely way [21:03:07] `well funny you mention because I've been thinking for a while it would be nice to completely replace the steward requests system with something like a more visibility flexible tsportal either onwiki, preferable for ux integration, or as its own thing if it would not be feasible to come up with something that integrates well` [21:03:08] sounds interesting actually [21:04:18] `this among many other ideas is in the den of 'sounds nice but got a pocket dev for that no oh well'` [21:04:18] very true. though, with vibe coding, a lot more potential for good prompt writers to cook something up and have the devs perform code review [21:11:04] [1/2] would not be opposed to it if it did pass rigorous review but it would have to be a quite strong pitch, and there is also the cultural aspect to vibe coding which my impression is that miraheze at large would be against it, and part of our sell at this point is that we're not going the fandom way with flinging ai at things. The extent we do use it is not really the ideal situation as [21:11:05] [2/2] it puts money in the wrong people's pockets although it has massively assisted our review process which would probably have had to change completely if we didn't do it. So, it would be technically possible but uphill [21:12:04] on a personal level though I am mostly concerned with results for the platform so if we got something that's maintainable and works well, and it had a path to improve outside just flinging claude at it, I'd probably be game but would want it community reviewed. It would be nice to have something in any case [21:14:56] ah [21:16:13] oh, sure, definitely shouldn't replace community and tech team review. If nothing else, it may be helpful in displaying a provable working prototype / concept for non-coders, in other to build support for the idea [21:26:55] I would agree; there are categories where tech can and should 'just do it' but when it involves heavy use of AI I would bump it to a pass through community question even if it might typically be more of a just do it situation [21:27:20] the prototype being stable, not generic in design, lasting 5 minutes with claire would do wonders [21:27:49] or SRD [21:28:08] two volunteers who've been heavy hitters in hole-poking subjects with tech [21:33:10] I'd argue the patroller system is enough for this [21:36:12] [1/2] its a good layer and more or less does the job, I'm just paranoid of split occasions where something sensitive is involved, there's a window where patrollers might not be there right that second, and as a result I always spend extra time doing a little verification because little things like creating a second account with a split letter off that seems legit to make a request bug me a [21:36:12] [2/2] nd are entirely possible [21:37:21] really two things, that window that might not be caught when I would prefer a more secure by design task system to eliminate the need for many and vigilent eyes, and admittedly far fetched attempts to abuse the system with subtle tricks that may fool most or all patrollers in a given window [21:37:52] my concerns are unproven on the SR but tricky abuses of process have been attempted and one that I can barely remember I only remember vaguely because it did almost get me [21:38:51] and then subtler things like built in split of ok you have been responded to by someone who can action what you want, vs a random input, without the need for others to manually mark themselves as non steward input or do gymnastics to phrase so they don't seem official which can cause confusion [21:39:28] or if it is a GA, wiki creator, assistant steward instead, let that be known too [21:39:47] I find myself regularly wishing for forum-style amenities basically [21:40:20] yeah phorge is better on that front because nobody can spoof anything and actual tech get a badge below their pfp [21:42:02] I like aspects of phorge for that reason, but its actually the example of what makes the question hard in my mind because it goes the other way to introduce new problems that are bad for ux [21:42:29] the login screen is unintuitive and confusing by design, the interface has its own funny text system, whole new layout to learn, things I want to completely avoid with a SR but better solution [21:42:59] oauth is friction but imo manageable if these other things were not concerns [21:43:16] when I do SR/RC requests I always copy the permalink which does inevitably lead to me being able to see the diff, so I don't think that's too bad for Steward requests that require privileged users to request them. not sure how it is for other steward requests [21:43:50] it used to be default procedure, I ended up not doing it because it was friction in the way of just getting things done [21:44:08] so I only indulge in that step if the action is more sensitive in nature where a better trail should probably exist [21:44:30] I dislike Phorge for many reasons but it does a good job of making it clear who's done what [21:44:51] I also make stewarding harder because I completely cut out external javascript of any kind and barely run js at all on miraheze besides minimum situations, so a script to do it short of putting something together at the browser level is unlikely to go far for me personally [21:44:59] Friction really is it. I'd love to move to a lower friction but higher auditability system like the expanded TSPortal that WO offers, but, as you say... [21:45:09] It must pass the Claire challenge [21:45:29] > the login screen is unintuitive and confusing by design, the interface has its own funny text system, whole new layout to learn, things I want to completely avoid with a SR but better solution [21:45:29] that's true. Most don't know to click login via MediaWiki [21:45:42] I do think the wo solution is starting to shape into a good model to learn from at least, but it definitely has work before that becomes a real discussion [21:46:00] If it's more than 4 clicks, we did a bad job. [21:46:01] this exists on the help desk too, and it's kind of a problem on Discord although we do have role colours and icons [21:46:22] imo the help desk is somewhat less sensitive in nature and falls back to the unintuitive nature of wiki as a discussion format [21:46:22] > If it's more than 4 clicks, we did a bad job. [21:46:22] +1 [21:47:07] tbh its why I liked flow/structured discussions a lot. techs hated it but aside from a few stupid behaviors I found it a lot better at basic things [21:47:10] An inherent flaw in any open system, where anyone can barge in with anything. 😄 Harder to know the people who are actually 'official' [21:48:11] the best possible arrangement with wikitext now seems to be ok so discussion tools and then find a random script on someone's userpage that makes it somewhat more reddit like so it finally starts resembling a real discussion system, which is fragile, frought to set up, unknown in the first place and iirc had some compatibility problems [21:48:12] But agree, the helpdesk is a more informal, anyone can chime in with possible suggestions, venue [21:49:26] its a point of friction in the entire wiki world that either we have fragile half baked discussion abstraction layers, or you abstain from all that and have to remember the squigglies which is inherently unintuitive [21:49:40] and the former doesn't help at all for rfcs and such [21:49:50] discussiontools is great until someone manually enters their signature and it now says 8:15 instead of 08:15 [21:50:26] discussion tools I kind of have a grudge from when it didn't play with captcha properly so people had their requests gobbled for a long time and all we could do was shrug and hope upstream fixes it [21:50:29] that was horrible tbh [21:51:06] sr is a glued together polish on a pig, its well engineered I think for what it is, but I would be happier to replace it entirely [21:51:52] naturally, forum extensions and any such solutions are bleak [21:52:05] and to replace the sr it would have to do more than I ever remember seeing from forum extensions anyway [21:52:08] we should use fandom's discussions system [21:52:20] I mean if nothing else its a discussions system [21:52:59] so that's probably near top of my wishlist [21:53:16] still exceeded slightly by getting a handle on nsfw wiki flagging and handling [22:11:49] Isn’t this what @pskyechology has been working on on off lately? [23:16:36] Yep. You would be correct.