gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Mon, Jun 4, 2012 at 1:03 PM, Izidor Matušov <izidor.matusov@xxxxxxxxx> wrote:
> Hi Bertrand,
>
> Nice pics! I would just say, that moving start date shouldn't update other
> start dates. We want from subtasks to be rather steps you have to accomplish
> before working on the main task than a "container" for subtasks. In other
> words, when I have planned a trip (14.6. - 20. 6.) and I have a subtask "Buy
> ticket" which should be done between 10.6. - 12. 6., according to you trip
> has to have start date 10.6.
>
> IMHO the only constrain for start date should be that start date < due date.
> In the current GTG it is more a planning mechanism (way how to hide task in
> workview) than something rigidly set.

All right, I'll update the drawing accordingly. That should help to
get a clear documentation on this behaviour.

>
> Izidor
>
>
>
> On 06/03/2012 10:33 PM, Bertrand Rousseau wrote:
>>
>> Hi,
>>
>> In order to (hopefully) make this stuff clearer, I've made an
>> illustration showing how I perceive the different situations happening
>> when changing the due date or the start date of a task. The
>> illustration is available here (in png and svg):
>>
>> https://docs.google.com/open?id=0B0KMTVA0nZXUdEVFNDB2akcydTg
>> https://docs.google.com/open?id=0B0KMTVA0nZXUVVY5eHlVYUpvckE
>>
>> For each kind of parent/children configurations, I tried to identify
>> how I think the parents and children dates should be affected when the
>> start/due dates of a task is changed.
>>
>> I think it's a good way to maintain consistency when changing dates,
>> mostly because it corresponds to how a visually-oriented
>> representation such as the one used in the illustration should behave.
>> Indeed, I think this visual representation corresponds to the natural
>> way of representing tasks in a timeline, which makes it interesting
>> and could maybe be used sometimes in GTG (this would make sense IMHO,
>> even though I have no idea about where or when we could use it).
>>
>> Please note that in this proposition, I think that only dates that are
>> explicitely set should be updated when necessary, other should be left
>> unset. Indeed, IMHO, setting no date implicetly means that this date
>> actually extends to all permitted time (take look at the illustration
>> to get a clearer idea about this), and this meaning should not be
>> altered by setting a specific date.
>>
>>
>> Bertrand
>>
>>
>> On Tue, May 29, 2012 at 1:01 PM, Nimit Shah<nimit.svnit@xxxxxxxxx>  wrote:
>>>
>>>
>>> Hey!
>>>     While working on the date structure. I got this doubt:
>>>     consider a structure A (due next month)
>>>                                   -- B (due tomorrow)
>>>    Now suppose, the user tries to set the start date of B to some later
>>> date than next month. What should I do? As of now. I am shifting B's
>>> start_date and due_date to the due date of A.
>>>   Izidor gave these suggestions:not change the start_date of B.
>>>                                              push the change of
>>> start_date and due_date over the whole structure (up and down).
>>>
>>>   Any suggestions, which of the approaches should I go ahead with?
>>>
>>> Nimit Shah,
>>> B Tech 3rd year,
>>> Computer Engineering Department,
>>> SVNIT Surat
>>> Secretary ACM-NIT Surat
>>> www.dude-says.blogspot.com
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~gtg-contributors
>>> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~gtg-contributors
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>> Bertrand Rousseau
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~gtg-contributors
>> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~gtg-contributors
>> More help   : https://help.launchpad.net/ListHelp
>
>



-- 
Bertrand Rousseau