[06:55:02] Hi all [06:55:02] The 2025 Wikimania Hackathon Showcase and Coolest Tool Award is happening today at 3:30 pm (EAT) in Nairobi (Ballroom 2) and online! πŸŽ‰ [06:55:04] Whether you’re on-site in Nairobi or joining virtually, we’d love to see you there! [06:55:05] Quick nudge β€” if you’d like to share your project during the showcase, please add your project details + links to this Etherpad now - https://etherpad.wikimedia.org/p/Hackathon_Showcase_%26_Coolest_Tool_Awards [06:55:07] Thanks, and see you soon! [07:00:44] If there’s anyone at Wikimania that wants a yubikey, please come and find myself or @Ladsgroup [07:37:05] @addshore Can you reboot codesearch? [08:47:22] Speaking of the hackathon showcase, does anyone here have admin rights in the wikimania wiki? The page for the showcase for the 2023 wikimania (https://wikimania.wikimedia.org/wiki/2023:Hackathon/Showcase) is fully protected so I am unable to add additional details (specifically, links to the presentations and video recording). Can anyone help me unprotect it? [08:48:06] For the record, I asked the user who implemented the full protection but they stopped responding: https://wikimania.wikimedia.org/wiki/User_talk:Exec8#Full_protection_of_Hackathon_showcase_page [08:49:29] I can do it with my staff account [08:49:57] Even semi protection is annoying because auto confirm [08:51:26] Or are they fully protected to keep it accurate from the time? [09:02:17] Yes, @deb_t ran into precisely that issue, and participated in the linked discussion to explain it (re @tehreedy: Even semi protection is annoying because auto confirm) [09:04:34] It seems so (the editor said "Similar to previous Wikimanias like 2018 and prior, the 2023 pages were meant to be locked for historical context"), but while I understand that stance for discussion pages, I don't think the same level of protection is warranted for content pages β€” I mean, it's a wiki after all :) (re @tehreedy: Or are they fully protected to keep [09:04:34] it accurate from the time?) [09:05:26] Semi-protection for old pages seems reasonable to avoid vandalism in pages that are likely not actively monitored, but once we set the bar to autoconfirmed accounts, it seems significantly less of an risk. [09:55:34] addshore: platform: linux/amd64 [09:56:19] waldyrious: I can do that, sure. [09:59:58] Done: https://wikimania.wikimedia.org/w/index.php?title=2023:Hackathon/Showcase&diff=prev&oldid=504797 [11:11:20] Reminder: Ahead of the showcase, please add your project to this Etherpad now - https://etherpad.wikimedia.org/p/Hackathon_Showcase_%26_Coolest_Tool_Awards [11:11:20] TY! [12:30:16] Hmm, interesting, I am still unable to edit the page. The "Extended confirmed" protection level apparently is only reached after 500 edits, which seems rather high. For context, my account in the wikimania wiki dates from 2020 and currently has 77 edits; if I add up the edits from the older wikimania wikis, (when they were separate) the total edits rise to ~350, [12:30:16] all the way back [12:30:18] to 2008. I am of course biased, but it seems to me that someone with my level of engagement should be considered trusted enough to make edits to such pages, no? (re @wmtelegram_bot: Done: https://wikimania.wikimedia.org/w/index.php?title=2023:Hackathon/Showcase&diff=prev&oldid=504797) [12:32:22] waldyrious: Ah, yeah, extended-confirmed does seem a bit high, agreed. I think you should start a discussion on-wiki about reducing that, though presumably it was put in for a reason. [12:34:18] In fact, there are pretty much the same number of extended confirmed users (https://wikimania.wikimedia.org/w/index.php?title=Special:ListUsers&group=extendedconfirmed) (46) as administrators (https://wikimania.wikimedia.org/wiki/Special:ListUsers?username=&group=sysop&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=50) (42). And funny enough, only 4 admins [12:34:18] are extended confirmed πŸ˜… [12:34:46] Showcase started! [12:38:13] Any link to watch? (re @ChlodAlejandro: Showcase started!) [12:38:14] Live stream: https://www.youtube.com/watch?v=Szjq7Emoqq0 (re @ChlodAlejandro: Showcase started!) [12:39:52] Etherpad link: https://etherpad.wikimedia.org/p/Hackathon_Showcase_%26_Coolest_Tool_Awards [12:40:29] Someone please back it up in case it disappears πŸ˜… [12:43:14] Does it already begin? [12:43:29] They are already on the third showcase (re @affandymurad: Does it already begin?) [12:57:01] πŸ“„ Slides: Evolving Hackathons – Structured Collaboration By Indic MediaWiki Developers UG [12:57:02] πŸ‘©β€πŸ’» @navya_sri_kalli & πŸ‘¨β€πŸ’»@Gopavasanth [12:57:04] Slides: https://commons.wikimedia.org/wiki/File:Evolving_Hackathons_Structured_Collaboration_by_Indic_MediaWiki_Developers_UG.pdf [13:17:20] Paulina won the most innovative coolest tool award this year. Hackathon got a shout out! : https://tools-static.wmflabs.org/bridgebot/d2f8bbdc/file_72885.jpg [13:21:08] Amazing projects and great work by everyone. Big claps for the host for his awesome presentation πŸ‘ [13:36:52] I think the streams are here: https://www.youtube.com/watch?v=-NYuHNruixs&list=PLhV3K_DS5YfLPVASK2MANk6wSHgWmbULz [13:45:56] Thank you! I'm so happy (re @Jennifer 8.: Paulina won the most innovative coolest tool award this year. Hackathon got a shout out!) [14:17:58] Congrats! (re @Jorgemet: Thank you! I'm so happy) [14:21:02] What does it do (re @Jennifer 8.: Paulina won the most innovative coolest tool award this year. Hackathon got a shout out!) [14:26:50] It's a search and query interface for cultural works and authors based on Wikidata. You can try it here: https://paulina.toolforge.org/ (re @cvictorovich: What does it do) [14:27:33] Thought it could assist mass edits… [15:23:08] Note that this isn't about what MediaWiki supports, but what WMF will run. Latest MW supports PHP 8.1,8.2,8.3 and soon 8.4. What you run is up to you. The main anchor points here are indeed Debian and other LTS programs. [15:23:08] At WMF we maintain our own apt component with packages anyway, so it doesn't matter that much what version we pick. Newer is preferred as it involves more perf improvements and enables better upstream collab with php.net, they're not yet in the maintenance-only phase so we can actually report stuff and have things fixed, and benefit from it. [15:23:10] https://www.mediawiki.org/wiki/Support_policy_for_PHP [15:23:11] https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables (re @bozzy: Our CTO announced PHP support 8.3. But that is not in Debian stable, or next stable. [15:23:13] I'm a bit curious about this. Why not PHP 8...) [17:33:13] The extendedconfirmed group seems to have been added to the Wikimania wiki via T389729 (https://phabricator.wikimedia.org/T389729), where @robertsky explicitly asked: [17:33:15] Add extendedconfirmed group so that pages need not be protected at admin level [17:33:16] Add auto-promote to extendedconfirmed group after 30 days of account creation and 500 edits. [17:33:18] However, I don't think the 500 edits limit was specifically chosen for the Wikimania wiki; it was originally chosen back in 2016 for enwiki via T126607 (https://phabricator.wikimedia.org/T126607), and every other wiki has gone with the same limit (https [17:33:18] //github.com/wikimedia/operations-mediawiki-config/blob/80190b9daf0972faccd22fa98c69f2bae8ef90a3/wmf-config/InitialiseSettings.p [17:33:19] hp#L4417-L4633) so far. So I'm not sure lowering that limit for the wikimania wiki specifically would be warranted. I would instead propose lowering the protection level of the 2023:Hackathon/Outcomes (https://wikimania.wikimedia.org/wiki/2023:Hackathon/Outcomes) page to regular semiprotection (i.e. allow autoconfirmed users). But perhaps @robertsky can chime in:) [17:33:19] (re @wmtelegra [17:33:20] m_bot: waldyrious: Ah, yeah, extended-confirmed does seem a bit high, agreed. I think you should start a discussion on-wiki a...) [19:03:54] The limits can absolutely be adjusted. (re @waldyrious: The extendedconfirmed group seems to have been added to the Wikimania wiki via T389729, where @robertsky explicitly asked: [19:03:55] Add e...) [19:11:35] It was great, thank you! [19:11:35] Hope to see many of you at the MediaWiki Users and Developers Conference in Hanover, Germany: [19:11:37] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_Fall_2025 [19:12:51] The EC group was added recently so that we do not need to give admin rights left and right while maintaining protection to limit vandalism. Most of the EC group members are translators. The editing count and/or age of account can be adjusted down if need be to allow more non translators editors into the group. (re @wmtelegram_bot: waldyrious: Ah, yeah, [19:12:51] extended-confirme [19:12:52] d does seem a bit high, agreed. I think you should start a discussion on-wiki a...) [19:16:08] As for the 2023 page, it was requested by Butch to lock up the namespace for archival. Is there a reason to edit that page? But this was before the EC group was being added. (re @waldyrious: The extendedconfirmed group seems to have been added to the Wikimania wiki via T389729, where @robertsky explicitly asked: [19:16:08] Add e...) [19:24:02] I'm glad you are open to adjusting the limit. I do have valid motives for editing that particular page, which I cited earlier in the conversation, but I would prefer not to special-case it since other pages would preserve the same limitation. Considering that the number of editors with the EC group is on the ballpark of the number of admins, and if modifying the [19:24:02] edit count thresh [19:24:02] old sounds reasonable to others, then I'd say then that the limit should definitely be reduced. Given the limited scope of the Wikimania wiki, I'd say something like 100 edits should be more than enough to allow people to maintain/improve the pages while preventing vandalism. WDYT? [20:05:32] maybe an editnotice for the 2023 (etc.) namespace would also be useful? as a hint about which kinds of edits we still want to see and which should be discouraged [20:19:16] Which constructive would you say should be discouraged? πŸ€” (re @lucaswerkmeister: maybe an editnotice for the 2023 (etc.) namespace would also be useful? as a hint about which kinds of edits we still want to se...) [20:31:19] All constructive should of course be okay. But an edit notice can make clear that a change that can be seen as revising history is not constructive, even if it would have made the content better at the time of the conference. (re @waldyrious: Which constructive would you say should be discouraged? πŸ€”) [20:34:59] I can see that for discussion pages for example, but I'm having trouble thinking of changes that would constitute revising history in content pages. And even if we can think of such edits, have these been an issue so far anyway? (re @Jan_ainali: All constructive should of course be okay. But an edit notice can make clear that a change that can be seen as revising [20:34:59] history ...) [20:59:34] Sounds good to me on the edit count. Wrt to the specific page and reason, I will check in on it later on my laptop. I just got back to my hotel and am freshening up now. (re @waldyrious: I'm glad you are open to adjusting the limit. I do have valid motives for editing that particular page, which I cited earlier in...)