launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 13 April 2011 20:35, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> On Wed, Apr 13, 2011 at 10:12 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>> As a user, I think being approximate is generally speaking fine, with
>> a couple of caveats.
>>
>> There are some counts that people want to drive to 0, such as critical
>> bugs, new bugs, inprogress bugs, maybe high bugs, maybe bugs assigned
>> to me.  If the count for them doesn't go to 0, or conversely if it
>> goes to 0 when some items still exist, it will be
>> annoying/confusing/frustrating.
>
> This is a good point; my prototype schema will never show 0 as nonzero
> - it will only show nonzero (calculated using source data) as possibly
> higher-nonzero (calculated using the summary table).

As John mentioned, saying there are 3 critical bugs when there are
actually 2 is nearly as alarming.

In short, if there are so few bugs in a class that they could all
appear on a screen (say <50) and the user could count them by hand,
people will notice if it's not precise.  I don't know if that is
reasonable to implement in your approach.

I think there is a history of bugs to support the thesis people do
notice discrepancies at small absolute values.

> Indeed. OTOH I think with 2 critical *private* bugs you'd been quite
> unlikely to be subscribed twice. IMBW.

If you mean having two different subscription paths to see the bug, I
think it does happen.  Subscription is used for a bunch of things in
Launchpad, including the dupefinder offering to subscribe you (and I'm
pretty sure that's independent of whether you're already implicitly
subscribed.)  I think another case is apport bug filing directly
subscribing you even if you're already in a team that can see it.

> I would like the API to use these summaries as well where we can. We
> have a bunch of work to do to break the assumption that the results
> set is at all like a list object first; my current batchnav 1.2.4 work
> goes someway towards that, but there is more to do.

+1

Martin