hi Lisa,
Interesting indeed.
After after having wondered myself how to use it, here is what I do:
Folders:
In every views I create, I always add a criteria "OR is folder".
Folders are areas of life and not really tasks to accomplish. I have
folders for clients, for someday/maybe lists, "book to read", "to buy", etc.
This way, I can always add a new task to a folder, even if it was empty
(and thus would have not been displayed)
Projects:
A consider a project a group of multiple differents task, that will take
time to complete.
ie: "construct a playstand for children", suppose to buy wood, to print the
plans, to list the tools I need, etc. this are very differents actions,
differents contexts, several days, etc.
Parent/children taks and subtasks:
I group tasks with subtasks without use of project status if they belongs
to the same project, and are something like a checklist.
ie: in my previous exemple (project = construct playstand), then "Buy wood"
would be the parent taks of the tasks -go to DIY Store, buy 2 large wooden
boards, buy 3 small wooden boards, etc.
I don't have a clear use of Review feature in mind.
Le jeudi 27 décembre 2012 15:37:53 UTC+1, Lisa S a écrit :
>
> Great question! I would be curious about the answers to this also, as I've
> never found a use for marking things as a project that I can both maintain
> and make worth remembering to check off the project checkbox.
>
> I see them as somewhat separate choices. Folders, for me, are easy -- they
> are containers -- anything that is not a task in itself. They never become
> active or represent work, they just hold things that do. My folders only
> change when I'm reorganizing my tree. Parent tasks that are not folders, on
> the other hand, are bigger-level tasks that include the parts they contain
> (subtasks). They become active when all of the subparts are done and
> represent work.
>
> So when do you mark a task as a Project? Projects can have a status, which
> is mainly used for grouping in the Projects view. They can have effort
> which combines the effort of the subtasks (I think there is an
> inconsistency here --- projects aren't completed when subtasks are all
> completed, but the project itself can't have a separate time estimate?)
>
> To blur the line even further, folders can also be projects. (I just was
> playing around with it, and if I want to group by project, I might want
> "Morning Routine" to be a project, so that everything is grouped, even
> though I'll never complete Morning Routine so it really does deserve a
> folder tag).
>
> So for me the question becomes, what is the difference between a project
> and a parent task? What makes it worthy of clicking "Project" and manually
> setting it's status? Ideally, I think I would use them to represent the key
> idea of the work, rather than the actions involved. If you use GTD, "mom's
> birthday" is the project. When you are reviewing work, you sometimes want
> to work at the level of projects ("On my plate this week I've got Christmas
> dinner prep, Christmas gifts, making progress on fixing the back deck that
> is about to leak, house cleaning, etc"). With work it can be different
> clients, different checkpoint deadlines, meetings, etc. Then each project
> has actions, and sometimes sub projects. I need to buy gifts, wrap gifts,
> go online and order some gift cards, and mail some packages. Those are all
> actions -- but if I want to review my overall work I don't always need to
> see those details, so I can group by the project.
>
> But -- what about all the strays? It's a lot of work to just figure out
> what belongs with what, and then not everything fits. What about all the
> routine tasks and the little bits of life? so I get overwhelmed, and I
> don't trust that I'll see everything with the Project view. So the question
> for me becomes, how do I decide what to mark as a project and still make
> sure I see everything I need?
>
> What granularity works best to use projects and when does another feature
> work better? For example, "buy gifts" really isn't a project -- because I
> buy stocking stuffers at the same places I buy groceries and sundries -- so
> "@Errands" context works better to group those. (Also, in such an "ever
> connected world, I've moved from location-based contexts such as
> "@Computer", "@Phone", to contexts that are more categorical, "!SelfCare"
> -- and that starts blurring the line with folders and projects too!
>
> So I tried an experiment...deciding which of my day's tasks (==starred)
> are projects, and which are part of projects, by grouping my Active Starred
> tasks by Project -- the tab system is *lovely* for this, by the way,
> because I didn't mess up my regular daily view. Interestingly, many of the
> project groupings I chose were also folders -- for example, "Morning
> Routine". If I'm going to group my work by what it is a part of, "Morning
> Routine" works as well as any for those. But I still had a lot of strays.
> Where does "get tires rotated" fall? Is it part of an Automotive Care
> project? Not really, but as much as Morning Routine I suppose. It's this
> blurry line that really catches me up. I want easy rules to apply because
> small decisions are exhausting when they add up.
>
> I really like the idea in GTD that everything is a project until you break
> it down into actions. I wonder how it might work if there were an option to
> make everything a project by default. Then in order to get things off my
> "project" list I would have to figure out what actions they have. I suppose
> its six of one, half a dozen of the other.
>
> Perhaps I could use the review feature to get myself to break things
> down...not sure.
>
>
> On Thu, Dec 27, 2012 at 6:31 AM, Michael Emerald, CFA
> <[email protected]<javascript:>
> > wrote:
>
>> Hi.****
>>
>> ** **
>>
>> Up front I’ll tell you I understand how each is implemented in MLO. My
>> question is how do you use them, for maximum benefit? I’ll tell you how I
>> use them, admitting that I get a bit confused now and then.****
>>
>> ** **
>>
>> Projects:****
>>
>> When I want to see Active Tasks grouped in some order, rather than a
>> plain simple list, I’ll often create a project, and then group by project.
>> The project, thus, isn’t really a project. Rather, it’s more of a
>> container for related recurring tasks.****
>>
>> ** **
>>
>> In outline view, when I want to group tasks I use a folder. Those
>> folders don’t affect my active task list, since I don’t do anything with
>> folders (group by, etc.) in my active task list.****
>>
>> ** **
>>
>> Would you recommend a better implementation than what I do presently?****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *Michael Emerald, CFA*
>>
>> ** **
>>
>> *Facebook:*
>>
>> http://www.facebook.com/michael.emerald****
>>
>> ** **
>>
>> *Boston Plein Air Artists Group: *
>>
>> http://painter.meetup.com/84/****
>>
>> ** **
>>
>> *Art Blog:*
>>
>> http://emeraldartandphotography.blogspot.com/****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "MyLifeOrganized" group.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> To unsubscribe from this group, send email to
>> [email protected] <javascript:>.
>> For more options, visit this group at
>> http://groups.google.com/group/mylifeorganized?hl=en.
>>
>
>
>
> --
> Lisa
>
> ------------------------------
> Lisa Stroyan, mailto: [email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"MyLifeOrganized" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mylifeorganized/-/4U1qOsULhjsJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mylifeorganized?hl=en.
