Seems like this problem will solve itself once we implement auto-
triaging of events to DONE.
From other users on the design/users list however, it doesn't sound
like this is the common case.
On Nov 1, 2007, at 4:41 PM, Bobby Rullo wrote:
There is a bug (https://bugzilla.osafoundation.org/show_bug.cgi?
id=10759) which says Cosmo UI takes too long to load.
The reason it takes too long to load is because there are lots and
lots of NOW items, and we always return all NOW items in the
dashboard query.
The reason there are lots and lots of NOW items is because people
don't triage their items.
Those are the facts. What is less certain is WHY people don't
triage their items - I suspect it's for a number of reasons such as:
a) They don't use triaging
b) It takes too long to triage each item manually
Esther was the impetus for filing this bug - she went to view the
Mitch8 calendar and it had 38 pages of NOW items. She and Mitch
don't use the triaging bits of Chandler right now, so she never
triages stuff to DONE. (For clues to _why_ she doesn't use triaging
see http://lists.osafoundation.org/pipermail/chandler-users/2007-
August/000437.html and the rest of the thread. Esther wants finer-
grained/customizable statuses for one thing...)
Several ideas on how to fix this problem have been proposed. From
the bug comment:
We could limit the amount of items returned in the now query to
some arbitrary
number.
We could have add the ability to triage more than one item at once
We could have a feature which turns triaging off.
We could have a feature which makes the auto-triaging/tickliing
behavior a
little different, so that (optionally) events tickle into DONE
instead of NOW
One other idea which might be the simplest to do is to have a
preference for the default view. Presumably, people who aren't
using the Triage features don't have much interest in the dashboard
view.
The trick is though, where do you persist the preference? If it's
by user, what does that mean for people who are viewing the
collection via a ticket? Do we just go with the owner's preference?
Do we have per-collection preferences for this?
Anyhow, doing this seems to be the minimal amount of work to solve
bug 10759, but in the long term being able to perform actions on
multiple events as well as controlling how triaging works is
important.
Feedback appreciated!
bobby
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
