Surprisingly, voting didn't come up very high in the TPC. I think it's only covered under "Workflows": https://www.mediawiki.org/wiki/Talk_pages_consultation_2019/Phase_1_report#Workflows

Opinion may change as this tool becomes more widely used though.

Updating the task description with some examples Michel Ney shared on mw.org here: https://www.mediawiki.org/wiki/Topic:Vu8z37woqb5eit3e.

Task description update
Adding en.wiki RfC's as a potential use case via @Barkeep49

• en.wiki RfCs
  • See: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Discussion_Tools_RFC_responses.

I’m wondering if we could special case any discussion that starts with an indented comment, and in those cases add a new affordance to comment at the same level:

===vote!===
* support. (sig)

vote!

• support. (sig) [ reply ]
• [ add comment ]

This would require a heading (or sub heading) to immediately precede the first vote, but this is already quite a common convention and it would not be that disruptive to require it going forward. If a vote introduction is required, users would just need to ensure there was an additional sub-heading before the voting started. It would also solve the problem of the vote introduction being considered part of the first comment:

I’m not part of the first comment.
* But that’s impossible to tell programmatically. (sig)

This does not address the issue of whether votes can be replied to, which is usually determined on a case by case basis. For that we would definitely need some extra syntax:

===vote!===
__NOREPLY__
* support. (sig)

vote!

• support. (sig)
• [ add comment ]

The above proposal would allow the tool to work in a large number of cases without any new syntax. Many other cases could also work using minimal existing syntax (extra sub-heading).

False positives would just result in an inoffensive [ add comment ] button that adds a comment at the same (indented) level as the OP.

The issue of unwanted [ reply ] buttons is separated from the new vote functionality and can be decided on a case by case basis. It is also not a technical blocker to the new vote functionality, which is good because adding new syntax is not trivial.

Task description update

• ADDED === Open questions
• ADDED === Approaches for @Esanders to fill in with what is described in T259865#6655698 and discussed during today's standup wherein the following idea was shared: "What about adding an additional check for where * or # (read: not :) is used as the indentation syntax for first "comment."

Is this vote easy enough to figure out?

* I’ve got a lot of stuff to say.
: But I don't know how to create a valid list structure and still get the visual appearance I want.
: Will you be able to figure out how much of this is my vote?  (sig)

The comments people are posting at en.wiki [i] about the potential of reinstating the {{Support}} and {{Oppose}} templates will likely be helpful to consider when deciding on an initial approach for adding voting-style discussion support to DiscussionTools.

Thank you to @Whatamidoing-WMF for noticing this and bringing it to our attention; I've added the link below to the task description.

i. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#RfC:_Should_we_have_Support/Oppose/etc._survey_convenience_templates?

In T259865#6683562, @Whatamidoing-WMF wrote:

Is this vote easy enough to figure out?

With all comments we include everything up to the previous signature, so that should be parsed correctly. The proposal here is just to add another call-to-action to make voting-like interactions easier, parsing existing votes is an unrelated issue.

Do you expect that some discussions are partly voting and partly classic? See this.

@ppelberg Hello, please see Meta – Stewards Elections. There is a good voting style I think. What do you think about it?

In T269163#6686411, @Esanders wrote:

On inspecting a few AfD pages across various wikis, there appears to be quite a lot that have leading signed comments at 0 indentation.

My proposed heuristic was these two rules:

1. First comment after heading has indentation > 0
2. First comment at indentation > 0 is a bullet/numbered list item

I think condition (1) would exclude quite a lot of existing vote pages, and wouldn't require those wikis to change their conventions (I mentioned this is my previous comment).

I'm now thinking we should drop (1) and just go with (2). This would obviously result in more false positives, although I suspect not that many except for wikis that commonly indent with bullets (ru.wiki), but as I stated before, I don't think false positives are particularly problematic.

In T269163#6686429, @Esanders wrote:

I've made dtdebug a bit mask, so we can enable various pieces of the debugger separately:

• dtdebug = 1: Show comment/signature highlighting
• dtdebug = 2: Show [ add comment ] (vote) buttons when section starts in a bullet/numbered (original heurstic)
• dtdebug = 3: Show 1+2
• dtdebug = 4: Show [ add comment ] (vote) buttons when first comment or reply is a bullet/numbered list (revised permissive heurstic)
• dtdebug = 5: Show 1+4

Is it possible that a drop-down menu like that for "Styling" (text formatting) be created on the left of the text box, which allows an user to choose a reply type of their choice: indented, bulleted, or numbered. I created a rough image of what I think could be implemented. This will allow an user to choose a reply type on a case-by-case basis as they see fit. The default remains indentation. I also noticed that discussion so far on the phab ticket generally revolves around English Wikipedia, but this solution will allow it to work on any Wikimedia project.

In T259865#8274241, @CX_Zoom wrote:

Is it possible that a drop-down menu like that for "Styling" (text formatting) be created on the left of the text box, which allows an user to choose a reply type of their choice: indented, bulleted, or numbered.

There are two issues with this approach:

• Where to click to add the vote? See for example the enwiki RFC in the description: the votes are in a separate subsection, there’s no leading comment you could reply to in order to vote. (Replying to the last vote would indent it an extra level.)
• It would force everyone to use the drop-down menu – this is annoying, and would inevitably lead to some votes using wrong syntax. Ideally the software would detect votes, but even if not, it should be possible to set the mode on a per-discussion rather than a per-comment level.

This file isn’t publicly visible. 🙁 Could you please click File Not Attached for this file in the Referenced files section in the upper right corner and attach it so that it becomes public? Thanks in advance!

Hi Tacsipacsi, I just noticed the above comment. I've attached the file now.

• I think normal indent should be the default and bullet/number remain optional.

A potential solution for both the first and second point could be to use a magic word to control reply tool features. Maybe something like: {{REPLYTOOL:custom text|default indent type}}

• Using {{REPLYTOOL:cast your support vote|#}} at RFA support section creates a reply link that looks as [cast your support vote], which on clicking defaults to #-indent. This magic word can force a customised text (not just [reply]) even where there is no signature.
• Similarly, {{REPLYTOOL:cast your vote|*}} at XFDs can create [cast your vote] link, which on clicking defaults to*-indent. And so on.
  • This link is shown only at the exact location where this magic word is used. It shouldn't turn every natural instance of [reply] links to the customised text & indent.

Using a magic word would probably work. (Although I think a parser tag, e.g. <replylink style="#">Cast your support vote</replylink>, would fit better, as parser functions usually output wikitext, and a reply link cannot be represented as wikitext.) It just doesn’t have anything to do with your original suggestion. 🙂

In T259865#8413525, @CX_Zoom wrote:

I've attached the file now.

Thanks!

Thanks, tbh I'm no novice on tech end and do not yet know the capabilities or lack thereof of magic words, parser functions, etc. But I thought that there could be solution somewhere with that approach. I hope that we can get something out of it. Thanks!

I'm pretty new, is there any progress on this?

@aliu: Hi, in general for any tasks, all known progress can be found in previous task comments.

I mean if there’s any updates, it’s been a couple months.

e.g. <replylink style="#">Cast your support vote</replylink>

This is exactly the sort of thing I was envisioning: a parser tag that specifies the character(s) to be prefixed (any combo of *#:) and turns into a button that opens a textbox.

In some discussions like RfA and some RfCs, there can be a heading (=== … ===) between the opening statement and !votes, so it's important that the place to insert a !vote can be manually specified by editors.

Just FYI, to get Convenient-Discussions add numbered list items, you just need to put an empty # in that section, which will convert into <ol><li class="mw-empty-elt"></li></ol> and affect almost nothing on the page. Don't know if that's a good idea for Reply Tool. But whatever you agree on, I hope that markup will have some manifestation in the DOM or at least configuration accessible by non-native scripts.