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

In T207237#5344049, @kostajh wrote:

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.

In T207237#5755428, @Insertcleverphrasehere wrote:

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

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

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.

Wouldn't change tags be the more obvious solution for this, instead of trying to recreate the log page in wikitext? Special:Log can be filtered by the combination of a user + a tag (and optionally a date range), that seems to fulfill the use case.

Twinkle does it using wikitext logs and it's really popular.

I spitballed some ideas earlier in this ticket, but at this point I'd be in favor of duplicating how Twinkle does it exactly, right down to the same log page names, same log entry formatting, and having the log pages contain a combination of both Twinkle and PageTriage entries.

As you say, we already have Special:Log -> Page curation log -> delete for PageTriage if we want to look at its activity via Special:Log instead. The Special:Log is 1) less detailed (doesn't contain the full AFD reason, for example, which can be a paragraph or multiple paragraphs) and 2) more scalable (has pagination). Pros and cons.

I think this feature is low hanging fruit. Wouldn't take long to code. Doesn't need consensus. Moving it to the top of the kanban board.

Code can be copy pasted from Twinkle and adapted.

There is also potential to put a list of CSDs in a json file onwiki somewhere, and having Twinkle and PageTriage share that list.

In general I don't think it's a good idea to create some complex API where PageTriage tries to use Twinkle or talk to Twinkle. I think that while the initial idea of avoiding code duplication is admirable, that maintaining that API would increase technical debt in the long run. It's also an external dependency. Seems fragile.

Discussed in Discord today. Requested by @Illusion_Flame.

Still at the top of our NPP features kanban board.

Looks like there's 3 or 4 different ideas for how to implement this though.