Page MenuHomePhabricator

Counting votes on voting pages
Open, MediumPublic5 Estimated Story Points

Description

Background

The CommunityRequests extension is currently designed to store votes as wikitext on a /Votes subpage of either a focus area, and later wishes. When a vote is saved, we need to update communityrequests_wishes.cr_vote_count (wishes) or communityrequests_focus_areas.crfa_vote_count (focus areas) accordingly.

Acceptance criteria

  • Add a configuration variable to specify what the voting subpage is called. i.e. $wgCommunityRequestsVotingSubpage = '/Voting';
  • Introduce a parser tag for votes. We don't store any voting data other than the tally count, so an empty parser function with no output is fine for now, i.e. <vote>. This will get embedded in the voting template, so don't worry about presentation.
  • Keep a tally of each vote, storing the counter with ParserOutput::setExtensionData(), similar to what we're doing for the other parser tags
  • Use the LinksUpdateComplete hook to get the final count (pulling the tally from the extension data)
  • Before saving, ensure we're on a qualifying page
  • Get the Wish or FocusArea object from the page title, and update the vote count field for the corresponding row in the wishes/focus_areas table

Event Timeline

I don't think this is needed. See discussion at T388219 – refers to an older version of this task

Cparle renamed this task from New action api endpoint to count votes for focus area to Hook to update votes for focus area.Mar 11 2025, 3:50 PM
Cparle updated the task description. (Show Details)
Cparle renamed this task from Hook to update votes for focus area to Handle votes for focus area.Mar 11 2025, 3:53 PM

Updated description based on discussion in T388219

I like the idea of triggering on changes to the /Votes page — could we avoid the config var because we already know if a page is a focus area (based on the presence of {{#focus-area}}) and I guess the subpage name will need to be set to something static anyway? One of the ideas I like with what we've got so far is that we're not enforcing any particular subpage structures for any of this, which I think keeps it simpler.

i.e. when a Foo/Bar/Votes subpage is edited, we count the votes and update any focus area row with a page title that matches the parent page's. Which I think could perhaps be done with something along the lines of update community_requests_focus_areas set crfa_vote_count = 3 where crfa_page = ( select page_id from page where page_title = 'Foo/Bar' LIMIT 1 ) — so if the parent isn't already a focus area, nothing happens.

JWheeler-WMF set the point value for this task to 3.Apr 29 2025, 4:58 PM
MusikAnimal renamed this task from Handle votes for focus area to Counting votes on voting pages.May 29 2025, 4:40 PM
MusikAnimal updated the task description. (Show Details)
MusikAnimal changed the point value for this task from 3 to 5.

Change #1168186 had a related patch set uploaded (by Dmaza; author: Dmaza):

[mediawiki/extensions/CommunityRequests@master] [WIP]

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

Change #1168186 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Count votes on focus areas and wishes

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