Re: Adding Org Files to org-agenda-files

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> Currently I am researching "NEXT" and how people are thinking and
> trying to see if I miss some concepts. My approach seem to be
> simpler. There is project and there are tasks in their most logical
> chronological or executable order just as a program. One has to do
> first one, then next. Which one is next is clear from the order of
> tasks. Marking it "NEXT" to me seem redundant as it would mean I have
> not made good order.

NEXT is relevant to complex projects where multiple tasks can be active
at the same time. Or when some urgent tasks are added to the project as
it goes. Then, instead of constant reshuffling of the task order and
re-evaluating the order of tasks, one can simply mark the new urgent
tasks NEXT and later use sparse trees to only look at the tasks that
should be done at the current stage of the project. The key point is
minimising exposure to irrelevant information - the number of tasks in
large project can be demoralising, especially if one gets reminded about
it frequently.

You might also check
https://old.reddit.com/r/orgmode/comments/i4hx1z/gtd_problem_with_todo_workflowconstantly/g0ihg2d/
 

> If the type of heading is "task" then I do not need to use "TODO" as
> it implies it is task. But Org headings do not have fixed types so it
> is visually and practically better to use TODO. Here would the
> inheritance be useful more than to tags. As if user marks one heading
> as TODO, then all subtrees could automatically get its TODO.

That can be done. Should be trivial using org-edna
(http://www.nongnu.org/org-edna-el/), for example. Or you can use
org-trigger-hook and mark all the children with TODO keyword if the
parent heading is marked TODO.

> The DELEGATED type, I have seen people using this and myself also. But
> if something is fully delegated and not any more mine, then I would
> not have it in my file. So it is something usually that I have to
> think of. Many of the tasks I think of are already assigned, I could
> call it delegated. And I keep property :ASSIGNED: under the Org
> heading. When I wish to send this task, I press one key and it is
> automatically sent to the person assigned. But I am one supervising it.

I guess the key reason to have DELEGATED is just to be reminded to
followup on the progress.

> By using this approach one can assign tasks:
>
> #+TITLE: My Org File
> #+AUTHOR: Me
> #+PROPERTY: ASSIGNED_ALL James Jane John Juda Mehdi
>
> ** TODO Negotiate with land owner
>
> Now when one does {C-c C-x p} the minibuffer prompt asks for
> "Property: " and there is ASSIGNED available as one of choices.
>
> In the next step it asks user for ASSIGNED value, and there are
> choices such as James Jane John Juda and Mehdi. Then it becomes like
> this.
>
> ** TODO Negotiate with land owner
>    :PROPERTIES:
>    :ASSIGNED: Mehdi
>    :END:
>
> This way the major type TODO does not change, but one knows that it is
> assigned or delegated to Mehdi.

I would do it in an opposite manner - mark the task DELEGATED, which
triggers {C-c C-x p} and prompts me for the ASSIGNED value. The
advantage of my method is simply that it is easier to see later -
DELEGATED keyword is visible on the headline, which the PROPERTY drawer
is folded by default. Of course, it would not matter if you configure
org to not fold the PROPERTY drawers.

Best,
Ihor