User talk:SMcCandlish

1, 2, 3, 4, 5, 6, 7, 8, 9

Mini-toolbox

The Phabricator Workboard for Tech News
MW Editing team e-meetings, via Google Hangouts (Tuesdays, noon–12:30pm PDT = 20:00 UTC during DST, 19:00 otherwise, but often half an hour earlier).
MW Tech Advice e-meetings, via IRC at #wikimedia-tech^connect (Wednesdays, 1–2pm PDT = 16:00–17:00 UTC).

Wrong balance at Community Wishlist Survey

Latest comment: 4 years ago4 comments2 people in discussion

Under one item of our wishlist you write “Community Wishlist Survey is rather broken, in accepting only what has the most votes this year, which is never, ever going to be stuff template editors need.” That is a valid point that deserves wider attention. How would you suggest this to be fixed? One fix I can see would be to put effort and effect in proportion. A wishlist without any regard for cost will tend to favor the most expensive items, regardless of how many useful items can be had at the same price. ◅ SebastianHelm (talk) 13:45, 16 December 2020 (UTC)Reply

@SebastianHelm: Yes, there's definitely that effect.

That one's challenging to address, since assumptions about difficulty of implementing something are often – maybe even usually? – wrong (just ask any software engineer, especially one tasked with changing existing features or adding new ones to an existing product mostly written by other people). I'm reminded of the voter guide I get in the mail; there's a dedicated legislative analysis office that comes up with estimated costs and complications of implementing various ballot measures. WMF having someone[s] on staff doing this for CWS proposals and Phab requests in general might help, but it might be easy to be wrong and get fired/sacked. >;-)
The no. 1 thing to me is true prioritization. Mission-critical things, e.g., accessibility solutions, HTML (and other) standards-compliance fixes, security improvements, and other key proposals which meet with support should take precedence over all attempts to add new features or "polish the chrome" on things that already are properly functional. Secondarily, improvements to existing features people definitely use (wishlist, search, editing tools) should generally have higher priority (among accepted proposals) than requests for all-new features.
- This, to me, is where the process (not just CWS, but WMF's MW development in general) has failed the worst. It's also deeply entwined in why I resigned as a WMF Tech Ambassador to en.WP; the short version of my statement on my user page about this is: WMF is acting like a software company with a customer base and a marketing plan (what it wants customers to go for), instead of behaving as a globally important NGO with a constituency and a mission to serve the actual needs of that constituency. Some of the standards compliance things have been open tickets for 15+ years, across multiple bug-tracker systems, and some attempts to "fix" them have simply introduced more compliance problems, cutting off our nose to spite our face. There's a competence problem of some kind happening somewhere, even if most of the devs are amazing. But whoever thought it was good idea to have : equate to ‎<dd> and render visually as an indent, and do this in absence of a proper ‎<dl> list structure was foolish. Of course it would get abused for purely visual indentation not d-list construction, especially if no alternative was provided to do indentation properly. But it was an even worse idea (one I just now learned about, in the mobile skin) to replace that abuse of ‎<dd> with abuse of ‎<blockquote>, which is strictly reserved for actual quotations. The ‎<div> generic element exists for a reason, and is super-mega-obviously the one to use here (though on talk pages the HTML 5 element ‎<article> might be a better choice, especially with smart id stuff for thread building; this can probably just be ripped wholesale from any good blog, forum, or other CMS that is open-source.
- No one who is unwilling to totally absorb the HTML and CSS specs has any business working on HTML and CSS code (including code that generates that code) at a professional level. I don't mean fire/sack anyone, just move them to something they're actually competent at, and put experts on the tasks the non-experts have been screwing up. Seriously, the kind of screwups involved are things that would not have been tolerated at a regular meritocracy-driven open source project; they would have been fixed years ago, and a bad mistake, like moving from abuse of one element to abuse of another instead of use of the proper one, would likely never have happened.
- A conceptually similar issue (which I raised with a WMF person at w:en:WP:VPTECH, I think, within the last month) is WMF's internal hostility to VPNs, and inability to distinguish them from other kinds of services, nor to recognize the value they provide for security in an increasingly mobile but increasingly vulnerable computing and communications environment. The current practice of just blacklisting almost every block of IP addresses that happen to resolve to machines that provide VPN out-node services (generally blacklisted because of other services they provide) is downright stupid. It betrays a sort of "stuck in 2004" ignorance about how the technology works. Not just the necessity of VPNs these days, but the simple fact that any given IP address is apt to resolve to multiple [virtual] servers, even by multiple entities, and any given "server" is apt to have multiple sometimes unrelated IP addresses, all due to cloud computing, and software/servers-as-a-service models. It's rather like trying to block travel from Massachusetts because you heard about a bank robber who was born in Massachusetts, and also block entry to banks while you're at it, because anyone going into one might be a robber. This is not how to address sockpuppetry and other abuse problems, anymore than just massacring the entire populations of Nigeria and India is how to address the problem of online scams often coming from or passing through Nigeria and India.
CWS proposals that pertain primarily to WMF projects should get pretty much all priority; stuff that's extraneous to that (e.g. features for bending MW into a blogging platform) should be left to third-party development, other than any necessary hooks for that development. And even then only if both WMF and the overall community think spending any time at all on that hook is worthwhile. Just because someone can conceive of a way to torque MW into being something it was not supposed to be doesn't make it a good idea.
But there also need to be more CWS categories, or subcategories, that independently rank proposals within them. The current ones are mostly too sweeping, and net together many unrelated things (plus they become so long they are difficult to get through).
- E.g., almost all requests for template/module tools are stuffed under "Editing", which is not at all what most people are thinking about for that category (they're thinking of public-facing content, the form we used for creating it, and the tools that operate on the content in that form, like add markup with a button press, etc.).
- It even needs to split between source-mode editing and VisualEditor. Some of the proposals this year are VE-only, but are not labeled as such, and end up being confusing.
Then there's the issue of the same proposals being made for 5 or 10 years in a row and always being supported but never implemented. Support assessment needs to be cumulative (within reason; some of the proposals mutate a little over time, but the entire WMF community is good at assessing shifting consensus over time, so this is not much of a challenge).
Not-quite-relatedly, there are often also essentially duplicate proposals (I saw at least three this year: one pair already identified as such by someone; one pair flagged as such by me, though I only did that one way; and one pair unmarked because I was exhausted by the end and couldn't be bothered). Just as en.Wikipedia's Arbitration Committee (and several other processes, have clerks), someone should be tasked with clerking this stuff and merging proposals that are too similar (just present the options as variants, and if the proposal in general passes, the exact version to implement can be another discussion for another time, if that's not already clear from the CWS comments). I think there actually is some clerking going on already, since I have seen translation and other work get done. Maybe whoever's doing it needs an assistant.
One other thing: this survey is so daunting it is very difficult to actually get through it all. It might be more practical to stagger it, e.g. put out the Editing section one month and the Search section another month, and so on, so one does not have to spend literally an entire waking day to wade through it all.
We're getting too little input from too few editors. In part this is because of the issue in the bullet above this, but in part it's due to lack of local-project awareness and engagement. One radical change in approach could be for projects to host their own wishlists, or have RfCs for items to add, and then forward this on the bigger, cross-project process. There are numerous ways this could be reshaped, and each would present its own strengths and weaknesses.
Some of it could also be more top-down. The devs will have ideas about what really needs to get done, what is nearing completion and pretty easy to do, what is virtually impossible, and some other matters, like what WMF's executive team and/or board are hoping for (which the community often doesn't know anything about in detail until too late) and solicit feedback more directly.
Frankly, WMF needs to be willing to spend more money on getting stuff done. It has a lot of money, and isn't really spending enough of it on mission-critical things. I come from a "tech nonprofit" background (EFF and CRF), so I know very well what that problem looks like. A common version is over-spending on executive salaries and perqs (also for the board), like luxury furniture and first-class travel, at the expense of sufficient program staff (the average tech, communications, and other program staffer at such organizations is in dire need of at least one assistant, often a department, and the organization will not realize this until that over-worked and under-paid person burns out and leaves, and the org finds that person has to be replaced with 2 or 4 or 8 to get the same work done).

I could probably come up with more ideas and observations (see, e.g., w:en:User:SMcCandlish/Discretionary sanctions 2013–2018 review for an example of the kind of policy analysis I can do when I devote enough time to it, and even that's two years out of date and would cover several more more things than it does if I revised it significantly).
— SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< , 02:21, 17 December 2020 (UTC)Reply

Wow, I had no idea there was so much behind it – and you're hiding it in the comment to one wish! How best to tackle all of this? Does it even make sense to try and find a solution for one problem that only addresses a small shard of the whole?

Good point about the clerical tasks. I would see those as part of project management; why aren't WMF's PMs doing that?

You're right that the sheer amount of wishes is daunting. It may be a good idea to stagger it, but ultimately the workload stays the same. Not sure how to actually reduce the workload. Maybe similar to what we wrote in the wish for preferences: Mark everything for which a wish exists with a “🎁” symbol – in the UI and the manual – which links to the wish under discussion. So users will see wishes at the right moment and the right place, and only for those functionalities that they use or are interested enough to RTFM. I think this may also address the issue of getting input from too few editors. ◅ SebastianHelm (talk) 22:58, 17 December 2020 (UTC)Reply

This thread would probably have more impact at Talk:Community Wishlist Survey, so I've copied it over there. — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 04:14, 19 December 2020 (UTC)Reply

Democratic authoritarianism

Latest comment: 4 years ago2 comments2 people in discussion

Hello.
Your formulation of the concept at en:Wikipedia talk:There is no justice made you one of the most respected en.Wikipedians by me. BTW I am astonished that such criticism of the regime has been possible in mainstream essays as late as in 2016. Incnis Mrsi (talk) 08:17, 29 January 2021 (UTC)Reply

@Incnis Mrsi: Thanks, and I'm glad you liked it. :-) I worked most of that material into w:en:Wikipedia:Advice for hotheads, which covers several other things, including explosive behavior, false civility, and attempts to "argue Wikipedia into capitulation". I'll take the liberty of engaging in some coffee-fueled morning rambling:

As for essays, there's long been a lot of tolerance for conflicting viewpoints between various of them. We even have pairs of directly contradictory ones (or seemingly so, until you see that they address different kind of issues/incidents/questions). But ones that just do not at all align with the community's norms tend to get userspaced (or deleted at MfD if they're so off-kilter they have a NOTHERE vibe).

On the more philosophical "democratic authoritarianism" thing (not exactly the term I would use, but I see what you mean), and how it relates to an entity like WMF and a project like Wikipedia, I'm reminded of Twitter and Facebook kicking Trump and friends off their platforms (way later than they should have). They are privately owned companies with terms of use/service and a public to answer to. Various people in Trump's camp are claiming they are being "censored". They're making legally incorrect First Amendment arguments (the 1A only applies against censorship by the state, and doesn't let someone force their expression to be carried by private-sector third parties). WMF is in a similar boat. It isn't in a position to allow PoV pushers and other disruptive parties free reign, to allow defamatory material in articles on living people, and so on. WP is more like a newspaper or magazine publisher. PeTA and Greenpeace do not have a legal or "moral" right to force The Wall Street Journal to print their advocacy material, and the Family Research Council and the Eagle Forum can't require Huffington Post to given them equal "air time".

There are some grey areas, the common carriers. The gist is that various private or somewhat privatized entities have quasi-monopoly privileges, in exchange for infrastructure rollout, and liability shields for content they did not create, in exchange for not being permitted to monitor and censor. Some are arguing that social networking sites should be like this, should operate like package delivery services and telephone companies, as passive conduits for anything people want to send through them. I think this would be disastrous, since even with such sites trying to enforce ToU/ToS against against racist rabblerousing, black-market trading, insurrection and terrorism planning, etc., etc., the effect on our society of social media's propensity for creating borderless "reality bubbles" that inculcate us-vs.-them thinking, radicalization, and the spread and belief in patent falsehoods has just about ripped society apart over the last decade, and it's not looking to get better immediately if at all. If anything, non-state actors in the online information and communication space need to be more rather than less restrictive about what they'll permit on their systems, And that goes for far-left stuff too; the trans right activists making death threats against TERFs, or supposed antifa people agitating to burn down courthouses and cops' homes, should have their accounts nuked right along with anti-abortionists doxxing clinic workers in hopes they'll be tracked down and murdered, or white-nationalist "militia" nuts planning racist hate crimes.

The fundamental difference between a common carrier and a social networking site (in the broad sense, including webboards, collaborative content projects, etc.) is the public, memetic component. You can't recruit 10,000 people to join your telephone call or share in the goods inside a package you ordered from Amazon. There is no broad threat to society from having privacy and freedom of expression in one's phone calls and postal mail (even if certain crimes can be organized that way). There's obviously a big one inherent in using technology to create "permeably-walled-garden" propaganda and indoctrination farms, abusing private-sector services that were intended to make people's lives better and happier.

I have a lot of concerns about people system-gaming WP's "assume good faith" position through crafty "civil PoV-pushing" techniques to essentially bend WP articles to propagandistic purposes. It's already happening in a lot of topics, and it's hard to do much about it. All the pushers have to do is bait neutrality-minded editors into doing something explicitly uncivil, then get them banned from the topic area so the PoV pushers can just own it. This POVRAILROAD technique is precisely what was happening in the recent Flyer22 ArbCom case. The "AGF is not a suicide pact" maxim is going to have to be taken more seriously. WP is not longer a project eagerly accepting thousands of new editors per month from SlashDot and other nerdy forums to attempt the wacky idea of building a free encyclopedia. Eventualism essentially expired in the late 2000s at the latest. WP is a free encyclopedia, one of the most-read information sources in the world by the general public, and is under constant pressure to say non-neutral things on thousands of topics. We can still assume good faith, at first and for a while, but that has to stop with regard to a particular party when we see clear evidence to the contrary in their behavior. I should stop here or this will just get longer and longer. >;-)
— SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 14:00, 29 January 2021 (UTC)Reply

Tech News: 2025-43

Latest comment: 27 days ago1 comment1 person in discussion

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

To optimize how user data is stored in our databases, the saved preferences of users who haven't logged in for over five years and have fewer than 100 edits will be cleared. When those users return, default settings will apply. [1]
View all 20 community-submitted tasks that were resolved last week. For example, there was a broken link from the GlobalContributions interface message to the XTools GlobalContributions page which has now been fixed. [2]

Updates for technical contributors

The work to reroute all traffic to API endpoints under the rest.php route through a common API gateway is now complete. If any issues are observed, please file a phabricator ticket to the Service Ops team board.
Edits to Wikidata references or qualifiers will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. [3]
Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:36, 20 October 2025 (UTC)Reply

Tech News: 2025-44

Latest comment: 20 days ago1 comment1 person in discussion

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

The Wikipedia iOS app has launched an A/B/C test of improvements made to the tabbed browsing feature for select regions and languages. The test, named “More dynamic tabs”, explores new tab experiences and includes “Did you know” and “Because you read” article recommendations. You can read more on the project page.
Autoconfirmed users on small and medium wikis with the CampaignEvents extension can now use Event Registration without the Event Organizer right. This feature lets organizers enable registration, manage participants, and lets users register with one click instead of signing event pages.
View all 31 community-submitted tasks that were resolved last week. For example, the issue of flashing colors when holding or pressing the arrow keys under the dark mode settings in Vector 2022 has been fixed. [4]

Updates for technical contributors

The CampaignEvents extension will be deployed to all remaining wikis during the week of 17 November 2025. The extension currently includes three features: Event Registration, Collaboration List, and Invitation List. For this rollout, Invitation List will not be enabled on Wikifunctions and MediaWiki unless requested by those communities. Visit the deployment page to learn more.
The SwaggerUI-based REST sandbox experience is now live on all wiki projects. The sandbox can be accessed through the Special:RestSandbox page. Please report any issues to the MediaWiki Interfaces team board, or join the discussion on the project launch page. [5]
Transform endpoints with a trailing slash path in the MediaWiki REST API are now marked as deprecated. They will remain functional during this time, but removal is expected by the end of January 2026. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found and tested using the REST Sandbox. See the MediaWiki REST API Deprecation page for more detailed information about the API deprecation policies and procedures.
A dedicated changelog now exists for the MediaWiki REST API. The changelog provides an overview of these changes, making it easier for developers to keep track of improvements and iterations. Announcements will also continue to flow through the standard communication channels, including Tech News and email distribution lists, but can now be more easily referenced from a central location. If you have feedback about the style, structure, or content of this changelog, please join the discussion.
Administrators can delete the tracking category which was previously added by the JsonConfig extension, as it is no longer used. See the categories linked from Q130635582. It is OK if there are still pages listed in the category as that is just a caching issue, and they will be automatically cleared out the next time each page is edited. [6]
Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:32, 27 October 2025 (UTC)Reply

Tech News: 2025-45

Latest comment: 13 days ago1 comment1 person in discussion

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

Administrators will now find that Special:MergeHistory is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [7]
For users with "Automatically subscribe to topics" enabled in their preferences, starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "Add topic" or "Reply" widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [8]
Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [9]
Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments. [10]
Users with large watchlists have long faced timeouts when editing Special:EditWatchlist. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A community wish has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [11]
View all 31 community-submitted tasks that were resolved last week. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [12]

Updates for technical contributors

Since 2019 the Wikimedia URL Shortener at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as "Get shortened URL". There are 30 wikis that also install an older "ShortUrl" extension. The old extension will soon be removed. This means /s/ URLs will not be advertised under article titles via HTML class="title-shortlink". The /s/ URLs will keep working. [13]
On Thursday, October 30, the MediaWiki Interfaces and SRE Service Operations teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board.
MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [14]
Detailed code updates later this week: MediaWiki

In depth

In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in a Diff blog post.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:35, 3 November 2025 (UTC)Reply

Tech News: 2025-46

Latest comment: 6 days ago1 comment1 person in discussion

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

Example of a talk page with the new design, in French.

Starting November 12, users will see a change in the appearance of talk pages on some Wikipedias. Almost all wikis have received this design change; English Wikipedia will get these changes later. You can read more on Diff. Users can opt out of these changes in their user preferences in "Show discussion activity". [15]
MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request. [16]
Using the "Show preview" or "Show changes" buttons in the wikitext editor will now carry over certain URL parameters like 'useskin', 'uselang' and 'section'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content. [17][18][19]
Wikivoyage wikis can use colored map markers in the article text. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed. [20]
The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging. [21]
The Reader Growth team is launching an experiment called "Image browsing" to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis. [22]
View all 27 community-submitted tasks that were resolved last week. For example the inability to lock accounts on mobile sites has been fixed. [23]

Updates for technical contributors

Nominations are open on Wikitech for new Toolforge standards committee members. The committee oversees the Toolforge Right to fork policy and Abandoned tool policy among other duties. Nominations will remain open through 2025-11-28.
The JWT issuer field in OAuth 2 access tokens for SUL wikis has been changed to https://meta.wikimedia.org. Old access tokens will still work. [24]
The JWT subject field in OAuth 2 access tokens will soon change from <user id> to mw:<identity type>:<user id>, where <identity type> is typically CentralAuth: (for SUL wikis) or local:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the sessionJwt cookie more similar. Old access tokens will still work. [25]
MediaWiki's block messages (blockedtext, blockedtext-partial, autoblockedtext, systemblockedtext, blockedtext-tempuser, autoblockedtext-tempuser) now support additional parameters indicating whether the user is blocked from editing their own user talk page $9 or emailing other users $10. [26]
A REL1_45 branch for MediaWiki core and each of the extensions and skins in Wikimedia git has been created. This is the first step in the release process for MediaWiki 1.45.0, scheduled for late November 2025. If you are working on a critical bug fix or working on a new feature, you may need to take note of this change. [27]
The process for generating CirrusSearch dumps has been updated due to slowing performance. If you encounter any issues migrating to the replacement dumps, please contact the Search Platform Team for support. [28][29]
Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:38, 10 November 2025 (UTC)Reply