Task priority

Another way to do this would be through Triage Status, as is used in Chandler [1]. This is a very effective way of ordering tasks.

[1] http://chandlerproject.org/

Thanks for the idea. You could explain a bit more what is a "Triage status" and how you would see it in GTG ?

I've tried chandler several times without never succeeding using it for more than a few minutes.

Hi Lionel! I've also had a few false starts with Chandler in the past. It does have a few nice features which it would be good to see in GTG though. Let me explain the Triage Status thing a little more...

Functionally, triage status (I'm just going to call it status) would work in the same way as priority. It is a ranked sequence which is applied to your tasks. The terms are different though. With status, instead of having a sequence that goes 'High', 'Medium', Low', you have a list that goes something like 'Now', 'Soon, 'Later', 'Done' (Chandler uses 'Now', 'Later', 'Done'). You'd probably have a column in the tasks pane which would contain the status, and which you'd use to sort your tasks (you can see this in Chander).

The main difference between status and priority is in the meanings it communicates and the kinds of work flows it produces. Priority seems essentially reactive. Status is a more proactive way of viewing and organising your tasks. In this sense, status allows use cases that priority does not:
 - A user starts GTG. They want to immediately see the tasks that they are currently working on.
 - A user wants to use GTG to decide which tasks they will work on after they have completed their current tasks.
etc.

One problem with priority which status avoids is that it doesn't map to the sequence in which a user wants to complete their tasks. A high priority task might not need to be done for a long time, for example. ('Due date' is unable to serve this function, imo. Status is categorical - it is an ordinal assignment, not an interval one. Hence it is orientated towards the grouping of tasks. The way I work (and I think most people work), is by focusing on a small number of tasks at any one time, rather than just one. Further, status allows the temporal ordering of tasks which don't have fixed due dates.)

Seems interesting.

If I understand correctly, from an implementation point of view, it's only about changing the words "High, Medium, Low" into " Now, Soon, Later" ?

I don't really like "High-Medium-Low" so it looks interesting to me. Personnaly, I use tags for more or less the same : I've one "urgent" tag and one "someday" tag. I'm interested by your approach but I'm curious to hear Bertand about that (he's the real conceptual thinker of the team)

On Tue, Mar 3, 2009 at 2:04 PM, Lionel Dricot <email address hidden> wrote:
> Seems interesting.
>
> If I understand correctly, from an implementation point of view, it's
> only about changing the words "High, Medium, Low" into " Now, Soon,
> Later" ?
>
> I don't really like "High-Medium-Low" so it looks interesting to me.
> Personnaly, I use tags for more or less the same : I've one "urgent" tag
> and one "someday" tag. I'm interested by your approach but I'm curious
> to hear Bertand about that (he's the real conceptual thinker of the
> team)

These aspects regard the work-flow perspective of GTG, which are in a
very early stage of decision/development (as I just said in Bug
#337008). I am very interested in knowing more about the different
existing systems in place, so thank you for you bug reports, Allan.

Regarding this specific bug, I cannot decide clearly what's the best.
My take is that, indeed, priorities like "High", "Medium", "Low" does
not fit, because, sincerely, nothing is ever "High priority", "Medium
priority", etc. So chandler-like priorities "Now", "Soon", etc. are
very interesting since it better fits our mental model of
organization, I guess ("I must do <x> now, <y> can wait, and I must
not forgot about <z> even though it's not required now"). So, if we
were to implement task priority, I would clearly opt for this latest
solution.

<metadiscussion>This discussion is also related to the
tag/places/inbox discussion since all thoses elements interact
together to build a work flow, so if we decide something, we must keep
those aspects in mind. My feeling about all this is that tags are
handy since it is a very flexible tool for organization but it comes
too short for implementing a complete workflow, so we probably need a
more complex organization toolset with priorities,
categories/places/..., inbox, etc. The constraints being that it
should not inforce a specific workflow (keep flexibility: not everyone
is using GTD, and not every GTD-addict is using it in its "pure" form)
and it should keep everything very simple, with simple and clear basic
tools.</metadiscussion>

So, in conclusion, if we decide to implement priorities, using
Chandler-like words is fine for me.

> --
> Task priority
> https://bugs.launchpad.net/bugs/313695
> You received this bug notification because you are a member of Gtg
> developers, which is the registrant for gtg.
>
> Status in Getting Things Gnome!: Confirmed
> - Show quoted text -
> Bug description:
> Task should have a priority : low, medium, high.
>
> The work view should display tasks by order of priority and the (future) random task chooser should always choose an high priority task.
>
> By default, the priority of a task should be high (in order to be sure that you will never miss a quickly added task)
>

--
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : <email address hidden>
tel : +32 485 96 69 86

Can the method be combined? Sometime I may have task which is very important , but I don't need to do right now. For example, you may need achieve a course project , otherwise you will fail on the course . It need to be finished within this month. So you still have time to do another thing. The task is "high" priority , but can do it "later".

On the other side, you may have task which is not important , but you need to do it soon. For example, you may want to buy milk but the shop will be closed within a hour. If you don't go out , you can wait for next day. Then the task is "low" priority" , but should do it "soon".

Could explain a bit more how you use these "untimed" priorities? Can't
you flag the "Buy milk" task as "Now", and the "Course project" as
"Soon" for instance?

On Wed, Mar 11, 2009 at 3:44 AM, Ben Lau <email address hidden> wrote:
> Can the method be combined? Sometime I may have task which is very
> important , but I don't need to do right now. For example, you may need
> achieve a course project , otherwise you will fail on the course . It
> need to be finished within this month. So you still have time to do
> another thing. The task is "high" priority , but can do it "later".
>
> On the other side, you may have task which is not important , but you
> need to do it soon. For example, you may want to buy milk but the shop
> will be closed within a hour. If you don't go out , you can wait for
> next day. Then the task is "low" priority" , but should do it "soon".
>
> --
> Task priority
> https://bugs.launchpad.net/bugs/313695
> You received this bug notification because you are a member of Gtg
> developers, which is the registrant for gtg.
>
> Status in Getting Things Gnome!: Confirmed
>
> Bug description:
> Task should have a priority : low, medium, high.
>
> The work view should display tasks by order of priority and the (future) random task chooser should always choose an high priority task.
>
> By default, the priority of a task should be high (in order to be sure that you will never miss a quickly added task)
>

--
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : <email address hidden>
tel : +32 485 96 69 86

Keep it simple, please.

If you want to have priority, juste use TAG for this.
@urgent, @low @medium, etc...

What i can imagine is a plugin or a built-in feature that allow you to declare in which order (depending on _some_tags) you want to have the view sorted.

I like the idea of triage status ("now", "soon", "later") suggested above. However, it made more sense for me to implement it as a form of due date, so they can coexist in the sorted list with items with traditional due dates. Often, tasks have a relative timeframe but are not necessarily due on an exact date.

For sorting purposes,
"now" = tomorrow
"soon" = in one week
"later" = in one year

The code is in the branch:
https://code.launchpad.net/~kevin-mehall/gtg/fuzzy-due-dates

Let me know what you think of this idea and/or implementation.

I was thinking : could we make this a bit less hackish and more cleaner by defining our own date object (even if we cannot subclass the datetime python object) and by using it everywhere?

A good indicator would be that there will be no "from datetime import date" left anywhere except in tools/dates.py.

What do you think? Would it require a lot of changes?

Just a note: I noticed that once any of the three "now" "soon" and "later" button is pressed, it will never go unpressed again graphically, even if it keeps working fine.

Lionel> That's a good idea. I'll try that and see if it ends up simplifying things. It shouldn't require too many changes outside of dates.py.

Luca> That's odd. They aren't toggle buttons (but maybe they should be), and I'm not sure why a regular pushbutton would look pressed when it's not being clicked.

Luca> I might have found what you're talking about. The buttons remain highlighted (as if the mouse were over them) when the calendar is re-opened. Moving the mouse onto the button and off again resets it to its normal state. This may be because the popup window is hidden before the button can receive the "mouse-leave" event, so it stays highlighted. It also happens to the "Clear" button.

Kevin> Yes, it does happen also with the clear button. Should we open another bug to GTG on this matter?

After using your branch yesterday, I cannot use the trunk anymore. I'm already addicted! I want it in 0.2, no matter what ;-)

I rewrote the patch, adding a Date class with RealDate, FuzzyDate, and NoDate subclasses. That allowed a ton of refactoring and simplification of date handling throughout GTG. Task objects now store Date instances rather than constantly converting between "y-m-d" strings and datetime.date objects.

It's stable for me, but it could use some testing.

Good work. I did some testing, and I've noticed that if you open a task and set as start date anyone of the fuzzy dates, the one you choset get set as the due date instead of the start date.

I fixed the bug with the start date. Thanks, Luca!

Anything else that needs to be changed before this is merged?

I'm thinking that maybe 'soon' should sort as 2 weeks or 1 month away rather than 1 week to put more real due dates closer to the top. Any thoughts? How soon is 'soon'?

Hi Kevin, I think that 2 weeks is fine as a first try for "soon". We could change that with the feedback of the 1.9 if needed anyway.

This is ready to merge for me. Nice work Kevin. You had to dive in several GTG places, not an easy work. I'm really glad that you did that :-)

Does it makes sense to have those priority in the "start date" field ? It looks confusing to me and not really needed, isn't it?

I agree

Luca > what do you think about merging first, solving minor issues afterward ?

Definitely. Plus, maybe some user prefer to have a fuzzy start date.

I went ahead and merged this branch.

I don't know if fuzzy start dates are useful. (I don't really use the start date field much anyway.) It should be easy to hide the buttons on the start date calendar popup if that is what you decide is best. Let me know if you want me to do that.

Kevin > thanks a lot for the merge ! /me is happy \o/

A fuzzy start date is a total waste. Start date purpose is to hide tasks from the task view. Start date has no other effect. Putting a fuzzy start date would put the task definitely out of the taskview, which is not intuitive (and, in my mind, not useful).

I can't see any use case for a fuzzy start date.

-> +1 to remove it.

I hid the buttons on the start date calendar popup. If users really want to set fuzzy dates as start dates for some reason, they are still able to type 'now', 'soon', or 'later' into the text box.