How do you decide whether something should be a project or a tag in Everdo (GTD)?
I understand that “areas” should be large and ideally non-overlapping. Below the areas we can have tags and projects to group tasks. But when to choose a project and when a tag?
A rule of thumb for me is that projects should have a time limit and a clear outcome, while tags (sub-areas) are for responsibilities, roles, duties etc. which have no clear “finish line” and single outcome. Is this a good differentiation?
For instance, I am maintaining several open source projects, these projects would not correspond to projects in Everdo but rather exist as tags (sub areas), because the goal is not to “finish” these open source projects, but to keep them alive.
A bit problematic with that approach is however that this can create too many tags and the filter bar becomes a bit unwieldy. Any ideas how to make this more manageable?
More than an idea, a question: why having a project or tag, why do you want to have a subarea? What’s the advantage of it?
From an outsider point of view, it feels like you are adding unnecessary complexity to the system.
For me, projects are outcomes I want to achieve in the near future. I don’t use tags other than for contexts.
In your example, with open software - you mention you are maintaining different projects. If there is something I want to change about any of these projects that requires several actions, I would have a project for it. This project would go under whatever area you consider open software contributions go for you.
If there’s nothing that requires an action for any of the open soft projects at this moment in time, they would simply not be in my system.
And if I want to make sure I’m paying enough attention to all the projects, I’d add them to my weekly review checklist, so that weekly I sit down and consider whether I’m maintaining the balance.
Thanks for your input @Mai. I agree that trying to keep as little as necessary in Everdo is a good approach. I’ve also started to move stuff away from task management to check lists outside. In the past, I kept all someday/maybe stuff in my task manager, but I found it is easier to review these things in simple text lists outside.
The case of open source software is a bit special because usually you keep the tasks separate in GitHub or other issues trackers. There are only a few additional tasks and housekeeping stuff or issues that need special attention that I keep separately in my own local task management.
The reason why I use projects or tasks is to keep better overview and being able to focus/filter on one project only. If I cannot filter, the list under “Next” would be too huge. I want to see at a glance only the tasks that belong to a certain open source project. This is also because it is hard to switch between the projects. They are often written in different programming languages, need different development environments, and some time to mentally “get into” the project again after you did not work on it for some weeks or months. In this sense, a project is in fact very similar to a context in GTD, and I could use contexts for this purpose. But as far as I understand, contexts are only special tags (starting with @) in Everdo.
Given the mental energy required to switch OS projects (including different languages), this is akin to travel time between different physical locations. So your sub-areas are effectively contexts and would justify an @ tag. No?
That failing, you could have a single @OpenSource or @GitHub area and the #Project 1 etc. That way when you select @GitHub, there should be a manageable number of # tags to then select for
Personally, I think that nested tags could address some of this too - especially with ability to collapse these. However, I understand that there are technical impediments. See Nested or dependent tags
@arete, that’s a good point. The @phone context in GTD exists mainly because you need to be in a certain mental “mood” to make phone calls, and in that mood you can then make several of them. Similar to an OSS project. It needs some mental switch to get into the project again, and if you’re “in it”, then you can fix several bugs or add several features. You usually don’t want to switch between projects to fix one bug in each, but work on one project for a longer time, before switching to the next.
On the other hand, the context list shold not be blown out of proportions. I agree that nested tags could help. Then you could e.g. nest all your C++ projects under one tag/context, and al JavaScript projects under another one.