[05:59:16] > <@_discord_97152293861863424:t2bot.io> I've found a few other extensions (EmbedVideo, DynamicPageList) that have a dependency on composer/installers:... (full message at ) [15:10:13] https://digitalfreedomfund.org/another-tech-is-possible/ [15:15:56] I'm following https://gerrit.wikimedia.org/g/mediawiki/core/+/HEAD/DEVELOPERS.md [15:15:57] and [15:15:57] echo "MW_DOCKER_UID=$(id -u) [15:15:58] MW_DOCKER_GID=$(id -g)" >> .env [15:15:58] doesn't work on windows. what do I run instead? [19:57:44] hi! the last section here looks like it doesn't make sense: https://www.mediawiki.org/wiki/Manual:$wgDnsBlacklistUrls#Trigger_DNSBL_on_specific_actions [19:58:03] and you know what? it really doesn't work [19:58:34] also it doesn't look like the code could do what the docs say: https://gerrit.wikimedia.org/g/mediawiki/core/+/3482ce559c40c85093e23bf7e3a95cb0eda09ad9/includes/block/BlockManager.php#260 [19:59:09] at this point I'm just curious if anyone has an idea how this section ended up there and what it was possibly referring to [19:59:15] Ostrzyciel, are you implying that the docs are less than perfect?! (-; [20:00:11] yep, that section looks really wrong [20:00:53] Added by a user named DNsbl [20:01:58] hm, fascinating indeed [20:02:00] https://www.mediawiki.org/wiki/Special:Contributions/Dnsbl1 [20:02:06] and https://www.mediawiki.org/wiki/Topic:Vq1zftdbu158qko1 [20:02:39] seems that they basically...posted a feature request on the manual page in the form of a "yep, this is totally an existing thing which works"?! bizarre... [20:02:42] As an aside, i really wish we exposed the wikipedia blocklist as a DNSBL [20:02:54] it'd certainly be helpful [20:04:00] oh gee, it's that kind of user [20:04:08] ...thanks for the rapid investigation :D [20:04:47] +1 to bawolff's idea with wikimedia's blocklist [20:05:26] Also, i wish we had Captchas that just worked out of the box. Default config of MediaWiki directly after install should not be such a spam shitshow [20:06:07] There are Windows-specific information missing there [20:06:38] atxatx4928[m]: missing where? [20:07:18] For example, the writing permission for the database is still broken for Windows: https://phabricator.wikimedia.org/T270437 [20:07:27] You have to manually set the permission [20:08:57] Also some commands require you to use PowerShell and some with Bash [20:09:21] wow, those docker instructions look complicated [20:09:43] It is not that bad once you get it set up [20:09:45] * bawolff continues in his belief that docker/vagrant/et al are more confusing to new devs than just installing mediawiki normally [20:09:57] At least it's better than Vagrant [20:11:44] bawolff: +2 to that [20:11:54] Personally, I run into so much trouble with the MW Vagrant and Docker on Windows that put me off from development at all, especially since I'm not equipped with the skill to run a proper MW instance [20:11:57] but, is it as good as sudo apt install apache2 php ? [20:12:15] I mean, windows is a bit of a pain in general [20:12:35] Local Docker development is great for people without the skillset to set up a wiki like me, it is simple when it works [20:12:43] And the alternative to docker/vagrant would be installing XAMPP or something like that, which isn't exactly a good experience either [20:13:33] Windows is a pain in general yes, but there are a significant portion of potential dev that are using Windows too. Taking more care with Windows will attract more new devs [20:13:52] Yeah I don't have the dedication to use XAMPP [20:14:08] PHP itself is already a pain point for skin developers [20:15:27] And that means people might actually test mediawiki on windows, which would be nice [20:15:48] although i suppose docker is really running mediawiki on windows in a linux virtual machine [20:15:58] SO maybe it doesn't test the actual windows support [20:16:14] But we definitely need people to test on windows, because im pretty sure there are bugs there [20:16:46] Yeah the local development Docker is running a Linux container on Windows [20:18:49] atxatx4928[m]: in any case, welcome to mediawiki development :) [20:19:08] The local development setup has been broken since 1.35, which put me off development for years. I was using Vagrant back then and it wasn't updated to support 1.35. And then there's the issue where 1.35 requires PHP 7.4 while WMF is on PHP 7.2, which forces Docker and Vagrant in 7.2 to stay with WMF production [20:20:23] From what i saw, the other big problem with vagrant, was when things went wrong, it was always very confusing error messages or unclear what to do about it [20:20:55] WMF and ancient versions of PHP: A love story as old as time [20:21:11] I just wish that the local development setup can be better supported since not every developer has the skill set to run a MW instance. The skill ceiling is just so high to develop something in the MW ecosystem [20:21:40] It's not really [20:21:49] 11 days until PHP 7.4 is out of support! [20:22:08] I suspect you may be overestimating how hard it is to setup a mediawiki instance [20:22:14] Yes Vagrant was super confusing to use, thanks God that Docker is much simpler to use when it works correctly [20:22:21] I really do think that docker is much harder [20:22:40] Or at least on mac and linux. I could believe that on windows its easier [20:22:50] PHP itself is already a pain point for skin developers <-- I'd dare to disagree :) [20:23:07] bawolff, you're overestimating Redmond's flagship, I fear >.> [20:23:16] true, its a pain point for all developers :P [20:23:23] At least the DEVELOPERS.md file isn't hard to follow. I run it on Windows and Mac easily (apart from having to hunt down Windows-specific issues) [20:23:56] * bawolff actually did not know that file existed until right now [20:24:24] Skin is especially bad because PHP used to be a hard requirement before Mustache [20:24:39] bawolff: RIIR πŸ¦€ [20:25:09] Izno[m]: ikr [20:25:46] That basically limits skin developers to process both PHP and front-end skills. [20:26:28] our skin code also isn't exactly the most well written PHP either [20:27:03] Monobook currently is nice [20:27:28] That class hierarchy is super weird. What belongs in Skin vs BaseTemplate vs SkinTemplate vs OutputPage? Who knows [20:28:33] Vector had to do with the ugly scenario with common laws between 2022 and legacy, along with all the analytics and A/B testing. [20:28:33] Minerva had an ugly divorce with MobileFrontend and had never fully recovered. [20:28:43] rofl [20:29:09] I personally don't understand why 2022 and legacy was smushed together so much [20:29:18] They're basically separate skins, they should have been separate repos [20:29:44] there was some original plan where changes would be made gradually so one would morph into the other. that got dropped by the wayside at some point (after the "cleanup" done to make the skinning system "better") [20:29:52] There's a lot of progress on Skin Architecture pushed by the Desktop Improvement team and Jdlrobson [20:29:58] so now we have two skins in one repo [20:30:11] you're not the only one who has voiced this [20:30:35] Disclaimer: I'm not a part of the DI team but I follow really closely [20:31:31] The idea was the WMF had vouched to support both skins back in a RfC. They agree to feature freeze legacy Vector while providing support for it [20:32:08] "agreed" As if the community wouldn't literally murder them if they said otherwise [20:32:13] theoretically enabled by putting them in the same place. [20:32:53] Now the below are my educated guesses, from spending years following the project and reading tasks and commits [20:33:41] Well hindsight is 20:20, but I don't really see how having them in the same repo helps that much, just makes things confusing [20:35:29] - Allow A/B testing to yield accurate result. Everyone on Vector is subjected to it. Anon are on legacy. Registered are enrolled into 2022 and further divided through A/B in 2022. It gives an usable sample size to test features, which is especially important for an extremely high traffic site like Wikipedia production. [20:37:09] - Allow better caching to save server performance. 2022 and legacy Vector are made to share some resources such as static assets. Since legacy Vector is the most used skin, its resources are the most cached as well, and some of those are shared with 2022. [20:37:43] That only works if people are regularly switching between legacy and 2022 [20:37:53] varnish cache and the rest are definitely large enough to have both [20:38:16] You can argue whether the maintenance is worth it, it is a double edge sword. It is PITA to maintain the current two skin structures but at the same time you can make sure that legacy Vector are always updated to work in the latest MW [20:38:42] You don't have to have people switch between. [20:38:56] I mean, it only makes sense for browser cache [20:39:29] There aren't really any other shared caches that are small enough or with fast enough evictions that both wouldn't be cached [20:39:55] [I say, without measuring anything or analyzing any systems, so you know take with salt] [20:40:38] Just to give a very simple example: [20:40:38] To measure how users react to the ToC feature in 2022, you can compare various metrics like button click rate on the 2022 ToC vs legacy, etc. [20:41:19] you can do that in two separate skins anyway [20:41:43] Yes you can, but then you need to solve the recruitment problem [20:42:19] You need to recruit enough people to 2022 to ensure a large enough sample size [20:44:08] that's a problem anyway? [20:45:24] Yes because design decisions should be data driven, even more importantly for Vector as a highly used skin [20:47:15] Without the research data backing the design decisions, it is difficult to make informed decisions especially when you have a vocal community like this [20:47:40] lol, like wikipedians care about data ;) [20:48:03] well history has demonstrated that data or not, the WMF does what it wants, which may not align with what the communities want [20:48:04] Every single change in Vector can cause public distress, and that's why the research is especially important [20:48:16] But i generally agree collecting data is important [20:49:14] although data collection can be subject to bias and misinterpretation, so I wouldn't call it a pancea either [20:49:19] But then I have to say that I'm not on the DI team, I'm just making educated guesses as someone who follows the project and also works in UX design [20:49:48] also I'd like to take a moment to remind that there *is* MW-related life outside the WMF-sphere ;) [20:49:56] The DI team have sessions once in a while where you can ask them those questions [20:50:14] I have no idea if our A/B framework allows cross skin A/B testing. If it doesn't, that seems like a reasonable reason to use one repo [20:50:30] *cross repo [20:50:42] ashley: lies [20:50:55] clearly [20:51:04] There is, I seldom work on WMF-related MW projects [20:51:52] bawolff: also I have no idea about A/B testing but if anything, that sounds like an enhancement/feature request for it rather than a reason to clutter up repos IMO :] [20:51:54] (as I'm typing on a third party MediaWiki Discord server) [20:52:12] Oh, is discord linked to this channel now? [20:52:38] we have a bridge through Matrix [20:52:47] Yes. Wait, what do I look like on IRC then [20:52:50] so now you get two times the Izno [20:53:01] atxatx4928[m]: You look like you are using matrix [20:53:11] `` [20:53:14] I prefer the Capybara Izno [20:53:16] which i guess makes sense if the link goes through matrix [20:53:25] Oh I am just using the MediaWiki Discord channel [20:53:41] It's a prairie dog, not a capybara πŸ˜‚ [20:54:03] Hard to tell with all the Freedom accessories lol [20:54:14] On the bright side, that means i no longer feel like i am missing out not using matrix :) [20:54:17] πŸ‡ΊπŸ‡Έ πŸ¦… [20:55:13] We have a lot more channels on discord. This is just one of them. [20:55:13] It is great since not many people use all the platform together, and there are a lot of traffic on the Discord and also the IRC [20:55:29] irc has been dying a bit tbh [20:56:07] discord is the new irc, except for the lack of dcc servers and decentralization [20:56:08] Well the WMF folks are there most of the time [20:56:28] I rarely see anyone on the Discord channel [20:56:30] which is a shame, because unlike that overly advertised awful proprietary thing, IRC actually works and likely will keep working until the end of time and won't have bullshit CAPTCHAs and the like... [20:56:37] Somewhat, but ever since WMF adopted secret slack, there's been a marked decrease [20:56:54] Slack is amazing though [20:56:57] Also everything split into separate channels all over the place, which futher kind of decreased [20:57:18] I always kind of hated slack. TO many emoijis and memes and moving things [20:57:19] obligatory https://xkcd.com/1782/ [20:57:36] Slack has awesome integration so you can automate and customize a lot of workflow [20:58:00] irc has bots... i don't really see much of a difference [20:58:07] bawolff: it's probably related to the whole "WMF and its gazillion teams" thing...you know what they say about too many chefs in the kitchen an' all [20:58:11] But most importantly, irc is public [20:58:24] i always felt slack/discord were essentially the same app at the beginning. They've both gone their own ways (mostly) now [20:58:24] I guess one can always maintain a gateway/bridge [20:58:38] not unlike here I guess Β―\_(ツ)_/Β― [20:58:46] Slack can be used like IFTTT [20:58:59] I should look closer into Matrix [20:59:09] You can connect other softwares and services to it, bots are different [20:59:31] Prod[m]: I think the value proposition for both was: Imagine if irc was invented more recently than 1988 [21:00:03] FWIW, i don't really like matrix that much (at least the web client). It feels like a cheap less polished version of slack [21:00:39] something something open source [21:00:57] I haven't used Matrix before. But for the communities i'm in, discord is mandatory [21:01:03] Slack is industry standard to be fair [21:01:19] I used it at work at my previous job [21:01:24] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html apparently relevant [21:01:37] Shocking amount of downtime given that they are literally a company specializing just in that [21:01:52] I can't recall libera/freenode ever being down [21:03:03] Izno[m]: I mean, he also calls out github there. Kind of hard to take him seriously on that one [21:03:21] At least my personal experience, most FOSS have worse UX compared to alternatives. Many users care more about UX than the effort needed to use a FOSS alternative [21:03:36] doesn't seem unreasonable to note that github does have alternatives, the same way that Discord has alternatives πŸ™‚ [21:04:01] whether or not those alternatives scale is a question that apparently only Red Hat and the WMF have answered in the affirmative [21:04:06] Just that, if github was a problem for open source, it hasn't really happened yet, which implies its not that big a problem [21:04:51] atxatx4928[m]: yeah, but some people like to feel "special" knowing they are part of the elect who can edit Xorg files by hand to make their monitor work :P [21:04:53] You need highly incentivized volunteers to make a FOSS project as good as a commercial project backed by paid employees and company funding [21:05:09] πŸ™ƒ [21:05:31] Power to those people, people can enjoy different things πŸ™‚ [21:05:32] I don't think that's true. However, you need to find a competitive niche that is not UX design, because commercial is going to beat you on that [21:05:47] a paycheck does not make one magically competent, that is darn well sure [21:06:03] as demonstrated by the WMF also 🀭 [21:06:06] I think the bigger problem is that design is very subjective, but also requires consistency [21:06:18] Which are things bazaar model open source does poorly [21:06:27] Often time the (pre)onboarding UX on FOSS is bad enough to deter users away [21:06:36] Izno[m]: (-; [21:06:56] bawolff: does "let's design something, use it for a while and then throw it all away every N years" count as consistent? >.> [21:07:03] There are different type of designs, but I would say that UX design nowadays are more data-driven so it is more objective [21:07:50] Sometimes yes, but sometimes data driven is just code for "let me setup the experiment so i get the answer i want so i can justify it to others" [21:08:21] never had the WMF do that before [21:08:34] It is essentially it, you set up a hypothesis to prove or disprove in UX design [21:08:47] * a hypothesis/problem, * statement to prove [21:09:02] statement to disprove* [21:09:13] right, but if scientists can p-hack so can ux desginers [21:09:36] or in most cases, not inentionally, but allow subtle biases to creep into experiment design [21:09:39] > implying scientists are any better at stats than anyone else [21:10:25] Yes it is always something to avoid, designers are human being after all [21:10:44] As far as open source goes though - to even get to the point where you can run an experiment, you probably have to have lots of clout in the project [21:11:01] In normal software dev, you file some bugs, make some patches, and slowly onboard responsibility [21:11:11] if the results don't match the theory, change the results [21:11:18] Lol [21:11:25] I think the path to onboard into a community developed open source project as a UX designer is much harder [21:11:28] You are suppose to redefine the problem statement and test again [21:11:43] There's less small things you can do to edge towards bigger and bigger responsibility [21:11:48] bawolff (@_discord_678824495032827930:t2bot.io) there are many reasons [21:12:10] The biggest reason (for me) is just I need to pay rent and I only have so much time [21:12:23] hmm, interesting how pings show up on irc [21:12:29] 13:11 < atxatx4928[m]> bawolff (@_discord_678824495032827930:t2bot.io) there are many reasons [21:12:41] atxatx4928[m]: indeed, me too [21:12:51] Yeah it works on the Discord side too! [21:13:10] I mean, im unemployed at the moment, which is part of the reason im spending a lot of time around mediawiki recently [21:13:16] And as you mentioned, onboarding is much harder as only some UX designers have the required technical skill to navigate some projects [21:14:07] but its hard to find time when i actually have a full time job (for that matter, open source contributions are a lot less "fun" when its basically the same as your job) [21:14:24] Even frontend languages (HTML/CSS/JS) are not that common among UX designers, let alone knowing enough to implement your design [21:14:48] right, and open source projects are pretty famous for having bad onboarding, but usually if there is anything there, its aimed towards coders [21:15:34] Not to mention in commercial projects, often you have the authority to order people to implement your designs. Which is not how open source works [21:16:21] There are wonderful ones out there too. For example Tachiyomi on Android is pretty successful [21:18:52] It is dictated by how passionate are the contributors on the project, then whether they have the right skillset to cover all areas [21:19:23] * all areas, and also how it is organized [21:20:11] Totally unrelated: anyone knows if there will be another RC for 1.39, or are we moving to stable release this month? [21:20:24] Its supposed to be out this month [21:20:33] but i don't actually know [21:21:26] Hi, installing 37.6 I get an excp on initial display of /view/Main_Page Error: Call to undefined method MWTidy::isEnabled() [21:21:27] Backtrace: from /home/bestprac/public_html/includes/Sanitizer.php(464) [21:21:53] belltowerwikis: You might have a mix of files from different versions of MediaWiki [21:21:58] yes i do [21:22:17] how do i address that, and have just one version [21:22:29] Generally the best way is to re-install [21:22:39] ok, reinstall under a different directory. ok [21:22:45] step 1) find a time machine... [21:23:01] yeah, and copy over LocalSettings.php extensions and images directories [21:23:53] got it. thanks bawolff