I use sub-labels often. On a cosmetic level, they help to keep my 120+ project labels in order and more accessible when using GTDInbox, though unless the upper level labels are short, using the search function in Gmail gets clumsy (using the Labels dropdown box search function).

I sometimes assign both the upper-level and sub-level labels to an item, but that would be unnecessary if filters would automatically include sub-levels. In the PalmOS software ShadowPlan (CodeJedi.com), one can mark a filter as “greedy” in which case “the filter matches all children when a parent matches”.

I suppose GTDInbox could automatically add the higher level labels after a sub-label is chosen, but that seems clumsy to me. Perhaps as a configurable option that might work and probably would be easy to implement.

I have some canned Gmail filters that I invoke, but I must add that it is hard to get them right: I usually need to construct the search in an editor as multiple lines, then join the lines into one line to paste it into the search box. When the project labels get lengthy, then the queries get harder to read as well, so that is a negative to using nested sub-projects.

I do, however, use nested labels for “Misc” like Clients/IBM.

In my usage, I would never assign anything to Project, instead assigning those general tasks/references to Project/General (or something). That gives the option of sorting on Project/General (and avoiding all the subProjects), Project/subProject or sorting on Project to get it all.

1. Nested subProjects in another Project

P/Loans
P/Loans/BofA
P/Loans/WellFargo
P/Loans/CreditUnion

I have several nested projects like this. In this example, Loans is used for information/tasks necessary for all my home loans. The subfolders are for tasks/correspondence related to the specific tasks for that bank. In this case, I never need to see all the tasks of the subfolders at the same time because I work on one subProject at a time. This usage is similar to…

2. Nested subProjects in another Folder

P/Contracts/Company1
P/Contracts/Company2
P/Contracts/Company3 …

In this example, there is no main project, only subProjects, because there are no tasks or reference items relating to the general category of Contracts. So why do it? In the Projects drop down in emails and in the sidebar, the subProjects are nested in the parent folder and listed as a group. Its a way to organize and group projects, and also hide a long list of subProjects that don’t need top level accessibility.

3. Prefixed projects

P/Wedding Flowers
P/Wedding Location
P/Wedding Invitations …

I used this format for my wedding because there were a lot of actions during a short period of my life. I wanted them all to be top-level, but still be organized in some way. When that busy period ended, they all went to Old: (to Z: in my case). I could have easily nested them all in a subFolder by turning “P/Wedding ” to “P/Wedding/”.

4. Dual tags

P/NewCondo and P/CondoMoveIn
P/NewCondo and P/CondoRemodel

This is similar to #1. You can have tasks in the mainProject or the subProjects, and they are organized in the Projects list. The advantage of this method is that you can sort via the sidebar to get all subProjects in one display, or sort by a single subProject. This is by far my LEAST favorite method or sorting projects because of the extra work involved in assigning double labels. The only reason I’ve done this is when my projects are poorly defined and I realize that tasks relate to multiple projects. I’ve never used this method on purpose.

So, knowing I have used all four types, how do I want subProjects to be handled in GTDInbox? Personally, I never want to see all my subProject actions at the same time. If I did, I would make them one project. There’s reason to see all Next Actions tasks, or all Phone tasks, or all (sub)Project tasks, but not a reason to see a grouping of subProject tasks. If I’m working on Client2 or WeddingFlowers or LoanBofA then I don’t care about the other clients, wedding tasks, or alternate bank requirements.

I VOTE TO LEAVE IT AS IT IS. I didn’t know what my recommendation would be until I started reviewing all the ways I use Projects.

However, I would not object to a change in which Projects included subProjects in a display. I would tweak my existing projects, but it would still work. Here’s what would have to change:

1. P/Loans would become P/Loans/GeneralTasks. I probably would never sort by the mainProject folder of P/Loans, but any user of GTDInbox would have that option.

2. Nesting via a folder (instead of a project) and #3 Prefixed Projects names would be unaffected by such a change.

4. Dual Project names would be unnecessary with the change. This is a good thing.

Final note: What we really need is the ability the use wild cards in our searches. We need to search on P/Client* as well as P/Client2. That would solve the whole issue.

Thanks for reading to the bottom. Let me know if this was helpful.

I generally don’t use sub-projects. But I use a folder structure to group related projects.
(BTW: I use special characters as prefixes so that the GTD labels are sorted at the beginning of the label list:: “!/” for statuses, “+/” for projects, “@/” for contexts, “x/” for old, “_/” timing labels, and “#/” for refs (which I don’t use very much))

For example, sales projects are grouped in the “Opps” folder:

+/Opps/090712_BlaCorp
+/Opps/090925_ACME_Wiget_Deal

Support cases are organized in the folder “Sup” and then usually in a sub folder for per company:

+/Sup/XY/090910_GUI_Issue
+/Sup/XY/090915_New_Release

When a project is done it gets prepended with an “x/”, e.g. “x/+/Misc/090911_New-Laptop”. Note I conserve the “+/” so that the label can be identified as a project later on.

Each project name is prepended with an inception date-stamp, so that older projects appear on the top of the list – so I am reminded to get the oldest ones done.

So IMO extensive sub-project support is not needed. What I would like to see in GTDInbox thogh, is the ability to search for actions in a project group. E.g. I can list all actions for my sales opps.

I have extensively used MonkeyGTD ( http://monkeygtd.tiddlyspot.com/#MonkeyGTD) previously which does not use hierarchical labels and it works very well.
It implements inheritance so sub projects know what they belong to and in the long run I find this approach simpler and easier to adjust.

So my vote is against P/xxx altogether…

However, I imagine this cannot be implemented with Gmail labels because a label is not also an email (whereas in TiddlyWiki a tag is a tiddler. Perhaps this is a request to gmail

I mainly seem to be moving gradually because more & more my tasks are set from emails so by using GTDInbox I can avoid lots of copy paste steps.