emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: daniela-spit@gmx.it, Tim Cross <theophilusx@gmail.com>,
	emacs-orgmode@gnu.org
Subject: Re: Adding Org Files to org-agenda-files
Date: Sun, 29 Nov 2020 20:05:08 +0300	[thread overview]
Message-ID: <X8PUxDDjQVRSybcP@protected.rcdrun.com> (raw)
In-Reply-To: <87ft4s5oug.fsf@localhost>

* Ihor Radchenko <yantar92@gmail.com> [2020-11-29 15:25]:
> 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/

,----
| So anything that is actionable is NEXT and anything that is depends on
| something else should be a TODO? That seems like most tasks are NEXT
| as opposed to TODO--intuitively, I would think most tasks should be
| TODO and moved to NEXT when they are to be worked on now. Or do you
| pluck from a large list of NEXT items and schedule them when you want
| to work on them?
| 
| The concept of NEXT tasks is most relevant to big projects. If, say,
| you have a project with 10 big tasks you need to do in order to
| complete the project, it is not very good idea to work on them at the
| same time. Instead, you only mark 1-2 tasks as NEXT to finish them
| first. Once you mark them DONE, the project will become stuck (no NEXT
| tasks), which will be seen during GTD review process. So, you will
| mark another 1-2 tasks as NEXT and continue working.
`----

From there I can understand that. We are doing that for projects but
we never assign NEXT.

Because TODO group of tags and DONE group of tags designate basically
something TO DO and something that is DONE and completed, then NEXT in
itself is basically TODO-NEXT. But some people are designated several
tasks as NEXT so that is contradictory to logic as only one should be
next according to me.

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.

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

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.

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.

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

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

Yes. And users may assign in their minds any kinds of meaning. They
are not clear.

Example is with NEXT, I would not use it as it becomes clear from good
plan what is next. It is DESCRIBED in our tasks what is next by
several words or sentences.

Just like when purchasing metal roof must come first before sleeping
in a cabin. They are though free to decide if they wish to sleep first
in the cabin and purchase the roof tomorrow, but I am not going to pay
a lodge if it is raining.

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

For me personally it does not matter as I am easily transitioning to
meta level assignments. Assignments or delegations I use very often,
always. Every day.

I like to press key `a', choose person, write assignment task and
close it. Finished there. Computer sends the task, SMS, and maybe even
follow up and reminders at specified intervals.

With Org definitely same can be done, it is just less relational, more
error prone. Of course I could designate a key to choose a person,
then write assignment task and press key to send it to person
assigned. I have that already.

Relational database approach gives me speedier access or better
overview without hassles. Additionally I can access tasks in the
database by any programming language not necessarily Emacs Lisp. It
can be just `psql' the command line tool to database. It could extract
the task by using email address of a person and attach the pending
list of tasks and date when they have been sent in the email (by
pressing key).

For the `fzf' command line tool that I discovered only recently I
would like to cry as I missed something like that for years. It is
like helm-mode on console.




  parent reply	other threads:[~2020-11-29 17:08 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-28 15:39 Adding Org Files to org-agenda-files daniela-spit
2020-11-28 16:51 ` Jeremie Juste
2020-11-28 16:54   ` daniela-spit
2020-11-28 17:01   ` daniela-spit
2020-11-28 17:41     ` Jeremie Juste
2020-11-28 18:12       ` daniela-spit
2020-11-28 18:30       ` daniela-spit
2020-11-28 18:43       ` daniela-spit
2020-11-28 19:01         ` Jeremie Juste
2020-11-28 19:16           ` daniela-spit
2020-11-28 19:26             ` Detlef Steuer
2020-11-28 19:44               ` daniela-spit
2020-11-28 19:55             ` Jeremie Juste
2020-11-28 20:06               ` daniela-spit
2020-11-28 20:11               ` daniela-spit
2020-11-28 20:27                 ` Jeremie Juste
2020-11-28 20:40                   ` daniela-spit
2020-11-28 21:32                     ` Jeremie Juste
2020-11-28 21:45                       ` daniela-spit
2020-11-28 23:18                         ` Jeremie Juste
2020-11-28 23:29                           ` daniela-spit
2020-11-29  1:36                             ` Tim Cross
2020-11-29  2:54                               ` daniela-spit
2020-11-29  3:51                                 ` Tim Cross
2020-11-29  4:05                                   ` daniela-spit
2020-11-29  5:23                                     ` Tim Cross
2020-11-29  9:30                                       ` Jean Louis
2020-11-29  6:50                                     ` Jean Louis
2020-11-29  6:41                                   ` Jean Louis
2020-11-29 12:28                                     ` Ihor Radchenko
2020-11-29 13:00                                       ` Tim Cross
2020-11-29 17:11                                         ` Jean Louis
2020-11-29 17:05                                       ` Jean Louis [this message]
2020-12-01  2:24                                         ` Ihor Radchenko
2020-12-01  8:59                                           ` Jean Louis
2020-12-13 15:36                                             ` Ihor Radchenko
2020-12-13 16:27                                               ` steve-humphreys
2020-12-25  2:17                                                 ` Ihor Radchenko
2020-12-13 20:21                                               ` Jean Louis
2020-12-13 20:59                                               ` Tim Cross
2020-12-13 21:59                                                 ` pietru
2020-12-13 23:28                                                 ` Jean Louis
2020-11-29  4:46                             ` Jean Louis
2020-11-29 14:46                               ` daniela-spit
2020-11-29 17:01                                 ` Tim Cross
2020-11-29 17:38                                   ` daniela-spit
2020-11-29 20:55                                     ` Jeremie Juste
2020-11-30  0:21                                       ` Tim Cross
2020-11-28 23:36                           ` daniela-spit
2020-11-29  5:51                             ` Jean Louis
2020-11-28 20:28                 ` daniela-spit
2020-11-28 18:50       ` daniela-spit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X8PUxDDjQVRSybcP@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=daniela-spit@gmx.it \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).