emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Manual Ordering and Dynamic Priority
Date: Thu, 01 Sep 2022 07:42:39 +1000	[thread overview]
Message-ID: <86o7w0q9zr.fsf@gmail.com> (raw)
In-Reply-To: <20220831161348.GA2413557@itccanarias.org>


Eduardo Suarez <esuarez@itccanarias.org> writes:

> I have lots of tasks (todos) and I would like to create a long backlog based on
> my perceived priority.
>
> I was thinking to deal with them in the following way:
>
> - divide them in groups (categories or similar),
> - manually sort priority for every group,
> - mergesort groups, that is, start merging groups in pairs, and manually sort
>   for every step the union group until I have a large sorted backlog.
>
> For this to be practical, I would need an easy way to sort manually a group of
> tasks and get them assigned automatically a priority (or any other hack) so
> that priority ordering matches manual ordering.
>
> Any idea about how to get this done?
>
> If I had to implement it (I don't know lisp), I would assign a property (say
> BACKLOG_PRIORITY) for every new task, with value the higher value of any other
> tasks in agenda plus ten (for instance). Then I would query a subset of tasks
> and sort them manually, swapping their values every time I swap their order. I
> would also allow to assign a value directly based on free slots, not to bubble
> the whole list for a low priority task.
>
> Does it sound over-engineered? Any idea?

It does sound a bit like over-engineering to me :-)

My first question would be "How long have you been using org-mode to
manage your tasks?"

My observation from being a long-term org-mode user (and speaking from
personal experience), is that the first big mistake people tend to make
is to over engineer their setup. I suspect many people, after first
using org-mode, they get somewhat carried away with the
possibilities. They immediately get caught up in this dream of having an
organised world where all their tasks are captured, neat, organised,
prioritised and chaos is under control.

They start by defining a precise and well laid out plan for capturing
tasks and managing them. Tasks are given priorities, effort estimates,
there are capture templates for everything you can possibly think of and
no matter what they are doing, they can open their agenda and
immediately see what to do next, little thought or effort required.

This approach suffers from two fundamental flaws

- Life is by nature chaotic. You cannot eliminate the chaos. The best
  you can do is find ways to make dealing with the chaos less painful.

- Life is about getting things done, not planning to get things
  done. Overly complex management of your tasks is very likely to result
  in more time spent managing the tasks than actually doing the tasks.

My first recommendation for most people is use org with default settings
for the first few months. The defaults are not a bad starting point and
after a few months, you will know what the pain points are for your
specific situation and can then start looking at how to address them.

Be very careful about priorities. The problem is, priorities actually
change faster than you might expect. I actually rarely use priorities as
I find most of the time, they are not adding real benefit. I know what
the priorities are. Only in extremely large or complex projects,
particularly ones with complex dependencies, have I found priorities
useful.

The other point to note is that because you now have an efficient and
quick way to gather task information, you will likely end up with a
growing list of tasks in your backlog. The reality is, a far larger
number of these tasks will never see the light of day than you may
think. I find that very 6 months or so, I go through my backlog of tasks
and move any which have not seen any progress for 12 months into a
backlog archive. These tend to be ideas or tasks which in all honestly
are never going to bubble up to the point of being acted on. This could
be because priorities or requirements have changed, the ideas underlying
the tasks needs more thought or is just a bad idea, the need for the
task no longer relevant etc. Any time spent on prioritising, classifying
or ordering these tasks is largely wasted effort. 

The other problem with priorities are they tend to only represent the
urgency of a task and not the importance of that task. The danger is, if
you only focus on urgency, you become reactive and less proactive. All
your time is spent responding to urgency with little time allocated to
implementing less urgent but important tasks which ironically, will
often result in improvements and less urgent tasks. This can be avoided
if you are disciplined and ensure you also give high priority to
non-urgent, but important tasks. However, this can be hard to do,
especially in a busy environment with lots of conflicting tasks.

Tags can be a very useful mechanism for classifying tasks. However, the
mistake people often make with tags is to create far too many different
tags. You need to be disciplined with tags and keep them to a
minimum. If you have too many, you will spend too much time trying to
decide which tag to apply, will get inconsistency in your tagging and
when it comes time to use the tags, you won't know which tag is
best. Keep tags to as small a number as possible.

For the first 6 - 12 months, my recommendation is to keep things as
simple as possible. Your aim is to minimise the time you need to spend
in planning and organising your tasks while also minimising the tasks
which get missed, forgotten or don't get done in time. Your workflow
needs to be making your life easier, not harder by imposing more things
you have to do. Your looking for ways to help manage the chaos, not
eliminate it and it needs to work in a chaotic environment with
conflicting demands for your time and attention. After 6 - 12 months,
review and identify the 5 most frustrating/time consuming/failing
aspects of your org based workflow and see how they might be addressed
using existing org mode facilities. Implement a solution and use it for
6 months before going through another review and refine process. You
will be surprised how far you can get just using built-in org mode
facilities. At some point, you will likely get to the point where some
real org customisation is needed. However, you will also likely find
very similar customisation has already been done by others whch you will
be able to adapt. 

The key focus should always be in making org mode work for you and not
the other way around. If you find your spending more time managing your
tasks with org mode, your likely got it wrong. It has to make your life
easier or there simply isn't any point to it regardless of how cool,
clever or useful it may seem in theory.


  parent reply	other threads:[~2022-08-31 23:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 16:13 Manual Ordering and Dynamic Priority Eduardo Suarez
2022-08-31 16:27 ` indieterminacy
2022-08-31 21:42 ` Tim Cross [this message]
2022-09-09 10:01   ` Rudolf Adamkovič
2022-09-09 22:05     ` Tim Cross
2022-09-10  8:17       ` Eduardo Suarez-Santana
2022-09-02 12:52 ` Ihor Radchenko
2022-09-06  9:15 ` Eduardo Suárez
2022-09-07  4:45   ` Ihor Radchenko

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=86o7w0q9zr.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).