I recently faced a (poll) situation here on Meta where I would have loved (and failed) …
- to use Systemic Consensing [~ counting resistance instead of appraisal] (which I had started to appreciate in the weekly developer meetings in my previous job) or
- to apply the more granular Systemic Consensus Principle [~ counting resistance on an interval scale], as requested here by @faithinchaos.
Background
What happened
- Two weeks ago, I had noticed that the word “[group] owner” had not been translated consistently in the German locale (“Eigentümer” [~ owner] vs. “Besitzer” [~ possessor]). What’s more, I considered that there may be a word that is even more suitable than the two words used so far (namely “Verantwortlicher” [~ responsible] or “Verwalter” [~ manager]).
- As a consequence, I shared my finding in the dedicated feedback topic.
- I was pondering on how to best get authoritative feedback from the community with regard to which translation to migrate to, and determined that the best way an approximation of “Systemic Consensing” (to the extent currently possible in Discourse).
- In the end, I created a poll with 4 options (the two currently used words and the two potentially more suitable words), allowing every participant to choose between 1 and 4 options (
[poll type=multiple min=1 max=4 public=true]) and specifically asking everyone to choose all options they could live with (literally “all options that don’t give you a headache”).
- Result:
- Three users (A, B, C) participated in the poll.
- A and B choose 2 of 4 options and C chose 1 of 4 options .
- Two options (i, ii) got 2 votes, one option (iii) got 1 vote and another option (iv) got no vote.
- One user (D) replied (without participating in the poll) and suggested a 5th word (“Koordinator” [~ coordinator]).
- Summary: The poll was probably misunderstood (as the result would otherwise indicate a lot of headache) and failed to achieve its goal (with regard to finding the [best] option, defined by the one that most people could live with).
What’s the problem
Use case: Find the optimal translation by prompting feedback from the community.
More formally: We have an inconsistent translation S->C of a source S with a set of current translations C∈{C1,…,Cn} and we would like to prompt the community to find the optimal translation S->T, which may include new translations* N->{N1,...,Nm}; in other words: T'∈{C1,...,Cn,N1,...,Nm})
(If you don’t like the use case, think instead about finding the optimal date for a Community meeting, i.e. the date where most people would come, because they actually have time.)
Let’s assume for a moment that the use case is realistic and valid, and that a poll is a reasonable tool for it.
- Why not use a “single choice” poll (users choose one option; the most voted option “wins”)?
-
Bias: The single choice limitation divides users. It disfavors “risky” (e.g. revolutionary) options and favors “popular” (e.g. status quo) options.
- Why not use a “multiple choice” poll (users choose one or more options; the most voted option “wins”)?
-
Strategy: Users with a clear preference (or with an option that they proposed themselves) may not want to vote for a less preferred option, even if it is acceptable for them, because also voting for a less preferred option may disfavor the preferred option.
- Why not use a “multiple choice” poll and specifically ask users to choose all acceptable options or phrase the options accordingly (as suggested by Tobias)?
-
Clarity: It may not work (like in my real example). The poll doesn’t look/feel different, so users are inclined to act like they would normally in a “multiple choice” poll.
What’s the solution
For now, I have identified four aspects of the problem and its solution:
A. New options after poll start
While it is desirable to collect all options upfront, this does not necessarily correspond to reality.
- In Discourse, the question of adding new options to an ongoing poll (i.e. as soon as votes have been casted) doesn’t arise so far, simply because it is technically prevented (except for starting the poll from scratch).
- Obviously, this makes sense in “single choice” polls, since a new option is less likely to “win” (simply because it wasn’t considered by the users that voted before).
- Actually, this also makes sense for “multiple choice” polls, since the choices are de facto not independent (i.e. a new option may incline people to not have voted for another option).
- In contrast, the question “Can you live with this option?” can be answered independently for each option, which would allow new options. (And the same holds for the date-related question: “Would you have time next Saturday?”)
B. Non-binary choice
While it is comprehensible to divide choices into “chosen” and “not chosen”, this does not necessarily represent the actual choice adequately.
- In Discourse, a poll option can either be chosen or not, so it is not possible to have an “in-between” like “if need be” in a Doodle.
- A solution would be a poll parameter that enables intermediate value between “chosen” and “not chosen” (e.g. “undecided”).
- A more general solution would be a poll parameter that takes a list of values that users are then offered for each option (e.g. [0,1,2] like in @faithinchaos’s example).
C. Independent choice
While it may desirable to have users reason about each option independently, this is not necessarily likely to happen, if options are presented together.
- In Discourse, all options of a poll are shown together, so even when users are currently reasoning about one option, they also see the other options.
- A solution would be a poll parameter that lets it present its options one after another, one at a time, once a user decides to participate in a poll.
D. Empty choice
While it may not make sense to cast an empty vote in traditional “single choice” and “multiple choice” polls, this does not necessarily hold for all polls. (Note that this is somehow linked to A., because users with an empty choice may actually want to propose a new option.)
- In Discourse, a choice has to be made (as far as I know) in order to participate in a poll. This means that “participants” that don’t find a suitable choice, are currently not counted, which may undermine validity of a poll.
- A solution would a poll parameter that allows casting a vote with an empty choice. (Note that having a separate option “Empty choice.” wouldn’t be a sane alternative, because users can then still choose this option alongside other options.)
tl;dr
How could Discourse better support alternative polls like “Systemic Consensing”?
