Notes from debugging: From https://github.com/wikimedia/mediawiki-extensions-PageTriage/blob/master/modules/ext.pageTriage.tagData/deletionTags.json#L478, the deletion tagging code is adding the param of the redirectsfordiscussion tag to the talkpagenotiftpl template which is added to the user's talk page.

The wording of the text has been changed (to avoid WP:OWN issues). It now says "Unfortunately, I do not think it is ready for publishing as a live article at this time because ...". This avoids the "your article" phrase and is equally relevant to the page creator as well as other contributors. Closing this ticket.

Codebase revision: https://gitlab.wikimedia.org/mpg/moveToDraft/-/commit/1aa5b9928fe96e4506bd2926a4f3d098d23bbd2f

In the codebase in revision https://gitlab.wikimedia.org/mpg/moveToDraft/-/commit/a520fbecadcd15b1d57464f64bb2749c08862e54
and on enwiki in revision https://en.wikipedia.org/w/index.php?title=User:MPGuy2824/MoveToDraft/core.js&diff=prev&oldid=1262039716

I would guess that https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/PageTriage/+/refs/heads/master/modules/ext.pageTriage.newPagesFeed/stores/settings.js#210 is to blame. This is not there in when processing the date_range_from variable. There is similar code at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/PageTriage/+/refs/heads/master/modules/ext.pageTriage.newPagesFeed/stores/settings.js#298.

Just to note, the bug exists for AfC too. Steps to reproduce:

A somewhat related use case: there is already (only) one maint tag in the article, and a reviewer is adding only one more, then both tags should be put inside a {{Multiple issues}} template.

I saw this consistently yesterday (when I filed the report). I have Vector legacy skin, but I cannot reproduce it today.
Closing for now. Will reopen (with a screenshot) if it crops up again.

The template that is used for the talkpage notice has its own section header. Compare Template:Db-llm-notice to Template:Db-disambig-notice-NPF.
One option would be to remove the section header from the llm template. The problem is that this might be used by other people/scripts which might have got used to it already. Another option is to duplicate the template to a PageTriage specific one (with a NPF at the end) and modify it in the same way as option 1.

T349048: Mark as reviewed log entry should mention if it's an article or redirect is the ticket that Novem is talking about. I think Pppery would like the Special:Log page changed since it is right now not possible to filter for only article reviews (e.g. https://en.wikipedia.org/wiki/Special:Log?type=pagetriage-curation&user=Zzz_plant&page=&wpdate=&tagfilter=&subtype=review&wpFormIdentifier=logeventslist&issubmitted=1 shows both).

Fix is live on enwiki

In T321534#10537783, @Bunnypranav wrote:

@MPGuy2824 Will it work if this is just an additional tag in deletionTags.json?

Probable location of change: the setupDeletionTags function in delete.js.

Maybe skipnotif is what I meant.
But yeah, adding a check and not notifying for maintenance tags on redirects is probably the easier way.

In T329346#9731804, @Novem_Linguae wrote:

We should give some thought to if we want to put this behind a preference or not, and if that preference should default to off or on.

In T355030#9474500, @Novem_Linguae wrote:

The patch is marked as work in progress. Is that correct, or is it ready for review?

unstalled now.

@Novem_Linguae this seems fixed to me on enwiki. Can you check?

Adding Susana, for a code review of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/1006902.

In T349886#9565314, @Novem_Linguae wrote:

New idea: Same as the screenshot above, but add an ⓘ icon to the header that, when clicked, displays a tooltip with the stats. This keeps the stats but lets us get rid of the footer, and avoids cluttering the header.

I'd be on board with this. We might even be able to hit the stats api only when the tooltip is requested, as opposed to every time the page is hit.

The list Api being called doesn't have the right param when that particular filter is applied.
It looks like modules/ext.pageTriage.newPagesFeed.vue/stores/settings.js doesn't have the required lines for autopatrolled. The other filters in the "That:" list do work.

In T348743#9294287, @Ladsgroup wrote:

It calls getExternalLB which shouldn't be called outside of rdbms anymore but it's only in tests (https://codesearch.wmcloud.org/things/?q=getExternalLB&files=&excludeFiles=&repos=Extension%3APageTriage) are you sure it's needed? Can you just remove that?

Suggestions from Chlod regarding a way in JS to figure out if a particular extension has been installed:

could check if DT's JS module (ext.discussionTools.init) is "registered" with mw.loader.getState("ext.discussionTools.init"); it'll be null if DT isn't present
there's also other ext.discussionTools.* modules that you can test for
this might be worth checking on the backend side instead, though, and fed into mw.config, considering that there's an additional requirement: topic subscription is enabled, both on-wiki and for the user

Seems to be ok now. e.g. https://en.wikipedia.org/w/index.php?title=Shamshabad%2C_Madhya_Pradesh&diff=1199175004&oldid=1199173347

Unsure what to do when there are multiple tags added , but one or more don't have skipNotification=true. This isn't a problem for redirects since only the redirect tags are shown to the reviewer and for none of them we need to notify the creator. But, it could be a problem in the future when the skipNotification param is added to article tags as well. My current thought is that if any of the tags need notification, then notify about all.

All clear. Closing.

Yep, your image is what I was proposing. In the context of T343445: Do not notify user about redirect templates the patch writer would probably have to add a param skipNotification=true for every relevant redirect tag, which is most/all of them.