gtg team mailing list archive

[Bertrand Rousseau <question197755@xxxxxxxxxxxxxxxxxxxxx>]

Question #197755 on Getting Things GNOME! changed:
https://answers.launchpad.net/gtg/+question/197755

    Status: Open => Answered

Bertrand Rousseau proposed the following answer:
On Mon, May 21, 2012 at 11:01 PM, Antonio Roquentin
<question197755@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Question #197755 on Getting Things GNOME! changed:
> https://answers.launchpad.net/gtg/+question/197755
>
>    Status: Answered => Open
>
> Antonio Roquentin is still having a problem:
> Thanks, great to know you are working on this. Let me just elaborate a
> little bit. To be precise (and maybe pedantic sorry), I see multiple use
> cases: the user may set
>
> 1. due_date < start_date (i) on purpose or (ii) accidentally
> 2. start_date > due_date (i) on purpose or (ii) accidentally
>
> To minimize the occurrence of 1.ii and 2.ii GTG might indicate which
> dates are incompatible with the current value of either due_date or
> start_date, depending on the chosen menu. An elegant way may be to grey
> out these incombatible dates in the calendars (very much like when you
> are selecting the dates for a trip). I don't know how difficult it is to
> implement this, maybe it's not worth.
>
> For 1.i and 2.ii, I think it would be nice to provide a reasonable new
> value for the other date. If I had already defined both start and due
> date, it means I had already estimated the amount of time needed by this
> task and it would make sense to repropose this time span as the time
> difference between the two new dates. Actually I don't see a reasonable
> use case for 2.i: it may mean I am trying to postpone a task, but to
> achieve that I will most probably redefine the due date first.

Unfortunately I don't know how we could differentiate the use case
where the user has previously defined a specific due date because of a
deadline (which could be moved prior the start date for some reason),
and the use case where the user has defined a due date following
his/her estimation of the required work time.

I'd say that since GTG use the parameter "due date" and not "requied
work time", we should not consider the time span between the two date
as the defining parameters, but the date themselves. Therefore
specifying an incompatible due/start date pair should redefine the
pair as being the same date. In the absence of more information,
that's the best we can do.

Maybe we could consider later to give the possibility to the user to
specify either a start date/due date pair or a start date/total work
time pair (those choices would be exclusive). Depending on the chosen
pair, we could then differentiate the behavior when incompatible dates
are entered.

> I am not sure I understand your option #3. But the simple option #2 will
> probably be fine.
>
> Anyway, since you are working on this it probably doesn't make sense to
> open a bug, right. Or does it?
>
> --
> You received this question notification because you are a member of Gtg
> developers, which is an answer contact for Getting Things GNOME!.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg
> Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg
> More help   : https://help.launchpad.net/ListHelp


-- 
Bertrand Rousseau

You received this question notification because you are a member of Gtg
developers, which is an answer contact for Getting Things GNOME!.