Wikitech-l January 2022

wikitech-l@lists.wikimedia.org

55 participants
55 discussions

List related to repositories which haven't mediawiki/mediawiki-codesniffer
by Zoran Dori 10 Jan '23

10 Jan '23

Hello, can someone to update list https://phabricator.wikimedia.org/P10500 which contains repositories which haven't mediawiki/mediawiki-codesniffer. I found in list that much repositories are empty, and repositories which aren't available on Gerrit. So, can someone please update this list of repositories (in mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at least, contains one PHP file. or to provide me command with which I can update list when I want, so I don't need to request it every time. Best regards, Zoran. P. S.: Happy weekend! :)

4 6

Repository ownership of the Lingo extension
by Zoran Dori 10 Jan '23

10 Jan '23

Hi everyone, I want to notify you that I have, on behalf of the WikiTeq company, made a task https://phabricator.wikimedia.org/T298277 for requesting repository ownership for the Lingo extension. In case that you have any kind of questions, please let me know. :) Best regards, Zoran

3 3

Best practices for extensions
by Krinkle 14 Mar '22

14 Mar '22

TLDR: Tech leads please review Best practices for extensions <https://www.mediawiki.org/wiki/Best_practices_for_extensions> on mediawiki.org. Hi all, You may be familiar with the Best practices for extensions <https://www.mediawiki.org/wiki/Best_practices_for_extensions> page on mediawiki.org. It has been marked as a draft since 2017. I'd like to polish this page and get it to a state where it would be uncontroversial to label it as "Development guideline <https://www.mediawiki.org/wiki/Development_guidelines>". This would not make it a hard policy. Neither does it imply that it covers all practices in all situations. Rather, it would mean that the items that are there now are indeed a part of our current best practices. We would keep it alive through bold <https://en.wikipedia.org/wiki/Wikipedia:Be_bold> edits and talk page conversations, similar to our Coding conventions <https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP> and other such guidelines that we maintain peer to peer and through consensus. The reason I've not simply labelled it as such already is because before today I found the document to be out of sync with our actual practices. I have made a number of changes with descriptive edit summaries to bring it in sync with what I percieve to be our best practices; based on how myself and other maintainers perform code review at large, and how we review new extensions prior to deployment. All are welcome to fix mistakes, raise questions/concerns on the talk page, on this thread. You're also welcome to message me directly anytime if you prefer. If you consider yourself familiar with our practices and/or lead and mentor other engineers, please take a minute to review the page and consider whether the items reflect your current understanding and judgement. -- Timo Tijhof, Principal Engineer, Wikimedia Performance Team.

5 7

Call for projects and mentors for Google Summer of Code 2022 and Outreachy Round 24 is ongoing!
by Srishti Sethi 22 Feb '22

22 Feb '22

Hello everyone, TLDR; Wikimedia will soon be applying as a mentoring organization to Google Summer of Code 2022 <https://summerofcode.withgoogle.com> [1] and Outreachy Round 24 <https://www.outreachy.org/> [2]. We are currently working on a list of interesting project ideas to include in the application. If you have some ideas for coding or non-coding (design, documentation, translation, outreach, research) projects, share them here: < https://phabricator.wikimedia.org/T299453> [3]. *Timeline* As a mentor, you will engage potential candidates in the application period for both programs between March and April. You will help candidates make small contributions to your project and answer any project-related queries during this time. You will work more closely with the accepted candidates during the coding period between May and August. *New changes are coming to GSoC* GSoC has exciting changes this year, including: * Eligibility criteria redefined–the program is now open to all open-source newcomers 18 years and older. It will no longer be solely focused on university students or recent graduates. * Multiple sizes of projects supported–ranging from ~175 to ~350 hr long. * Increased flexibility in project timing–project deadline can be extended to up to 22 weeks. *Tips for proposing projects* * Follow this task description template when you propose a project in Phabricator: < https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4]. Add #Google- Summer-of-Code (2022) or #Outreachy (Round 24) tag. * Project should require an experienced developer ~15 days and a newcomer ~3 months to complete. * Each project should have at least two mentors, and one of them should hold a technical background. * Ideally, the project has no tight deadlines, a moderate learning curve, and fewer dependencies on Wikimedia's core infrastructure. Projects addressing the needs of a language community are most welcome! * If you don't have an idea in mind and would like to pick one from an existing list, check out these projects: < https://phabricator.wikimedia.org/tag/outreach-programs-projects/> [4] * To learn more about the roles and responsibilities of mentors, visit our resources on MediaWiki.org: < https://www.mediawiki.org/wiki/Outreachy/Mentors> [5], < https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors> [6]. Cheers, Srishti [1] https://summerofcode.withgoogle.com [2] https://www.outreachy.org/ [3] https://phabricator.wikimedia.org/T299453 [4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/ [5] https://www.mediawiki.org/wiki/Outreachy/Mentors [6] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

Talk to the Search Platform Team—February 2nd, 2022
by Trey Jones 01 Feb '22

01 Feb '22

The Search Platform Team <https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> 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, Wikimedia Commons Query Service, etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, February 2nd, 2022 Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET & WAT 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 Hope to talk to you next week! —Trey Trey Jones Staff Computational Linguist, Search Platform Wikimedia Foundation UTC–5 / EST

1 1

🚂🌈Summary of 1.38.0-wmf.19 train deployment
by Brennen Bearnes 31 Jan '22

31 Jan '22

This email is a summary of the Wikimedia production deployment of 1.38.0-wmf.19 * Conductor: Brennen Bearnes * Backup Conductor: Jeena Huneidi * Blocker Task: T293960 <https://phabricator.wikimedia.org/T293960> * Current Status <https://versions.toolforge.org>: Stable on all wikis. 📈 By the Numbers Sparklines comparing with the last 5 trains. * 319 Patches ▆▁▇▇█ * 1 Rollback ▄▁█▁▂ * 1 Day of delay ▂▂█▁▂ * 18 Blockers ▂▁▂▆█ 🌈 Trainbow Love 😻 Thanks to folks who reported or resolved blockers: * Amir Sarabadani * Taavi Väänänen * Zabe * Legoktm * Umherirrender * Bartosz Dziewoński * Jon Robson * Urbanecm * Tyler Cipriani * Ammarpad * Lucas Werkmeister (WMDE) Others no doubt contributed, but there'd be a rather long list of blockers to parse to figure out who I'm missing. Additionally, a special thanks to everyone who helped debug T300214 - 'No such file or directory' CI failures in multiple repos <https://phabricator.wikimedia.org/T300214> in #wikimedia-releng: * Zabe * hashar * bd8080 * James_F * dancy * thcipriani * Amir1 * andrewbogott * TimStarling ...and anyone else I'm more than likely missing in scrollback. -- Brennen Bearnes Release Engineering Wikimedia Foundation

1 0

January 2022 Edition of the Technical Community Newsletter
by Melinda Seckington 31 Jan '22

31 Jan '22

Hi everyone, We’re happy to announce the January 2022 edition of the Technical Community Newsletter < https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2022/January>. The newsletter is compiled by the Wikimedia Developer Advocacy Team. It aims to share highlights, news, and information of interest from and about the Wikimedia technical community. The Wikimedia Technical Community is large and diverse, and we know we can't capture everything perfectly. We would love to hear your ideas for future newsletters. Let us know what you would like to see or highlights you would like us to include. Subscribe to the Technical Community Newsletter <https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>, if you'd like to keep up with essential updates and information. Thanks, Melinda -- Melinda Seckington Developer Advocacy Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Interested in Contributing to Wikimedia Foundation
by Ankit Aggarwal 29 Jan '22

29 Jan '22

Respected Sir/Madam, I'm Ankit Aggarwal, a 3rd year engineering student at MAIT. I am new to open source contribution. I would love to contribute to your organization. I am interested in Web Development. Can you please guide me how i can start contributing. My Technical skills are: 1). HTML 2). CSS 3). JavaScript 4). ReactJS Hoping for a positive response. Regards Ankit Aggarwal

2 1

Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)
by Kunal Mehta 28 Jan '22

28 Jan '22

Hi, On 1/1/22 12:10, Asaf Bartov wrote: > It seems to me there are *very few* people who could change status quo, > not much more than a handful: the Foundation's executive leadership (in > its annual planning work, coming up this first quarter of 2022), and the > Board of Trustees. If the goal is to get paid WMF staff to fix the issues, then you're correct. However, I do not believe that as a solution is healthy long-term. The WMF isn't perfect and I don't think it's desirable to have a huge WMF that tries to do everything and has a monopoly on technical prioritization. The technical stack must be co-owned by volunteers and paid staff from different orgs at all levels. It's significantly more straightforward now for trusted volunteers to get NDA/deployment access than it used to be, there are dedicated training sessions, etc. Given that the multimedia stack is neglected and the WMF has given no indication it intends to work on/fix the problem, we should be recruiting people outside the WMF's paid staff who are interested in working on this and give them the necessary access/mentorship to get it done. Given the amount of work on e.g. T40010[1] to develop an alternative SVG renderer, I'm sure those people exist. Take moving Thumbor to Buster[2] for example. That requires forward-porting some Debian packages written Python, and then testing in WMCS that there's no horrible regressions in newer imagemagick, librsvg, etc. I'm always happy to mentor people w/r to Debian packaging (and have done so in the past), and there are a decent amount of people in our community who know Python, and likely others from the Commons community who would be willing to help with testing and dealing with whatever fallout. So I think the status quo can be changed by just about anyone who is motivated to do so, not by trying to convince the WMF to change its prioritization, but just by doing the work. We should be empowering those people rather than continuing to further entrench a WMF technical monopoly. [1] https://phabricator.wikimedia.org/T40010 [2] https://phabricator.wikimedia.org/T216815 -- Legoktm

11 10

Re: [Wikimedia-l] Uplifting the multimedia stack (was: Community Wishlist Survery)
by Strainu 28 Jan '22

28 Jan '22

> So where is the best current place to discuss scaling Commons, and all that entails? My impression is that we don't have one. All we hear is "it needs to be planned", but there is no transparency on what that planning involves or when it actually happens. > I'd be surprised if the bottleneck were people or budget The main problem I see is that we end up in this kind of situation. Scaling and bug fixing critical features should be part of the annual budget. Each line of code deployed to production wikis should have an owner and associated maintenance budget each year. Without this, the team will not even commit reviews - see the thread on wikitech a few months back where a volunteer programmer willing to work on Upload Wizard was basically told "We will not review your code. Go fork." > Some examples from recent discussions Also improvements to the Upload Wizard. There are quite a few open items in Phab on this. I really hope you will have better luck than others with bringing this issue up in the priority list for next year - multimedia support is growing more outdated by the minute. Strainu Pe joi, 30 decembrie 2021, Samuel Klein <meta.sj(a)gmail.com> a scris: > Separate thread. I'm not sure which list is appropriate. > ... but not all the way to sentience. > > The annual community wishlist survey (implemented by a small team, possibly in isolation?) may not be the mechanism for prioritizing large changes, but the latter also deserves a community-curated priority queue. To complement the staff-maintained priorities in phab ~ > For core challenges (like Commons stability and capacity), I'd be surprised if the bottleneck were people or budget. We do need a shared understanding of what issues are most important and most urgent, and how to solve them. For instance, a way to turn Amir's recent email about the problem (and related phab tickets) into a family of persistent, implementable specs and proposals and their articulated obstacles. > An issue tracker like phab is good for tracking the progress and dependencies of agreed-upon tasks, but weak for discussing what is important, what we know about it, how to address it. And weak for discussing ecosystem-design issues that are important and need persistent updating but don't have a simple checklist of steps. > So where is the best current place to discuss scaling Commons, and all that entails? Some examples from recent discussions (most from the wm-l thread below): > - Uploads: Support for large file uploads / Keeping bulk upload tools online > - Video: Debugging + rolling out the videojs player > - Formats: Adding support for CML and dozens of other common high-demand file formats > - Thumbs: Updating thumbor and librsvg > - Search: WCQS still down, noauth option wanted for tools > - General: Finish implementing redesign of the image table > > SJ > On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com> wrote: >> >> I'm not debating your note. It is very valid that we lack proper support for multimedia stack. I myself wrote a detailed rant on how broken it is [1] but three notes: >> - Fixing something like this takes time, you need to assign the budget for it (which means it has to be done during the annual planning) and if gets approved, you need to start it with the fiscal year (meaning July 2022) and then hire (meaning, write JD, do recruitment, interview lots of people, get them hired) which can take from several months to years. Once they are hired, you need to onboard them and let them learn about our technical infrastructure which takes at least two good months. Software engineering is not magic, it takes time, blood and sweat. [2] >> - Making another team focus on multimedia requires changes in planning, budget, OKR, etc. etc. Are we sure moving the focus of teams is a good idea? Most teams are already focusing on vital parts of wikimedia and changing the focus will turn this into a whack-a-mole game where we fix multimedia but now we have critical issues in security or performance. >> - Voting Wishlist survey is a good band-aid in the meantime. To at least address the worst parts for now. >> >> I don't understand your point tbh, either you think it's a good idea to make requests for improvements in multimedia in the wishlist survey or you think it's not. If you think it's not, then it's offtopic to this thread. >> [1] https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org… >> [2] There is a classic book in this topic called "The Mythical Man-month" >> >> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote: >>> >>> we have to vote for regular maintenance and support for essential functions like uploading files which is the core mission of Wikimedia Commons

3 2

2025

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 January 2022