Page MenuHomePhabricator

Support replying to a vote
Open, Needs TriagePublicFeature

Description

Feature summary:

  • A parser function that takes a username and timestamp that, when used on the talk page of a wish/FA, creates a block quote of the matching support vote with an anchor, and adds "this comment has a reply here" (and perhaps the first few words of the reply) below the vote linking to the anchor
  • A button next to each support vote with a comment saying "reply", which creates a section with said parser function

Use case(s):
Here is a clear example of a conversation happening on the votes page. Inevitably someone is going to say in their support comment something someone else disagrees with, and it would create a sense of unfairness if the only way to rebut it with the same visibility was to cast a support vote yourself.

Benefits:
All substantial discussion on a given wish/FA can take place on its talk page, avoiding splintered discussions between the votes and talk pages, and the talk page being more visible will encourage users to toss ideas, thus facilitating innovation.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

This approach sounds like a nice compromise given the technical barrier we have to allowing threaded replies to votes.

We know how to scan a page, count parser function invocations, and collect any data generated by those parser functions. That's easy. What's not so easy:

  • We'd have to load the wikitext of the talk page and I guess cache that aggressively to avoid it being queried on every pageview.
  • Avoiding confusion of having a parser function in the wikitext of a new discussion topic. We could do the usual <!-- do not touch this line --> kind of thing, but that feels quite icky. I'm hoping we can do better.

In the meantime, I can try get an automated edit notice in place so users know threaded comments on the /Votes page will get wiped out. Though the /Votes page is now protected by the manually-edit-wishlist right, so maybe that's not as important now.

We'd have to load the wikitext of the talk page and I guess cache that aggressively to avoid it being queried on every pageview.

I've assumed caching on every save/purge rather than every pageview is how {{#CommunityRequests:wish/focus-area/vote}} already work. It's not?

Avoiding confusion of having a parser function in the wikitext of a new discussion topic. We could do the usual <!-- do not touch this line --> kind of thing, but that feels quite icky. I'm hoping we can do better.

Community Tech bot already adds {{Community Wishlist/Talk}} after a talk page is created. Something similar could be done by the extension adding a tag (or outright prepending the parser function for that matter, if possible).

Scratch the last point, even if you could use a tag the challenge of keeping track of which vote is being replied to remains, my bad. Now that I think about it, the new section should still show the comment being replied to. The user would be much less likely to remove the parser function if it turned into basically {{talk quote|<original comment>}} after preview/save.