legalnonsense/elgantt

Re-using dynamic dependency definition syntax like, e.g., org-edna

Opened this issue · 3 comments

novoid commented

Hi,

Disclaimer: I'm not a user of your elgantt yet and currently, I don't have the personal/business requirement for generating Gantt charts. However, I'd love to see a Gantt solution that I'd use in case I need it. If this solution comes with almost no additional effort, I do think that me as well as many more people would use elgantt in their daily life as an additional visualization even for smaller projects. Therefore, this discussion does not necessarily reflect your strategy for elgantt but I'd like to have discussed my ideas with you.

My personal approach for defining tasks for a project that hold dependencies would be org-edna. Although I'm a user of org-depend, for project management, I'd switch to org-edna because it offers much more features in comparison.

This way, I'd define dynamic dependencies such as:

  • task A has an estimated execution time of 3 days
    • :EFFORT: 3d property according to manual
  • when task A is finished, task B has to start immediately
    • :TRIGGER: ids(taskB) scheduled!(".") todo!(TODO) via org-edna
  • task B is estimated with 2 days
  • when task A is finished, task C should start 3 days afterwards
    • :TRIGGER: ids(taskC) scheduled!("++3d") todo!(TODO) via org-edna
  • task C is estimated with 1 day
  • and so forth.

This is all possible with standard Org + org-edna features. The big advantage is that I don't have to define specific dates for all scheduled and deadline dates/times. When task A takes longer than 3 days, the other tasks get shifted automatically.

Using your current elgantt approach (:ELGANTT-LINKED-TO:, SCHEDULED + DEADLINE), I'd have to re-schedule and "re-deadline" all tasks that are not done yet.

Therefore, my personal approach would be:

  • the proprietary property :ELGANTT-LINKED-TO: would be replaced or extended by various :TRIGGER: properties of org-edna using dynamic linking
  • SCHEDULED + DEADLINE: could be used as well but only for fixed dates because of external dependencies you can not influence

Related links:

legalnonsense commented

Have never looked at org-edna before but it looks interesting. You should be able to do what you are describing but I'd need to see a sample org file to be of much help.

novoid commented

Hi @legalnonsense,

I'm starting with org-edna myself, as I am switching from org-depend.

Here is an example snippet you might find useful. In the example, the tasks B and C both depend on task A while task D depends on task C.

As you can see, with enable org-edna, the Org workflow is supported as is supposed to be: headings get their todo keywords and get scheduled according to the finalization day/time of the previous task from where they are depending on. This enables a flexible definition of a project with relative dates for Gantt charts instead of "hard-coded" dates which result in manual effort in case one single task takes longer than expected.

Therefore, this would reflect the usual project management workflows much better: define efforts and dependencies within the Org headings and periodically derive a temporarily Gantt chart to see the current state of the project. An archive of previously generated Gantt charts then shows you how the project developed over time. Meta-data of tasks that took longer than expected can be found properly with standard Org syntax.

I refrained from adding examples with fixed deadlines since you already know their implications which does not change when using org-edna. Please also notice, that the documentation of org-edna demonstrates much much more features that might be handy for managing projects. I just wanted to focus on a minimal set of features I would use in my projects.

First, the initial state of this "project":

*** TODO task A
SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:EFFORT: 3d
:ID: taskA
:TRIGGER: ids(taskB) scheduled!(".") todo!(TODO)  ids(taskC) scheduled!("++3d") todo!(STARTED)
:END:

*** task B
:PROPERTIES:
:ID: taskB
:EFFORT: 2d
:END:

*** task C
:PROPERTIES:
:ID: taskC
:EFFORT: 1d
:TRIGGER: ids(taskD) scheduled!(".") todo!(WAITING)
:END:

*** task D
:PROPERTIES:
:ID: taskD
:EFFORT: 5d
:END:

This is what you get, when you finish "task A":

*** DONE task A
CLOSED: [2020-07-31 Fri 13:03] SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:EFFORT: 3d
:ID: taskA
:TRIGGER: ids(taskB) scheduled!(".") todo!(TODO)  ids(taskC) scheduled!("++3d") todo!(STARTED)
:END:

*** TODO task B
SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:ID: taskB
:EFFORT: 2d
:END:

*** STARTED task C
SCHEDULED: <2020-08-03 Mon>
:PROPERTIES:
:ID: taskC
:EFFORT: 1d
:TRIGGER: ids(taskD) scheduled!(".") todo!(WAITING)
:END:

*** task D
:PROPERTIES:
:ID: taskD
:EFFORT: 5d
:END:

And that is the result when "task C" gets marked as done:

*** DONE task A
CLOSED: [2020-07-31 Fri 13:03] SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:EFFORT: 3d
:ID: taskA
:TRIGGER: ids(taskB) scheduled!(".") todo!(TODO)  ids(taskC) scheduled!("++3d") todo!(STARTED)
:END:

*** TODO task B
SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:ID: taskB
:EFFORT: 2d
:END:

*** DONE task C
CLOSED: [2020-07-31 Fri 13:04] SCHEDULED: <2020-08-03 Mon>
:PROPERTIES:
:ID: taskC
:EFFORT: 1d
:TRIGGER: ids(taskD) scheduled!(".") todo!(WAITING)
:END:

*** WAITING task D
SCHEDULED: <2020-07-31 Fri>
:PROPERTIES:
:ID: taskD
:EFFORT: 5d
:END:

Does this example contain all the information that you wanted to see?

legalnonsense commented

I apologize but I missed your comment. May take a some days but I will take a look at this and get back to you.

  • 👍2