Re: Adding Org Files to org-agenda-files

[Tim Cross]

Ihor Radchenko <yantar92@gmail.com> writes:

> 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/
>

Exactly. Not all the tasks in my task list are related or have
dependencies between them. I use NEXT as part of my planning process.

>> 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.
>

This assumes the only things you have under a TODO heading is other TODO
headings. That isn't how I structure my work. I might have many other
headings under a TODO heading which are not tasks, but are perhaps
related to the task. Sometimes I might have many tasks which are not
dependent on each other and so are all at the same level.

> 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.
>

Exactly. I don't just assign a task to someone and then forget about it.
I want to be reminded about which tasks have been delegated so that I
can follow up on them. Sometimes a delegated task is a dependency in
tasks which I have to do. I need to know when it is done in order to do
my task etc.

>> 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.
>

nd this highlights the main benefit of org mode. There is no 'one right
way'. It is up to the user to decide how to best use it to meet their
requirements. For me, I want a text only, relatively simple system which
has minimal dependencies on anything else (such as a database). I want
to be able to copy all my org files onto a thumb drive or put them into
the cloud and know I can access/use them from anywhere where I can run
Emacs or if Emacs is unavailable, just a basic editor where I can
edit/update them as text.

--
Tim Cross