Linux Format - UK (2020-03)

(Antfer) #1
http://www.techradar.com/pro/linux March 2020 LXF260 67

Project management TUTORIALS


Column View
re-formats your
Org document as
a table, and lets
you edit property
values in-line.

SUB-TASKS VS CHECKLISTS


total number. Using [%] instead will express it as a
percentage instead of a fraction. Note that the
completion of sub-tasks will update the progress of
the parent task, but not change its actual status (at
least not by default).

Set it back up
Once you have your project broken down into multiple,
smaller parts, one way to approach it is to do one part
at a time, in order, until they are all completed. However,
this isn’t always feasible. It’s therefore useful to know
which tasks need to be completed before others can
begin. In the world of suits, this is referred to as a
/predecessor/ relationship, and you can specify these
using Org-Mode properties.
Properties are attributes of a particular headline. You
can use the *org-set-property* command to add one to
your current headline (see the sidebar for more detail
on Properties syntax). The /ORDERED/ and
/BLOCKER/ properties are two such, and they’ll help
us to designate our dependency structure. ORDERED is
assigned to a parent task, and indicates that all its
children need to be completed in the order in which
they appear. BLOCKER, on the other hand, is assigned
to a parent or child, and indicates the task that must be
completed before that task can begin. The value you
assign to the BLOCKER property must be either
/start/, meaning the start of the project, /previous-
sibling/, which means the task before within the same
parent, or an ID of another task in the project (as
assigned using the /TASK_ID/).

What an effort
Now you have a rough idea of when things need to
happen in relation to one another. The next part of this
formula is knowing how long they’ll take. You can add
work estimates using the /EFFORT/ property
containing a time frame, either in H:MM notation or with
a whole number followed by m (minutes), h (hours), d
(days), or w (weeks).
EFFORT is useful to plan the project, but it’s good
practice to also record your time. When you start
working on a task, place the cursor on its headline, and
use the command *org-clock-in* to start a timer. When
you’ve finished, use *org-clock-out*. You can continue to
do this throughout the day as well as daily for longer
tasks, and Org-Mode will keep a running tally of the total
clocked time.
This record is called the /LOGBOOK/, and it’s
created directly below the Properties drawer for the
headline if one exists. This is another expandable and
collapsible (with the Tab key) region that will contain a
list of all the time logs you’ve created for that task.
They’re listed with the newest entry on top. If you’d like
a tally of all the time in a nicely formatted report, you
can choose a place in the Org-Mode file and use the
*org-clock-report* command to insert a block that lists
all the tasks with the clocked time you have to date. This
is what’s called a /dynamic block/ in Org-Mode, and as
you add time to your various tasks, you can place the
cursor within the block and use the command *org-
dblock-update* to automatically fill in revised tasks as
well as add new ones with clocked time.
It’s time to start figuring out when you’ll need to do
the tasks in your project in order to get it done. But you

may find it’s becoming difficult to get a view of your
project that you can use to plan effectively – at least in
the default “plain text” view of your Org-Mode
document. It’s time to set up something more usable,
called /Columns View/. This will enable you to view
tasks in a table that you can then use to update the
values of properties.
Add the following line at the start of your document:
#+COLUMNS: %40ITEM(Task) %8EFFORT
%ORDERED %BLOCKER{+}
These items, starting with a % symbol, describe what
the columns in your table will contain. The number
afterwards, if present, is how many spaces wide the
column will be. Otherwise the column is sized
automatically. The next item will be the column’s
contents, which you can see here include the /ITEM/
itself, the property /EFFORT/, the property
/ORDERED/, and the property /BLOCKER/ as we
configured them in the last section. If you’d like
something else to appear in the column header, you can
include it in brackets. Once this is set up, place the
cursor above the first Level-1 task in your plan, and use
the command *org-columns* to switch the document to
Columns View. Press the Q key to exit it.
As you will see, this gives you a much better look at
your plan. With the dependencies and effort in place, we
can now get on with actually scheduling the tasks. Start
by adding two additional properties, /SCHEDULED/
and /DEADLINE/, which will let us know when we’re
supposed to work on a particular task and when it will
need to be completed, respectively.
While you’re there, add columns for the /TODO/
status as well as the /CLOCKSUM/, so that you can
see any time you have logged to your tasks to round
out the picture:
#+COLUMNS: %40ITEM(TASK) %TODO %8EFFORT
%CLOCKSUM %SCHEDULED %DEADLINE %ORDERED
%BLOCKER{+}

Headlines are handled differently to /checklists/ in Org-Mode. While
both enable you to specify items that need to be done, checklists
have a couple of shortcomings when compared to headlines.
Firstly, they cannot have custom states; they’re either completed or
incomplete. Secondly, they don’t constitute the structure of the Org-
Mode document. Checklists are contained entirely within one
headline. Thirdly, they can’t have properties associated with them–
we’ll cover why this is important.
However, they are still useful if you just need to create a quick list of
items that need to be completed. They can also be nested, and rolled-
up to boot.

If you find
commands like
Column View
not producing
the results you
want, make sure
your cursor is
somewhere that
creates the right
scope. To affect
the entire file,
place the cursor
above the
first headline.

666March 202 McTkin Tig“You March 2020 LXF260 67


Project management TUTORIALS


ColumnView
re-formatsyour
Orgdocumentas
a table,andlets
youeditproperty
valuesin-line.

SUB-TASKSVSCHECKLISTS


total number. Using [%] instead will express it as a
percentage instead of a fraction. Note that the
completion of sub-tasks will update the progress of
the parent task, but not change its actual status (at
least not by default).


Set it back up
Once you have your project broken down into multiple,
smaller parts, one way to approach it is to do one part
at a time, in order, until they are all completed. However,
this isn’t always feasible. It’s therefore useful to know
which tasks need to be completed before others can
begin. In the world of suits, this is referred to as a
/predecessor/ relationship, and you can specify these
using Org-Mode properties.
Properties are attributes of a particular headline. You
can use the org-set-property command to add one to
your current headline (see the sidebar for more detail
on Properties syntax). The /ORDERED/ and
/BLOCKER/ properties are two such, and they’ll help
us to designate our dependency structure. ORDERED is
assigned to a parent task, and indicates that all its
children need to be completed in the order in which
they appear. BLOCKER, on the other hand, is assigned
to a parent or child, and indicates the task that must be
completed before that task can begin. The value you
assign to the BLOCKER property must be either
/start/, meaning the start of the project, /previous-
sibling/, which means the task before within the same
parent, or an ID of another task in the project (as
assigned using the /TASK_ID/).


What an effort
Now you have a rough idea of when things need to
happen in relation to one another. The next part of this
formula is knowing how long they’ll take. You can add
work estimates using the /EFFORT/ property
containing a time frame, either in H:MM notation or with
a whole number followed by m (minutes), h (hours), d
(days), or w (weeks).
EFFORT is useful to plan the project, but it’s good
practice to also record your time. When you start
working on a task, place the cursor on its headline, and
use the command org-clock-in to start a timer. When
you’ve finished, use org-clock-out. You can continue to
do this throughout the day as well as daily for longer
tasks, and Org-Mode will keep a running tally of the total
clocked time.
This record is called the /LOGBOOK/, and it’s
created directly below the Properties drawer for the
headline if one exists. This is another expandable and
collapsible (with the Tab key) region that will contain a
list of all the time logs you’ve created for that task.
They’re listed with the newest entry on top. If you’d like
a tally of all the time in a nicely formatted report, you
can choose a place in the Org-Mode file and use the
org-clock-report command to insert a block that lists
all the tasks with the clocked time you have to date. This
is what’s called a /dynamic block/ in Org-Mode, and as
you add time to your various tasks, you can place the
cursor within the block and use the command org-
dblock-update
to automatically fill in revised tasks as
well as add new ones with clocked time.
It’s time to start figuring out when you’ll need to do
the tasks in your project in order to get it done. But you


may find it’s becoming difficult to get a view of your
project that you can use to plan effectively – at least in
the default “plain text” view of your Org-Mode
document. It’s time to set up something more usable,
called /Columns View/. This will enable you to view
tasks in a table that you can then use to update the
values of properties.
Add the following line at the start of your document:
#+COLUMNS: %40ITEM(Task) %8EFFORT
%ORDERED %BLOCKER{+}
These items, starting with a % symbol, describe what
the columns in your table will contain. The number
afterwards, if present, is how many spaces wide the
column will be. Otherwise the column is sized
automatically. The next item will be the column’s
contents, which you can see here include the /ITEM/
itself, the property /EFFORT/, the property
/ORDERED/, and the property /BLOCKER/ as we
configured them in the last section. If you’d like
something else to appear in the column header, you can
include it in brackets. Once this is set up, place the
cursor above the first Level-1 task in your plan, and use
the command *org-columns* to switch the document to
Columns View. Press the Q key to exit it.
As you will see, this gives you a much better look at
your plan. With the dependencies and effort in place, we
can now get on with actually scheduling the tasks. Start
by adding two additional properties, /SCHEDULED/
and /DEADLINE/, which will let us know when we’re
supposed to work on a particular task and when it will
need to be completed, respectively.
While you’re there, add columns for the /TODO/
status as well as the /CLOCKSUM/, so that you can
see any time you have logged to your tasks to round
out the picture:
#+COLUMNS: %40ITEM(TASK) %TODO %8EFFORT
%CLOCKSUM %SCHEDULED %DEADLINE %ORDERED
%BLOCKER{+}

Headlines are handled differently to /checklists/ in Org-Mode. While
both enable you to specify items that need to be done, checklists
have a couple of shortcomings when compared to headlines.
Firstly, they cannot have custom states; they’re either completed or
incomplete. Secondly, they don’t constitute the structure of the Org-
Mode document. Checklists are contained entirely within one
headline. Thirdly, they can’t have properties associated with them–
we’ll cover why this is important.
However, they are still useful if you just need to create a quick list of
items that need to be completed. They can also be nested, and rolled-
up to boot.

If youfind
commandslike
ColumnView
notproducing
theresultsyou
want,makesure
yourcursoris
somewherethat
createstheright
scope.Toaffect
theentirefile,
placethecursor
abovethe
firstheadline.
Free download pdf