Survey: faster pages or accurate bug counts
Rob asked on the launchpad-dev list whether people would mind seeing slightly inaccurate bug counts on some pages in Launchpad, if it meant the page would load faster.
So, if a project had 503 bugs its bug overview page might report that it has 500 bugs. However, for small numbers Launchpad would continue to report an accurate number, as the difference between three bugs and, say, no bugs is immense.
What do you think? Is a slightly inaccurate bug count a price worth paying for a faster page load? The survey closes 17.00 UTC Monday.
If you can’t see the survey embedded in this post, follow this link.
Create your free online surveys with SurveyMonkey, the world’s leading questionnaire tool.
April 14th, 2011 at 1:46 pm
I’d rather have a faster page, I wouldn’t mind seeing “About 500 bugs” instead of “502 bugs”, because I wouldn’t do much with that specific info. If I wanted to know the exact bug count for some reason, I’d use something else anyway (API?).
April 14th, 2011 at 2:16 pm
Why can’t you have both?
April 14th, 2011 at 3:00 pm
As long as it reflects that, ie “~500 bugs” and not “500 bugs” then it’s fine.
April 14th, 2011 at 3:26 pm
I don’t think there’s anything wrong with returning approximate results, as long as they are not passed off as being accurate (scientists and engineers nearly always quote a tolerance or certainty in addition to the value itself).
Sometimes the answers might even be wildly out: this is what Google does, for instance it might say “About 174,000results”, and if you click down to page 50 you’ll actually find that it’s 259,813 as that level of detail is calculated.
April 14th, 2011 at 4:45 pm
I wonder who would care about 500 vs. 503 bugs.
April 14th, 2011 at 9:37 pm
@Albert the issue is one of cost.
We have 750K bugs, 900K bug tasks, and 10% are private (e.g. security fixes, private projects and so forth).
When you visit https://bugs.launchpad.net/ubuntu the query to get bug stats – like how many are new, untriaged, critical etc – ends up doing a table scan on the bug table (bugs have no context, only *tasks* know that they are for Ubuntu, or for a given package). That table scan and data summing take ~4 seconds in every plan we’ve tried.
If we build an aggregate model of the data – precalculating this – we can get completely accurate figures for public bugs, but because there are multiple ways an individual might see private bugs (e.g. they might be in the ubuntu security team *and* be the person that filed the bug in the first place) the aggregates can overcount *private bugs only*. We could mix aggregates for public bugs and direct queries for private bugs, but it would be slower than just using aggregates – as well as being a bit more complex. Most folk deal with few private bugs, and those that do tend to be more experienced users – my intuition is that we can do the simplest aggregate for now, and enlarge it to be more precise in private bug situations in the future.
@Paul I agree that we need to explain about the figures if they are going to be confusing people.
April 15th, 2011 at 5:54 am
I wonder what the results would be if you asked people:
In order from 1 to 4, would you rather Launchpad
a- got faster
b- got new features
c- had more polish on existing features (ie fixes to non-crash bugs or poor ui)
d- was more reliably available
April 19th, 2011 at 5:12 pm
[…] Last week I asked what you’d prefer: faster loading pages that may have slightly inaccurate bug counts or slower loading pages where the bug counts were guaranteed to be accurate always. […]