[00:02:54] Probably nothing if it was related to the CU tool as i suspect it was. [00:08:19] That's... also a good thing to know with certainty even without specifics [00:09:06] Would cc @owenrb on that. I'm not certain I would classify it as a data breach, but I'm also not certain how much I can say on the matter. Or if my interpretation is correct. [00:10:36] And yeah, got a few outages that still need their Incident Reports written. Got way too much going on at the moment. [00:13:16] Hi I'm interested in helping out in wake of recent staff departures. I have almost 20 years of wiki experience and have served on two different wiki-related nonprofit boards. I think my role as an outsider can help restore trust. I like the service that Miraheze provides and i would like to help keep it going. [00:21:19] I’m the crazy person for reading the entire GDPR text, I know. But I’m also a concerned that someone here doesn’t know whether or not a breach occurred, and if they can even report it. [00:21:50] People at Miraheze really need training in data protection. [00:25:54] I asked a similar question a day ago, and the only reply I got was that there aren’t enough officials to run an election for the board, so it’s not possible right now. [00:26:31] The board has appointed board members. I would like to be an appointed member. [00:27:06] oh no MH phab is down again [00:29:41] What’s your plan for restoring trust? I’m legitimately curious. [00:40:37] looking [01:47:26] A more detailed answer would require me to take the time to understand the issues better. At a high level, I believe there are really basic things the Miraheze management is not doing, like for instance holding regular board elections to ensure community voices are on the board. I would start with that. [02:02:19] Anyways for reference I am https://meta.wikimedia.org/wiki/User:Harej [02:05:00] Ayyy, a fellow 2 decader [02:05:45] I got my start on Wikipedia in 2001 when it debuted, I was in grade 9 at the time. I remember the early days fondly, before Wikipedia became huge and overbloated [02:09:05] 2001? That's... really difficult to top [02:11:08] I appreciate that it's gotten easier to edit but of course I'm nostalgic for when the stakes were a lot lower [02:11:24] (easier to edit only in a technical sense, in that the tools are better, not in any other respect) [03:33:09] [1/3] I suggest new commers to use PortableInfobox extension, which proves to be easiest way to create infoboxes [03:33:10] [2/3] in fact there is already a thread on that, so [03:33:10] [3/3] https://discord.com/channels/407504499280707585/1117981753576001567/1118290254454079488 [03:40:16] [1/2] tbh I don't even how one should start election on such high level right [03:40:17] [2/2] there are currently voting for global sysops and a wiki creator on Meta [03:50:00] for which right? Board? [03:55:28] Thanks, I found that and the pinned post here and I've been working on it :) [04:48:17] There is no incident report as there is no evidence that information was disclosed to outside parties that would make this a notifiable incident. Further, due to the nature of CheckUser being logged, if there was suspicion, those affected are easily identifiable and those affected would be contacted directly inline with GDPR [04:50:42] I agree, and this was proposed and is being looked at, though a former Director disagreed this is necessary and tabled a dissolution motion when this was suggested as it would 'make recruitment of new volunteers harder' [04:52:13] Board elections have been opened for nearly 3 years straight now, the community do not seem interested in arranging and running it inline with community policy however [05:05:23] the remaining trusted community members aren't qualified enough to run here, meanwhile the qualified and experienced ones aren't well know by community - what should we sdo now? [05:06:14] Hire people who aren't trusted or qualified, obviously [05:11:18] Can you pretty much just put that on an incident page? PII was disclosed outside of policy affecting # of people; all of those who were affected were already informed. I know filling out reports is boring but the most important parts of Trust & Safety are trust and safety. [05:11:58] I can create a wiki page for sure about it [05:12:23] Thanks. That increases my confidence a lot. [05:14:11] Also I find https://meta.wikitide.com/wiki/User:Raidarr intriguing where Raidarr states the T&S ban was technically valid - there's been a lot discussion over whether or not T&S have acted appropriately, but this is the first time the subject has actually shared they agree it was valid action to take in the situation [05:18:02] This has been kind a mess to me as a wiki bureaucrat. There's been not many clear statements about why they've boarded the Wikiflower to sail for new shores, and on the Miraheze end not a lot to feel like stability is ensured. [05:18:27] [1/2] > Wikiflower [05:18:27] [2/2] I laughed. [05:18:31] It's a mess all around [05:18:54] All The Tropes was once accused of being the Tropeflower and the insult stuck with me 🙂 [05:19:27] heh [05:21:02] [1/2] So far as mine and my friends' wikis, the current plan is to stay on Miraheze for ATT and the Daz Freebies wiki, but to move a private wiki over to WikiTide so it can be made public. This is purely a business decision, because the content is illegal to be made public in the UK, but allowed to be public under US copyright law. (and encouraged to be public under Canadian copyr [05:21:02] [2/2] ight, but that's not an option) [05:21:47] I wonder how a Canadian wikifarm would be run; probably by Dmehus [05:22:14] Arranging one requires Stewards now, instead of an Election Commission though so if Labster or Harej wanted to run, they technically could since we do still have Stewards. [05:22:15] Copyright law is quite a doozy, particularly UK copyright law. Government guidance is rather vague. A unified guide would be nice but I'm not sure that'll happen... [05:25:45] I don’t think that Raidarr agreed it was a valid action to take [05:25:52] but rather the rationale for the ban was valid [05:26:50] From my interpretation at least, the meaning is that raidarr admits he did indeed breach his restrictions technically. But based on conversations that have happened subsequently, he disagrees with the permanent service ban vehemently [05:26:58] but doesn’t have the will to pursue if [05:49:39] The real problem is that the rules are way too rigid and doesn't allow someone else to appeal. [05:50:00] Also influence of the crowd reduce the chance of appealing [05:50:08] 💀 [05:51:35] This was done under the guise of protecting Miraheze from liability [05:55:46] Oh, forgot that Raidarr refused to do the training and choose to resign instead [05:57:15] [1/2] > There was no public data breach or any suspicion that data was mishandled in a way that created a high risk to anyone. [05:57:15] [2/2] Technically he just perform unauthorised access and hence the problem with T&S [05:58:09] This in no case rose to the necessity of a T/S-enforced IBAN between raidarr and Naleksuh [05:58:22] data protection doesn't equal interaction bans in any world [05:58:33] which should be valid as well...... [06:03:14] But if you admit you did wrong when you were told in clear cut language "you'll be banned if you do this", then surely you just accept the validity of the consequence [06:04:32] There is, the Board agreed based on the evidence, it was a valid course of action based on the wider circumstances [06:05:45] And it would have been. Had he refused and resigned, nothing would have happened. But he didn't just do that [06:06:14] I'm a Canuck, can I run it lol [06:08:10] no, he referred to Naleksuh once in an ill-advised moment [06:08:29] tell me if I'm wrong: trust and safety restrictions are meant to enforce the law and prevent liability, correct? [06:08:46] how would Naleksuh interacting with raidarr (or vice versa) place Miraheze in legal jeopardy? [06:08:53] I cannot figure that out [06:08:58] [1/7] [06:08:58] [2/7] consumes the philosophy section of the local library . [06:08:59] [3/7] ..are we not all a wikifarm unto ourselves when you think about it? [06:08:59] [4/7] A repository of knowledge and experiences? [06:08:59] [5/7] A host of half-finished bad ideas alongside several very good ones? [06:08:59] [6/7] ...hey who wants hashbrowns? [06:09:00] [7/7] /scene [06:09:40] We aren't just in the business of protecting ourselves - so actions don't just have to protect us. [06:09:56] Who was that IBAN meant to protect? [06:09:57] Naleksuh? [06:10:09] An interaction ban was necessary to prevent further offending [06:11:08] I'm confused, was data protection leaked to Naleksuh by raidarr? [06:11:29] Data Protection was not the sole reason for action [06:11:34] I have stated this numerous times [06:12:13] @BWM can we maybe consider a more appropriate question? [06:12:29] Rather than over focus on the single action, we need to start looking at what's next [06:12:48] We will go nowhere and end up gone if we want to go round in circles moaning at @owenrb [06:13:11] If Miraheze considers how it maybe can improve, we got the best chance of making something for the future [06:13:55] Yes we can, and I'd love to be able to try and move forward. But I'm also trying to help salvage Raidarr's reputation here. A T/S ban seriously diminishes any respect that a lot of people that don't have in-depth knowledge have for a user, and I'm trying to prevent a portrait being painted of raidarr as evil. [06:14:27] Raidarr isn't here to defend himself, and leaving him open to be the constant subject of targeting here while he can't speak for himself is wrong. [06:14:43] Sometimes moving on is the best thing that can be done to preserve ones reputation [06:15:12] The reason this is such a common theme and constantly in the spotlight, is people keeping bringing it to light and attention of the channel [06:16:23] T&S intentionally are very discreet in their actions, half the information that has come out has been forced out by those seeking to 'protect someone's reputation' while all they've done is forced the release of more and more information to damage said person's reputation [06:17:05] Raidarr has expressed no interest in appealing, so surely moving on is now the best way forward than constantly making this the conversation every day for several weeks? [06:17:43] Very well, then [06:18:38] Would it be too much to ask for a written explanation by you (similar to what @Labster requested above) about what happened? That way, to prevent these future conversations, we can refer them to that page/statement. [06:18:52] Instead of doing this all over again [06:19:17] I can do that, as I said above I will seek to do [06:19:44] Thank you [06:19:52] now onto this [06:20:02] 1. Frankly, reduce redundancies [06:20:37] 2. Free punch and pie [06:20:37] What I mean is this: There is too much focus on improving ease for volunteers as opposed to maintaining a stable system for the community [06:21:21] Tech-wise: There are a lot of backend systems that while make it a ton easier for volunteers in SRE to work with, it uses up a lot of funds and server space....and has little to no impact on wikis and communities [06:21:38] Community-wise: The GIWA role is really just a great example of this [06:22:09] Example for this one as I'm curious there? [06:24:54] [1/4] I'm not extremely familiar with backend, so if I mess up a detail apologies there, but overall I think some of the redundant systems that have been pointed out to me are: [06:24:54] [2/4] - Upgrading to the newest MediaWiki version constantly (happy to elaborate in a second message) [06:24:54] [3/4] - Icinga [06:24:54] [4/4] - Grafana/Matomo (seems they have similar purposes so not sure why there's 2) [06:25:39] So I would argue Icinga and Grafana are necessary as they're monitoring solutions to keep the systems running [06:26:11] Right and I agree [06:26:15] but why do we need 3 of them? [06:26:50] if they all have entirely different uses that absolutely cannot be combined into one service, or Miraheze cannot function without all 3, then that's one thing [06:27:10] but otherwise.....redundancy [06:27:50] many services for one goal (in this case monitoring) if they all have even remotely similar uses doesn't seem right [06:27:57] So Icinga is very much "is it working or not" and Grafana is very data oriented, good for tracking long term problems and trouble shooting causes [06:28:56] Also I don't think they have any affect on server resourcing or space, they seem like extremely low intensive pieces of software that provide benefits much greater than their affects [06:29:53] The real problem here is that there is a small amount of wikis that use excessive amount of storage [06:29:53] Swift also afaik could be one of the redundancies I mentioned [06:30:10] correct me if I'm wrong, but the previous one was Gluster? [06:30:44] i don't remember the exact reason why we switched so context there would be helpful [06:30:48] Isn't swift the entire file storage architecture, I also would argue that's not a nice to have for tech but rather a necessity for the community [06:31:03] right but why migrate from Gluster? [06:31:11] gluster was troublesome, no? [06:31:15] slow etc [06:31:20] I don't know the exact reason again why so if there was one then that makes sense [06:31:25] Gluster was inefficient and it going down usually caused the entire farm to go down in shambles [06:31:34] Ah, that makes sense [06:31:37] @paladox can clarify more, but I think since the switch, the service has been much more stable due to the change [06:31:43] That I wasn't sure about [06:31:45] @BWM Grafana and Matomo do separate jobs [06:31:58] Quite frankly, you should stick to the community tasks [06:32:12] We still have 2 members of SRE that can make things more efficient [06:32:28] trust me I have no desire to take on SRE tasks [06:32:34] that's a realm that I can admire from a distance [06:32:50] We've already turned off features before where usage is low and expensive to run [06:33:05] Yeh Swift has been more stable for us. Meta won’t freeze and it also allows maintenance as well. [06:33:05] @BWM well admire it then and stop saying uneducated things about what's best [06:33:47] You could move some stuff from icinga to grafana but I'm not sure you can completely replicate icinga's alerting [06:33:53] WMF are trying that [06:34:17] But Matomo and grafana are miles apart [06:34:36] Replace Matomo for Google Analytics of course lol [06:34:37] Upgrading to the latest mediawiki version is something we've discussed moving to LTS for a bit [06:34:55] This was about to be my next point [06:35:09] Personally I don't believe it's something we should do as I think given the fairly major changes coming, it'll get you less time to prepare [06:35:11] Upgrading to the newest MW version every time is a good sell for advertising for new wikis [06:35:25] So you're more likely to find a lot more extensions break suddenly [06:35:41] But otherwise, are the differences between for example, 1.37 and 1.38 that large? [06:35:42] Upgrading release by release will allow us to work much more closely with users [06:36:06] But it seems like to me that the time we spend upgrading to newest MW versions every time takes away from time for innovation [06:36:15] see the Community Wishlist Survey for this year [06:36:19] Previously not always, the differences between 1.39 -> 1.40 -> 1.41 -> 1.42 most definitely are [06:36:22] none of that was even announced by SRE I don't think [06:36:48] I don't disagree that it's a very time consuming process and we need to do something better [06:37:01] The actual upgrades themselves though are now a couple of scripts [06:37:17] It's the testing that's hard and that's something we've been pushing to hand over to the community [06:37:28] Because you guys know what you do best [06:37:32] Multiversion is a dream and could help solve the difficulties of upgrading [06:37:38] testing always must careful [06:37:43] And certainly with parsoid, we won't be testing much [06:38:13] The community will from 1.41 need to be testing via features we'll make available [06:38:25] Testing is hard, especially on 'specialized' extensions like Cargo or SMW where most of SRE doesn't know squat about [06:38:36] we've been testing for months, Agent would attest to that [06:38:43] and still have ~45 extensions to go of 325 [06:38:50] @BWM I'm well aware [06:38:55] It's honestly a miracle we've gotten to that number [06:39:00] there is room for innovation instead of trying to upgrade every time tbh [06:39:03] I know what the release process is [06:39:05] A lot of binge testing has occurred [06:39:10] @owenrb ^ per my point [06:39:11] heh [06:39:21] Personally, the only way it's going to work in future is if the community engage much more closer [06:39:32] Because some of the changes coming we simply can't test [06:39:44] There's only imo 2 extensions that SRE should be testing [06:39:49] Right, which we'd need a more active Meta community for [06:39:49] CheckUser & Oversight [06:39:54] CheckUser, CentralAuth [06:39:54] Yes [06:40:01] Oversight is MW core, no? [06:40:06] Well, changing the cadence of upgrades is something the community should probably be consulted on at the very least as a big selling point for Miraheze is that we're always on the latest MW version [06:40:09] 2 functions then [06:40:34] Oversight? You mean suppression? :P [06:40:34] CentralAuth can mostly be tested by users. Only lock needs testing by SRE. [06:40:52] lock, assigning global roles yeah [06:41:04] right, but that spirals into another discussion of its own [06:41:05] Most WMF extensions never really experience issues for upgrades [06:41:07] It doesn't help the messages are called suppress and the group oversight agent [06:41:21] didn't we change the group name to `suppressor`? [06:41:25] RhinosF1: the group was renamed to `suppress` [06:41:26] yeah [06:41:42] because the i18n for our custom oversight group was a disaster and burning dumpster fire [06:41:57] so the group name was changed to suppress in order to use core i18n [06:43:01] [1/3] how do we get more Meta....people? [06:43:01] [2/3] which spirals into....how do we increase volunteering? [06:43:02] [3/3] which is a disaster of a conversation [06:43:07] you see what I'm getting at [06:43:10] I have no clue [06:43:24] [1/5] maybe [06:43:25] [2/5] just maybe [06:43:25] [3/5] make echo notifs, at least? for bureaus of wikis on upcoming upgrades thus inviting them to test features [06:43:25] [4/5] I mean - at my place everyone who works w/ a system waiting for an update must participate in testing [06:43:26] [5/5] a lot of wiki admins simply aren't aware of those things, clearly [06:43:53] Custom Echo notifications are hard to implement last I remember [06:43:55] That isn’t a bad shout actually, MH should use Echo more for notifications as well as site notices. [06:44:13] Agent: it was too much of a server load as far as I remember [06:44:24] site notices annoy people a lot from what I can tell [06:44:26] Not really, Agent. The default config on Mw.org works pretty well with minimal adaptation. [06:44:26] Cross-wiki Echo notifs being enabled by default are, indeed [06:44:33] the last fundraiser is an example [06:44:38] [[phab:T10584]] [06:44:38] https://meta.miraheze.org/wiki/phab:T10584 [06:44:38]