When is a TODO really a TODO ? ...

When is a TODO really a TODO ? ...

[Richard G Riley]

I'd just like to point a little issue when discussing TODO items. There
is frequently a tendency to confuse an item marked with "TODO" for a
TODO item ....

e.g

,----
| C-c C-v runs the command org-show-todo-tree
|   which is an interactive compiled Lisp function in `/home/shamrock/programming/lisp/org-5.13h/org.elc'.
| It is bound to C-c C-v, <menu-bar> <Org> <TODO Lists> <Show TODO Tree>, <menu-bar> <Org> <Special views current file> <TODO Tree>.
| (org-show-todo-tree arg)
| 
| Make a compact tree which shows all headlines marked with TODO.
`----

Items marked with TODO are not more special than one marked with APPLE :
its all down to the sequences e.g

#+SEQ_TODO: APPLE(t) WAITING(w@) INPROGRESS(p@) | DONE(d) CANCELLED(x@) DELEGATED(l@)

And the org-show-todo-tree actually shows any tasks marked as "in
sequence" or "being processed" if you will

I mention this because I got confused a lot earlier in my experiences
with org-mode as to what TODO items really are. It seems, and please
correct me if I am wrong, that there really are not any TODO items -
there are only items assigned a process status. ie far more generic.

Anyway, just some idle thoughts!

Re: When is a TODO really a TODO ? ...

[Carsten Dominik]

Hi Richard,

you make an interesting point.  The fact that items with a process  
state are called TODO
items had two roots:

- historically:  Initially, there was only TODO and DONE.

- pedagogically: Org-mode tries to be "easy-entry, but then
   lots of stuff under the hood".
   This is why TODO items are introduced the way they are.
   You said that you have been confused by this, so maybe it
   is not the right way after all.  Any proposals on how to
   address this in the docs?

- Carsten



On  4Nov2007, at 6:38 PM, Richard G Riley wrote:

>
> I'd just like to point a little issue when discussing TODO items.  
> There
> is frequently a tendency to confuse an item marked with "TODO" for a
> TODO item ....
>
> e.g
>
> ,----
> | C-c C-v runs the command org-show-todo-tree
> |   which is an interactive compiled Lisp function in `/home/ 
> shamrock/programming/lisp/org-5.13h/org.elc'.
> | It is bound to C-c C-v, <menu-bar> <Org> <TODO Lists> <Show TODO  
> Tree>, <menu-bar> <Org> <Special views current file> <TODO Tree>.
> | (org-show-todo-tree arg)
> |
> | Make a compact tree which shows all headlines marked with TODO.
> `----
>
> Items marked with TODO are not more special than one marked with  
> APPLE :
> its all down to the sequences e.g
>
> #+SEQ_TODO: APPLE(t) WAITING(w@) INPROGRESS(p@) | DONE(d) CANCELLED 
> (x@) DELEGATED(l@)
>
> And the org-show-todo-tree actually shows any tasks marked as "in
> sequence" or "being processed" if you will
>
> I mention this because I got confused a lot earlier in my experiences
> with org-mode as to what TODO items really are. It seems, and please
> correct me if I am wrong, that there really are not any TODO items -
> there are only items assigned a process status. ie far more generic.
>
> Anyway, just some idle thoughts!
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: When is a TODO really a TODO ? ...

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> you make an interesting point.  The fact that items with a process
> state are called TODO
> items had two roots:
>
> - historically:  Initially, there was only TODO and DONE.
>
> - pedagogically: Org-mode tries to be "easy-entry, but then
>   lots of stuff under the hood".
>   This is why TODO items are introduced the way they are.
>   You said that you have been confused by this, so maybe it
>   is not the right way after all.  Any proposals on how to
>   address this in the docs?
>

Maybe just call todo items 'Tasks' and their current state is 'TODO',
'DONE', etc ?

,----
| * TODO Thing 1
|   I'm a task
| ** NEXT Thing 1 first item
|    Me too! work on me next
| * Some random information
|   I'm not a task since I don't need to be 'done'
| * DONE Completed task
|   I'm a completed task
`----

Bernt

Re: Re: When is a TODO really a TODO ? ...

[Bastien]

Bernt Hansen <bernt@alumni.uwaterloo.ca> writes:

>> - pedagogically: Org-mode tries to be "easy-entry, but then
>>   lots of stuff under the hood".
>>   This is why TODO items are introduced the way they are.
>>   You said that you have been confused by this, so maybe it
>>   is not the right way after all.  Any proposals on how to
>>   address this in the docs?
>>
>
> Maybe just call todo items 'Tasks' and their current state is 'TODO',
> 'DONE', etc ?

Good idea.  Here is a list of possible conventions for the manual:

- use "keyword" for TODO keyword
- use "tasks" for entries that have a keyword
- use "entries" for other entries (or entries "in general")
- use "heading" when referring to the entry as "outline-able"
- use "headline" in the context of exporting/publishing

Maybe some typesetting conventions wouldn't hurt, too:

- use uppercase for KEYWORD
- use uppercase for drawers and special PROPERTIES
- capitalized the first letter for user-defined properties
- use lower-case for tags

Maybe this would help make the examples even more clearer.  This is
especially crucial when if comes to complex agenda searches.

What do you think?

-- 
Bastien

Re: Re: When is a TODO really a TODO ? ...

[Carsten Dominik]

On  6Nov2007, at 4:28 AM, Bastien wrote:

> Bernt Hansen <bernt@alumni.uwaterloo.ca> writes:
>
>>> - pedagogically: Org-mode tries to be "easy-entry, but then
>>>   lots of stuff under the hood".
>>>   This is why TODO items are introduced the way they are.
>>>   You said that you have been confused by this, so maybe it
>>>   is not the right way after all.  Any proposals on how to
>>>   address this in the docs?
>>>
>>
>> Maybe just call todo items 'Tasks' and their current state is 'TODO',
>> 'DONE', etc ?
>
> Good idea.  Here is a list of possible conventions for the manual:

> - use "keyword" for TODO keyword
> - use "tasks" for entries that have a keyword
> - use "entries" for other entries (or entries "in general")
> - use "heading" when referring to the entry as "outline-able"
> - use "headline" in the context of exporting/publishing
>
> Maybe some typesetting conventions wouldn't hurt, too:
>
> - use uppercase for KEYWORD
> - use uppercase for drawers and special PROPERTIES
> - capitalized the first letter for user-defined properties
> - use lower-case for tags
>
> Maybe this would help make the examples even more clearer.  This is
> especially crucial when if comes to complex agenda searches.
>
> What do you think?


This sounds like exactly how things should be......
One possible hickup:  In a GTD setting, an entry becomes a task by
attaching a context, so possibly without a TODO keyword.

- Carsten

Re: Re: When is a TODO really a TODO ? ...

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

>> Maybe this would help make the examples even more clearer.  This is
>> especially crucial when if comes to complex agenda searches.
>>
>> What do you think?
>
> What about if a task is not a task?  What if it's a person, a
> reservation, an event or some other thing to be organized?

The purpose of "task" was to find a replacement for "TODO item".

There are many occurrences of "TODO item" or "TODO entry" in the manual,
and "task" is better because it's more general.  

Of course it is not perfect, and no replacement would be, because it is
impossible to capture all possible uses for an entry in a single word...
but in the lack of better alternatives, I think it's okay, especially if
we dedicate a "Writing conventions" section at the beginning of the
manual, explaining both the scope and the limitation of conventions
(like using "tasks" for headlines that have a keyword).

> We need to make sure we keep is easy cases easy.  I don't think
> incremental discoveries after that are a bad thing.

Yes, precisely.  This is why all these possible conventions have to be
carefully and gradually implemented, so that we can check new Org users
don't get lost.

-- 
Bastien

Re: Re: When is a TODO really a TODO ? ...

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> "Eddward DeVilla" <eddward@gmail.com> writes:
>
>>> Maybe this would help make the examples even more clearer.  This is
>>> especially crucial when if comes to complex agenda searches.
>>>
>>> What do you think?
>>
>> What about if a task is not a task?  What if it's a person, a
>> reservation, an event or some other thing to be organized?

"to be organized" - implying "task" to be undertaken.

>
> The purpose of "task" was to find a replacement for "TODO item".
>
> There are many occurrences of "TODO item" or "TODO entry" in the manual,
> and "task" is better because it's more general.  

I agree. A task is an org-item with a status applied from a sequence of task
statuses.

tasks generally progress from an initial state to a completion state


>
> Of course it is not perfect, and no replacement would be, because it is
> impossible to capture all possible uses for an entry in a single word...
> but in the lack of better alternatives, I think it's okay, especially if
> we dedicate a "Writing conventions" section at the beginning of the
> manual, explaining both the scope and the limitation of conventions
> (like using "tasks" for headlines that have a keyword).
>
>> We need to make sure we keep is easy cases easy.  I don't think
>> incremental discoveries after that are a bad thing.
>
> Yes, precisely.  This is why all these possible conventions have to be
> carefully and gradually implemented, so that we can check new Org users
> don't get lost.

Re: Re: When is a TODO really a TODO ? ...

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>> There are many occurrences of "TODO item" or "TODO entry" in the manual,
>> and "task" is better because it's more general.  
>
> I agree. A task is an org-item with a status applied from a sequence of task
> statuses.
>
> tasks generally progress from an initial state to a completion state

If you want to be even more (too much?) precise, we could use:

- "task" for items with sequential sets of keywords
- "entry" for items with "type" (not sequence) keyword
- "item" for headlines that are not yet a task or an entry

Don't know if this would be relevant everywhere.  We should try to
gradually fix the manual first and see if a special case needs to be
made for the difference between entry/item.

-- 
Bastien