In T334940#9653579, @FeRDNYC wrote:

In T334940#9645371, @ChaseKiwi wrote:

this editor is of the view that a low overhead and secure graph option that allows an ordinary editor to update changing data by text entry is core functionality moving on that the Wikimedia Foundation could usefully prioritise.

I have to dissent on that characterization. It's one that's been thrown into this Phab ticket several times by various participants. "Graphs are core functionality". Well, sorry, no.

It's an Internet encyclopedia. The webservers are core functionality. The Wikitext parser is core functionality. Page editing, the content database, template transclusion, File (image) embedding, user account management... these are all core functionalities. Lose any one of them, continuing to operate Wikipedia in any meaningful fashion becomes an unsustainable and extremely short-term proposition until the missing piece is restored.

(Even Echo, which we've come to rely upon so heavily that my initial list included it, I have to admit isn't core functionality. We managed to make do with fully manual, template-based talk page notifications for a really long time, and we'd find a way to make do if we suddenly had to go back to that again. It'd suck really, really hard, but it wouldn't kill the project.)

Scribunto probably IS core functionality, today, because even though we got by without Modules for many, many years, so much of the original pure-Template infrastructure has undergone an extremely one-way conversion to Lua code that I don't see how we could survive without it anymore.

Graphs are a valuable feature. They're an important feature to a sizable portion of both the editor and reader communities. They are not core functionality. The fact that the encyclopedia is still intact — diminished, certainly... perhaps even handicapped... but undeniably intact — after many months without them, demonstrates that all by itself.

I work in a software company (as a technical writer, but it doesn't matter). If any of the teams in our company would have concentrated on dark mode instead of quickly fixing such a major bug in production, I'm definitely sure that team would have been immediately kicked out of the company.

In T334940#9597471, @aliu wrote:

Hmm. Without a given reason to decline, the reject isn't very convincing to me. The only reason against that I can see in that thread is an (unfounded?) distrust in intadmins being able to respond timely, and a pretty good concern about intadmins not necessarily knowing about graphs, which could be solved with making the small group template editors instead of intadmins.

In T334940#9537862, @Ahecht wrote:

For those not on the mailing list, the message from MMiller on February 6 was:

...

Yes, the situation in T130888 seems the same.
There is no other mechanism, apart from the watchlist, where one could observe all new files/pages that have been added to a watched category.

It seems that the reason is the "Latest revision" filter enabled. Without it, I see much more records.

Today I was notified about addition of a number of files. As I compare two files (one of the today's ones and one of the previous ones), I see the difference in the tool by which a photo was added. Maybe that's what makes the bug occur:

• Uploaded own work with UploadWizard - notified.
• Uploaded using Commons Mobile App - not notified.

In T315627#8188427, @kostajh wrote:

In T315627#8168382, @Aklapper wrote:

Fairly regularly we get people reporting errors about their watchlist not loading.

Incomplete list for the records: https://phabricator.wikimedia.org/maniphest/?ids=315603,309446,265347,95888,47380,68212,69123,41510#R

Server-side request: Create a ticket tagged with Wikimedia-maintenance-script-run and asking folks to run mwscript runBatchedQuery.php --wiki wikidatabasename "DELETE FROM watchlist WHERE wl_user = 9999999999 LIMIT 5000;" ?

If we go that route, a dedicated maintenance script might be less error-prone.

@Reedy , do you mean that the only way to edit my watchlist is directly from pages?

Another example when this could be useful:

In T265513#6548796, @Etonkovidova wrote:

Thanks, @Michgrig for reporting. I did some additional testing and the issue is present without "Live updates" turned on.

Hi guys,
The issue reproduces now exactly as it was from the beginning. For example, I do not see the addition of this file into this category, because the category was added at the moment of upload. Although, I see the addition of this file into this category, because the category was added later than upload.
Please revise the bug.

Have you tried to reproduce the issue by adding articles whose items are related to properties that were changed before you add? I'm not sure but it seems that doesn't work.
It seems that a property should be changed after you start watching an article.

I've just checked, nothing changed.
The first one displays Wikidata item labels in Wikipedia infoboxes, the second one is intended for fast Wikidata population with the information from Wikipedia infoboxes.

@Mbch331,
I have two Wikidata-related gadgets enabled

As a version:
Incorrectly displayed changes are done in properties while correctly displayed ones are done in items. Here are Wikidata edits that correspond to incorrectly displayed changes from my first screenshot: