(Not a duplicate of Preventing bad edits from unlocking votes, as that covers users editing posts to unlock their own vote; this is about automated scripts editing posts.)

This may seem like a minor bug, and I thought so too for a long time, but I'm reporting this now because the supposed scenario I thought of at the time actually came to fruition recently. (This isn't a duplicate of that either, since that's a question asking about the scenario and why it happens; the answer points to the fact that automated script edits were made. This is a follow-up request from that answer.)

Votes are locked after a 5-minute grace period. Any edit made after that period unlocks the vote permanently. This is no matter what edit was performed (major and substantive, or really minor), and no matter whether the edit was done by a human or by an automated script written by SE.

In the above case, a user had many of their posts unupvoted as a result of the script that edited HTTP links to HTTPS a while back. Not too far while back, we had a user suspended as a result of massively unaccepting answers; such massive vote retraction would be prevented by this.

Note that we already have a special case for such edits: they are explicitly prevented from bumping posts, while other forms of Community user editing (e.g. anonymous edits) do bump posts. Can we piggyback on this to make it so that the Community user's automated script edits don't unlock votes?

  • 2
    Why is this being negatively received? Commented Sep 5, 2018 at 22:29
  • 3
    Your title initially struck me as a complaint and I was expecting to see some "woe is me I lost my rep" in the body. Reading it I see that you are recommending that the behavior of the Community user's edits be changed. That sounds to me like a feature request and I'd make that the emphasis of your title. Commented Sep 5, 2018 at 23:32
  • 3
    This whole thing assumes that we actually record some sort of special flag on an edit when it was performend automatically by something. We don't. An edit is an edit. The only thing special about automated ones is that we skipped the process for updating the "last active" flag for the post, which is what actually pushes it back onto the homepage.
    – animuson StaffMod
    Commented Sep 5, 2018 at 23:58
  • @animuson Can you also skip the process of unlocking the votes? Or is whether or not a vote is "locked" calculated only at the time of attempted retraction? Commented Sep 6, 2018 at 0:21
  • 5
    It's calculated on the fly by just looking at when the last edit was made. There is no explicit "locked" flag there either.
    – animuson StaffMod
    Commented Sep 6, 2018 at 0:23
  • @Nathaniel Title edited. I strongly believe that it's a bug, since it was abused by a user and similar behavior caused another user to be suspended. If, on the other hand, a prior bug reporting this had been dismissed as by design, I'd make this a feature request since that would be a design change. Commented Sep 6, 2018 at 0:26
  • @animuson Can we implement this by setting a "locked" flag? Or would it just be more convenient to ignore Community user edits when checking to see if a vote is locked? (I'm against that due to the recent episode of extremely substantive edits from anonymous users on this site.) Commented Sep 6, 2018 at 0:28
  • 3
    You'd have to convince someone that this problem actually matters enough that complicating the vote locking system is warranted. I'm not really convinced. Sounds like a bunch of effort to solve a problem that's only even come up once.
    – animuson StaffMod
    Commented Sep 6, 2018 at 0:36
  • @animuson The HTTP to HTTPS link change affected the majority of posts across SE, rendering votes on all those posts stretching from many years unlocked. Now that this loophole has become public by the question I linked here, people may start exploiting it. If you're still not convinced, what action can be taken against the specific user involved in the un-upvoting there? Commented Sep 6, 2018 at 0:40
  • 3
    This is not a big problem. Why do you care if some votes can be changed because of an automatic edit? There are hundreds of other things it would be better for developer time to be spent on. Commented Sep 6, 2018 at 0:50
  • 1
    @curiousdannii Disregarding the dev time spent on this, is this a good suggestion in principle? Also, we have our first documented incident of someone abusing this, and once is enough in my opinion. Commented Sep 6, 2018 at 0:51
  • 5
    No. It's not a problem. I don't even really like vote locking in the first place. Commented Sep 6, 2018 at 0:53

1 Answer 1


I don't really like vote-locking (especially on metas), but given that we have it, it should behave consistently for all edits. Community♦ edits just aren't that special. If somebody has exploited it to conduct "targeted unvoting", deal with that user.

I'm pretty sure that the way vote changes work for the vast majority of us is: we vote at some point and move on. Sometime later the question crosses our screen again and we think "no wait, my vote on that was incorrect" and try to cancel it. If there's been an edit that works; if there hasn't it doesn't. It doesn't matter what the edit was; most people in this situation don't look at it and are evaluating the post anew. (I'm not talking about cases where you were involved in a discussion after which you want to change your vote.)

Feature requests need to make a convincing argument to invest in making a change, especially if that change would make the code more complex and the interface more confusing. ("Wait, that edit was after my vote -- why can't I reverse it?", said confused users on metas across the network.) This question argues on the basis of a single incident and speculation that enough people to matter will deliberately exploit it to punish specific users. I find that reasoning insufficiently convincing.

A final note: scripts aren't the only thing that cause edits attributed to Community♦, so you can't just look at who edited when the state needs to be calculated.

  • This was a bug report, but animuson retagged it as a feature request. Commented Sep 6, 2018 at 1:08
  • 2
    And you rolled it back. SE employees get the final word on what is or isn't a bug. It was functionally a feature request from the start. Commented Sep 6, 2018 at 1:09
  • Also, I said in the bottom of the post that I'm only referring to script edits. Commented Sep 6, 2018 at 1:09
  • And animuson already explained in comments why it can't be done at the point of origin, which means all Community edits look the same when it matters. Commented Sep 6, 2018 at 1:10
  • So your final note is irrelevant, because I already know that and already pointed that out in the question and in comments. Commented Sep 6, 2018 at 1:11
  • I put it there to anticipate the next argument -- ok, we can't do it from the script, so let's just look at the editor. That doesn't work. And I'm not going to invest a lot of energy on whether it would work when it's not a good idea in the first place. Commented Sep 6, 2018 at 1:11
  • Why is it "not a good idea in the first place"? Disregarding the dev time and complexity, is this a good request in principle? Commented Sep 6, 2018 at 1:13
  • 6
    No it's not. I explained that already. Commented Sep 6, 2018 at 1:13

You must log in to answer this question.

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