There has been repeated UV tickets on this, all of them declined. Basically, there are a number of inconsistencies in the rep system that revolve around this: certain actions (accepting answers, having your answers accepted, winning bounties) can go above the soft daily cap of 200 but if you're below 200 they don't increase your soft cap meaning you can get ordering issues.

Lets say you've gained 190 for the day. Someone upvotes then accepts your answer. You're up to 215. If instead they accept them upvote you're at 205.

Also, upvotes can cancel out downvotes which leads to situations where you have 20 upvotes above the cap then a single downvote so lose -2 (ie gain 198 for the day) whereas if the downvote had happeend before any of the 20 excess upvotes that woudln't have happened.

I've never seen a reason for this inconsitency and such tickets are declined that the system is "by design" so I'd like to know what the "by design" part of this is and why it's like that.

  • 2
    I would also dearly love to see this particular issue resolved. The rep inconsistencies are leaning towards "silly".
    – zombat
    Aug 3, 2009 at 21:59
  • Life is inconsistent by design. Two equally talented developers will have different opportunities depending on many things, some totally arbitrary. SO just reflects that. Mar 20, 2010 at 9:42

4 Answers 4


Wouldn't it be easy if the accepted answer rep just did not count towards the cap? Just let the cap only count upvotes, and there will never be any inconsistency.

  • 7
    I suggested that on UV. It was declined.
    – cletus
    Jun 29, 2009 at 11:42
  • 2
    That sounds like it might even be easier to implement than the existing cap system Jun 29, 2009 at 11:54
  • This sounds like a good idea, i think. Jun 29, 2009 at 13:35
  • I think the cap should count upvotes and downvotes over the period, to avoid the inconsistency mentioned by cletus where 20 upvotes post-cap followed by one downvote loses you 2 rep. It's not about the 2 points, but if you're going to fix it then it's worth doing a proper job. Jul 10, 2009 at 10:11

I agree with Jon and Jeff that the reputation system is working pretty well as a whole. The thing I'm not happy about is that Stack Overflow is a community for developers and for such a community, it doesn't look good to have obvious bugs.

For example, when you are over daily cap and you downvote someone (which can happen pretty easily when you are browsing on the iPhone) and you revoke that downvote immediately, the reduced reputation will not be restored. This is not a significant thing in terms of reputation but it reflects the professionalism of the site. Changing the design as a result of bugs is not a good thing (by the way, I'm a proponent of the uncapped accepted answer behavior; I said that in general).

To quote Eric Lippert:

And when a flaw is found, changing the code to fix the flaw without considering whether the fix breaks something else is not a good problem-solving technique.
when you find a bug, consider whether your algorithm is deeply flawed to begin with before you just randomly start swapping the directions of comparisons around and break stuff that already works.

I suggest polishing the reputation part of the Stack Overflow code base and officially documenting the intentional inconsistent behavior somewhere in the FAQ.

  • +1 proper FAQ "documentation" would be very welcomed.
    – cregox
    Mar 16, 2010 at 17:23

Well, from our perspective, reputation isn't meant to be a precision tool used to build lifesaving surgical instruments or rocket ships.

It's a broad aggregate representation of the trust the community puts in you. Thus, the simple way it's calculated has been good enough.

If you are really worried about the "loss" of 5 or 10 rep due to order of operations, then I humbly suggest you're overthinking this.

now completed, see:
How do I audit my reputation?

  • 15
    TBH I What's was fully expecting a "what does 5 or 10 rep matter?" type answer. Glad I wasn't disappointed. But that's not even the issue. Inconsistency is its own problem. What's wrong with striving for consistency? Plus it can also mean 150-200 in a day if you have a badly timed bounty win (which I know I have) that eats up your soft cap. Again, rep isn't the issue but it's almost like the system is telling you that you shouldn't have bothered.
    – cletus
    Jun 29, 2009 at 10:13
  • 9
    Woah snarky. If it's a "broad aggregate" it shouln't be a number.
    – Aidan Ryan
    Jun 29, 2009 at 18:09
  • 11
    Jeff this is absolutely a bug, and a classic example of audience > author. It can't be that hard for you to change this in line with malach's suggestion and would save a lot of aggro. If 5 or 10 rep shouldn't matter for us to lose, then why does it matter for you to withold? (a stronger term than I intend, but conveys the point I think)
    – bananakata
    Jul 1, 2009 at 8:06
  • Maybe rep shouldn't be a number at all then. Only a name of what your current rep allows. That way no one sees the 5 - 10 "discrepancies" but we all still have a general idea of where everyone stands.
    – toast
    Jul 4, 2009 at 0:07
  • 9
    @Jeff The SO community is made up of people (programmers) who, for better or worse, will tend to fret about perceived bugs. As it would appear to be trivial to fix, I can't see why you can't just do it.
    – nb69307
    Jul 4, 2009 at 17:54
  • 2
    "isn't meant to be a precision tool", but still there are site features depending on this imprecision (edit, vote, etc.). Maybe SO 2.0 will have better rules "by design". I know mechanism design is a hard topic.
    – akarnokd
    Jul 12, 2009 at 12:11
  • 1
    kd304, we're talking about differences on the order of a few percentage points, for users that have tens of thousands of reputation points total. "Perspective, do you have any of that tonight?" – Antono Ego, Ratatouille. Jul 12, 2009 at 14:41
  • 8
    Sorry Jeff, but I think you're being a bit too defensive here. If you didn't want it to be a precision tool, it shouldn't use definitive numbers. "A few percentage points" or not, rep is by far one of the most important elements of the site, and the one that brings a lot of people back. Those few percentage points represent a much larger frustration level, and if the fix is simple, it's worth considering. I would firmly place this in the "bug" category.
    – zombat
    Aug 3, 2009 at 21:57
  • I never worried and also understood the concept about that, but very nice to see this got implemented, cheers
    – YOU
    Mar 20, 2010 at 9:28

I'd say that what we've got works reasonably well at the moment, even though I agree that it's inconsistent. From the sounds of it (based on previous podcasts) it's a relatively fragile system - I think I'd rather leave it alone than tinker with some tricky timing issues. On the other hand, I'd rather revisit the issue of rep caps completely: I still believe that a rep cap based on time isn't as useful as a rep cap based on a cap per post.

I'm not arguing against there being rep caps at all, and it's quite possible that whatever alternative was proposed would end up reducing my rep rather than increasing it - this isn't about personal gain, even though I'm sure it looks like it.

FWIW, this was my first UV suggestion(declined). This prompted my first mention on the podcast, long before I got anywhere in terms of rep. (I think I had about 1K rep when I posted the suggestion, back when 10K was a huge amount to have :)

EDIT: I totally agree with Jeff's point about it really not being terribly important. On the other hand, for those users who do treat it as a sort of game, it's akin to rules being inconsistent in any other game... I'd say that changing the rep system definitely counts as tinkering round the edges of the system rather than adding really significant value to the site in general. I doubt that anyone's going to get so annoyed by the inconsistencies that they stop contributing due to them.


You must log in to answer this question.

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