Some top of mind questions we'd need to answer to tackle this:

• The default edit summary, "Mass deletion of pages added by ..." doesn't exactly apply to talk pages - the page isn't added by this user, it's just a related page. What edit summary should we use for associated talk pages?
• How do we present the option to delete talk pages? A checkbox that applies to all pages below? It could check/uncheck all the not-created-by-this-user talk pages in the list.
• How should talk pages be displayed in the list of pages to be deleted? It might make sense to display them differently to other pages to make clear these are associated pages, not pages directly created by the user.

In T95797#9766085, @Samwalton9-WMF wrote:

Some top of mind questions we'd need to answer to tackle this:

• The default edit summary, "Mass deletion of pages added by ..." doesn't exactly apply to talk pages - the page isn't added by this user, it's just a related page. What edit summary should we use for associated talk pages?

We could simply prepend text like "Deleting associated talk page - " to the selected/entered deletion reason.

Normal page:
(G2: Test page: Mass deletion of pages added by Samwalton9)

Talk page:
(Deleting associated talk page - G2: Test page: Mass deletion of pages added by Samwalton9)

• How do we present the option to delete talk pages? A checkbox that applies to all pages below? It could check/uncheck all the not-created-by-this-user talk pages in the list.

If we present all associated discussion pages as checkboxes in the list in some way, we could add a checkbox at the top which says "Also delete associated talk pages" and have this control those checkboxes specifically.

New question: Should this checkbox be on the initial form too, or only once you've brought up a list of pages? If the latter, should discussion pages be selected by default or not? I'm inclined to say not, as this is probably unexpected behaviour.

In T95797#9766085, @Samwalton9-WMF wrote:

• How should talk pages be displayed in the list of pages to be deleted? It might make sense to display them differently to other pages to make clear these are associated pages, not pages directly created by the user.

We decided not to display them - the primary purpose of doing so would be to facilitate deselecting specific pages, but we (and two other admins I spoke to) couldn't think of circumstances where deleting a page but not the associated talk page would be helpful.

The downsides of live-commenting your thought process at a Hackathon is that the back-and-forth is fully documented. Since my last comment we went back and forth on a bunch of options and explorations and spoke to ~5 admins to get their feedback. I'm going to update the ticket description based on what we've decided.

• The default edit summary, "Mass deletion of pages added by ..." doesn't exactly apply to talk pages - the page isn't added by this user, it's just a related page. What edit summary should we use for associated talk pages?

Apologies if I'm stating the obvious here, but could MediaWiki:Delete-talk-summary-prefix be used for this?

In T95797#9770118, @A_smart_kitten wrote:

• The default edit summary, "Mass deletion of pages added by ..." doesn't exactly apply to talk pages - the page isn't added by this user, it's just a related page. What edit summary should we use for associated talk pages?

Apologies if I'm stating the obvious here, but could MediaWiki:Delete-talk-summary-prefix be used for this?

This is a great idea! I didn't realise this existed - it definitely makes sense to re-use this.

@jsn.sherman

A simple approach would be to check for/fetch a talk page for each page in doDelete() and also check to make sure it's not already in the list. However, a naive implementation would not respect $limit.

Does $limit here refer to the field where users decide how many pages to retrieve? In which sense the concern, as I understand it, would be that a user enters '100' pages to retrieve, and then we attempt to delete 200 because we've ~doubled our list?

Is there a technical concern here, or is this about user expectations?

In T95797#10210283, @Samwalton9-WMF wrote:

@jsn.sherman

A simple approach would be to check for/fetch a talk page for each page in doDelete() and also check to make sure it's not already in the list. However, a naive implementation would not respect $limit.

Does $limit here refer to the field where users decide how many pages to retrieve? In which sense the concern, as I understand it, would be that a user enters '100' pages to retrieve, and then we attempt to delete 200 because we've ~doubled our list?

Is there a technical concern here, or is this about user expectations?

Going with the second approach (or something like it) is a better design because it means that all pages to be deleted will be in the $pages array and will be handled identically by doDelete(). If we simply respect $limit, we don't have to worry about the implications of breaking it ;)

In T95797#10215185, @jsn.sherman wrote:

In T95797#10210283, @Samwalton9-WMF wrote:

@jsn.sherman

A simple approach would be to check for/fetch a talk page for each page in doDelete() and also check to make sure it's not already in the list. However, a naive implementation would not respect $limit.

Does $limit here refer to the field where users decide how many pages to retrieve? In which sense the concern, as I understand it, would be that a user enters '100' pages to retrieve, and then we attempt to delete 200 because we've ~doubled our list?

Is there a technical concern here, or is this about user expectations?

Going with the second approach (or something like it) is a better design because it means that all pages to be deleted will be in the $pages array and will be handled identically by doDelete(). If we simply respect $limit, we don't have to worry about the implications of breaking it ;)

This implies we would need to have the checkbox for this feature on the first view, rather than the second, since it affects how many pages we list, is that right?

A second thought - we are considering two other features that extend the number of pages deleted from the naive list - T46318: Add an option to Nuke to also delete subpages of deleted pages and T364222: Add an option to Nuke to also delete redirects pointing to deleted pages. Imagining that we implement all three of these and a user selects all three (likely) - respecting $limit may result in a very low number of actual pages that can be deleted. e.g. imagining that a page has 1 talk page, 2 subpages, and 7 redirects, at a rate of 10:1 a limit of 500 means we can only delete 50 articles and their associated pages.

I understand the concern and don't want to assume there's an easy answer so is it worth perhaps at this first step worrying about the implications of breaking $limit, given that we potentially have these other features in the future?

In T95797#10281178, @Samwalton9-WMF wrote:

In T95797#10215185, @jsn.sherman wrote:

In T95797#10210283, @Samwalton9-WMF wrote:

@jsn.sherman

A simple approach would be to check for/fetch a talk page for each page in doDelete() and also check to make sure it's not already in the list. However, a naive implementation would not respect $limit.

Does $limit here refer to the field where users decide how many pages to retrieve? In which sense the concern, as I understand it, would be that a user enters '100' pages to retrieve, and then we attempt to delete 200 because we've ~doubled our list?

Is there a technical concern here, or is this about user expectations?

Going with the second approach (or something like it) is a better design because it means that all pages to be deleted will be in the $pages array and will be handled identically by doDelete(). If we simply respect $limit, we don't have to worry about the implications of breaking it ;)

This implies we would need to have the checkbox for this feature on the first view, rather than the second, since it affects how many pages we list, is that right?

correct

A second thought - we are considering two other features that extend the number of pages deleted from the naive list - T46318: Add an option to Nuke to also delete subpages of deleted pages and T364222: Add an option to Nuke to also delete redirects pointing to deleted pages. Imagining that we implement all three of these and a user selects all three (likely) - respecting $limit may result in a very low number of actual pages that can be deleted. e.g. imagining that a page has 1 talk page, 2 subpages, and 7 redirects, at a rate of 10:1 a limit of 500 means we can only delete 50 articles and their associated pages.

The answer here would be to increase the limit after running tests and determining that it is fine to do so.

I understand the concern and don't want to assume there's an easy answer so is it worth perhaps at this first step worrying about the implications of breaking $limit, given that we potentially have these other features in the future?

Yes, we should respect $limit.

A couple of things we discussed about this today:

• For talk pages the above issue only maximally halves the number of pages it's possible to delete (500->250) if every page has a talk page.
• We should make a mockup of the new flow with this feature, because it should be on the first form, so that admins can see the full list of pages they're going to delete before doing so. The text on the button should also make clear that this is about discussion pages associated with pages that aren't already discussion pages. This might be obvious to admins already, so if there's no clear way to achieve this without writing a lot of words, I think it's OK to keep it shorter.

I just wrote the following example, which I'll get feedback on, but feels like the better of the two options to me. In this way, the admin can simply re-run Nuke later and still delete all the pages they want to. If we went for the second option, talk pages would be left hanging and wouldn't be picked up on a 2nd run.

We should opt to present a page and its discussion page over additional pages. As an example, say a user created articles A, B, and C, each has a talk page created by a different user, and the limit of pages Nuke can retrieve is 4. We should retrieve A, Talk:A, B, and Talk:B, rather than A, B, C, and Talk:A.

But what if the page limit is 5 in this case? Do we present A, Talk:A, B, Talk:B, and C, or do we truncate the list early and leave C, so that a re-run of Nuke could delete it and its talk page, rather than (as implied above) leaving it hanging and not deleted?