• View
• Edit
• History
• Print
• Login

The Item Hierarchy in v0.8

Parents and children

When we want to get something done - like, say, get a web-package to manage my task list - then usually I can't do it in one action: it gets broken down into several tasks. So, I create a project "get a web-package to manage my task list", and then I set out what the very next thing I have to do, to start making that happen: "search web for existing GTD software". That's a next action, and the sole reason I'm doing it is to get one step closer to making the project happen. Within gtd-php, I create a next action: ""search web for existing GTD software", and associate it with my project ""get a web-package to manage my task list", by assigning the project as the parent of my next action. And now, when I view the action, I can see the project it's associated with; and when I view the project, I can see the actions I need to do in order to deliver the project. The parent-child relationship within the software is just a way of tagging the two, to indicate that the action is there as a component of the project.

A lot of the things I do are very specific, with a definable completion status - they are projects. However, there are some things I do that are less oriented to a specific delivery, such as "stay on top of things". So, I'd create a goal of "stay on top of things", and to help me keep track of how I'm doing that, in gtd-php, when there's a project that will help me stay on top of things, such as "get a web-package to manage my task list", then I make that goal the parent of that project.

A description of the hierarchy

In 0.8, the hierarchy of projects and actions that form the core of the GTD productivity system, has been extended as follows:

This is a synthesis of the hierarchy set out in Covey^{(needs reference)}, with the runway-50,000ft analogy set out in the GTD book. Where they differ (that is, at the top two levels), Covey's version has been used - so, where Allen uses Mission, Covey and gtd-php have Values; and where Allen uses Objectives, Covey and gtd-php use Visions. By 1.0, we expect that the labels on the hierarchy will be customisable by the user.

For these four categories:

 # vision
 # role
 # goal
 # project

any can be the parent of everything on the same line in that list, or below: so a goal can be the parent of other goals and of projects. A value can be the parent of anything, but cannot be the child of anything.

You can use it as you see fit. There are few set rules to the levels above project. You can attach as much or little data and significance as you want to the upper levels: the projects and actions remain the core of gtd-php functionality, and the other levels give the context, if you want to incorporate that into the way you use gtd-php.

You may wish to keep your gtd-php installation purely for the management of your things to do, in which case you'll probably only use projects and actions: as David Allen writes in the GTD book: Focusing on values does not simplify your life. It gives meaning and direction-and a lot more complexity.

Values are viewed as being fairly stable over the long term. The intention of writing them into the data is to continually remind the user to align their goals and projects with those values. Yes, I can be efficient at cutting down that forest (ticking off actions and projects) but is it the right forest? (Vision and Values). Therefore, I'd like to tie those values with my specific visions (5 year plans) and then roles and goals which are the means to achieving the vision.

My projects are aligned with my goals. Any project may satisfy multiple goals, but may often only address one. Those goals are specific to the roles in my life. Generally each role has multiple goals, but usually each goal belongs to one role. Those roles represent the relationships with people I have and the hats I wear in my life. They generally don't have much information attached to them, other than description, possibly category (professional/personal), and occasionally time-frame (for some committee appointment or some time-limited office, etc). Those roles are aligned with my few visions for my life--- which if in alignment mean that I am achieving my life visions through the work I do in various capacities (the hats I wear). In this view, things I am doing that don't help me achieve my visions become painfully obvious. And lastly, my visions must be congruent with my values, otherwise something is seriously wrong.

References are pieces of information that are valuable, but not cause for direct action. References can be attached to Projects.

How related items in the hierarchy behave

If an item is deleted, then its children become orphans. They will still appear on the list of items, and will also appear on the Review > Orphans page. If a project is deleted, then its actions will have their next action flags reset: an action cannot be a next action unless it is the child of another item (almost always a project).

When you mark an item complete, then its children will not be automatically marked complete.

Note that if you mark a project complete, but leave some of its actions incomplete, those actions will not appear on the default listing from Process > Actions. However, you can view all incomplete actions, regardless of the completion status of their parent projects, by selecting Any in the Parent Completion Status dropdown box. Or, you can just choose to view those incomplete actions which are children of completed projects, by selecting Complete in that Parent Completion Status dropdown box. In general, by default, the list of items shows incomplete children of incomplete parents; so if you mark a parent complete, its children will not appear on the default list of items.

Example

Value: Peace and caring.

Documentation Items