Page MenuHomePhabricator

Spike: Page Curation should create a new AfD discussion page if one already exists [8 hours]
Closed, ResolvedPublic

Description

As a Page Curation user, I want to see distinctly named AfD discussion pages (per each AfD discussion), so that I can easily find and track all AfD discussions.

Steps to reproduce

  1. Use Page Curation to nominate a new page for deletion (AfD).
  2. Repeat step #1.

Actual results

Page Curation adds the AfD text to the same page, even though it already exists.

Expected results

Page Curation should create a new AfD page, appending to the title (2nd nomination) or (3rd nomination), etc., based on what AfD pages already exist.

For instance, if "Foobar" is nominated for deletion, the page Wikipedia:Articles_for_deletion/Foobar is created. The next time it is nominated for deletion (say, the first AfD resulted in a "keep"), Page Curation should create Wikipedia:Articles_for_deletion/Foobar_(2nd_nomination).


Original report:

See Wikipedia:Articles for deletion/Queen Street Bus Terminal for example. The page Queen Street Bus Terminal was nominated by Atsme. If the first deletion discussion page already exists, page curation should add text to the appropriate discussion page instead (i.e. with "2nd nomination", "3rd nomination", etc. in parentheses suffixed to the end of the title) for consistency with Twinkle.

Event Timeline

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJul 1 2017, 6:22 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
GeoffreyT2000 updated the task description. (Show Details)Jul 1 2017, 6:28 PM
GeoffreyT2000 updated the task description. (Show Details)Jul 3 2017, 4:39 PM
Catrope renamed this task from Page curation adds text to first deletion discussion page if it already exists to Page curation should add text to first deletion discussion page if it already exists.Jul 11 2017, 6:11 PM
Catrope renamed this task from Page curation should add text to first deletion discussion page if it already exists to Page curation adds text to first deletion discussion page if it already exists.
Catrope added a subscriber: Catrope.

So are you saying you want it to create [[Wikipedia:Articles_for_deletion/Queen_Street_Bus_Terminal (2nd nomination)]] instead? I understand your description of what it currently does, but I don't understand precisely what you want it to do instead.

MusikAnimal added a comment.EditedJul 11 2017, 7:08 PM

So are you saying you want it to create [[Wikipedia:Articles_for_deletion/Queen_Street_Bus_Terminal (2nd nomination)]] instead? I understand your description of what it currently does, but I don't understand precisely what you want it to do instead.

Correct. Wikipedia:Articles for deletion/Queen Street Bus Terminal already existed so it should have created Wikipedia:Articles for deletion/Queen Street Bus Terminal (2nd nomination), and so forth.

Relevant Twinkle code that may be of help:
https://github.com/azatoth/twinkle/blob/master/modules/twinklexfd.js#L525-L541

If the deletion discussion is still open, though, it should ideally reuse it (that likely means someone vandalized the page and removed {{Article for deletion}}.

Xaosflux triaged this task as Normal priority.Dec 11 2017, 11:57 PM

Still a problem... to the point that it is never advisable to use Page curation to nominate for AfD. Pretty sure most patrollers use Twinkle instead after they realise this bug exists.

Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 26 2018, 4:51 AM

@Insertcleverphrasehere, @Compassionate727, @GeoffreyT2000 - The way that English Wikipedia handles this situation seems overly complicated. Ideally we want every action that PageTriage takes to be configurable on-wiki (See https://www.mediawiki.org/wiki/Extension:PageTriage#On-wiki_configuration). Setting up support for creating additional pages and adding disambiguation strings would likely necessitate breaking the config model and resorting to custom code for English Wikipedia. The more we write custom code for English Wikipedia, the less configurable PageTriage becomes and the less likely that it will ever become available for other language wikis. Is there any possibility that English Wikipedia would be willing to simplify the AfD process and just list new nominations on the same page? This would also have the advantage of allowing people to easily refer to previous debates and would also simplify the nomination process (which right now is kind of a pain when there are previous nominations). I know this would be a big change, but I really don't understand why the current process is so complicated.

I have started an RfC for @kaldari's proposal above at Wikipedia talk:Articles for deletion#RfC: Stop creating separate AfD pages for renominations. If that proposal passes, then this task should be closed as declined.

@GeoffreyT2000 Explaining why you were proposing the change in the RfC lead probably would have helped, although I'm not surprised it's not going over well. This didn't seem like something that would.

Alsee added a subscriber: Alsee.Sep 27 2018, 11:07 AM

The RFC currently has 10 responses at 80% Oppose. There's little chance it will turn the other way.

I understand why this would be more convenient on the programmer side to put a new AFD on the bottom of an existing page, but it would be bad for people working on EnWiki. We probably run into longer discussions and more cases of multiple re-nomination than somewhere like Commons. For example the deletion discussion for Covfefe was 136k long. That's probably a 1% case, but it's not unusual for discussions to run upwards of 50k. In an admittedly extreme case, Gay Nigger Association of America hit (22nd nomination). Five-to-nine nominations is more realistic for a really bad case recurring article. It's easier to use a clean page for the new work.

I know this goes way beyond the current task scope, but the inactive T103082 Workflow project would solve things like this. Each Wiki could configure the process locally.

@GeoffreyT2000 - Well, it's clear that RfC isn't going to result in consensus to change, so feel free to close it as [[WP:SNOW]]. Thanks for the effort though.

@MMiller_WMF - It looks like we'll need to fix this at some point.

Just to note that I now use User:Writ Keeper/Scripts/deletionFinder.js so I don't accidentally nominate a page at AfD a second time.

For some reason, MediaWiki has never had to render ordinal numbers (1st, 2nd, 3rd, etc), so there's no facility in MW core to generate these that I know of. Thankfully enwiki does have a template that does this, so here's a suggested approach that doesn't depend on building (internationalized!) ordinal support into MW core:

  • Create an i18n message that controls the name of the AfD subpage; pass it the page name (as $1) and the sequence number (as $2)
  • Start with the sequence number set to 1, and check if the resulting page title exists. If it does, try sequence number 2, 3, etc, until you find a page title that doesn't exist. Use that title for the AfD nomination.
  • In en.json, set the value of this message to something like $1 (nomination $2) or $1{{PLURAL:$2|1=| (nomination $2)}}. This is not compatible with enwiki's naming scheme, but it's a sensible default that doesn't require ordinals or anything else complicated.
  • On enwiki, create a local override of the message with $1{{PLURAL:$2|1=| ({{ordinal|$2}} nomination)}}. (Note that {{ordinal}} is a Lua-powered template that already exists on enwiki.)

(You could also use $1{{#ifeq:$2|1|| ({{ordinal|$2}} nomination)}}, that's equivalent to the PLURAL construct. However, we can't use {{#ifeq:}} in the software default without making PageTriage depend on the ParserFunctions extension, so we should definitely use PLURAL there.)

Alsee added a comment.Oct 18 2018, 2:46 AM

Note: For assorted reasons, there occasionally gaps in the (Nth nomination) sequence. If you look at Gay Nigger Association of America (22nd nomination), no pages exist at 3rd 4th 10th 11th 19th 20th or 21st. I'm not sure if Twinkle would create a new nomination at the first open slot (3rd), or if it's smart enough to create the new page at 23rd. Creating the new page at 23rd would definitely be preferable. It's probably worth checking the Twinkle code to see if it contains a solution for this, as well as checking whether it reveals any other corner cases or implementation details we've overlooked.

JTannerWMF moved this task from FY 2019-20 to Q2 2019-20 on the Growth-Team board.Jan 3 2019, 3:57 PM
JTannerWMF moved this task from Q2 2019-20 to External on the Growth-Team board.Feb 6 2019, 6:52 PM
94rain added a subscriber: 94rain.May 25 2019, 12:03 PM
ifried added a subscriber: ifried.Jul 11 2019, 10:44 PM
MusikAnimal renamed this task from Page curation adds text to first deletion discussion page if it already exists to Page Curation should create a new AfD discussion page if one already exists.Jul 23 2019, 9:59 PM
MusikAnimal updated the task description. (Show Details)
MusikAnimal updated the task description. (Show Details)Jul 23 2019, 10:02 PM
ifried updated the task description. (Show Details)Jul 23 2019, 10:14 PM
ifried renamed this task from Page Curation should create a new AfD discussion page if one already exists to Spike: Page Curation should create a new AfD discussion page if one already exists [8 hours].Jul 23 2019, 11:48 PM
ifried moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
MaxSem claimed this task.Aug 14 2019, 11:33 PM
MaxSem moved this task from Ready to In Development on the Community-Tech (Kanban (Q1 2019-20)) board.

Spike outcome

This looks doable, if we're to discard the need to support more than one wiki (which is outside of scope of our current work anyway).

Generating page name: Roan has summed it up nicely in this comment. Note that due to PageTriage's WMF-centeredness, relying on ParserFunctions wouldn't be as big of a sin than in general, however looks like this message would need to be parsed on the client side, which would mean no ParserFunctions anyway. This message would have to always be in content language so you'll have to pass it as a JS config variable.

Finding the page: instead of checking for page existence one by one, you can batch it like this.

And are we aiming to find the next number in sequence, or just the first available one?

As @Alsee mentions above, there are somtimes gaps. It sounds like it'd be easier to retrieve the prefix list, count them (and add 1 for the 1st nomination?), and then start looping, checking for existence, and incrementing. Although, are there pages that already have parentheses in their titles that would break that approach?

Twinkle loops through the titles (it's actually parsing the DOM (!!!), probably because it predates API:Allpages which is what we use), parsing out the integer using regex, finding the maximum value, then adding 1: https://github.com/azatoth/twinkle/blob/master/modules/twinklexfd.js#L627-L655 I recommend using similar logic since this been battled-tested. I don't know how we would make it respect localization, etc.

Bear in mind the AfD system we support is pretty unique to English Wikipedia. Worse comes to worse, I think it's okay if we treat all of the AfD stuff as enwiki-only, and hard-code ordinal variations like Twinkle does.

aezell added a subscriber: aezell.Aug 21 2019, 5:09 PM

I think it's fine in this case if our first go at this is focused on the existing EN-wiki only scope. It's not ideal and certainly not what we'd do if we had the chance to start from scratch. However, given the scope of a Wishlist item, I think holding to that for this work is acceptable.

I agree with @aezell regarding the focus on en-wiki only. Since this ticket was converted to a spike, I've created a separate ticket for the work itself: T231357

There's nothing left to review here I think. Work has started on T231357.

What happens to spike's after review? Straight to done?

Yes. Once we've created the tasks needed to do the work the spike recommends, we can close the spike task.

aezell closed this task as Resolved.Sep 11 2019, 5:11 PM