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.

In T334940#9481766, @Chicocvenancio wrote:

@Ita140188 I'd like to strongly pushback on your comment. It is meaningless to say hundreds of people work at WMF implying therefore solutions should be quick if we don't analyse the magnitude of the work to keep the websites of the wikimedia projects working.

This is a security issue on an upstream project that won't be fixed upstream. It is not a trivial matter to have this fixed in safe and functional way.

I do think we have several technical areas without proper ownership, and graphs was one of them, but without a significant increase in people available and responsible for technical stewardship it is unlikely to be solved. I invite you to ponder if your comment is more or less likely to invite volunteers and professionals alike to join that group.

What is frustrating about this is that we do have a team of highly paid professionals, it's the hundreds of people working at WMF. They should solve this problem or at least be responsible for the hard part of defining requirements, creating a plan and coordinating stakeholders and volunteers. What I've seen until now is either a completely dysfunctional way of working, or zero interest in solving this problem. Both of which are quite problematic since this affects thousands of pages and (interactive) graphs should be a core functionality for Wikipedia.

I have the same problem

In T165864#3815102, @MusikAnimal wrote:

In T165864#3815090, @Ita140188 wrote:

I am sorry I opened a duplicate discussion, I am not familiar with Phabricator.

No need to apologize! :)

the current behavior is surely misleading (since the page exists!).

Indeed. The tool is about pages created by the given user, and only those pages. So basically we need to somehow convey that "the version of the page created by this user was deleted". Versions created by other users -- before or after -- are not accounted for. I'm thinking we could add a footnote or explanatory text above or below the table. Showing a current size of 0 certainly doesn't help... so like I said maybe we'll leave that blank.

Also in the case cited the page deletion was merely technical, as it was needed for a redirect, and not under AfD. I think there should be some sort of distinction between these cases.

Yeah, I agree the "deleted" tag may look like a negative thing, but in reality it's just reporting what happened. XTools (rightfully) has no knowledge of deletion criteria, which vary wiki to wiki, and even on English Wikipedia you can't count on the deletion summary being a standard one. Here's a thought -- maybe when you hover over the "deleted" text, a tooltip is shown with the deletion summary? That way anyone could easily find out why it was deleted. I don't want to introduce a new column for deletion summaries, since they can be very long and it would clutter the interface.

In T165864#3815083, @MusikAnimal wrote:

@Ita140188 This is actually expected behaviour. XTools shows any page that you created that was deleted, regardless of whether it was recreated (unless you recreated it). This is desirable for instance if an admin wanted to evaluate a user's eligibility for autopatrolled. If the user created a bunch of pages deleted under AfD, they'd want to know about it, even if someone else recreated it.

I agree putting 0 as the current size is misleading, though. In the database, live and deleted pages are (essentially) in two separate tables. This means it is not easy to see that you created a page that was deleted, and also get info on the live version of it that was created by someone else. We could instead remove the 0 and leave that cell blank, and also add a footnote or something that indicates the pages has been recreated by someone else. Would that help clear things up?