Jean Louis <bugs@gnu.support> writes: > We write tasks in their most logical chronological order and every > staff member is instructed to follow the order. One simply cannot > drive a car without putting petrol first, so that system is > followed. Some tasks on the ground can be done without chronological > order and our staff members are left to decide on that. When they > arrive to town and need to buy timber, maybe carpenter is discovered > right there while the task says that once they arrive to village that > they should look for carpenter. What is NEXT is mostly practically > decided while doing things at my side.
But what if the road to village is blocked by weather conditions? Should the staff members just stop doing the project and wait until the road becomes accessible? That sounds not very efficient. If all the tasks that one can start doing at current stage of the project are marked NEXT, instead of waiting for the blocked tasks, one can simply choose another NEXT task and get some progress on the project despite the first tasks cannot be done at this moment. > Interesting complication (Edna) that is supposed to be useful. Before > constructing the series of those tasks user would need to construct > series of tasks to construct series of tasks. > > Concept is great: This task can be completed only when tasks 1, 4 and > 7 are completed. But practical life is different. When conducting > projects staff members may discover on ground that dependable task can > be completed without 1, 4 and 7 being completed as one could not > predict future randomity. It may be also discovered that those 1, 4 > and 7 are not true dependencies but some other tasks. This would imply > that planner must know very well future incidents which is rarely the > case as it would be so easy to predict future one would not be writing > tasks. This can indeed be problem, especially if one tries to create too detailed dependencies. However, some very standard procedures might still benefit from this. For example, safety checklists might be the case when such task dependencies do make sense. Both the checklist and the dependency can be pre-defined as a capture template and then used in different projects serving as a reminder for necessary actions. I personally use very simple edna dependencies - when there is a book series or a movie/documentary split into several series, I sometimes block the later series until I watch earlier: https://github.com/yantar92/emacs-config/blob/master/config.org#task-dependencies In any case, I suggested this package simply as an example how to make all subheadings become TODO as soon as one changes the parent to TODO state. > It is useful in trees and it should be an org built-in to mark all > children nodes with the tag. It becomes very trivial when using > database with nodes having a parent: > > ,---- > | UPDATE hlinks SET hlinks_tags = 'TODO' WHERE hlinks_parent = THIS ONE; > `---- > > But rather a function would be used or type assigned. The above is > only example that shows how complex hard coded Elisp functions can be > replaced with 3-4 lines single function when database is a backend. Why do you think that analogous Elisp function would be complex? (defun yant/trigger-children (arg) "Change all the children to TODO when parent is TODO." (when (and (eq (plist-get arg :type) 'todo-state-change) (not (boundp 'trigger-children-progress)) (string= (plist-get arg :to) "TODO")) (let (trigger-children-progress) (org-map-tree (lambda () (org-todo "TODO")))))) (add-hook 'org-trigger-hook #'yant/trigger-children) > No wonder this guy has put Org mode in a sandwich on the logo of > SMOS. It eats the Org. > > SMOS - A Comprehensive Self-Management System > https://smos.cs-syd.eu/features As for me, SMOS is too inflexible in comparison with org-mode. See https://old.reddit.com/r/orgmode/comments/ivlczu/smos_a_comprehensive_selfmanagement_tool/ Best, Ihor
