Projects, sub projects and you.

This wasn’t intended, but given the insight yielded by the discussion on Statuses, I’m now really interested to know how you structure Projects. I think we can refine our Review process.

This is particularly aimed at anyone who has nested/folder-esque projects and sub projects  – e.g. P/GTDInbox/Ideas. How do you do you structure your project and sub-project labels? What is your process for deciding how to categorise? How do you review those projects?

I know in my case, I use P/GTDInbox/Ideas and P/GTDInbox/Bugs, but P/GTDInbox itself is quite redundant. It’s just a convenient way to organise (and hide) my labels.

It raises a really interesting question, which is, should we be doing more with P/GTDInbox? If, on the GTDInbox sidebar, I click P/GTDInbox, I actually expect search results that include that label and all its children (I.e. “label:p-gtdinbox OR label:p-gtdinbox-ideas OR label:p-gtdinbox-bugs“). I certainly think it makes more sense, but it is quite different to the Gmail approach, and therefore I wonder if there is a use case that it would be bad for – the only one I can think is where you are using the parent label for some purpose, and only want to view it on its own.

(I’d also really appreciate any examples where your parent labels – as with my P/GTDInbox – are regularly used even though they have more specific child labels?)

  

This was written by Andy Mitchell