scheduling all not completed tasks

[Oleg Pavliv]

Once a task is done I add "actual:end" date and "actual:priority 900".
I also set a flag 'done' to be able to report it in the status report.

task t1 "t1" {
effort 4d
allocate myself

#once it is done
actual:end 2012-04-03
actual:priority 900
flags done
}

I want that all tasks which are not finished (that means without
'actual:end' and/or 'flag done') to be scheduled from Now.
So all finished tasks are scheduled before now and not-finished after
now.
I understand that the past schedule might be not coherent - there may
be some free (or overloaded) resources.
For me it's totally acceptable.

I saw that I can do something similar using booking tasks and tracking
scenario, but for me bookings are too complicated to use.
I want to mark a task as done by only adding a couple of lines to the
task, like actual:end or a 'done' flag. But I don't want to mess
around with bookings.

Can I achieve this with the taskjuggler?

Thanks in advance for you replies

[MaS]

I can't provide an answer towards the path you are trying to go. But this is how I do it.

I use booking - i want to know the deviations between my estimate and true effort.
I guess you can avoid bookings this way:

Definately do not change you original plan. Use a seperate file, somethng like "progress.tji". In this file provide supplements to the individual tasks, for example:

supplement some.task {

actual:start 2012-02-01-09:00
actual:effort 2d

}

Use the attribute complete = 100 in your report to identify finished or unfinished tasks.

Regards,
Mas

> --
> You received this message because you are subscribed to the "TaskJuggler Users" group.
> To post to this group, send email to taskjugg...@googlegroups.com
> To unsubscribe from this group, send email to
> taskjuggler-us...@googlegroups.com
> For more information about TaskJuggler visit http://www.taskjuggler.org

[Oleg Pavliv]

Thanks for your answer.

I don't understand how supplement to a task can be used to my purpose.

I want to have the schedule which is up-to-date.
That means:
- all tasks which are DONE should be scheduled in the past according
to their 'end' attribute
- all tasks which aren't done should be scheduled in the future
according to their dependencies and priorities

Schedule in the past may be not accurate (overtime and gaps are
possible). I don't care about it.
But I don't want the taskjuggler to schedule not completed tasks in
the past as if they were done.


For me it's the most natural way of scheduling.
And I can't believe that nobody wanted to work this way.

On May 12, 9:48 pm, MaS <marcs...@googlemail.com> wrote:
> I can't provide an answer towards the path you are trying to go. But this is how I do it.
>
> I use booking - i want to know the deviations between my estimate and true effort.
> I guess you can avoid bookings this way:
>
> Definately do not change you original plan. Use a seperate file, somethng like "progress.tji". In this file provide supplements to the individual tasks, for example:
>
> supplement some.task {
>
> actual:start 2012-02-01-09:00
> actual:effort 2d
>
> }
>
> Use the attribute complete = 100 in your report to identify finished or unfinished tasks.
>
> Regards,
> Mas
>

> Am 08.05.2012 um 14:44 schrieb Oleg Pavliv <oleg.pav...@gmail.com>:
>
>
>
>
>

[Christian Egli]

Oleg Pavliv <oleg....@gmail.com> writes:

> Schedule in the past may be not accurate (overtime and gaps are
> possible). I don't care about it. But I don't want the taskjuggler to
> schedule not completed tasks in the past as if they were done.
>

> And I can't believe that nobody wanted to work this way.

You're not the only one. I'm still trying to find out how to convice the
scheduler to do this. IIRC Carl Worth has been trying to do something
along this line (and I think he found a solution). Check the archives.

Thanks
Christian

--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

-----
Tag der offenen Tuer
Die SBS laedt Sie herzlich ein: 30. Juni 2012 von 9 bis 16 Uhr.
Mehr Informationen erhalten Sie unter www.sbs.ch/offenetuer

[Mathieu Clabaut]

On Mon, May 14, 2012 at 9:21 AM, Christian Egli <christi...@sbs.ch> wrote:

Oleg Pavliv <oleg....@gmail.com> writes:

> Schedule in the past may be not accurate (overtime and gaps are
> possible). I don't care about it. But I don't want the taskjuggler to
> schedule not completed tasks in the past as if they were done.
>

> And I can't believe that nobody wanted to work this way.

You're not the only one. I'm still trying to find out how to convice the
scheduler to do this. IIRC Carl Worth has been trying to do something
along this line (and I think he found a solution). Check the archives.

I think you have to put the start, end, complete and scheduled attributes... Something like : 

task xx "XX" {

      start 2012-02-03

      end 2012-02-08

      complete 100

      scheduled

} 

Thanks
Christian

--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

-----
Tag der offenen Tuer
Die SBS laedt Sie herzlich ein: 30. Juni 2012 von 9 bis 16 Uhr.
Mehr Informationen erhalten Sie unter www.sbs.ch/offenetuer

[Oleg Pavliv]

What I found so far is the following workaround:

I define a task 'now'

task now "now" {
start ${now}
}

and I add the depends to all my not completed tasks.
It works but it's horrible. Because I need to add it for all leaf
tasks.
And for some deep tasks I need to write:

task deep_leaf {
depends !!!!!!now
}

[Oleg Pavliv]

Well, actually, I don't need to put all these exclamations before
'now'.

depends can refer the absolute ID.

[Damo]

I agree totally.

This is definitely a poor part of an otherwise great piece of
software. The logic MUST be that if a task is not complete or has no
bookings, it cannot be in the past, otherwise it is a real failing.
Sometimes we don't want to schedule by dependencies. Sometime the
sequence is not important. Sometimes we just want to put in effort and
see where the scheduler pushes the activities to.

I thought that the purpose of "projection {strict}" was to enforce the
determination of completion on the bookings listings. But this is now
deprecated, as we are told that the enforcement is now automatic. Yet
if a task hasn't started, it can have no bookings. With no bookings
and no dependencies, the task gets wrongly deemed as completed some
time in the past. This is a circular argument that cannot work.

TJ3 is great, but please Mr. Schlaeger, sort this one out.

Damo

[Carl Worth]

On Mon, 14 May 2012 09:21:42 +0200, Christian Egli <christi...@sbs.ch>
wrote:

> Oleg Pavliv <oleg....@gmail.com> writes:
>
> > Schedule in the past may be not accurate (overtime and gaps are
> > possible). I don't care about it. But I don't want the taskjuggler to
> > schedule not completed tasks in the past as if they were done.
> >
> > And I can't believe that nobody wanted to work this way.

Yes, this is exactly how I want to work as well.

> You're not the only one. I'm still trying to find out how to convice the
> scheduler to do this. IIRC Carl Worth has been trying to do something
> along this line (and I think he found a solution). Check the archives.

The archived discussion I had on this point is here:

http://groups.google.com/group/taskjuggler-users/browse_thread/thread/64293f7acb7818a1#

My team is still using the solution I described there, (namely, we set
an "end" date when a task is complete).

With TaskJuggler 3.1.0 this does what we want. Namely, completed tasks
appear in the past, and only incomplete tasks are scheduled in the
future.

Unfortunately, with the bug fix that Chris described in the above-linked
thread, this behavior isn't the same with 3.2.0, (instead, TaskJuggler
3.2.0 simply gives errors for our input file).

So our team is currently sticking with 3.1.0 until we can come up with
some solution that will let us use a newer TaskJuggler.

We're considering adopting a workflow where we simply remove completed
tasks from the input file. This would have a couple of disadvantages:

* We would lose the ability to generate reports of completed tasks.

That is, we couldn't use TaskJuggler to generate these reports. We
could still use our git history to find tasks that have been
completed.

* In addition to deleting a completed task, we would also need to
delete any dependencies on the task.

This part would be a nuisance.

But then we could at least start using 3.2.0.

What I would prefer is a simple attribute to set on a task that would
force it to be scheduled in the past. The way that "end" did this in
3.1.0 was actually pretty good. If I wanted to be very careful about
recording past history, I could set "end" and "effort" correctly and the
task shows up at the correct position in the past.

Chris, is there any chance we can get something like that in the future?

-Carl

--
carl.d...@intel.com

[Chris Schlaeger]

On Fri, May 25, 2012 at 6:50 AM, Damo <noreall...@gmail.com> wrote:
> I agree totally.
>
> This is definitely a poor part of an otherwise great piece of
> software.  The logic MUST be that if a task is not complete or has no
> bookings, it cannot be in the past, otherwise it is a real failing.
> Sometimes we don't want to schedule by dependencies.  Sometime the
> sequence is not important. Sometimes we just want to put in effort and
> see where the scheduler pushes the activities to.
>
> I thought that the purpose of "projection {strict}" was to enforce the
> determination of completion on the bookings listings.  But this is now
> deprecated, as we are told that the enforcement is now automatic.  Yet
> if a task hasn't started, it can have no bookings.  With no bookings
> and no dependencies, the task gets wrongly deemed as completed some
> time in the past.  This is a circular argument that cannot work.

Strict projection mode is enabled for a scenario if there is any task
with bookings. This affects all tasks in this scenario, whether they
have bookings or not. If you don't see this, it may be a bug. Please
post a small sample project and I will look at this.

Chris

[Chris Schlaeger]

On Fri, May 25, 2012 at 11:17 PM, Carl Worth <cwo...@cworth.org> wrote:
> What I would prefer is a simple attribute to set on a task that would
> force it to be scheduled in the past. The way that "end" did this in
> 3.1.0 was actually pretty good. If I wanted to be very careful about
> recording past history, I could set "end" and "effort" correctly and the
> task shows up at the correct position in the past.
>
> Chris, is there any chance we can get something like that in the future?

I'm thinking about a scheduling mode that would respect the 'complete'
attribute to record past effort. Due to the lack of fine grain
allocation information, I would have to disable all booking related
values in the reports though. I still need to investigate all the side
effects though.

Chris

[William Everett]

Dear Chris,

This is good news. I would be very intersted in being able to use "complet" to track progress even if it means disabling the bookings facility which we don't intend to use anyway. What we actually do at our project meetings is estimate the effort remaining to complet the task. The percentage complet is then calculated from the effort already spent and that remaining. Doing things this way means we revalidate the total effort required at each meeting and confirm the budget. So an alternative to using "effort" and "comple" could be to use "effort done" and "effort remaining". Would this be possible ?

Best regards, William

---

De : Chris Schlaeger <cschl...@gmail.com>
À : taskjugg...@googlegroups.com
Envoyé le : Vendredi 1 juin 2012 21h47
Objet : Re: [taskjuggler-users] Re: scheduling all not completed tasks

--
You received this message because you are subscribed to the "TaskJuggler Users" group.
To post to this group, send email to taskjugg...@googlegroups.com
To unsubscribe from this group, send email to

taskjuggler-users+unsub...@googlegroups.com

[Chris Schlaeger]

On Mon, Jun 4, 2012 at 12:41 PM, William Everett <wdre...@yahoo.fr> wrote:
> Dear Chris,
>
> This is good news. I would be very intersted in being able to use "complet"
> to track progress even if it means disabling the bookings facility which we
> don't intend to use anyway. What we actually do at our project meetings is
> estimate the effort remaining to complet the task. The percentage complet is
> then calculated from the effort already spent and that remaining. Doing
> things this way means we revalidate the total effort required at each
> meeting and confirm the budget. So an alternative to using "effort" and
> "comple" could be to use "effort done" and "effort remaining". Would this be
> possible ?

Well, that's the challenge I'm looking at. Without bookings (or
incomplete bookings) I'd have to disable every value that is
calculated from bookings. And that's a lot. Anything effort related,
resource lists, every cost function. I'm not sure if that's worth the
exercise.

Chris

[Carl Worth]

I would be very interested in this.

Our project is considering moving from TaskJuggler 3.1 to TaskJuggler
3.2 and had decided for now to simply start deleting completed tasks
From the input file, (which isn't ideal, of course).

We're currently not using any booking statements, so we wouldn't miss
anything in the reports that relies on those.

But I'm not sure what all the side effects might be on the code itself.

Please let me know if I can be of any assistance with testing or
anything, (I have not yet dived into the implementation of TaskJuggler
itself).

-Carl

[Chris Schlaeger]

On Thu, Jun 7, 2012 at 2:09 AM, Carl Worth <cwo...@cworth.org> wrote:
> Chris Schlaeger <cschl...@gmail.com> writes:
>> On Fri, May 25, 2012 at 11:17 PM, Carl Worth <cwo...@cworth.org> wrote:
>>> Chris, is there any chance we can get something like that in the future?
>>
>> I'm thinking about a scheduling mode that would respect the 'complete'
>> attribute to record past effort. Due to the lack of fine grain
>> allocation information, I would have to disable all booking related
>> values in the reports though. I still need to investigate all the side
>> effects though.

I've tried various approaches to support such a sloppy tracking mode.
Unfortunately, I haven't found a way to implement this without causing
major problems or crude hacks. Bookings are such an integral part of
the internal scheduling and reporting engine that they are required
and cannot be easily faked. All methods I came up with are at least as
much effort as using the --freeze option once a week. I found that
even deleting old tasks is more effort than using the --freeze
feature.

Chris

[Carl Worth]

Chris Schlaeger <cschl...@gmail.com> writes:
> I've tried various approaches to support such a sloppy tracking mode.

Thanks for looking.

> Unfortunately, I haven't found a way to implement this without causing
> major problems or crude hacks.

It's funny, because the old version TaskJuggler (3.1) is still doing
almost exactly what we want, (via the "end" attribute rather than
"complete", but the behavior is what we want). And if I recall it was a
fairly minor code change you made that fixed this ''bug''.

I haven't looked at the internals at all yet, but if we had this
functionality before, (even if accidentally), doesn't that suggest it
might still be possible?

> All methods I came up with are at least as much effort as using the
> --freeze option once a week.

We haven't actually tried using --freeze, but if I understand it
correctly it's not much use for us. Our team tends not to execute
_exactly_ according to what the schedule says, (nor spend the effort to
get the plan to reflect _exactly_ what their intent is).

So if I understand --freeze correctly, it wouldn't help us.

> I found that even deleting old tasks is more effort than using the
> --freeze feature.

For us, getting --freeze to work would require something like lots of
careful tweaking of priority values to get the scheduler to give us an
order reflecting reality. That's harder than what we're doing currently.

And for our team, this would feel like fighting the tool rather than
benefiting from it. When we have a set of N tasks without dependencies
between them we know that we can choose any one of them to start
with. When we see TaskJuggler present one particular order for these
tasks, we don't have any interest in trying to get that order to match
our plans. Instead, we want to just start coding, (and watch
TaskJuggler figure things out as tasks get completed).

-Carl

--
carl.d...@intel.com

[Wenzel Kalus]

interesting discussion. 

I also was struggling with new tasks scheduled in past and handling of finished tasks.

This is how I manage our projects successfully (version 3.0 and 3.2):

tasks that are finished get start, end, effort, resource, complete 100 and scheduled attribute. "scheduled" is important, otherwise, taskjuggler

considers these tasks within its scheduling algorithm ...causing problems.

For tasks that are in process, the start date is calculated from now - some days reflecting the spent efforts. All other tasks

start now, unless there is some fixed start day. The tjp file is generated out of our task/milestone database ...and well,

the resulting reports (gant) are really valid and quite good. Unfortunately, efforts (all kinds of column ids) for past tasks are reported as 0...

which is a pity/bug or ...I missed a trick.

hope it helps

2012/5/8 Oleg Pavliv <oleg....@gmail.com>

--
You received this message because you are subscribed to the "TaskJuggler Users" group.
To post to this group, send email to taskjugg...@googlegroups.com
To unsubscribe from this group, send email to

taskjuggler-us...@googlegroups.com