14

I recently got this question in the Close Votes queue (screenshot for <10k users). Before I voted to close it, it had 2 votes to close it as a duplicate, 1 vote to close it as "off-topic" and 1 vote to close it as "unclear what you're asking". I voted to close it as "unclear what you're asking".

So at the end, there were two votes to close as a duplicate and two votes to close as "unclear what you're asking". According to this answer, the last close vote will be used to determine the close reason in case of a tie. In this case, the last close vote was mine and the reason was "unclear what you're asking". But it was still closed as a duplicate.

What's going on here? Is this a bug? Is the answer I linked to wrong? Is there a special case for duplicates? Something else?

Improve this question
7

1 Answer 1

Reset to default
11

Looks like there's a slight bug here...

Normally, the way consensus is determined when closing is by...

  1. Sorting all relevant close votes, newest-first
  2. Grouping those sorted votes by close reason
  3. Sorting the groups by # of votes in each group, largest-first

If all groups have exactly 1 close vote in them, the oldest (first) vote is used as the reason for closure. Otherwise, the first group in the list is used.

(this gets slightly more complicated for off-topic, but we can ignore that here)

Now, here's where it gets interesting: the grouping and sorting in steps #2 and #3 is stable - it won't change the order of votes within a group or between groups that have the same number of votes, and groups are created in the order their key first appears in the list. Since that list is sorted newest-first, the first group in the resulting list will be either the one with the most votes or the newest one with the most votes in the case of a tie. So clearly, the system works as it has been documented and the scenario you're describing cannot have occurred.

...Unless I lied about step #1. Which, it turns out, I did!

Seems it's a bit dodgy trying to store a vote and immediately retrieve it - sometimes it wouldn't be retrieved. So to fix that bug, the logic was changed to retrieve all previous votes, then store the new one, then add the new one to the list of retrieved votes and continue with the process.

...Only problem is, the vote gets added to the end of the list. Which was sorted newest-first.

And so you get what we saw here.

6-6-2018: fixed

The fix for the problem described above involved changing a call to List<T>.Add(vote) into one to List<T>.Insert(0, vote). Also a comment for the next person to mess with this logic.

Improve this answer
13
  • "...Unless I lied about step #1. Which, it turns out, I did!" Are you telling us little lies?
    – Anne Daunted GoFundMonica
    Commented Mar 1, 2018 at 18:43
  • 2
    sweet, sweet lies, @Anne... (It probably won't surprise you to learn that I wrote this post as sort of a stream of consciousness as I researched this behavior)
    – Shog9
    Commented Mar 1, 2018 at 18:45
  • 1
    So basically, when sorting the votes newest-first, it actually puts the last vote last, while the first four in the sorting order are the first four that were cast, newest first?
    – Sonic the Anonymous Hedgehog
    Commented Mar 1, 2018 at 19:00
  • 1
    Right, @ano: 4,3,2,1,5
    – Shog9
    Commented Mar 1, 2018 at 19:01
  • So how easy is it, from the technical side, to fix this?
    – Sonic the Anonymous Hedgehog
    Commented Mar 1, 2018 at 19:02
  • Pretty easy. But not high priority
    – Shog9
    Commented Mar 1, 2018 at 19:02
  • So would this be status-planned, status-deferred, or status-declined? Or status-reproduced?
    – Sonic the Anonymous Hedgehog
    Commented Mar 1, 2018 at 19:03
  • None of the above, @ano. We don't currently have a tag for whatever this is.
    – Shog9
    Commented Mar 1, 2018 at 19:08
  • status-ehhhhhh-it-kindaworks ;p
    – Journeyman Geek
    Commented Mar 2, 2018 at 6:59
  • Giving preference to the oldest vote in case of a tie doesn't seem logical anyway, considering that question could have been edited, and clarifying comments could have been added since that vote. In most cases, a more recent vote will be a better informed vote. The bug is an improvement on the original design.
    – user315433
    Commented Mar 2, 2018 at 18:37
  • That bit is by-design, @FTP, although I can see the philosophical argument for changing it. In any case, 5 different close reasons is an extremely rare event; maybe happened a few dozen times in the entire history of SO.
    – Shog9
    Commented Mar 2, 2018 at 18:46
  • Comment goes like "Dear next person who mess with this logic, you'll have to confront Shog first"?
    – Shadow Wizard
    Commented Jun 6, 2018 at 14:00
  • 1
    Comment says something like "keep list sorted when adding not yet live vote"... Though now that I think about it, linking to this thread would've been more helpful. Oh well. That's why blame exists.
    – Shog9
    Commented Jun 6, 2018 at 14:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .