First off I don't think having "this week", "this month" or "this year" is a good idea; while it's computationally cheaper than the equivalent "last 7 days", "last 30 days", "last 365 days" it becomes kind of useless every Sunday (1st of month (like, uh, today), 1st of year).

This really becomes evident when you see a user's top tags and realize they all come from the same recent question. (Paul Nathan's top tags, e.g., are , and ; hmm, why is that familiar...)

That "problem" (I don't think it's a feature anyway) is also caused because IMHO week reputation and weekly top tags really are kind of meh; it's just not enough data to be representative. The user page would go from "always the same faces" to something quite more transient (and random); I'm not sure I like that.

The situation is even worse on new, low activity Stack Exchanges. Let's look at Bycicles:

Mah reps, let me show you them.

Yup! I just signed up. Our favourite unicorn shepherd also gets some first page action with his 1 rep change (or rather, -1 rep change).

Association bonus and downvotes counting in the leagues have been fixed in the meantime, as Jeff points out.

Here's what that users page looks like with two months of data.

So yes, I'd rather see a last rolling quarter window for something both more dynamic than what we had, more stable than what we're having and more interesting overall.

  • I thought this week means (today-7) ~ today (:
    – YOU
    Commented Mar 1, 2011 at 8:23
  • @SMark That would've been labeled "7d" (just like it is in the 10k tools)
    – badp
    Commented Mar 1, 2011 at 8:24
  • 1
    careful, we are fixing bugs Commented Mar 1, 2011 at 9:36
  • 8
    Maybe I'm the only one, but this page shouldn't have gotten past hallway usability testing. It's just ugly. My eyes go everywhere and nowhere all at once, and my brain short circuits. I don't have the energy to be more specific, nor to beat the "OMG CHANGE THIS BACK OR THE FUTURE OF OUR CHILDREN IS DOOMED" drum. So I'll just leave it at, damn that's ugly.
    – hobodave
    Commented Mar 2, 2011 at 4:21
  • 1
    This would also solve mu issue.
    – SLaks
    Commented Mar 2, 2011 at 14:25
  • 4
    Not that I've seen the team back down on any decision they've made, ever, but I'm starting a bounty on this so more people see it. As I write this, the new user page on SA shows 32 out of 36 users with a 0 next to their name. This isn't merely bad, it's completely useless.. Team, please start doing more testing and actually listening to feedback once in a while.
    – Aarobot
    Commented Mar 6, 2011 at 2:45
  • @Aarobot, oh, that's not entirely fair. How about their decision on the number of reviews a suggested edit needed to get (2)?
    – badp
    Commented Mar 6, 2011 at 9:00
  • 2
    I don't seem to remember that debate, @badp. I suppose I may have exaggerated a little, but I'm frustrated and annoyed that they would push something so bad out to the entire network apparently without doing any serious testing, and then when a horde of people come out to say "this sucks", the only response after nearly a full week is "well, we like it". That's the designer's equivalent of "works on my machine", and it's not the first time this has happened.
    – Aarobot
    Commented Mar 6, 2011 at 17:58
  • @Aarobot 32 people is barely "a horde of people", and I've always felt that the reasons against a change are more important than the number of upvotes attached to them (at least for the team). The debate about the number of reviewers happened mostly on chat.
    – badp
    Commented Mar 6, 2011 at 20:27
  • Sure enough @badp, but I also haven't heard any non-team-members speaking in support of this system, so while 32 may be a small sample size, it's telling that there's been virtually no dissent (and especially no convincing rationale from the opposite side - again, other than "we like it").
    – Aarobot
    Commented Mar 6, 2011 at 20:46
  • @Aarobot Eh, if waffles thinks "last x days" is hard to do cheaply with the existing code base, he's probably got a better picture of how hard it can exactly be than we do.
    – badp
    Commented Mar 6, 2011 at 20:52
  • If it's too expensive to do something halfway useful then they should have just done nothing at all. Regardless, while waffles surely knows more about the code and database than we do, I do know that I could whip up something like this in a matter of hours with the data.stackexchange schema and a SQL Agent job.
    – Aarobot
    Commented Mar 6, 2011 at 21:02
  • @badp see my edit
    – waffles
    Commented Mar 9, 2011 at 7:10
  • @waffles Here, have a +25. I'm still not completely satisfied, but I appreciate your efforts.
    – badp
    Commented Mar 9, 2011 at 7:40

3 Answers 3


I was also totally jarred when we discussed this feature. Intuitively I thought week = 7 days rolling ... makes sense. Always populated.

I have, however, come around to this design, because of:

  1. Parity with SE leagues - all the SE leagues work this way, it would be odd to have leagues on our sites work differently.

  2. Technically building a 7 day rolling rep count is much harder than fixed time frames.

  3. The leagues feel a lot more like a game when they have a start date set in stone. Everybody starts on equal footing and then as time progresses it stabilizes. You start the game on Sunday, finish it on Sunday and then repeat. Everyone feels like they have a chance. Not happy with the game this week, you can try playing again next week.

  4. Rolling leagues can be confusing for end-users, you feel like you made progress today, yet you made less progress than you did 7 days ago, so you drop in ranking.

That said, we still have bugs, we need to exclude the 100 rep association bonus under all conditions.

I am not convinced I would like to exclude any users from the default tab in /users as people use that page to find users.


There is a new network wide setting (Stack Overflow is excluded) that requires an interval has 6 days of data prior to being picked, SO se sites should always default to a sane tab.

  • 3
    I tend to disagree that /users must follow /leagues. Otherwise why have two pages? Leagues make sense (to an extent) to follow static dates so that you can go last month, 2 months ago etc. /users, not so much since there is only one Week/Month/Quarter, ever. If you want league data, go to league. Commented Mar 2, 2011 at 2:51
  • 6
    Okay, that's all very nice and good, but the fact remains that with the current system, you end up with utterly useless results when you're near the beginning of the time period, which, with this default, happens every week. That may be fine for rep leagues but I really don't think that the global users page should be part of the "game". If people want to play a game then the rep leagues still exist, do they not?
    – Aarobot
    Commented Mar 2, 2011 at 2:51
  • 12
    Really the bottom line is that when somebody goes to the /users page, the question in their mind is "who are the notable users here?" and not "how am I doing this week?" Parts #3 and #4 just seem totally back-asswards to me, they are answering a question that maybe 0.1% of users care about instead of the one that 99.9% of users care about. I thought the motivation for this feature was to highlight active users, not turn the entire /users page into a carbon copy of the rep leagues.
    – Aarobot
    Commented Mar 2, 2011 at 2:57
  • Rolling leagues can be confusing for end-users ? You mean like PGA or Tennis rankings that have an active tail? Commented Mar 2, 2011 at 3:12
  • @waffles It does sound quite hard, until I realize that the users' rep graphs already track denormalized reputation over time, so you already track all the data anyway.
    – badp
    Commented Mar 2, 2011 at 6:51
  • @badp - how long can you wait for your rep graph? now multiply that by.. 100000 users + anonymous? say 10 of them are hitting the /users page, to produce the list of 36 at a particular page - you're going to be doing your rep graph thing how many times? Commented Mar 2, 2011 at 10:23
  • @Richard As far as I can see, looking at the rep chart does not trigger a full reputation recalculation. Asking for the reputation for all users 7 days ago thus ought to be (not incredibly more) expensive as pulling reputation for all users right now is; obviously this näive approach gives trouble such as ignoring rep bonuses.
    – badp
    Commented Mar 2, 2011 at 11:06
  • @badp ... for 7 days it is easily doable, we just grab it from the vote table, a year becomes much more expensive ... we have to aggregate all totals from a table and then order on it
    – waffles
    Commented Mar 2, 2011 at 11:45
  • 1
    @Aarobot — the point about "who are the notable users here" is really good. I voted it up, but maybe you could post it as a question in itself to raise visibility?
    – mattdm
    Commented Mar 2, 2011 at 13:46
  • 1
    @waffles: if a year was the default period, that would be an understandable roadblock... Then again, if a year was the default period, it would only be a real problem for a short time each year. As @Aarobot notes, the default as it exists is gonna be semi-useless for a day or so every week. If a true rolling count is still impractical, then perhaps a weighted moving average would suffice... or even just a delay (show the previous week's score for the duration of the current week).
    – Shog9
    Commented Mar 2, 2011 at 18:50
  • I honestly really don't understand where the difficulty is. It's not difficult. Just denormalize the rolling week/month/quarter/year rep per user in its own stats table, recalculate it at the beginning of every day with a scheduled task, and then for the /users page, add today's reputation (which is already separately tracked and denormalized) to that number to get real-time results. There is no practical reason why one very simple daily aggregation job and a two-table join should be technically impossible or even impractical.
    – Aarobot
    Commented Mar 3, 2011 at 15:38
  • 1
    @Shog9, I also like the idea of a weighted average (strongly weighted toward the present) because it highlights current activity without totally throwing away prior activity. I worry that even a rolling total creates a disincentive to long-term participation - as in, "OK, I made it to the top spot this week, now I can finally relax." Most people are only going to look at / be interested in the default view, so it's important that the default view show people with long-term and recent contributions, not just whoever had a good day.
    – Aarobot
    Commented Mar 3, 2011 at 15:44
  • @Shog9 @Aarobot I really do want to improve this, showing a one day delay at the start of a period is a simple fix, however the rolling rep league is tricky, there is a bunch of logic that lives only in the recalc c# routines, I can get an estimate of rep for a period using SQL but it may be off by a tiny percent for certain people who hit the rep cap.
    – waffles
    Commented Mar 3, 2011 at 22:50
  • I'm not sure if a 1-delay (or any hard-coded threshold) solves the problem for low-traffic sites. Personally I'd rather see a 10% margin of error than a screen full of what might as well be random numbers. Still rather confused about the whole logic/architecture thing - you've got denormalized rep counts stored somewhere as evidenced by the rep graph, so just set up a new table and a SQLAgent job to repopulate it every day?
    – Aarobot
    Commented Mar 5, 2011 at 0:53

I must emphatically agree with this complaint. Even with the migration bonus "bug" fixed (originally we were seeing users with no posts who just registered), there's just way too much noise in the "week" display for it to make any sense as the default view.

I understand the rationale for this feature. I realize that there was a widespread sense of "what have you done for me lately?" when people looked at the old users page, and a sense of discouragement among newer members upon realizing that they would probably never make it to the front page. But a 1-week view, even if it actually worked correctly and displayed 1 full week as opposed to "this calendar week", is simply too short a time frame.

People upvote weird stuff sometimes on Stack Exchanges. We all know that there's an element of timing and flat-out randomness in voting. This isn't generally seen as a problem because it tends to sort itself out pretty well over the long term. Random swarms of upvotes are quickly lost in the ether over a period of weeks or months if you don't keep up your activity, but on every site other than Stack Overflow, reputation tends to arrive in sporadic bursts, and even the Mortarboard badge is rare.

When your "top" users have a score of 22 (some with overall scores of less than 100), something's way wrong. That's one half-decent question or answer and an accept vote (given, not received).

At least set some reasonable thresholds here, and don't show users who've had fewer than 10 upvotes or so. Or, as badp says, just use a rolling month or quarter as the default view, which will have less randomness and noise on a lower-activity SE (i.e. all of them).

Otherwise the user page is basically kindergarten for adults. Everyone's a winner! Again!

  • well, it is late Tuesday Pacific and cooking.stackexchange.com/users looks pretty solid to me; you may see frothiness a bit earlier in the week of course. Commented Mar 9, 2011 at 2:31
  • @Jeff: That looks solid to you? Honestly? There are users on the first page who haven't made a single post in months. And a number of other users who have contributed only with questions, have posted none or hardly any answers. Sure, it might look fine at a superficial glance but the results are in fact about 50% nonsense.
    – Aarobot
    Commented Mar 9, 2011 at 2:38
  • @Jeff, what if we defaulted to month if week is "empty" or "quarter" if month is empty and so on. Where empty is defined as any users exist on the first page with with 200 rep (or less)
    – waffles
    Commented Mar 9, 2011 at 4:13
  • how many days of data do you need on cooking for the list to make sense, on SO it seems pretty good after 1 day, on SU/SF I think maybe 6 days or more, how much data do you think SEs need?
    – waffles
    Commented Mar 9, 2011 at 4:36
  • @waffles: The month view looks reasonable; quarter view is better (I actually recognize most of the names from their activity). Higher-activity SEs like Gaming might be able to do with less. Your previous suggestion (dynamic default) sounds like it could work - would have to see it in practice.
    – Aarobot
    Commented Mar 9, 2011 at 14:53

The two obvious options that come to mind

  1. Treat week as a moving window of today + last 6 days (UTC)

    • This is computationally expensive, and would probably be best updated daily or at most hourly.
    • If you need to see your position change after every single vote, you are in trouble.

  2. Treat week as last week

    • This would apply equally to month/quarter
    • An option would be to rachet over to current [period] once we are more than 50% into the period, or only after a certain threshold of time has passed within the current [period]
    • Using the option of racheting over, even if it is at least 2 days into the week, would allow for the early non-sensical volatility to play no role in the /users page, giving it some modicum of stability while still allowing renewed (clean-slate) efforts every week/m/q
  • I'm not really seeing how a rolling 7 days is any more computationally expensive than a calendar week. Either way, it's an aggregate value based on data that's frequently changing. You either denormalize or cache it if you have to. Besides, I'd rather let the team worry about how to get around such issues; technical limitations are not an excuse for poor UI.
    – Aarobot
    Commented Mar 2, 2011 at 2:48
  • @Aarobot if you consider that it is reusing the /league data, it is 0 expense to produce the /users table. How is that not computationally less expensive than any other option? Commented Mar 2, 2011 at 2:53
  • 1
    Ok, sure, you've got me there, but if that is actually the reason for doing it the way they're doing it then it is a horrible reason. You should never trade what you actually need for what you just happen to have. Sacrificing user experience for a minor performance boost (or worse, to save a few lines of code) is bad bad bad juju.
    – Aarobot
    Commented Mar 2, 2011 at 2:59
  • All that being said, I think your option #2 is an okay compromise if the team intends to play the "technical difficulties" card. Just set the default window to month instead of week, and either show last month's data or add this month's data to last month's data during the first week. Way simpler than a rolling average, you just need two buckets instead of one.
    – Aarobot
    Commented Mar 2, 2011 at 3:03
  • I could accept treat week as "last week" for the first day of the week. That way stuff does not go nuts on the first day. I like non-rolling totals cause you get a better sense of "progress".
    – waffles
    Commented Mar 2, 2011 at 3:28
  • But, @waffles, this sense of "progress" is completely illusory because you lose all progress after 1 week / 1 month / whatever. If you actually really stop to think about how this system will work on an ongoing basis, it's almost completely unusable as either an ongoing progress tracker or a current activity tracker. I understand what you're going for but this just does not achieve that goal. It's the worst of both worlds on low-traffic sites, displaying random nonsense for most of the time and throwing away perfectly good data when it's finally available.
    – Aarobot
    Commented Mar 2, 2011 at 4:06
  • @Aarobot - "I'm not really seeing how a rolling 7 days is any more computationally expensive than a calendar week"....trust me, it's way (many hundreds of thousands of times) more expensive if you see how we're tracking current progress. Our reasoning is we want that clean slate just like the leagues have always had. Performance is not our reasoning, though it does perform better than any suggested alternative here. A different default sort for smaller sites? That may be a possibility, that's a feature request that I'd propose. Commented Mar 6, 2011 at 11:32
  • @Richard - that would be true, though we're not pulling data from SE here (other than your rank league)...we're calculating this real-time locally on each site whereas the leagues are daily (based entirely on total rep). Commented Mar 6, 2011 at 11:33
  • @Nick: I say again, that isn't why people go to the /users page. Have you even looked at this outside Stack Overflow? Starting with a clean slate every calendar week on a site that doesn't even get 1000 votes for the entire week is, I'm sorry I have to say this, an idiotic design. It's stupid even on high traffic sites because you already have the rep leagues. Who on earth decided that the /users page should be a crappier version of the leagues and why? Because of a few low-rep users complaining that they could never beat Jon Skeet?
    – Aarobot
    Commented Mar 6, 2011 at 18:03
  • And @Nick, you say "A different default sort for smaller sites... may be a possibility, that's a feature request that I'd propose." Is that not exactly what this feature-request is and has been for a week? I don't see a [stackoverflow] tag anywhere, and there's a screen shot from the Bicycles site specifically calling out the effects on lower-traffic SEs. I can't support this view/default on any site, personally, but what you're suggesting we ask for has already been asked for.
    – Aarobot
    Commented Mar 6, 2011 at 18:07

You must log in to answer this question.

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