Often, ad hoc polls are constructed when each user types # Support - ~~~~ or # Oppose - ~~~~ in the appropriate sections, resulting in numbered lists of all the supporters and opposers. Would this (or something similar) be possible in Flow?
Topic on Talk:Flow Portal/Archive2
Agreed. I think this is covered under Flow/Use cases.
Are you sure? I couldn't find anything like this.
See all the references to "voting" in that use case page. I know that we don't officially use the v-word for support/oppose discussion, but that's what it's referring to.
I see. I don't know why I didn't notice it before. :-)
Yeah. I use the term "!vote" pretty often. The word "vote" is easier to understand than "enumerated option comment", which is the technical term for what we're talking about.
A poll widget, with a way to specify default choices for quick submission, would be incredibly useful.
E.g.:
"Create poll" → "Set options" → you type "support" and "oppose", or "keep" and "delete", or other common selections, "comment" could be included as standard → People get a drop-down menu with the options and a text box for reasoning.
The end result looks like any other vote has done in the past, but saves people having to type "* '''Support'''" (etc) all the time. Maybe also an option to set an optional expiry time after which no further posts would be accepted.
This would not be adapted for discussions with a wide and dynamic range of !voting options such as XfDs (keep, merge, userfy, delete, incubate, redirect, comment, keep and rename, delete and salt, etc), where furthermore users often switch positions, making neat separations undesirable. Even in discussions with clear, stable and desirable separations (support/oppose/neutral for example, as in RFA - indeed perhaps the most stable and delineated process on en.wp, but its uniqueness makes of it a poor case study - and it's considered broken by most commentators so this is telling), many users make a point to qualify their !vote, such as weak oppose, provisional support, etc. There may also be resistance to changes that would seem to emphasize the numerical aspects.
It doesn't have to be a single poll widget. We could have restrictive-widgets that limit options, and open-ended workflow-widgets that allow user-entered values.
And/Or we could adapt the way we write, by placing our qualifications after the keyword, e.g.
- "Support - provisionally as long as squirrels are included..."
As in other aspects, we need to maintain the fullest extent of on-wiki customizability possible. For RFA/RFBs and some RFCs, a fixed format separating !votes along choices with the possibility of entering an optional bolded opening statement (weak support, etc) different from the default may indeed make the trick. However, for others, an all-!votes together approach (no separation) would be preferable, with selection of bolded opening comment (which may be aided by a drop down menu if needs be).
So as you suggest, we'd need two types of poll workflows: one with separation (and default votes) and one without separation, both with customizable bolded opening statements. Workflow admins should be able to tweak workflows as needed for the various ever-changing processes.
Absolutely. Possibly more than 2, or meta-poll-workflows that can be adapted into numerous subtypes. Whatever we decide we need; as malleable as legoblocks. (Hmm, possibly more like the Universal adapter set...?!)
I've added an {anchor} to Jorm's comment at en:Wikipedia_talk:Flow/Archive_1#What_Flow_actually_is as I think it covers a lot of useful ground.
I'm not sure that RFA/RFB actually require separate sections. We do that now solely because that's the only way to count the votes automatically. If Flow can keep a tally (and that seems to be planned), then there's no reason why we would need to have !votes be out of chronological order.
There are advantages to separate sections. If the candidate wants to respond to all the objections, having the Opposes in one place is useful. So too if someone wants to see, "Why did the RfX succeed/fail?" And so on.
Of course, this is a post-facto justification, not the actual reason. But the same applies to most complaints against Flow, VisualEditor, etc, etc, etc...
You are describing one of the "workflow" tools that we'll be implementing.