-5

Stack Exchange has vote locking:

Locked Vote

This feature should be removed. Instead, if an upvote is revoked enough time later, no reputation is changed (the poster keeps the reputation the upvote originally conferred and the voter keeps the penalty for any downvote given).

There isn't a very good explanation for why it exists: Why do votes get locked?. The best answer is to prevent tactical downvoting, but vote locking isn't an effective defense against this (permanently losing 1 reputation to gain the 10s of reputation from extra upvotes seems well worth it).

There seems to be a category of other problems, such revenge un-upvoting (where a user revokes their upvotes of a specific other user's posts) related to the change in reputation from revoking upvotes. This is why I suggest not having reputation change after a vote has stood for long enough. This would also help against tactical downvoting as the downvote becomes non-refundable after a certain amount of time.

Locked votes cause a number of other problems:

  1. The world changes. An answer that was right five years ago may no longer be right today. I should be able to change my vote to a more current answer if I revisit the question.

  2. It prevents people from changing their vote after working with an answer and seeing the full consequences of its proposed solution.

  3. It works very poorly with the trending votes feature currently being A/B tested because it prevents you from asserting that your vote on a question is still current.

  4. Comments to a post can change the meaning without an edit, but don't allow for changing of votes (only editing the post allows for it).

  5. Locked votes likely causes extraneous edits to posts just so votes can be recast.

Note: in response to feedback, I have edited this proposal to include a provision for locking the reputation from votes.


Note to moderators: I believe this question is sufficiently different from Can we get rid of locked votes or have a longer grace period? that question is more specifically about extending the grace period because you may discover that an answer is bad after working with it (point #2 above). This question is about a broader class of issue.

8
  • 12
    I disagree. There have been cases in the past where users have abused the system to go through and revenge unupvote, i.e. remove all their past upvotes toward another user, for the same reason as revenge downvoting, once votes ended up getting massively unlocked following mass automated script edits. While the team considers that a violation of policy, they will not restore lost rep in such cases. Apr 21 at 18:01
  • 4
    @SonictheSaveUkraine-hog, limiting the (daily) number of unupvotes may be more appropriate to avoid abuse than locking all old votes. It even prevents users from editing a question to perform a revenge unupvote.
    – m7913d
    May 2 at 15:38
  • 1
    Related (four days later): Vote lock timer of 5 minutes too short May 2 at 21:10
  • @m7913d With an edit, it's much easier for moderator action to be taken, since the edit unmasks the user performing the unupvote. This allows local moderators to more quickly deal with the user than if there were no edit, which would require a staff member to query the database to find out who did it. Also, you could have a user who patiently removes the limit number of votes every day, and there's still the issue of the ensuing rep loss being permanent. May 2 at 21:30
  • 1
    There's also another issue I thought of, and this ties into problem 1. In my view, even if an answer later becomes outdated, the user should still be able to keep the rep they earned from the time it was useful: as I said earlier, retracting the upvote would undo the reputation gain. It's why deleted posts that score high enough don't incur a reputation loss when deleted a long time later. May 3 at 5:59
  • @SonictheSaveUkraine-hog, requiring the edit just to quickly identify the user who did the unupvote seems to be a misuse of the side effects of editing a question and/or a bad SE design. SE may just log/show old unupvotes the same way as an unupvote after an edit.
    – m7913d
    May 3 at 7:31
  • 3
    The upvotes of an answer are, in my opinion, in the first place an indication for how good/well received the answer is. Most people are not interested in how much rep this question has added to the user. Just don't decreasing the user rep in case of an old upvote may tackle your concern (similar to special handling of deleted high score questions.
    – m7913d
    May 3 at 7:35
  • 1
    @SonictheSaveUkraine-hog I've updated the post to suggest having the reputation get frozen after some amount of time rather than the vote. This should solve all of your issues
    – Zags
    May 4 at 14:18

1 Answer 1

4

The world changes. An answer that was right 5 years ago may no longer be right today. I should be able to change my vote to a more current answer if I revisit the question.

The world changes. War History never changes. If a post was useful N years ago, it was useful N years ago, nothing is going to change that. Upvote is an atomic unit of usefulness on the Stack Exchange network, it does not just "go away" with time, and is not transferrable. Frankly, unupvoting a useful answer in favor of a newer one just because it is newer is borderline misuse of the voting system.

It prevents people from changing their vote after working with an answer and seeing the full consequences of its proposed solution.

The voting system is not a perfect one. In an ideal world, users should vote on an answer only after assessing all potential ramifications of relying on the solution provided. However, we do not live in a perfect world, but that is just an unfortunate circumstance. Leave a comment describing why the post turned out to be harmful, and future visitors, if they agree, will vote accordingly.

It works very poorly with the trending votes feature currently being A/B tested because it prevents you from asserting that your vote on a question is still current.

That is a valid concern, and should be provided as feedback on the post (which you actually did before this request, so thank you for doing the right thing). However, this is a reason to improve the trending sort feature, not a reason for getting rid of the vote lock.

Comments to a post can change the meaning without an edit, but don't allow for changing of votes (only editing the post allows for it).

Same issue as with realising the post was actually harmful a significant time later — we do not live in a perfect world. However, other users also see those comments and can vote on the post accordingly. That said, there might exist a solution of if we allow the lock to be lifted once if enough users mark it as such (but that is outside the scope of the proposal in question). You might also be interested in this and this discussions on allowing vote changes after new comments, there is some merit to it.

Locked votes likely causes extraneous edits to posts just so votes can be recast.

True, they sometimes do indeed (although it's been considered as a valid measure since times immemorial)), and that is probably the strongest argument towards doing something about the vote locking system, but it is still possible to address without removing the lock itself.

11
  • If upvote is atomic/doesn't go away, why do we allow an unupvote after an edit? Maybe, we should decouple reputation (=doesn't go away) and old unupvotes (or even old downvotes?). Note that upvotes and reputation are already partially decoupled in case of deleted answers (see comments above).
    – m7913d
    May 3 at 7:46
  • 2
    It's both upvote and downvote, @m7913d. We allow unvoting after edits because edits make posts better or worse (as opposed to time) - the quality of the post possibly changed, increasing or decreasing the usefulness of the post. May 3 at 12:07
  • 2
    If a post was useful N years ago, who the heck cares? Either it's useful now or it isn't.
    – user253751
    May 3 at 12:51
  • 2
    Because it does not change the history, @user253751 - if it was useful, it was useful. If there is a newer answer, it should get its own votes, not redistribute them from an old answer. May 3 at 12:55
  • 1
    @OlegValteriswithUkraine that still makes no sense. History is irrelevant. Other answers are irrelevant. If an answer is not useful then it should not be upvoted.
    – user253751
    May 3 at 13:00
  • mind substantiating that, @user253751? Last time I checked, we were building a repository of knowledge with content rated based on its quality, not applicability to the whims of today. May 3 at 13:04
  • 2
    @OlegValteriswithUkraine A repository of knowledge applicable to today, or a repository of knowledge applicable to N years ago?
    – user253751
    May 3 at 13:05
  • 2
    A repository of knowledge applicable to all times, @user253751. Not everyone is doing the latest thing - the existence of a newer way to do something does not invalidate the old and hence should not invalidate votes made. I am not sure what else I can say if that is not obvious enough, good luck! May 3 at 13:08
  • 2
    @OlegValteriswithUkraine Well, it doesn't work that way. What was applicable to Gradle 1.0 is not applicable to Gradle 7 and should not be the top answer to a question asking "How do I do this thing in Gradle?"
    – user253751
    May 3 at 13:10
  • It may remain in case somebody is looking for facts about Gradle 1.0, but it should not be a default answer for searches that merely specify "Gradle"
    – user253751
    May 4 at 9:04
  • So? Searches should not "merely specify Gradle" when they are seeking Gradle 7. Nor should they ignore the tags on a question (or for SO, the answer). You get what you ask for. Ask better to get better.
    – Nij
    May 6 at 9:52

You must log in to answer this question.

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