Page MenuHomePhabricator

Introduce a subscribable "Updates" section to wishes
Open, LowPublic8 Estimated Story PointsFeature

Description

Related wish: W43 – Allow editors to subscribe to community wishes

Problem

Having just gone through every singe wish doing the migration, I noticed we have a clunky, unstructured means of making notes about a wish visible to everyone reading it.

Examples:

In addition, these updates don't notify the users. They may never be informed an update even happened.

Proposal

Add a new section, "Updates", where Community Wishlist managers can help add context to the wish, explain decision-making (such as why a wish was declined), or to announce general updates on the wish.

r1205012 should be reworked so that the automatic logged updates (what we added for T411841) get copied to the "Updates" section as {{int: …}} messages (so they're always translated). In the form, we'd have a textarea input for Wishlist managers to write a new free-form update, and we send out the notification itself in the same way we did for T411841. If there's a structured change (i.e. status change) that happens in the same edit, they'd share the same comment in the "Updates" section.

Imagine an updates section that looks like:

  • [20:44, 5 October 2025] Wish created --WishProposer (talk)
  • [18:42, 10 October 2025] Status changed to "In progress" -- MusikAnimal (WMF)
  • [2:10, 20 October 2025] Add to focus area "Template recall and discovery" CParle (WMF)
  • [15:47, 5 November 2025] Status changed to "Done". Hello everyone! We are proud to announce this was has been completed. Thanks to everyone who helped make this wish come true. KSiebert (WMF)

Where each comment is presented as a bulleted item prefixed with a timestamp. We're sending out the notifications ourselves (as opposed to relying on DiscussionTools to do it via signed comments), so we can format the list however we'd like.

Screenshots

Screenshot from 2025-11-12 12-57-13.png (1,213×219 px, 73 KB)

Screenshot from 2025-11-12 13-01-53.png (753×252 px, 33 KB)

Event Timeline

MusikAnimal renamed this task from Introduce a "Notes" section to wishes to Introduce a "Notes" or "Updates" section to wishes.Oct 3 2025, 1:03 AM
MusikAnimal updated the task description. (Show Details)
MusikAnimal updated the task description. (Show Details)
dmaza changed the subtype of this task from "Task" to "Feature Request".Oct 9 2025, 4:58 PM
MusikAnimal raised the priority of this task from Low to Medium.
HMonroy changed the task status from Open to In Progress.Oct 27 2025, 4:50 PM
HMonroy claimed this task.

We can leverage the discussion tools extension by including __NEWSECTIONLINK__ magic word in wish pages. We can modify the wish parser function to include this text, and it will add a link "Add Topic" on top of the wish pages. It will allow users to start a new discussion section on a non-talk page.

For example: https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/W14

HMonroy changed the task status from In Progress to Open.Nov 4 2025, 9:00 PM
HMonroy removed HMonroy as the assignee of this task.
HMonroy subscribed.
MusikAnimal renamed this task from Introduce a "Notes" or "Updates" section to wishes to Introduce a subscribable "Updates" section to wishes.Nov 5 2025, 8:48 PM
MusikAnimal updated the task description. (Show Details)

I've got a prototype ready to demo for the next Planning meeting.

Change #1205012 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CommunityRequests@master] Updates feature: add basic support behind a feature flag

https://gerrit.wikimedia.org/r/1205012

MusikAnimal changed the task status from Open to In Progress.Nov 14 2025, 8:14 AM

I'm thinking this should use the logging. That will make it easier to run queries which we wanted for analysis, i.e. how long it takes on average for a wish to go from "Under review" to a triaged status. I filed T410810: Add logging to CommunityRequests

Change #1211242 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CommunityRequests@master] EntityChangesProcessor: service for comparing two entities

https://gerrit.wikimedia.org/r/1211242

Change #1211242 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] AbstractChangesProcessor: service for comparing two entities

https://gerrit.wikimedia.org/r/1211242

My spidey-senses are telling me this isn't worth pursuing unless we rework the experience. Originally I thought I had it all figured out, but then it occurred to me we can use DiscussionTools only for keeping track of subscriptions, and send out the notifications ourselves. That was done in T411841 and largely solves the wish W43 – Allow editors to subscribe to community wishes.

This feature would be only for making manual updates that send out notifications to subscribers. But then it's kind of weird to have that in one place, and the structured log of the meaningful changes live somewhere else (Special:Log). Also, they'd need to subscribe to not only the page, but the "Updates" section as well.

I'm thinking r1205012 should be reworked so that the automatic logged updates get copied to the "Updates" section as {{int: …}} messages (so they're always translated). In the form, we'd have a textarea input for Wishlist managers to write a new free-form update, and we send out the notification itself in the same way we did for T411841. If there's a structured change (i.e. status change) that happens in the same edit, they'd share the same comment in the "Updates" section. That seems much cleaner and easier to understand from a user standpoint.

That said, there's plenty of other higher-priority things to be spending my time on, so I'm going to put this back up for grabs and save it for the next Wishathon or a rainy day.