I don’t know !
Just checked https://meta.discourse.org/ and they’re no help… the documentation doesn’t
mention ranked choice polls…
Bastards.
Test poll, to try to figure out how rounds increment. Which would you most want to eat?
- Ice Cream
- Pie
- Cake
- Cookies
- Candy
- Bacon
- Fruit
- Olives
- Medicine
- Liver
- Dirt
- Worms
- Diet worms
0
voters
I see DcnDc posted such a poll in your polls thread; that has 32 votes and … 1 round.
(Maybe you could post this one there - it’ll get more traffic there.)
What the hell? Ice cream wins after getting the majority of the 1 votes? I don’t see any settings to define rounds and whatnot.
I just voted…
I can’t find any documentation or even references to how this works.
Yeah, that doesn’t make sense. After round 2, ice cream and cookies are tied, and ice cream and cookies were therefore eliminated???
Weird. I am finding it difficult to believe any of the results of the ranked choice poll. I guess I’d rather see a histogram. Thanks for voting!
It looks like it just always shows you the results as they currently stand, however many votes there are. As more votes come in the results will change. Currently, Ice Cream, Cookies, and Bacon are the tied winners–presumably because they were the #1 choice for each of the three submissions.
I just vandalized the results by voting diet worms #1, worms #2, and dirt #3.
The results seem consistent to with my understanding of ranked choice voting so far.
We need enough voters to get away from all the candidates having just 1 or zero votes.
I asked on the Discourse website and received the following reply
from the Ranked Choice Poll author :-
OK, I think I get it. A “round” is more like a loop counter, and when anyone answers the poll, the looper re-analyzes the votes. So if we suddenly had 100 people come vote for Fruit, eventually the results would be “Fruit wins in Round 1”. No folderol needed to eliminate worms and such.
Thanks for the research on this.
Since polls don’t exactly close, it only makes sense that whenever a new vote is cast, the whole process has to be re-run from scratch to determine who’s in the lead now. It’s just a more elaborate computation than the simple tallying of votes we’re used to in our primitive single vote first past the post voting.
e.g When the current tally is 9 to 6 in favor of “tastes great” over “less filling” then 5 votes show up for “less filling”, we don’t find it surprising that the score changes to 11 to 9 in favor of “less filling”.
The nature of ranked preference or STV voting is that the leader can be far more unstable as more votes accumulate when you have a lot of nearly equally desired candidates. It’s much more stable if you have two front runners and a handful of also-rans.
Testing dictation function on my new tablet. Yay! It works! That is all. Carry on.
Can you nest a spoiler within a spoiler?
Yes, you can!
It even makes it extra blurry. Which is good because I can pretty much read the spoilers through the first level of blur.
You can even nest a blur spoiler inside a summary spoiler AKA “Hide details” as the menu calls it:
Summary
This text This text will be blurredwill be hidden
The opposite, a summary spoiler inside a blur spoiler does not work quite right; the summary works, but the outer blur does not:
[spoiler]This text
Summary
will
be blurred[/spoiler]
Some experimentation shows that a blur spoiler can contain at most one consecutive paragraph break or it’ll malfunction, while the result of a summary spoiler generates multiple adjacent paragraph breaks, plus whatever adjacent break(s) may be in the payload.
Like this:
Here’s a blur with no breaks, but long enough to word wrap:
This text This text will sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurredwill be hidden.
Here’s the same thing with one paragraph break stuck in the middle:
This text This text will sfsdfsd sdfsddfs
sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurredwill be hidden.
With multiple separated paragraph breaks stuck in the middle:
This text This text will sfsdfsd sdfsddfs sdfsd
sfsdfsd sdfsddfs
sdfsd sfsdfsd sdfsddfs sdfsd
sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurredwill be hidden.
With two adjacent paragraph breaks stuck in the middle it goes haywire:
This text [spoiler]This text will sfsdfsd sdfsddfs
sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurred[/spoiler]will be hidden.
Oops.
You can work around this limitation by using two adjacent HTML <br/> tags to give you your desired visible paragraph break(s) with a blank line between them like this:
This text This text will sfsdfsd sdfsddfs
sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd
sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurredwill be hidden.
You could also use a single ordinary paragraph break with a <br/> just ahead or behind the break like this:
This text This text will sfsdfsd sdfsddfs
sdfsd sfsdfsd sdfsddfs sdfsd sfsdfsd sdfsddfs sdfsd
sfsdfsd sdfsddfs sdfsfsdfsd dfsd be blurredwill be hidden.
I personally prefer the dual <br/>s method but that’s just HTML coder’s taste, not functional difference (that I have noticed).
ETA: Here’s a whole thread on nested spoilers:
Late Add:
Interesting discovery:
My examples in that thread render differently now versus how they rendered when I wrote that post. Most of the point I was making about a shortfall in Discourse rendering of nested summaries has since been fixed.
Discourse, like any actively maintained hunk of software, is a moving target.
Pretty cool!
It does (if the tags are on their own lines, as with so many other tags) …
Summary
Some text
…but you can’t then re-blur it by clicking again (it just toggles the hide details on & off), but
then, why would you want to ?!
Cool. You’re certainly right and I was wrong. I had only tried it with the spoiler tags inline. Oops on me for failure to be thorough enough.
But that shortcoming can be overcome with yet more cleverness at the cost of more vertical space:
.
Summary
Some text
.
Once you’ve unblurred you can click on the lines with the “.” above and below the summary to reblur.
I threw a few hidden spaces after the "."s to make the clickable region larger and easier to hit with mouse or fingertip. Of course there’s nothing special about using “.”. I could have put “[click here to reblur]” in there just as well.
Even better if your prose naturally wants a larger blurred area with an embedded summary in it someplace. Then the preceding & subsequent text serve naturally as the clickable reblur anchors:
In the beginning
Summary
Rest of Bible goes here
Amen.
testy McTestFace