![]() ![]() ![]() the thing is that it is far too manual, the risk is that you omit one of your tags or your make a typo error and the system is not consistent. This is a way of doing it but here are my arguments to explain why it does not meet the objective : - you do not have project attributes (next action, etc.) - you rely only on tags that you manually enter : let us say a tag for the project name, a tag for next action etc. so RTM people we are with you, find the solution, we can help you choosing or selecting among alternatives and may the milk be with you Any way I think the idea for subtask, like the idea of gathering lists in tabs or any other way of list gathering stem from the same reason : "finding an appropriate way to deal with projects". why not use projects that could includes tasks and could be listed in lists (?). I'm not sure the best way is by adding sub-tasks, it would indeed transform RTM in something more complicated. so it is up to RTM people to find the appropriate means to deal with a project level (or hierarchy) in RTM, but in everybody's interest we'd like them to find one. That would be too a bad news for RTM people. but I think neglecting any of the two requirement would be an error 1) neglecting simplicity and attractivity of RTM would end in RTM not staying RTM anymore and people could walk awy from it 2) neglecting the need for a project notion, would be neglecting a real and durable need in to do list and GTD and sooner or later people needing it would leave, reluctantly but still leave for applications dealing with the project level. I think this is possible, the two requirement (project and simplicity) are conciiable, RTM people should think on how to do it simple and well. For that simplicity, in the line of the original concept has to be maintained. some kind of hierarchy is needed : a project level At the same time I understand the motivation behing RTM people (Emily) that one of the magic of RTM is making a boring subject (to do lists) an enjoyable application we go to with pleasure. of course lists can be used for that (as suggested by Doug in RTM blog) but then lists can not at the same time gather tasks of the same field (because we would like thos lists to list projects too among tasks). This discussion shows that there is a real need (should I friendly say a lack ? ) for a "project" notion (or level) in RTM. Does it accomplish the same thing that you are looking for? YMMV, but it works quite effectively for me! Much of this concept was inspired / directly stolen from this thread: -Tutunkommon Is the interface layout exactly what you want? Probably not. Now you have a list of your projects, and each project has a list of sub tasks. ![]() Tag it as: *Projects, +Packaging_Rewrite Again, search for tag:*Projects. The tab is your project, inside of that are your subtasks. ![]() Save this as a smart list called Packaging Rewrite. Finally, do a search for +Packaging_Rewrite. Add the rest of your subtasks in the same way. +Packaging_Rewrite, na This indicates that it is part of the packaging system rewrite project, it is performed at work, and it is a next action. I use a predecessor character for organization. For example: Rewrite interface logic to robot Tag this with your main project name. I do it for work: Create a task for your first sub-task. This is fairly simple to do with the existing structure. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |