Consistency between start and due dates

I also think that current state of start_date vs due_date is inconsistent. For the dropdown menu there is already a reported bug #826916 and the sollution is in progress.

GTG 0.2.4's behavior is wrong. We would like to add further features for planning in GTG and it request an assertion that due_date > start_date or due_date is set to no date. What to do when a user violates that? We could do several things:

1, Show a popup window to user and tell him that it was wrong, ala MS Windows => we don't want to do that because GTG shouldn't bully user for not changing due_date first
2, Set due_date to start_date
3, Postpone due_date by the difference of start_date. This is not so common use case and would result in modifying due_date too often. (e.g. I would like to start working on that task tomorrow but I can't postpone due_date)

Therefore we should go with the option #2.

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.

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?

On Mon, May 21, 2012 at 11:01 PM, Antonio Roquentin
<email address hidden> 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     : <email address hidden>
> Unsubscribe : https://launchpad.net/~gtg
> More help   : https://help.launchpad.net/ListHelp

--
Bertrand Rousseau

Thank you Bertrand, thank you Izidor.