Consistency between start and due dates

Asked by Roquentin on 2012-05-18

Suppose I have a task whose due date is already set. What is the expected behavior of the application if I try to set the start date after the due date? I see at least two possible events that may trigger this:

1) I accidentally select the wrong start date
2) I want to postpone the task and decide to define the new start date first

I find the current behavior somehow inconsistent. In 0.2.4 shipped with Precise, I am apparently allowed to set start date > due date, GTG does not complain. In the trunk version (rev.1179) I can still do that from the dropdown menu, but changing dates in the task window would behave differently: if start date > due date, due date is set to start date.

Before filing a bug report, please let me know what is GTG supposed to do in this case. For instance, the Thunderbird Lightning plugin would simply not allow start date > due date.

Question information

Language:
English Edit question
Status:
Solved
For:
Getting Things GNOME! Edit question
Assignee:
No assignee Edit question
Solved by:
Roquentin
Solved:
2012-05-22
Last query:
2012-05-22
Last reply:
2012-05-21
Izidor Matušov (izidor) said : #1

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.