gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Tue, Jun 08, 2010 at 11:21:24AM -0400, Paul Natsuo Kishimoto wrote:
> > What I'm sure is that we don't want the GTK UI to display the priority.
> > That's something that was one of the basics of GTG when we started it.
> > Don't mess with artificial priorities : it simply add workload on the user.
> > The Now, Soon and Later just provide the required information. 
> 
>   Right, and I didn't mean to suggest that. In the GTK UI, at least, the
> user would not see or directly edit the priority. But if the user
> started dragging-and-dropping tasks into different orders in the Work
> View or full view, then I think a priority would be the best way for GTG
> to remember that information.
> 
>   What does everyone else think?

I'm unversed in the original philosophizing that Lionel alluded to
regarding gtg's avoidance of prioritization, so don't take my opinion
here as representing the correct view.

But coming at it from my own angle (derived from spending altogether too
much time triaging X.org bug reports) I am not a big fan of manually set
priorities (ala high/med/low), as they tend to be a mix of importance,
urgency, severity, and other such abstract, extrinsic value judgments.
And then, all else being equal, I work on the high priorities first.

Looking at my own task list I can see some items which would be very
high to do on weekends but low during the week, and vice versa.  Others
which I *really* want to get done, but honestly aren't that important.
Others which are important in some contexts but not others.

In working on X.org bug reports, while I set priorities on bugs I hardly
ever pay attention to them for actually prioritizing my work.  Rather,
I've come to using a variety of specialized searches to help me filter
and sort so good work items bubble up; these are based on intrinsic
properties - bugs with patches attached, bugs that are fixed upstream,
bugs that have been tested with the latest X.org versions, etc.

So, coming from this mindset, with gtg I tend to favor also using
intrinsic parameters here for prioritizing tasks.  Tasks with due dates
coming soon, tasks that have parents and grandparents depending on them
being done, tasks that have already been bumped and rescheduled several
times, etc.

Anyway, I state all this not as an argument against having manually
priorities - like I mentioned, I do take them into account for bugs but
only secondarily - but rather that it may benefit us to think about
prioritization via means other than just an extrinsic 'priority' field.

> On Mon, 2010-06-07 at 23:14 -0700, Bryce Harrington wrote:
> > It's also interesting to think that, knowing the duration per task, and
> > number of tasks, you could quite directly figure out when you have too
> > many tasks scheduled on a given day.  Mmm, that could be handy...
> 
>   What we could do is this: in the UI, if the user selects multiple
> tasks in the Task Browser, a tooltip or other text could say "At least X
> hours" or similar. "At least" if some of the tasks have no duration set.

Actually I've got a branch I should merge at this point, with a new
feature that could make use of this in an obvious way.  Stay tuned.

>   I don't know about assuming a default duration. Personally, I write
> tasks as things I think of as atomic, i.e. I do the task by habit once I
> start it. Sometimes those are quick (Take out the garbage = 5 min.) and
> sometimes long (Do laundry = >2 hours, interspersed with other stuff).

Well, my 'default' really I mean 'average/typical', so for you it might
average to be 1 hr per task, so as a broad stroke if you don't bother to
give durations to either of those tasks they could be assumed to be 1 hr
each, and while the time estimate would be wrong for each task, it would
come to the correct total.

>   Perhaps the UI could have a preferences checkbox and some dropdowns:
> "[X] Assume tasks take [30] [minutes] to complete." By the act of
> setting these, the user would acknowledge that GTG is estimating the
> duration. I certainly wouldn't put this in the data model, tho.

Yeah, agreed.

Bryce