Wikitech-l December 2023

wikitech-l@lists.wikimedia.org

50 participants
38 discussions

[Wikimedia Research Showcase] December 12 at 17:30 UTC
by Kinneret Gordon 12 Dec '23

12 Dec '23

Hi All, The next Research Showcase will be live-streamed on Tuesday, December 12, at 9:30 AM PST / 17:30 UTC. Find your local time here <https://zonestamp.toolforge.org/1702402200>. This is a special showcase featuring a panel titled *"*A year of Generative AI: *Future directions for Wikimedia". *You can find more information on this showcase below. You can watch via the YouTube stream: https://youtube.com/live/UnAsD7-hZpo?feature=share <https://www.google.com/url?q=https://youtube.com/live/UnAsD7-hZpo?feature%3…>. As usual, you can join the conversation in the YouTube chat as soon as the showcase goes live. *This December marks the one-year anniversary of ChatGPT with the resulting public interest in generative AI and growing research focus on practical uses of large language models. There has been much discussion about how these generative models might disrupt the Wikimedia projects but also prototyping to see where they might be useful. To discuss what we've learned in the past year and what opportunities ahead are being enabled by research, we bring together a panel of four folks: Isaac Johnson (senior research scientist at the Wikimedia Foundation) will be the moderator and the three panelists are User:Barkeep49 [1], Maryana Pinchuk [2], and Robert West [3] to bring perspectives from the volunteer, product, and research communities. [1] https://en.wikipedia.org/wiki/User:Barkeep49 <https://en.wikipedia.org/wiki/User:Barkeep49> [2] https://meta.wikimedia.org/wiki/User:MPinchuk_(WMF) <https://meta.wikimedia.org/wiki/User:MPinchuk_(WMF)> [3] https://dlab.epfl.ch/people/west/ <https://dlab.epfl.ch/people/west/> * Looking forward to seeing you there! -- Kinneret Gordon Lead Research Community Officer Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

Contributing to Wikimedia
by Aryann Dwivedi 12 Dec '23

12 Dec '23

Dear Sir/Madam, I am Aryann Dwivedi, currently enrolled as an engineering student at NIT Nagpur. This marks my initial venture into the realm of open source contribution. Proficient in languages such as javascript, typescript, node,php, I have successfully executed several projects. Now, I am eager to channel my skills and contribute to your community. In pursuit of this goal, I want to seek guidance and mentorship from an experienced individual who possesses expertise in the mentioned domains. I am enthusiastic about taking on a small issue or feature to work on under your mentorship. Thank you for considering my request.

2 1

Re: Enabling canary events for all MediaWiki event streams
by Andrew Otto 11 Dec '23

11 Dec '23

Hi everyone, I just enabled canary events for the mentioned streams. Please comment here or on the task if you encounter any issues. Thank you! -Andrew Otto & the WMF Data Engineering team <https://wikitech.wikimedia.org/wiki/Data_Engineering> On Tue, Nov 7, 2023 at 1:57 PM Andrew Otto <otto(a)wikimedia.org> wrote: > tl;dr > > Ignore this email if you do not use MediaWiki event streams. > > On Monday December 11 2023, all MediaWiki related event streams will have artificial > canary events > <https://wikitech.wikimedia.org/wiki/Event_Platform/EventStreams#Canary_Even…> > injected into them. If you use any of these streams, you should discard > thesee canary events. > > Add code to your consumers that discards events where meta.domain == > "canary". > Canary Events > > At WMF, we use artificial 'canary' AKA 'heartbeat' events > <https://wikitech.wikimedia.org/wiki/Event_Platform/Stream_Configuration#can…> > to differentiate between a broken event stream and an empty event stream. > Canary events should be produced at least once an hour. If there are no > events in a stream for an hour, then something is likely broken with that > stream. > > These artificial canary events can be identified by the fact that their > meta.domain field is set to "canary". If you use any of the streams > listed below, you will need to add code that discards any events where meta.domain > == "canary". > > Back in 2020, we began producing canary events into all new streams, but > we never got around to enabling these for streams that already existed. We > needed to ensure that all consumers of these streams filtered out the > canary events. We're just finally getting around to enabling canary events > for all streams. > > We will enable canary event production > <https://phabricator.wikimedia.org/T266798> for the following streams on > Monday, December 11th, 2023: > > - mediawiki.recentchange > > - mediawiki.page-create > > - mediawiki.page-delete > > - mediawiki.page-links-change > > - mediawiki.page-move > > - mediawiki.page-properties-change > > - mediawiki.page-restrictions-change > > - mediawiki.page-suppress > > - mediawiki.page-undelete > > - mediawiki.revision-create > > - mediawiki.revision-visibility-change > > - mediawiki.user-blocks-change > > - mediawiki.centralnotice.campaign-change > > - mediawiki.centralnotice.campaign-create > > - mediawiki.centralnotice.campaign-delete > > If you consume any of these streams, either external to WMF networks using > EventStreams, or internally using Kafka, please ensure that your consumer > logic discards events where meta.domain == "canary" before this date. > (Note that not all of these streams are exposed publicly at > stream.wikimedia.org <https://stream.wikimedia.org/?doc#/streams>.) > > Thank you, > > -Andrew Otto & the WMF Data Engineering team > <https://wikitech.wikimedia.org/wiki/Data_Engineering> > > References > > - T266798 - Enable canary events for all MediaWiki streams > <https://phabricator.wikimedia.org/T266798> > > - T251609 - Automate ingestion and refinement into Hive of event data > from Kafka using stream configs and canary/heartbeat events > <https://phabricator.wikimedia.org/T251609> > >

1 0

MediaWiki in the age of AI - Keynote by Markus Krötzsch
by Bernhard Krabina, KM-A 11 Dec '23

11 Dec '23

Dear MediaWiki community, we are happy to announce that Markus Krötzsch will be joining us in Paderborn for the keynote talk at SMWCon 2023! In this talk, Markus will provide a personal perspective on the origins and principles of semantic wikis, and some of the key challenges that lie ahead in managing knowledge in the age of A! Don't miss it - you can still attend in person, or follow the conference via YouTube or Zoom. https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023 I you have not already participated in our __community survey__, please do so until this Wednesday. It is important for us to learn more about your SMW usage. Results will be presented next Tuesday. We thank this year's conference sponsors: ArchiXL: http://www.archixl.nl/ Specialists in enterprise architecture, knowledge management, and semantics Hallo Welt!: https://bluespice.com/ The company behind BlueSpice, the open-source enterprise wiki software MyWikis Europe: https://mywikis.eu/ GDPR compliant (Semantic) MediaWiki hosting from the heart of Europe. Wikibase Solutions: https://wikibase-solutions.com/ Specialist in business solutions with MediaWiki As well as the conference organizers MediaWiki Stakeholders' Group: https://mwstake.org/ Advocating the needs of MediaWiki users outside the Wikimedia Foundation KM-A Knowledge Management Associates: https://km-a.net/ KM-A educates and advises Knowledge Managers and connects the KM Community in Austria and the world. Paderborn University: https://www.uni-paderborn.de/en/ While always keeping society's needs in mind, scientists at Paderborn University are working on the technologies of the future. Juggel: https://www.juggel.com/ AI supported Knowledge Management based on MediaWiki and Semantic MediaWiki Best regards, Bernhard, Ad and Tobias

1 1

major upgrade of PageProperties -- json-schema compliant Builder, no SMW dependency, inline and popup forms, inline queries of hierarchical (json) data, result formats, Browse data, maintenance scripts, and more
by tdvit＠mail.com 10 Dec '23

10 Dec '23

1 0

Re: Inquiry Regarding Opportunities to contribute
by Vaishnavi Maheshwari 10 Dec '23

10 Dec '23

Hey! actually I am finding it a bit difficult to solve issues and make pull requests. so just wanted to ask if wikimedia has a system of providing personal mentors? It will be helpful and from whom I can ask questions in general? On Sat, Nov 18, 2023 at 11:58 PM Mailtrack Notification < notification(a)mailtrack.io> wrote: > 🔥 Hot conversation: wikitech-l(a)lists.wikimedia.org opened it many times > in a short period or forwarded it. View all 315 opens > <https://mailtrack.io/reauth?url=https://mailtrack.io/en/dashboard/show/2903…> > | turn off hot conversations > <https://mailtrack.io/en/dashboard/hot-notification/disable> >

2 1

Assurances and Support Regarding the Grid Engine Shutdown
by Seyram Komla Sapaty 08 Dec '23

08 Dec '23

Hello! After our initial announcement of the Grid Engine shutdown timeline[0], some of you raised concerns about losing your tools. We want to address those apprehensions while hopefully providing reassurance. No tools will be deleted until the grid engine shutdown date on 14 February 2023. However, for tools with unreachable maintainers, an outage will happen starting on 14 December 2023[1]. This is intended to raise awareness for users or maintainers who have not otherwise been reached. A list of these tools can be found here[2]. If you are a maintainer or a user of a tool in this list, comment on the associated phabricator ticket with migration plans or a request for more support. The goal is to have a plan for all tools running on the grid. We want all actively used tools to be migrated, and will help support users of critical tools without a maintainer. Thanks for your help in identifying and migrating those tools you maintain and depend on. We acknowledge that the timeline might seem tight, and we want to clarify that our approach is to make this process as seamless as possible. We have been actively engaging with tool maintainers over the past year, and we genuinely appreciate the efforts many of you have already made to migrate your tools to Kubernetes. We will continue to work closely with maintainers who might need additional time or assistance. If for any reason you have not received a phabricator ticket for your tool, please reach out. The phabricator ticket is a good place to communicate your needs and plans for any remaining tools or jobs. This will help us further organize and plan this process. Our primary goal is to support you through this transition. If you have further concerns about the deadline or if you need assistance with the migration process, please don't hesitate to reach out to us. We are available on IRC, Telegram, Phabricator[3], and through our other support channels[4]. Do you still have concerns or questions? Please let us know. We want to do this together with you, in a way which makes sense to everyone. We’re very grateful for all the hard work you do, and our only goal here is to secure the future of tools in the Wikimedia sphere, not to make your lives more difficult. Thank you! [0]: https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.… [1]: https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation#… [2]: https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation/… [3]: https://phabricator.wikimedia.org/project/board/6135/ [4]: https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Commun… -- Seyram Komla Sapaty Developer Advocate Wikimedia Cloud Services

1 0

Open question about commit message linter rules and GItLab's merge requests
by Bryan Davis 08 Dec '23

08 Dec '23

Recently I completed initial work to enable commit-message-validator [0] to work with GitLab CI and GitLab merge requests. For those who are unaware, commit-message-validator is a linter tool designed to enforce Wikimedia's commit message guidelines. [1] Soon after the feature was available, James Forrester added it to the test suite for abstract-wiki/wikifunctions/function-orchestrator [2] and found the first issue with the integration that I had not anticipated which he helpfully filed as T351253. [3] In my estimation, the problem comes down to a question of whether we should prioritize reading commit message footer information nicely in GitLab's merge request interface where they are rendered as GitLab flavored markdown data or not. James' team has developed a convention of appending a backslash (\) after footer lines so that they render as individual lines when processed as markdown. This in turn leads to commit-message-validator rejecting some footers, most obviously "Bug: Tnnnn" footers, for having unwanted characters (the trailing " \"). Reasonable people can disagree on the "best" solution here, but I think it is likely that as a group we can reach consensus on what the proper behavior of the commit-message-validator tool should be. The most obvious options are: * Change nothing in commit-message-validator and suggest folks live with markdown rendering artifacts in GitLab merge request descriptions. * Change commit-message-validator to allow trailing " \" data for commit message footers in GitLab repos. * Change commit-message-validator to allow users (typically a CI process) to configure allow/disallow of trailing " \" data for commit message footers Adding support for per-repo rules configuration would be a first for commit-message-validator. Until now it has provided a single opinionated ruleset based on interpretation of the commit message guidelines. [2] Folks who actually care about this minutia (how git commit message footers look in and out of GitLab markdown rendering) are encouraged to think carefully and provide their opinions and supporting data on T351253. [3] [0]: https://www.mediawiki.org/wiki/Commit-message-validator [1]: https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines [2]: https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orc… [3]: https://phabricator.wikimedia.org/T351253 Bryan -- Bryan Davis Wikimedia Foundation Principal Software Engineer Boise, ID USA [[m:User:BDavis_(WMF)]] irc: bd808

3 2

Collect telemetry (using WikimediaEvents) for a gadget
by psnbaotg 07 Dec '23

07 Dec '23

Hi there, I'm User:Diskdance, and recently I'm developing a default gadget for Chinese Wikipedia enhancing MediaWiki's variant handling logic, and under certain circumstances a prompt is shown at page load asking for a user's preferred variant. Consider it as a conditional Cookie notice, and its English screenshot can be found at https://commons.wikimedia.org/wiki/File:VariantAlly-En.png. Iknowthis can be very disruptive on UX, so I tend to be careful about its negative impact on page views. If the gadget can collect telemetry data about the prompt's display frequency and user interactions(using e.g. WikimediaEvents), I can know about its possible impact. Is this possible? It would be much appreciated if anybody could provide assistance. Best wishes,Diskdance

6 7

Talk to the Search Platform / Query Service Team—December 6, 2023
by Guillaume Lederrey 06 Dec '23

06 Dec '23

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, December 6, 2023 Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vgj-bbeb-uyi Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2023