Community Wishlist Survey 2023/Search and Categories/Improve tracking of categorization changes

From Meta, a Wikimedia project coordination wiki

Improve tracking of categorization changes

  • Problem: For several years now, categorization changes have had dedicated entries in recent changes and watchlist. This is useful for watchlist – when you watch a category and have categorization changes enabled, you can see recent additions and removals to the category. For recent changes, this isn't that useful as it lists changes to any category. On Special:RecentChangesLinked ("related changes"), it only shows additions to the category (and also categorization changes for other categories). It happens because when you remove a page from the category, it is no longer "linked" and thus it cannot be listed in the related changes anymore. Consequently, there is no native way to see all category additions and/or removals, and only them, from a single place. Additionally, there has been some technical debt around displaying the categorization changes. For example, sometimes it's unnecessarily difficult to access the diff.
  • Proposed solution: (one of these)
    1. Improve Special:RecentChangesLinked to implicitly show additions and removals of the category (when you have categorization changes enabled)
    2. Create a dedicated "mode" for categories in Special:RecentChangesLinked (i.e., make #1 explicit)
    3. Create a new special page dedicated to category changes (similarly, there is Special:NewPages for pages creations)
  • Who would benefit: Wiki gnomes checking for mistakes, patrollers checking for vandalism, wikis with complex categorizations
  • More comments: None of the above should require any major changes to the storage, it's just a matter of displaying better what is already being saved. Since this all is backed by the recent changes, the changes are only traceable for the last 30 days. There is also a proposal (phab:T6366) that a complete history of all category members (and time of their addition/removal) is stored, but that would probably be an epic task.
  • Phabricator tickets: phab:T89582, phab:T130134 (general problem); phab:T126851, phab:T148533, phab:T270662, phab:T270774 (display issues)
  • Proposer: Matěj Suchánek (talk) 09:54, 24 January 2023 (UTC)[reply]

Discussion

Repurposed from the 2021 and 2022 editions. --Matěj Suchánek (talk) 09:54, 24 January 2023 (UTC)[reply]

  • Question Question: This seems like it could quickly get out of hand, for example @Matěj Suchánek: if someone adds or removes a new category to a template such as w:cs:Šablona:Infobox - osoba or w:en:Template:Infoxbox person that cascades to other pages (possibly millions of pages) - what would you expect to populate in this proposed log? — xaosflux Talk 15:25, 25 January 2023 (UTC)[reply]
    I'm not suggesting any change to how the log is populated. My point is just a more logical view of the changes. --Matěj Suchánek (talk) 17:02, 25 January 2023 (UTC)[reply]
    1. The idea is to show currently available categorisation information in a more systematic way on a dedicated page, not just limited to the last 30 days.
    2. Ideally, every incoming/outgoing member should've been logged with the timestamp of when the software caught on with the categorisation of a ceratain page, but that might be too much of a task, so that isn't asked for at this moment of time.
    —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 22:06, 17 February 2023 (UTC)[reply]
  • Though it's beyond the scope of this wish, I'd like to mention there are use cases for extending inbound-link change tracking to namespaces other than categories. E.g. when someone creates a WikiStory for an article, a discussion is mentioned on another talk or project page, or an article watcher wants to learn when an article on a related topic has been created. I can't imagine the performance hit of doing that for all article→article links, however. Pelagic (talk) 17:05, 13 February 2023 (UTC)[reply]

Voting