I would like to touch once again on the concept of contexts. I
understand that the original GTD concept involved the type of work being
done. You would group calls together because when you finish a call and
still have the phone in your hand that's a good time to make another
call. Type of work being done is a kind of vague concept and it's
subject to getting extended and modified. As always in such matters
there's a predictable reaction that the mods have gone too far, with
calls to return to a more orthodox interpretation. The way such things
usually work out is that if there is a lot of utility to a particular
mod it will become popular and the calls for orthodoxy will fall away,
while if there is limited utility the discussion will fade away.
Two mods currently under discussion involve the use of context for GTD
status (active, waiting, someday etc) and the use of context for
delegation. Both have produced criticism for diverging from the orthodox
interpretation of context. I would like to point out that the truly
orthodox interpretation is long gone. Two examples: the fact that MLO
allows each context to have a schedule of open and closed hours gives
rise to contexts whose only characteristic is the schedule, like
#weekend, and #weekday-morning and so on. This is clearly not a type of
work but it has great utility so it is widely accepted. A second is
location where a point on the Earth's surface and a circle of specified
diameter around the point can be associated with a context. This gives
rise to events that to me a clearly outside of the original vision of
GTD, for example, I am driving home from a client meeting when my phone
alerts me to the fact that I am within a half mile of my friend's house
and I need to drop in and pick up the tools he had borrowed from me.
This has nothing to do with any idea that client consultations and
friends returning tools are in any way the same type of work but it has
utility so nobody is complaining.
In my personal opinion, the GTD status has no utility because I don't
use it but if someone does, I don't see that there is anything wrong
with putting it in the context field. Yes, it makes the context list
just a tiny bit longer but as long as you use different initial
characters to group >calls versus *someday in different parts of the
list, I don't see that as a big deal.
In my personal opinion, delegation has a lot of utility and I will go
into my thoughts on that elsewhere. I think that MLO could do more to
support delegation, I just don't see why that requires a different
field, rather than just a new use of context.
Last point: I have recently been accused of being defensive. That's true
but it is not because I want MLO functionality frozen where it is today.
I am defensive of space on the screen. When a new field is created, for
example delayed dependency, that does not require a dedicated column in
any task list, I have no problem. When a new field like text tag appears
which seems likely to want its own inch of column space in the task
list, then that means that everything else has to shrink an inch, which
probably translates to even more severely truncated task names. For that
reason I will probably not be using text tags unless some incredibly
high utility use case is devised by someone. And for this same reason,
whatever enhancements are needed for delegation, I would rather see them
implemented in context rather than allocating another new column.
-Dwight
--
You received this message because you are subscribed to the Google Groups
"MyLifeOrganized" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mylifeorganized+unsubscr...@googlegroups.com.
To post to this group, send email to mylifeorganized@googlegroups.com.
Visit this group at https://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mylifeorganized/eb4ec1b8-af44-5446-ff27-fd3d3397e11c%40dwightarthur.us.
For more options, visit https://groups.google.com/d/optout.
