On Mon, Jun 4, 2012 at 1:03 PM, Izidor Matušov <[email protected]> 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<[email protected]> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~gtg-contributors >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> -- >> Bertrand Rousseau >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~gtg-contributors >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~gtg-contributors >> More help : https://help.launchpad.net/ListHelp > > -- Bertrand Rousseau _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
