The Lego Mirror - MediaWiki

Interview with Brooke Vibber (2021)

2026-06-01T13:00:00+00:00

I had the pleasure of interviewing Brooke Vibber back in January 2021 for my story in the Wikipedia Signpost, The people who built Wikipedia, technically, which looked back at the technical history of Wikipedia to celebrate the 20th birthday.

I was not able to use all of the responses Brooke sent me for the article, but after re-reading them in light of current events, I feel it's still worth publishing five years later. Hopefully after reading this, you'll celebrate Brooke Vibber day with us today. Dankon Brooke!

What was it like getting started? Today we have a process of signing up to get a Gerrit account, a vote to give out +2 powers, NDAs for server access...what was it like then? How did you convince the powers that be (Was it Jimmy?) to give you server access?

It was all pretty loosey-goosey; if you showed up and put in good work helping out, you might well hear "yes" to getting some fairly direct access to things because that was the only way we were going to get anyone to do it!

In the earliest days I think Wikipedia ran on one of Bomis's servers so we usually would partner up with one of Jimmy's employees as an intermediary, but once we grew to dedicated servers, and then the Tampa-based hosting starting 2003-2004, it was really a core group of a few of us, many of whom are senior employees at WMF today.

As far as commit access and code review, that was very different in the early days -- we had CVS (before going SVN in 2006 or so) which meant no built-in system for local commits and pull requests, so "commit" meant roughly "merge/+2" and everyone else had to e-mail patches and me or Tim would personally review them and apply them. A lot of work!

Then in SVN times we started giving out commit access like candy, and I had to create an on-wiki code review system to help manage post-commit review...

I'm not super fond of gerrit's UI, but any flavor of pull request is a step up. ;)

My understanding is that you dropped out of film school to work on Wikipedia/MediaWiki full time - is that a fair characterization? (Or would you not prefer to be called a dropout?)

That sounds about right! :D I never quite finished my degree, and instead of taking the few more classes I needed I pivoted into work for Wikipedia which lead me into working at WMF. So, score another one for the dropouts, but I never struck it rich because we're a non-profit. ;)

What kind of programming experience did you have beforehand?

I actually grew up around programming -- my father is a software engineer and made sure my brother and I had the tools at home to learn if we were interested (8-bit Ataris when we were little, graduating up into the PC DOS/Windows/Linux worlds later). My brother and I both took well to it... though we craved that arts in high school and college -- he did some years in theater, and I worked on that film degree for a while. ;)

So when I fell back into computers, it was a world I'd never really left, but I'd also never been formally trained in it. Working on a massively-scaling-up project like early Wikipedia was a crash course in algorithmic complexity even if I didn't get all the flowerly language of big-O notation from textbooks. ;)

In February 2002, you suggested adding a WYSIWIG editor - did you ever imagine it would take as long as it did for us to get VisualEditor?

I always suspected it would be much harder to do full WYSIWIG while keeping complete compatibility with the old markup language, and I think I was proven right. :) That said, a lot of people still like the markup, so if we've succeeded at bringing it, hey! Nice.

Superprotect aside, should the rollout of MediaViewer have been as controversial as it was?

I think it should've been less controversial by far, but it also was a good example of the messaging around a rollout, and the communication between the developers, project managers, and users, was just not good. MediaViewer is great for many uses for casual readers -- its primary target audience -- but falls down in a particular way for editors who need to maintain images, not just look at them. This feedback could've been better dealt with and resolved, I think.

There's a trope that Wikimedians today are reluctant to any software change. Can you talk about some of the large software changes from the early days? How was communication with non-technical editors handled? What would be the thinking on whether to revert or leave it in a buggy state?

Honestly I think our change-conservativism issues were in full swing even in the early 2000s. We didn't make many markup changes after 2003, and only a few before that. We're now paying for that by continuing to be conservative in refusing to change things that are weird, confusing, and inconsistent because we didn't quite think through those changes and now refuse to change them again at all.

I believe you, Magnus and Tim were all college students when you got involved with Wikipedia. Do you think that was a coincidence or is there something about Wikipedia that appeals to students?

I definitely think there's an affinity between the college experience -- getting into a medium-sized world outside your house but before the big wide world and learning new fascinating things in a community of peers who want to learn and share knowledge -- and getting into the world of Wikipedia as a casual (or hardcore) editor or other contributor. :)

Today the WMF is a very professional (for lack of a better term) organization, in terms of defined processes, policies. There's an on call SRE team, etc. In the early days the servers were run by Bomis - was it like that? What kind of support did they provide? Were there power struggles between editors/volunteers and Bomis?

Bomis was very hands-off; when we ran on Bomis servers we just had some limitations in what we could access directly, and eventually I think they started encouraging Jimmy to buy separate servers when they started to become a large part of capacity. ;)

In 2012 you told the Signpost that your initial paychecks came from building "content-feed support for some third-party indexers" - I assume this was the Wikimedia update feed service? What parallels, if any, do you think this kind of API and funding model have with the new Wikimedia Enterprise project?

I think there's a direct parallel, and I'm glad to see us getting explicitly back into the business of checking in with folks who reuse our data and making sure they pay us for the privilege of the data being reliably present. :)

With 20 years of hindsight, what would you have told Magnus when he announced he was going to write the new wiki software in PHP?

Honestly, PHP was a good choice at the time. A lot of people make fun of it for its quirky syntax, function naming, and some old security misfeatures from 20 years ago, but it's an easily-approachable language with an execution model that fits web servers reasonably well and has clear ways to scale horizontally to serve more requests.

I can't really tell from the mailing list archives, but did Magnus (and later Lee for phase 3) tell people they were planning major rewrites of the software or did they just show up with it one day?

These were announced and talked about on the mailing lists. I actually feel like we were more attuned as a technical subcommunity to what was going on because there were only two lists to pay attention to, wikipedia-l and wikitech-l. ;) Magnus's code was also tested on meta.wikipedia.com (remember .com?) as I recall, before we upgraded English Wikipedia itself.

Do you think having one person do a major rewrite on their own was necessary or would have incremental refactoring have been better?

I think of Lee's rewrite as a huge one-person refactor from Magnus's early prototype. It changed a lot but had recognizably similar bones.

Ever since then we've been on the incremental refactoring track, with big internal changes being managed much more carefully.

Some of the other technology decisions like MySQL, Apache, memcached, and on have held up over time and are still actively in use today. Why do you think that is? What was the thought process when selecting those in the beginning?

These are tools that we adopted because they were tried and tested in the wild, and some of those have indeed stuck around while others have changed a bit. For instance I think we now use a mix of several web servers as well as Apache to implement the caching and TLS proxies, memcached is supplemented with redis, etc. But they've kept common protocols because they're tools that are so widely used that specialized high-performance versions that are compatible with the original exist.

And that's pretty cool!

Before you left for StatusNet, would you have considered yourself the BDFL of MediaWiki?

I'd say me and Tim Starling were kind of the dream team dual-BDFLs. :) I took a more hands-off role since I left for StatusNet and came back.

My feeling is that today neither you nor Tim (the other BDFL candidate) want that role - is that accurate? Why not? Do you view BDFLs as a good leadership model for a project like MediaWiki?

I think the BDFL role, and hero worship and cult-of-personality in general, are bad. I think communities of mutually respectful people, both developers and users, researchers and managers, editors and educators, should work together to manage their projects fairly.

Wikipedia or Wikimedia? Why?

Wikipedia has the name recognition. :)

For a piece of software named MediaWiki, it really doesn't do a great job of handling media. This is something you've worked on a ton, from ogv.js to maintaining TimedMediaHandler. Why is this an area of interest for you? Can you give a summary of your efforts? What do you think is the next area to explore for improving media?

Indeed, beyond handling image uploads we're not that great at media. ;)

I would love for us to do more work in general in this area, from audio to video to 3d models to interactive graphs and maps and diagrams of all kinds. We have some of these things, but none of them are resourced for additional by Wikimedia Foundation except for whatever research or side time interested parties like me put in.

I do hope something makes it in the budget for 2021-2022!

The main improvements I've been working on with TimedMediaHandler are:

finish removing the old jQueryUI-based Kaltura-built frontend
finish fixing bugs in the new VideoJS-based frontend, which loads less JS and has fewer modules -> thus performance benefits on first load
cleanup on the ogv.js shim which lets us play WebM and Ogg files directly in Safari -> combined with the above, this'll mostly fix video playback on iPhone

The ogv.js layer itself is one of my proudest projects, but one that's designed to become obsolete -- eventually either Safari will adopt a format we're willing to encode, or we'll adopt a format Safari can play. ;)

Future plans that I can't guarantee time for include modernizing the subtitle editor and integrating trim controls into the VisualEditor media selection. But I hope to get to them too...

Was "Contingency plans" something you were involved in? What was it like planning for a hurricane?

I think others worked on that particular list, but it was certainly something we thought about.

We only really had one or two hurricanes that directly threatened Tampa and didn't have any outages, but it really wasn't the best place for servers. :) It just happened to be near where Jimmy lived at the time, so was convenient for him to help load up the earliest servers. ;)

Are there any outage stories, or near outage stories that stick out to you as particularly funny/sad/interesting/memorable?

I think it was around Christmas 2003? We had just set up our new 64-bit database server, and had I think two or three other machines as web servers. This would've been at the Tampa data center, so all remote from where I was at the time in southern California.

Load kept going up on the db server... we weren't sure why, but it seemed to be a hardware failure... eventually it just choked up. We had to switch back to the replica on one of the lower-end boxes. We had partial service during the crash and switchover by using the file cache (is that feature still even there?) to serve out cached pages without hitting the DB.

The secondary machine had trouble too, and died a couple days later, making it a double outage.

On the plus side, this gave us lots of opportunity to push our donation link in error pages! ;)

https://en.wikipedia.org/wiki/Wikipedia:Milestones_2003#December_2003

What MediaWiki feature did you work on that you're most proud of and why?

Special:Export and the XML dump format. It's not pretty, but it gets the job done and helps tons of people build tools on top of it!

Who is someone from the early days of Wikipedia who doesn't get enough credit for their contributions?

Lee Daniel Crocker. Lee and I don't get along on some issues so we don't talk on Facebook anymore, but I learned a lot about programming from him and the work he put in in the early days of what became MediaWiki. And that's something I'll always appreciate.

A lot of old Wikipedia and foundation work and history is in the archives of lists.wikimedia.org. But today (public) mailing lists are mostly used for announcements and discussions (at least on wikitech-l, wikimedia-l and other top lists)...do you think the shift away from mailing lists makes sense?

I think it's not surprising, but I'm not sure I like it. Maybe it's just graybeard syndrome; it was easier to have an idea what's coming down the pipe "in the old days" but at the same time it was a smaller pipe, wasn't it? Maybe email vs phab vs gitlab vs discourse doesn't make a difference. Maybe it's just whether we can have thoughtful interactions and also steer the right people to the right discussions?

You quietly stepped down from TechCom last year - why?

Quite simply, the last couple years have been really rough on my mental health. I don't have the bandwidth or the ability to consistently concentrate on the many ongoing issues I'd need to keep up with TechCom work. While I work on that, I'm concentrating on less directed research projects and underresourced things like TimedMediaHandler that don't have strict deadlines.

Wikipedia is unique in that it allows users to contribute JS/CSS directly to the site rather than requiring browserside user scripts (Greasemonkey, etc.). Do you think that was a good idea at the time? Now? I know you've also worked on exploring how to sandbox these, can you talk a little bit about that?

a) I think it's SUPER GREAT
b) I think WE DID IT SO WRONG

;)

There are two problems with letting people run direct JS in the host app environment:

if they run someone else's malicious code it can take over their account
code may use internal data accessors and methods that aren't going to stay stable, potentially breaking over time

Both can be solved by using a sandboxed environment (probably a suitable iframe). I think there's a lot of cool stuff that can be built on top of this method, with full-on APIs for accessing an editor state as a plugin, or whatever.

So far I get a lot of "yes that sounds great" but not a lot of "yes I'll assign a PM and 2 engineers to it", so this remains on my research backlog. ;)

Why is VIBBER in all caps in your username?

It is a common convention in some language communities, including Esperanto speakers, to all-caps the family name to indicate which name portion is the family name and which is the personal name. I got into Wikipedia through discovering the Esperanto edition, so that's where I created my first user name according to the local convention!

If you could, what language would you rewrite MediaWiki in and why is it Rust?

There's so many good options. ;) Honestly for its primary market (running Wikipedia) PHP scales in the right ways and has an ok combination of easy to use and handles complex paradigms you need in your big program.

Rust would be great for a micro-wiki, which runs as a small executable as a peer-to-peer service or some crazy thing. ;)

Wikipedia’s 25th birthday proves the power of free speech

2026-01-15T17:00:00+00:00

Originally published on freedom.press

In the mid-1700s, Denis Diderot published his Encyclopédie in France, collecting the work of more than 140 authors to summarize the Enlightenment. It quickly landed on the Catholic Church's banned books list for including contrarian thoughts, and, at one point, his publisher preemptively censored some content without Diderot's knowledge.

Around the same time, King George III censored the first edition of Encyclopaedia Britannica, requiring the removal of some anatomically correct drawings in an article about midwifery.

So when the 13 newly independent American states ratified the First Amendment a few decades later, it laid the groundwork not only for a free press but also for an encyclopedia that was not censored by an oppressive government.

Today, we celebrate the realization of that dream in the form of Wikipedia, which over the past 25 years has been collaboratively built by unpaid strangers on the internet. Wikipedia went from the source that teachers universally clamored "you can't trust it" to one of the most reliable sources in a world of "disinformation" and AI-generated slop.

Despite not being written by professional journalists (I edit it myself as a volunteer and used to work for its nonprofit host, Wikimedia Foundation), it's still able to set trends and drive narratives. For example, in 2011, Wikipedia editors started collating a list of people killed by law enforcement in the U.S., three years before The Washington Post would win a Pulitzer for its version of the same.

And for better or worse, Wikipedia is most likely the largest single source powering today's AI models. All in all, it's the largest repository of knowledge in human history.

But it's important to understand and appreciate that Wikipedia only exists because of the robust free speech and free press protections that exist in the United States.

Wikipedia has never been actively censored in the U.S., nor has any U.S.-based editor ever been arrested for their edits to Wikipedia. There's never even been a serious threat of censorship of Wikipedia by the federal government. (The FBI once demanded Wikipedia stop using its seal under a law written to stop impersonation of federal agents; Wikipedia's legal team laughed it off.)

The same cannot be said about Wikipedia in other countries. In France, intelligence operatives held a Wikipedia administrator until he deleted an article about a military radio station, under the guise it contained classified information. Agents made this demand even though the information in question wasn't classified at all and was mostly based on a documentary that the French air force had worked on and publicly released.

In India, a court required Wikipedia to remove an article about a news agency because it was supposedly defamatory. To top it off, the court then demanded Wikipedia remove the separate article that was written about the court case and removal order!

This kind of censorship shouldn't happen in the U.S. The Supreme Court ruled the First Amendment protects publishing classified information in a case about the Pentagon Papers. A U.S. court cannot order an article to be taken down, as that would be an unconstitutional prior restraint.

In the U.S., the law known as Section 230 would also protect Wikipedia from defamation claims, and instead require litigants to sue the editor who actually wrote and published the allegedly defamatory content. Those editors would be protected under the First Amendment and the high court's New York Times v. Sullivan decision, which requires defamation claims from public officials — later expanded to public figures — to meet the much higher standard of actual malice to win (nearly every biography on Wikipedia is of a public figure, by policy).

And to state the obvious, the U.S. has never blocked all of Wikipedia, unlike China (since 2015), Myanmar (since 2021), or Turkey, which did so from 2017 until an appeal to the European Court of Human Rights forced that nation to unblock it in 2020. We know of one editor, Bassel Khartabil, who was executed for their online activity, and a few others who are incarcerated in Belarus and Saudi Arabia.

Certainly, there are plenty of people in power who wish they could censor or control Wikipedia. At first, it was through editing: In 2006, a number of Congressional staffers were caught whitewashing their bosses' biographies, and, in 2007, someone at the FBI tried to remove images from the Guantánamo Bay detention camp article.

Then, in 2013, Edward Snowden leaked that the National Security Agency was illegally spying on Wikipedia readers and editors, revealing that the U.S. had adopted the same playbook as China. Wikipedia responded by encrypting all connections using HTTPS a few years later, and (unsuccessfully) sued the NSA for First and Fourth amendment violations.

The attacks against Wikipedia are starting to ramp up once again; last year saw ethically compromised interim U.S. Attorney Ed Martin and Sen. Ted Cruz complain about Wikipedia's supposed left-wing bias, despite the First Amendment prohibiting the government from acting as speech police. We've also seen bits of the First Amendment firewall begin to crumble, with judges green-lighting prior restraints, or bipartisan groups of lawmakers working to repeal Section 230.

It will require a concerted effort by all of us to not just maintain existing First Amendment protections, but to expand them. That's the only way Wikipedia will thrive for another 25 years.

My 2024 Wikipedia editing

2025-01-24T03:08:00+00:00

I racked up 526 edits and created 8 new articles on the English Wikipedia over the past year. 2024 was a relatively quiet year for my editing (in 2023 I had 1,137 edits). I really tried to take the Marie Kondo aproach to it: I only edited if it sparked joy.

The eight article creations, plus one split, in chronological order:

While watching Michigan win the 2023 National Championship, I saw Bill Hancock appear on TV, so I created his article. (Easy guideline: if someone appears on a nationally televised sports broadcast, they're probably notable.)
I ressurrected the article on Project Maven, the Pentagon's project to use AI, etc. that multiple Google employees had walked out over back in 2018. I didn't write the text myself, I took it from the existing article on the Artificial intelligence arms race.
Created Wedding of Anant Ambani and Radhika Merchant, because it was basically on par with British royal weddings. (And then successfully defended it from deletion.)
Learned about Jeep ducking, which of course led to writing a Wikipedia article and obtaining an accompanying photo.
We went to the Montauk Point Lighthouse, which has a nice museum about itself and found there was a whole room dedicated to Giorgina Reid and no article for her.
I submitted this article to be featured on the main page's "did you know" section, to which it received rave reviews from my fellow editors.
Unfortunately I learned about Jack Limpert when he died. He's credited with shaping the "city magazine" format (another missing article I researched but still haven't written yet), but really I was more impressed that he succesfully figured out Deep Throat's identity as Mark Felt back in 1974.
There aren't very many dogs notable enough for articles, but Ben Herbstreit was one; I had known about him for a year now, but only realized he was notable after he died.
The tribute ESPN put together is one of the saddest videos you'll ever watch.
I saw a tweet claiming that China's 12345 hotline was a fantastic government service. I couldn't find any non-state media sources to back it up, but it was notable, similar to the US and Canada's 3-1-1.
Tanking is easily one of the worst parts about professional sports, so I was pretty excited when the PWHL adopted the Gold Plan.

Article writing#

I try to write about subjects I don't already know a bunch about. Doing so helps less of my personal bias and opinions slip in and helps reinforce Wikipedia being an amateur project. I'm far more likely to do a better job at solely summarizing what sources say if that's literally all I know about a subject.

Once I've found a subject, itt usually takes me around two to three hours to write an article from scratch. Most of the time is spent searching for and reading sources and then ~30 minutes to write it all up.

This may seem counterintuitive, but I try to ensure that all the articles I create are incomplete. I don't add infoboxes, categories, WikiProject banners, etc. I'll often leave links to sources that are useful but that I didn't include on the talk page, with editorial suggestions.

I think it's important that there are always easy ways for people to get involved with editing, and leaving "basic" elements of an article out provides an easy pathway. Along the same vein, I'll proofread the article once before saving, but if I spot a minor error afterwards (like, a grammar or spelling error, not a factual mistake), I'll just leave it.

For every new article I created this year, I wrote a short Mastodon post with a link (example), which did a decent job at getting my followers to improve them :)

I've primarily been helping out as an administrator at the Redirects for discussion process, which is perenially backlogged. I find it incredibly interesting because most of the subjects tend to be rather niche, with people trying to assess whether a redirect is useful for navigation or not, in addition to plenty of other factors.

Some fun examples: Bīn, Tighten, Asplode.

gerrit-grr 5.0

2024-08-19T00:00:00+00:00

I recently released 5.0.0 of my grr tool that makes working with Gerrit easier. It is an alternative to git-review; I personally think grr is more straightforward to use, but I also haven't used git-review since 2014 when I first got frustrated enough to create grr.

I had let it bitrot since I wasn't doing as much code review and it seemed like Wikimedia was going to move away from Gerrit but both of those have changed now!

There's no user-facing changes, it was just a lot of internal refactoring that required breaking API changes, and then removing that API entirely because it was blocking further refactoring. Rewriting grr in Rust was one of my first Rust projects and the code really showed that. It's now cleaned up and I also dropped all the dependencies that linked to C code (OpenSSL/libgit2) to make builds easier and more portable.

Fundamentally, grr is a small wrapper around Gerrit's native functionality. I don't think it's widely known that submitting a patch to Gerrit is as straightforward as git push origin HEAD:refs/for/<branch>. And if you want to set a custom topic, you can append %topic=<...>.

So that's exactly what grr executes; but much shorter. To submit a patch just run: grr. (If you need to push to the non-primary branch, use grr <branch>.) And to pull down a patch for review, run grr fetch <id>. There's some more commands documented in the README.

Going back to the %topic= example, grr provides a --topic <...> option that turns into that. If you want to immediately set a Code-Review +2 vote when uploading (e.g. to automatically trigger CI to merge), you can provide --code-review=+2 (turns into %l=Code-Review+2).

To install, run cargo install --locked gerrit-grr. Pre-built binaries and an OCI image are also available.

Building a less terrible URL shortener

2024-07-23T05:33:14+00:00

The demise of goo.gl is a good opportunity to write about how we built a less terrible URL shortener for Wikimedia projects: w.wiki. (I actually started writing this blog post in 2016 and never got back to it, oops.)

URL shorteners are generally a bad idea for a few main reasons:

They obfuscate the actual link destination, making it harder to figure out where a link will take you.
If they disappear or are shut down, the link is broken, even if the destination is fully functional.
They often collect extra tracking/analytics information.

But there are also legitimate reasons to want to shorten a URL, including use in printed media where it's easier for people to type a shorter URL. Or circumstances where there are restrictive character limits like tweets and IRC topics. The latter often affects non-ASCII languages even more when limits are measured in bytes instead of Unicode characters.

At the end of the day, there was still considerable demand for a URL shortener, so we figured we could provide one that was well, less terrible. Following a RfC, we adopted Tim's proposal, and a plan to avoid the aforementioned flaws:

Limit shortening to Wikimedia-controlled domains, so you have a general sense of where you'd end up. (Other generic URL shorteners are banned on Wikimedia sites because they bypass our domain-based spam blocking.)
Proactively provide dumps as a guarantee that if the service ever disappeared, people could still map URLs to their targets. You can find them on dumps.wikimedia.org and they're mirrored to the Internet Archive.
Intentionally avoid any extra tracking and metrics collection. It is still included in Wikimedia's general webrequest logs, but there is no dedicated, extra tracking for short URLs besides what every request gets.

Anyone can create short URLs for any approved domain, subject to some rate limits and anti-abuse mechanisms via a special page or the API.

All of this is open source and usable by any MediaWiki wiki by installing the UrlShortener extension. (Since this launched, additional functionality was added to use multiple character sets and generate QR codes.)

The dumps are nice for other purposes too, I use them to provide basic statistics on how many URLs have been shortened.

I still tend to have a mildly negative opinion about people using our URL shortner, but hey, it could be worse, at least they're not using goo.gl.

Making it easier for Toolforge tools to surface replag

2024-07-12T04:34:04+00:00

A number of tools hosted on Toolforge rely on the replicated MediaWiki databases, dubbed "Wiki Replicas".

Every so often these servers have replication lag, which affects the data returned as well as the performance of the queries. And when this happens, users get confused and start reporting bugs that aren't solvable.

This actually used to be way worse during the Toolserver era (sometimes replag would be on the scale of months!), and users were well educated to the potential problems. Most tools would display a banner if there was lag and there were even bots that would update an on-wiki template every hour.

A lot of these practices have been lost since the move to Toolforge since replag has been basically zero the whole time. Now that more database maintenance is happening (yay), replag is happening slightly more often.

So to make it easier for tool authors to display replag status to users with a minimal amount of effort, I've developed a new tool: replag-embed.toolforge.org

It provides an iframe that automatically displays a small banner if there's more than 30 seconds of lag and nothing otherwise.

As an example, as I write this, the current replag for commons.wikimedia.org looks like:

The replica database (s4) is currently lagged by 1762.9987 seconds (00:29:22), you may see outdated results or slowness. See the replag tool for more details.

Of course, you can use CSS to style it differently if you'd like.

I've integrated this into my Wiki streaks tool, where the banner appears/disappears depending on what wiki you select and whether it's lagged. The actual code required to do this was pretty simple.

replag-embed is written in Rust of course, (source code) and leverages in-memory caching to quickly serve responses.

Currently I'd consider this tool to be beta quality - I think it is promising and ready for other people to give it a try, but know there are probably some kinks that need to be worked out.

The Phabricator task tracking this work is T321640; comments there would be appreciated if you try it out.

#wikimedia-rust Matrix to IRC bridge is back

2024-06-19T20:11:08+00:00

tl;dr: You can now chat in #wikimedia-rust:matrix.org and reach folks on IRC

Nearly a year ago, the official Libera.Chat <-> Matrix bridge was shut down. There's a lot that went wrong in the technical and social operation of the bridge that the Libera.Chat staff have helpfully documented, but from a community management perspective the bridge, when it worked, was fantastic.

But, we now have a bridge back in place! Bridgebot is a deployment of matterbridge, which is primarily used in Wikimedia spaces for bridging IRC and Telegram, but it also speaks Matrix reasonably well.

Thanks to Bryan Davis for starting/maintaining the bridgebot project and Lucas Werkmeister for deploying the change; we now have a bot that relays comments between IRC and Matrix.

12:12:50 <wm-bb> [matrix] <legoktm> ooh, I think the Matrix bridging is working now
12:12:58 <legoktm> o/

And if you look at the view.matrix.org logs, those messages are there too.

So if you're interested in or working on Wikimedia-related things that are in Rust, please join us, in either IRC or Matrix or both :)

"Skip Mobile Wikipedia" add-on available on Android (again)

2023-12-27T05:42:30+00:00

In 2018 I announced the creation of my "Skip Mobile Wikipedia" Firefox add-on, which automatically redirects you to the desktop version of the site. At the time it worked on both standard desktop Firefox and in Firefox for Android, life was great.

Unfortunately at some point, Firefox stopped allowing arbitrary add-ons on Android and it was disabled. It was still usable in the "Nightly" edition, but that wasn't very user friendly.

Anyways, fast-forward to earlier this month, Firefox has re-enabled general add-on support, so "Skip Mobile Wikipedia" is installable and works again on Android. The source code is the same, I haven't had any need to update it since 2020.

I personally use the responsive Timeless skin, which I think provides a nicer viewing and editing experience from my phone. Happy browsing!

2023 Wikimedia Hackathon recap

2023-05-31T23:59:59+00:00

I had a wonderful time at the 2023 Wikimedia Hackthon in Athens, Greece, earlier this month. The best part was easily seeing old friends that I haven't met in person since probably 2018 and getting to hack and chat together. I also met a ton of new friends for the first time, even though we've been working together for multiple years at this point! I very much enjoy the remote, distributed nature of working in Wikimedia Tech, but it's also really nice to meet people in person.

This post is very scattered because that was my experience at the hackathon itself, just constantly running around, bumping into people.

I wrote that I wanted to work on: "mwbot-rs and Rust things, technical governance (open to nerd sniping)". I definitely did my fair share of Rust evangelism and had good discussions regarding technical governance (more on that another time). And some Mastodon evangelism and a bunch of sticker trading.

But before I got into hacking things, I tabulated and published the results of the 2022 Commons Picture of the Year contest, which I think turned out pretty well this year. Of course, the list of things to improve for next year keeps getting longer and longer (again, more on that in a future post).

At some point during conversation, I/we realized that the GWToolset extension was still deployed on Wikimedia Commons despite being, well, basically dead. It hadn't been used in over a year and last rites were administered back in November (literally, you have to look at the photos).

With a thumbs-up from extension-undeploying expert Zabe (and others), I undeployed it! There was a "fun" moment when the venue WiFi dropped so the scap output froze on my terminal, but I knew it sucessfully went through a few minutes later because of the IRC notification, phew. Anyways, RIP, end of an era.

And then Taavi deployed the RealMe extension, which allows wiki users to verify their Mastodon accounts and vice versa. But we went for dinner immediately after so Taavi wasn't even the first one to announce it, Raymond beat him to it! :-)

I spent a while rebasing a patch to bring EventStreams output to parity with the IRC feed that was first posted in April 2020 and got it merged (you're welcome Faidon ;)).

One of the last things I did before leaving was an interview about MediaWiki in the context of spinning up a new MediaWiki platform team (guess which one I am). At one point the question was "What is the single biggest pain point of working in MediaWiki?" Me: "can I have two?"

Reviewed a bunch of stuff:

Add Authorization to default $wgAllowedCorsHeaders - this is something 0xDeadbeef had asked for. Reedy, sitting next to us, verbally approved the security aspect, but since I had already packed away my laptop, I tried to +2 it from Lucas's only to discover he didn't have +2 on his volunteer account. Hence T337014. (And then I +2'd it later and Reedy did backports)
Define merge strategy for ContactConfig as array_plus_2d - me, crying about merge strategies again
Prepare CheckUser pagers for event table migration, Ensure last timestamp is shown when no matches found for an IP - it's nice sitting next to people because I can watch them demonstrate it working on their laptop instead of having to set it all up on mine :)
Add config to control default collapse state of CheckUserHelper - had a good discussion about avoiding (IMO) unnecessary config settings, and then I merged it :p
language: Annotate list() methods as preserving taintedness
Add 'preloadcontent' and 'editintro' in API prop=info - again, nice to sit next to people who have all the test cases ready to go

Probably the most important patch I wrote at the hackathon was to add MaxSem, Amir (Ladsgroup), TheDJ and Petr Pchelko to the primary MediaWiki authors list on Special:Version. <3

Despite having a bunch of wonderful people being there, it was also very apparent who wasn't there. We need more regional hackathons and after a bit of reassurance from Siebrand and Maarten, it became clear that we have enough Wikimedia Tech folks in New York City already, so uh, stay tuned for details about some future NYC-based hackathon and let me know if you're interested in helping!

Final thanks to the Wikimedia Foundation for giving me a scholarship to attend. I really can't wait until the next time I get to see everyone again.

Six months of Wikis World

2023-04-13T03:14:27+00:00

I did a lot of new, crazy things in 2022, but by far, the most unplanned and unexpected was running a social media server for my friends.

Somehow it has been six months since Taavi and I launched Wikis World, dubbed "a Mastodon server for wiki enthusiasts".

Given that milestone, it's time for me to come clean: I do not like microblogging. I don't like tweets nor toots nor most forms of character-limited posting. I'm a print journalist by training and mentality (there's a reason this blog has justified text!); I'd so much rather read your long-form blog posts and newsletters. I want all the nuance and detail that people leave out when microblogging.

But this seems to be the best option to beat corporate social media, so here I am, co-running a microblogging server. Not to mention that I'm attempting to co-run accounts for two projects I've basically dedicated the past decade of my life to: @MediaWiki and @Wikipedia.

Anyways, here are some assorted thoughts about running a Mastodon server.

Content moderation#

I feel like I have a good amount of "content moderation" experience from being a Wikipedia administrator and my conclusion is that I don't like it (what a trend, I promise there are actually things I like about this) and more importantly, I'm not very good at it. For the first few months I read literally every post on the Wikis World local timeline, analyzing to see whether it was okay or problematic. This was, unsurprisingly, incredibly unhealthy for me and once I realized how unhappy I was, I stopped doing it.

Especially once we added Lucas and now AntiComposite as additional moderators, I feel a lot more comfortable skimming the local timeline with the intent of actually seeing what people are posting, not pure moderation.

This is not to eschew proactive moderation (which is still important!), just that my approach was not working for me, and honestly, our members have demonstrated that they don't really need it. Which brings me to...

I've said in a few places that I wanted Wikis World to grow organically. I never really defined what un-organically was, but my rough idea was that we would build a community around/through Wikis World instead of just importing one from elsewhere. I don't think that ended up happening, but it was a bad goal and was never going to happen. We have slightly under 100 accounts, but it's not like all of us are talking to and with each other. Instead, I feel like I'm in a circle of ~5-15 people, largely Wikimedians active in tech areas, who regularly interact with each other, and half of those people host their account elsewhere. Plus the common thread bringing everyone together is wikis, which is already an existing community!

So far I'm pretty happy with how Wikis World has grown. I have a few ideas on how to reduce signup friction and automatically hand out invites, hopefully in the next few months.

It is incredibly empowering to exist in a social media space that is defined on my own terms (well, mostly). We are one of the few servers that defaults to a free Creative Commons license (hopefully not the only server). We have a culture that promotes free and open content over proprietary stuff. And when I encourage people to join the Fediverse, I know I'm bringing them to a space that respects them as individual human beings and won't deploy unethical dark patterns against them.

To me, that makes it all worth it. The fact that I'm also able to provide a service for my friends and other wiki folks is really just a bonus. Here's to six more months of Wikis World! :-)