Page MenuHomePhabricator

Page Curation Tools to add userspace CSD Log/PROD Log/AFD log functionality
Open, Needs TriagePublic

Description

While Twinkle keeps a userspace log of these forms of deletion nomination, the page curation toolbar does not. To maintain interoperability with twinkle, it should read the relevant section of twinkleoptions.js, if it exists, or simply check for the existence of the 'CSD log' and 'PROD log' user subpages.

I know that there is a deletion tag log: https://en.wikipedia.org/wiki/Special:Log?type=pagetriage-deletion&user=Insertcleverphrasehere&page=&wpdate=&tagfilter= but this log lumps PROD, CSD, and AfD taggings all together. Nobody wants to parse through all of that to check over their CSDs. Moreover it removes any ability to personally edit/organise your CSD log (adding comments/notes for future reference etc.) See mine for example: https://en.wikipedia.org/wiki/User:Insertcleverphrasehere/CSD_log

The other problem is that the Page Curation tools are currently unavailable on articles that are not in the NewPagesFeed (see task T207485: Enable page curation tools to be loaded on any page (optionally) for a fix to that); because of this, articles that are CSDed from elsewhere are necessarily not contained in your page curation log, but have to be done via Twinkle and the userspace CSD log. This fragments the CSD logs into two different places, making the issue even worse. It is essential to be able to keep track of your CSD logs, as these articles are often recreated days, weeks, or even months later by COI editors, with similar problems (this is especially true of paid editing and SPI-banned accounts).

Requested multiple times at the Suggested Improvements page:
https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#40._deletion_logs
https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#55._Ability_to_log_CSD_taggings_to_their_CSD_logs
https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#64._CSD/PRODs:_update_userspace_logs

Event Timeline

kostajh added a subscriber: kostajh.

Growth-Team will not have time to work on this in the short-to-medium term.

Growth-Team will not have time to work on this in the short-to-medium term.

I might be able to work on this. In delete.js, the code for tagging the page:

new mw.Api().postWithToken( 'csrf', {
	action: 'pagetriagetagging',
	pageid: mw.config.get( 'wgArticleId' ),
	top: text,
	deletion: 1,
	taglist: tagList.join( '|' )
} )
	.done( function () {
		that.notifyUser( count, key );
	} )

it should be possible to add a that.logToUserspace. A basic functionality would

  • Determine if the tag was CSD, PROD, or other (if other, exit the function)
  • Retrieve the user's username
  • Retrieve the content of User: + userName + / + CSD/PROD + log
  • Append to the current content a template with the name of the page that was tagged, and the tag used (eg ...{{subst:PageTriageSpeedyTagged|Foo|G1}} if the page [[Foo]] was tagged with CSD criteria G1
  • Save the page with the new content (and tag the edit as PageTriage)

@DannyS712 Thanks for the offer! Allow me to stop you before you spend a lot of time on this, as there are some complications that we've uncovered. The primary issue is that we need to read twinkleoptions.js to find out if we should log and where. This sort of gadget dependency doesn't belong in MediaWiki. So instead we've decided to introduce a JS hook that is fired when Page Curation tags a page for speedy/proposed deletion. Then Twinkle can listen to that and perform the logging. This also means we don't need to worry about staying up-to-date with Twinkle's logic (which has changed a bit over the years). I know you contribute to Twinkle, so maybe you could help with that side of it. I'll be around to help as well, but first we need to get this hook into Page Curation. We'll be working on that soon.

Where can I find information regarding who in the community is working on this further. This is one of the most important things for me regarding use of the deletion tools (I will not use the page curation tools without CSD and PROD log functionality added). I was disappointed to see a bare minimum done with the expectation that volunteers would have to finish it after you added the 'hooks',whatever that means (All I know is that it doesn't WORK). Let me know who I should be talking to regarding who is likely to finish this.

Where can I find information regarding who in the community is working on this further.

https://github.com/azatoth/twinkle/issues/709

Novem_Linguae renamed this task from Page Curation Tools to add userspace CSD Log/PROD Log functionality to Page Curation Tools to add userspace CSD Log/PROD Log/AFD log functionality.Tue, Jul 19, 11:43 PM

I think I would keep it simple. Writing a whole settings system is more complex than needed. So is adding Twinkle as a dependency. I think I'd like to just add a check box that persists its state with a cookie. Here is my implementation plan.

  • Add a check box next to "Mark for deletion" that says "Log to userspace". It reads a cookie to figure out state. If no cookie found, default state is checked.
  • Add click handler for the check box that writes a cookie to remember the setting.
  • Add a userlogpage field to all the deletion tag data in en:MediaWiki:PageTriageExternalDeletionTagsOptions.js. Fill it with data such as 'CSD log', 'PROD log', 'XfD log'
  • Add some ajax code and a new function to append a bullet to the log, in the same format that Twinkle does. Probably call the function from the back end of the tagPage() -> notifyUser() codepath.

If users want more features later then we can revisit later. But I think simple is a good start.

Read twinkleoptions.js idea:

Trying to read twinkleoptions.js and silently failing if not found, as described above, would also be a good solution. Yes it creates a dependency, but the worst that happens is the page isn't found and the feature doesn't execute, which is the current behavior. Using twinkleoptions.js would sidestep several issues, including having to keep track of user preferences, and properly handling custom Twinkle log locations.

Hook idea:

Trying to use a hook on the Twinkle end could potentially lead to a race condition. I guess the benefit is that we wouldn't have to duplicate Twinkle's log-writing logic.

After pondering, I am leaning towards the twinkleoptions.js idea. It will seamlessly add the functionality for the end users that have Twinkle configured, and it will do nothing (same behavior as now) for other folks.