Organizing by time or by subject and an idea

Organizing by time or by subject and an idea

[John Hendy]

I use org-mode for all of my work notes. For the most part, I'm very
happy with it. I know everything is in there somewhere and I can find
it. I currently have one file for my projects organized something like
this:

#+begin_src org

* Tracking

This is for misc todos. It's just a repo for holding them until done
and then I typically archive them.

* Project 1
** Journals
*** 2011 November
**** [2011-11-15 Tue] Weekly project update 				:mtg:
Summary

**** [2011-11-22 Tue] Weekly project update 				:mtg:

*************** todo action item 1
*************** done action item 2
		 CLOSED: [2012-01-11 Wed 18:01]
*************** cancelled action item 3
		 CLOSED: [2011-12-26 Mon 11:05]
		
**** [2011-11-28 Mon] Met with Person to go over test methods			:mtg:
Summary

*** 2012 January
**** [2012-01-03 Tue] Weekly project update					:mtg:
**** [2012-01-10 Tue] Weekly project update 				:mtg:
**** [2012-01-11 Wed] Analytical testing
**** [2012-01-17 Tue] Weekly project update					:mtg:

* Other project trees
Similar stuff as Project 1

* Misc Journals
Journal entries organized similarly as above, but not on my main projects

* Reference
Odds and ends that I just need to put somewhere for reference later

#+end_src

So, one of the issues I've constantly struggled with in org is whether
to try and create a skeleton outline of all of the aspects of the
project and fill it in bit by bit during things like weekly
meetings... or whether to do what I do above and go chronologically,
simply creating journal entries for the day something happens. Part of
the reason for choosing chronological is that I am required to
document Intellectual Property related concepts. Time ordering makes
it simple to just print out an export of the items since my last brain
dump and past them into a technical notebook for dating/witnessing.

To just keep adding means my exports will either be redundant (include
all the stuff I pasted last time too) or tedious (find all new updates
and move to separate temp file for exporting).

Last night as I drifted off to bed I had an idea connected to role as
team leader I have. It involves ordering by outline, but having some
way to show time-based updates. Imagine "snapshots" of
exports/org-files. Perhaps:


--- View as of two weeks ago when just creating a new project outline tree:
#+begin_src org

* Project 1
** Material evaluations
** Test results
** Voice of customer feedback
** Business plan

#+end_src

--- Now imagine a team meeting has occurred:
#+begin_src org

* Project 1
** Material evaluations
*** Polymer A + polymer B: John Smith has evaluated this combination
and it has acceptable such and such properties. Will proceed with the
following DOE to confirm:

[table of proposed experiments]

*** Polymer C + D: So and so also suggested looking into this combination

** Test results
** Voice of customer feedback
** Business plan

#+end_src


--- More time has passed and testing and another team meeting occurred
#+begin_src org

* Project 1
** Material evaluations
*** Polymer A + polymer B: John Smith has evaluated this combination
and it has acceptable such and such properties. Will proceed with the
following DOE to confirm:

[table of proposed experiments]

*** Polymer C + D: So and so also suggested looking into this combination

** Test results
John's test results are in. He confirmed A+B will be successful and
C+D has failed crucial requirements:

[table of experimental results, graphs, etc.]

Based on these results, the team decided to move forward with a small
scale pilot run of material.

** Voice of customer feedback
*** Team proposed week of [date] to move forward with voice of
customer feedback for prototypes using A+B.

** Business plan
*** Voice of customer will feed into value proposition and help
determine sale price

#+end_src


So... you get where I'm going, hopefully. I've thought of trying to
switch to an outline format by subject rather than date simply because
I think it makes waaaaay more sense. I'm constantly digging through
date trees for updates on the same subject matter that span several
team meetings. What I find neat is that I could publish my org-mode
file as the team leader to html and perhaps create some sort of
iterative snapshot view for the team. They could click through
hotlinks for each revision date in some sort of header that would
feature all new tree items in bold or something. It could create an
"OS X like time machine" view of the project history and make it easy
to see when things happened.

Thoughts? I'm open to suggestions on how to organize my information
better as well and am curious whether orgmoders typically opt for time
based entries (like mine far above) or a more outline/subject-focused
approach. For now, I've just been trying to get everything entered
*somewhere* -- having done that for a while, I'm realizing that my
current system is tedious for mining and think I'm headed toward an
outline/subject oriented approach.


Thanks for feedback (and for reading a rather long post),
John

Re: Organizing by time or by subject and an idea

[Max Mikhanosha]

At Fri, 20 Jan 2012 12:04:51 -0600,
John Hendy wrote:
> 
> I use org-mode for all of my work notes. For the most part, I'm very
> happy with it. I know everything is in there somewhere and I can find
> it. I currently have one file for my projects organized something like
> this:
> 
> 
> * Project 1
> ** Journals
> *** 2011 November
> **** [2011-11-15 Tue] Weekly project update 				:mtg:
> **** [2011-11-22 Tue] Weekly project update 				:mtg:
> 
> So, one of the issues I've constantly struggled with in org is whether
> to try and create a skeleton outline of all of the aspects of the
> project and fill it in bit by bit during things like weekly
> meetings... or whether to do what I do above and go chronologically,
> simply creating journal entries for the day something happens. Part of
> the reason for choosing chronological is that I am required to
> document Intellectual Property related concepts. Time ordering makes
> it simple to just print out an export of the items since my last brain
> dump and past them into a technical notebook for dating/witnessing.
> 
> To just keep adding means my exports will either be redundant (include
> all the stuff I pasted last time too) or tedious (find all new updates
> and move to separate temp file for exporting).

Generally I think the way to tackle this is to take advantage that you
are working with plain text and not with Word document, and use
standard Emacs/Unix tools for working with text.

Some ideas:

Before updating each project, cut-n-paste it into the new
revision.. Org mode makes it easy to cut-n-paste trees, for myself
duplicating a headline is simply pressing Y then P over a folded
headline (viper/vimpulse user)

So what about:

* Project 1 <... folded content... >

Then you about to start a team meeting, or review, or basically
revising the project. Cut-paste the whole tree so you have two
identical copies, then edit the copy's title to reflect revision
or date or draft number etc.

* Project 1 <... folded content... >
* Project 1 draft2 <... folded content... >

Start revising the draft2 tree.

When you need to figure out what had changed between "Project 1" and
"Project 1 draft 2", you put both into indirect buffers like so:

Go to Project 1, press, C-c C-x b (this will create indirect buffer
"Project 1-1"), then go to draft 2 tree, and do same thing. If you did
not edit the title, it will reuse the indirect buffer name, since its
titled after the headline. You can give different numeric prefix to
C-c C-x b to create different indirect buffers for headlines with same
text.

Then use M-x ediff-buffers, and you can navigate changes easily by
pressing n or p in ediff control panel. I just tried it out and it
worked pretty good. Only thing that could have worked better, is to
hook-up ediff with org-reveal or reveal-mode, so that it automatically
folds all unchanged stuff, and only reveals text in the highlighted
regions.

If you do this "copy the project" thing once a week or so, you can
have a nice ediff of the project's progress along the time-line.

Actually it may not be a bad idea to implement M-x
org-ediff-subtree-with-sibling command, that would do that
automatically, and would include the ediff hooks to do fold/reveal of
regions

The downside of this method is that you have to learn ediff, which is
IMHO has a steep learning curve for new users, but is very powerful
once you learn to use and customize it.

Regards,
  Max

Re: Organizing by time or by subject and an idea

[Max Mikhanosha]

At Sat, 21 Jan 2012 07:59:38 -0500,
Max Mikhanosha wrote:

> If you do this "copy the project" thing once a week or so, you can
> have a nice ediff of the project's progress along the time-line.
> 
> Actually it may not be a bad idea to implement M-x
> org-ediff-subtree-with-sibling command, that would do that
> automatically, and would include the ediff hooks to do fold/reveal of
> regions

Expanding on that thought, if one were to write a contrib module to do
this type of stuff, maybe each time you want to make revision of a
project, you make a copy of it, and archive the old one. This way all
searches only find the most recent stuff. And then have M-x
org-ediff-subtree-with-archive command, which accepts numeric argument
being the N'th copy of the archived tree?

Re: Organizing by time or by subject and an idea

[Max Mikhanosha]

At Sat, 21 Jan 2012 07:59:38 -0500,
Max Mikhanosha wrote:
> 
> Go to Project 1, press, C-c C-x b (this will create indirect buffer
> "Project 1-1"), then go to draft 2 tree, and do same thing. If you did
> not edit the title, it will reuse the indirect buffer name, since its
> titled after the headline. You can give different numeric prefix to
> C-c C-x b to create different indirect buffers for headlines with same
> text.

Correction, C-c C-x b always names the buffer same, adding "-1"
suffix, or numeric prefix instead of 1.

So to create two indirect buffers for two sub-trees, you need to do:

C-c C-x b on the first headline and
C-u 2 C-c C-x b on the second headline

Re: Organizing by time or by subject and an idea

[Eric S Fraga]

Max Mikhanosha <max@openchat.com> writes:

> At Fri, 20 Jan 2012 12:04:51 -0600,
> John Hendy wrote:

[...]

> Generally I think the way to tackle this is to take advantage that you
> are working with plain text and not with Word document, and use
> standard Emacs/Unix tools for working with text.

Agreed!

> Some ideas:
>
> Before updating each project, cut-n-paste it into the new
> revision.. Org mode makes it easy to cut-n-paste trees, for myself
> duplicating a headline is simply pressing Y then P over a folded
> headline (viper/vimpulse user)

Is it not easier to simply make use of any of the revision control
systems (git, mercurial, svn, even RCS) that are out there?  You can
easily tag a particular revision based on milestones and then see diffs
between the current content and any previous version.

In terms of the original questions, I use a combination of hierarchical
structure that is filled in as a project develops, with
revision control to allow me to see progress, together with a log based
recording of activities (e.g. meetings, deliverables delivered, issues
raised).  That is, I mix both of the approaches mentioned by John in his
initial email.

The key, as John has already stated, is to record everything!  With
emacs, I can usually pull out what I want *if* the information was
recorded in the first place.

Finally, tags can be very useful for quick searching as well.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.192.g32af)

Re: Organizing by time or by subject and an idea

[John Hendy]

On Mon, Jan 23, 2012 at 3:00 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Max Mikhanosha <max@openchat.com> writes:
>
>> At Fri, 20 Jan 2012 12:04:51 -0600,
>> John Hendy wrote:
>
> [...]
>
>> Generally I think the way to tackle this is to take advantage that you
>> are working with plain text and not with Word document, and use
>> standard Emacs/Unix tools for working with text.
>
> Agreed!
>

Thanks to both of you for input!

>> Some ideas:
>>
>> Before updating each project, cut-n-paste it into the new
>> revision.. Org mode makes it easy to cut-n-paste trees, for myself
>> duplicating a headline is simply pressing Y then P over a folded
>> headline (viper/vimpulse user)
>
> Is it not easier to simply make use of any of the revision control
> systems (git, mercurial, svn, even RCS) that are out there?  You can
> easily tag a particular revision based on milestones and then see diffs
> between the current content and any previous version.
>
> In terms of the original questions, I use a combination of hierarchical
> structure that is filled in as a project develops, with
> revision control to allow me to see progress, together with a log based
> recording of activities (e.g. meetings, deliverables delivered, issues
> raised).  That is, I mix both of the approaches mentioned by John in his
> initial email.
>

This is intriguing. I don't suppose you have a sample file of sorts?
Specifically, I'm interested in how you mix 'n match
hierarchical/topical vs. time-based organization. I really struggle
with this and my purely time based stuff is *definitely* not the way
to go in my opinion, as I have tons of related things in separate
trees with time stamps, which makes finding some little tidbit silly
since I'm looking through different dates for it.

Also, I'm a super git newb. The furthest I've gotten to is setting up
a repo for sharing stuff between work and home, for example, and
simply doing `git pull` from each location when I want to work on
something and then `git push` when I'm done. I'm assuming I could set
up some sort of cron job to `git commit; git push` each day/week or
something? And then learn more git commands to show progress?

Is there a way to spit git timeline based output into separate file revisions?

Sorry if this is getting too off-track from org. I should probably
look into the power of git on my own...


> The key, as John has already stated, is to record everything!  With
> emacs, I can usually pull out what I want *if* the information was
> recorded in the first place.
>
> Finally, tags can be very useful for quick searching as well.

I still need to figure out a better tag system as well. Currently, I
just have a project acronym under each main header:

-----
* Tracking
Odds and ends tasks

* Project 1      :proj1:
Stuff for project 1

* Project 2     :proj2:
Stuff for project 2

* References     :ref:
Misc things I need to refer back to now and then (project reporting IDs, etc.)
-----

That's quasi helpful, but not really... Do you tag by type of data
stored? Project/task type/name?



Thanks again,
John

>
> --
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
> : using Org-mode version 7.8.03 (release_7.8.03.192.g32af)
>

Re: Organizing by time or by subject and an idea

[Bernt Hansen]

John Hendy <jw.hendy@gmail.com> writes:

> On Mon, Jan 23, 2012 at 3:00 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>>
>> The key, as John has already stated, is to record everything!  With
>> emacs, I can usually pull out what I want *if* the information was
>> recorded in the first place.
>>
>> Finally, tags can be very useful for quick searching as well.
>
> I still need to figure out a better tag system as well. Currently, I
> just have a project acronym under each main header:
>
> -----
> * Tracking
> Odds and ends tasks
>
> * Project 1      :proj1:
> Stuff for project 1
>
> * Project 2     :proj2:
> Stuff for project 2
>
> * References     :ref:
> Misc things I need to refer back to now and then (project reporting IDs, etc.)
> -----
>
> That's quasi helpful, but not really... Do you tag by type of data
> stored? Project/task type/name?

Hi John,

I have lots of projects that have similar structure and headlines.  I
use tags sparingly -- mainly for filtering in the agenda and for
information about tasks.  I almost always work from the agenda to find
what to do next and having the tags indicating which project the task is
for is very convenient.  Tags are inherited so I'll normally tag the top
level project with some unique name and a few file tags are added for
grouping tasks.

I keep multiple projects in a single file but they are all related to
some larger projects.  I'll archive done state tasks away when they are
2 months old.

Something like this:

,----[ fileX.org ]
| #+FILETAGS: XX
| 
| * Tasks
| ** TODO Do this
| * TODO SomeProject                                               :someproject:
| ** TODO Create design document
| ** TODO Coding
| *** TODO FileA
| **** TODO FunctionQ
| *** TODO FileB
| * TODO OtherProject                                                  :otherproject:
| ** TODO Create design document
| ** TODO Coding
| *** TODO FileF
| **** TODO FunctionR
| *** TODO FileG
`----

,----[ fileY.org ]
| #+FILETAGS: YY
| 
| * Tasks
| ** TODO Do this
| * TODO ProjA                                               :proja:
| ** TODO Create design document
| ** TODO Coding
| *** TODO FileA
| **** TODO FunctionQ
| *** TODO FileB
| * TODO ProjB                                                  :projb:
| ** TODO Create design document
| ** TODO Coding
| *** TODO FileF
| **** TODO FunctionR
| *** TODO FileG
`----

When looking for tasks to work on in the agenda it's obvious what a task
belongs to.  Each task has an XX or YY tag from the FILETAGS line and
all projB tasks have a :projb: tag.  I use this a lot to quickly
distinguish tasks from each other in the global todo list.

My current global todo list has tasks with 1 - 5 tags.  Only HOLD tasks
have 5 tags (where :HOLD: is automatically added when I change the task
state)  All tasks have at least 1 tag (coming from the FILETAGS entry).

Filtering the agenda with tags is immensely useful.  You can limit to a
specific tag, or exclude tasks with some tag, etc which helps me focus
on the thing I'm working on now.

I also limit my block agenda view to subtree and project using my fairly
recent changes on http://doc.norang.ca/org-mode.html.

HTH,
Bernt

Re: Organizing by time or by subject and an idea

[Eric S Fraga]

John Hendy <jw.hendy@gmail.com> writes:

> On Mon, Jan 23, 2012 at 3:00 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

[...]

>> In terms of the original questions, I use a combination of hierarchical
>> structure that is filled in as a project develops, with
>> revision control to allow me to see progress, together with a log based
>> recording of activities (e.g. meetings, deliverables delivered, issues
>> raised).  That is, I mix both of the approaches mentioned by John in his
>> initial email.
>>
>
> This is intriguing. I don't suppose you have a sample file of sorts?
> Specifically, I'm interested in how you mix 'n match
> hierarchical/topical vs. time-based organization. I really struggle

I may have mislead you; I do not mix 'n match in a single org file.  A
project file will have various entries as required (meeting notes,
todos, actual code, whatever) but the time logging is completely
separate.  I log all my activities and each entry simply indicates the
particular project I am working on (or whatever, like reading emails
;-).  The logging is in a standalone file, imaginatively called log.org.

Likewise, general GTD stuff also goes into separate files: tasks.org,
diary.org.

So maybe not what you want after all...

[...]

> Also, I'm a super git newb. The furthest I've gotten to is setting up

I can't help you here.  I'm also a n00b when it comes to git.  I use it
pretty much like you for org related stuff: to keep various systems in
sync.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.283.g171ea)

Re: Organizing by time or by subject and an idea

[John Hendy]

I got food feedback as far as the "snapshots" inquiry, but am still
not settled on the time vs. topic hierarchy strategy (definite thanks
to Bernt and Eric Fraga!). I thought of a specific situation that
might help with receiving feedback.

I think were I solely working as an individual, the structure Bernt
suggested would work. Essentially:

* todo Some bigger task
** todo subtask 1
** todo subtask 2

And so on. Basically -- lay out the steps you think you need to do to
complete it... and complete it. Store notes under the todos and you're
good to go.

But I work with a team. Some todos are dependent on input from the
team... Consider this example:

* todo some bigger task
** todo decide on what color to make the widgets for the three field tests
** todo subtask 2

Now, let's say I have a team meeting where my marketer tells me the
decision for the widget colors:
- field test 1: red
- field test 2: blue
- field test 3 green

I have [at least] two options:

* todo some bigger task
** done decide on what color to make the widgets for the three field tests
- field test 1: red
- field test 2: blue
- field test 3 green

or...

* Team Meeting Summaries
** [timestamp] Team Update
Alice informed us of the color decisions:
- field test 1: red
- field test 2: blue
- field test 3 green


I feel stuck in situations like this... I need to reproduce minutes
and thus it makes sense to keep the information with the chronological
event in which it occurred. I also know that it fits a larger project
structure and fulfills some task. I don't think duplicating it is the
way to go...

I suppose I could do:

** done decide on colors
See meeting on [timestamp] or [[org-link]]

One other thought I had was to have an idea similar to radio tables.
Imagine if you could have a link from the chronological entry
(meeting) to the todo entry that's not complete. The link would jump
back and forth between the two... but it would play a radio table type
of role in that it would export from either location (the original or
the radio call for that snippet).

Thoughts on this?

** done decide on colors
<<mtg on [timestamp]>>

* Meetings
** [timestamp] team meeting
#+begin_src radio text
Alice informed us of the color decisions:
- field test 1: red
- field test 2: blue
- field test 3 green
#+end_src

The block only signifies that the block can be linked to; it exports
just the same as if the block weren't there. Yet, if the todo is
exported, it recreates that block in the todo.

Just an idea. I'd be interested in how others keep things together
both in their meeting/event context as well as the fact that these
events often feed tidbits of information into several applicable
locations in a topic-structured outline.


Thanks,
John



On Fri, Jan 20, 2012 at 12:04 PM, John Hendy <jw.hendy@gmail.com> wrote:
> I use org-mode for all of my work notes. For the most part, I'm very
> happy with it. I know everything is in there somewhere and I can find
> it. I currently have one file for my projects organized something like
> this:
>
> #+begin_src org
>
> * Tracking
>
> This is for misc todos. It's just a repo for holding them until done
> and then I typically archive them.
>
> * Project 1
> ** Journals
> *** 2011 November
> **** [2011-11-15 Tue] Weekly project update                             :mtg:
> Summary
>
> **** [2011-11-22 Tue] Weekly project update                             :mtg:
>
> *************** todo action item 1
> *************** done action item 2
>                 CLOSED: [2012-01-11 Wed 18:01]
> *************** cancelled action item 3
>                 CLOSED: [2011-12-26 Mon 11:05]
>
> **** [2011-11-28 Mon] Met with Person to go over test methods                   :mtg:
> Summary
>
> *** 2012 January
> **** [2012-01-03 Tue] Weekly project update                                     :mtg:
> **** [2012-01-10 Tue] Weekly project update                             :mtg:
> **** [2012-01-11 Wed] Analytical testing
> **** [2012-01-17 Tue] Weekly project update                                     :mtg:
>
> * Other project trees
> Similar stuff as Project 1
>
> * Misc Journals
> Journal entries organized similarly as above, but not on my main projects
>
> * Reference
> Odds and ends that I just need to put somewhere for reference later
>
> #+end_src
>
> So, one of the issues I've constantly struggled with in org is whether
> to try and create a skeleton outline of all of the aspects of the
> project and fill it in bit by bit during things like weekly
> meetings... or whether to do what I do above and go chronologically,
> simply creating journal entries for the day something happens. Part of
> the reason for choosing chronological is that I am required to
> document Intellectual Property related concepts. Time ordering makes
> it simple to just print out an export of the items since my last brain
> dump and past them into a technical notebook for dating/witnessing.
>
> To just keep adding means my exports will either be redundant (include
> all the stuff I pasted last time too) or tedious (find all new updates
> and move to separate temp file for exporting).
>
> Last night as I drifted off to bed I had an idea connected to role as
> team leader I have. It involves ordering by outline, but having some
> way to show time-based updates. Imagine "snapshots" of
> exports/org-files. Perhaps:
>
>
> --- View as of two weeks ago when just creating a new project outline tree:
> #+begin_src org
>
> * Project 1
> ** Material evaluations
> ** Test results
> ** Voice of customer feedback
> ** Business plan
>
> #+end_src
>
> --- Now imagine a team meeting has occurred:
> #+begin_src org
>
> * Project 1
> ** Material evaluations
> *** Polymer A + polymer B: John Smith has evaluated this combination
> and it has acceptable such and such properties. Will proceed with the
> following DOE to confirm:
>
> [table of proposed experiments]
>
> *** Polymer C + D: So and so also suggested looking into this combination
>
> ** Test results
> ** Voice of customer feedback
> ** Business plan
>
> #+end_src
>
>
> --- More time has passed and testing and another team meeting occurred
> #+begin_src org
>
> * Project 1
> ** Material evaluations
> *** Polymer A + polymer B: John Smith has evaluated this combination
> and it has acceptable such and such properties. Will proceed with the
> following DOE to confirm:
>
> [table of proposed experiments]
>
> *** Polymer C + D: So and so also suggested looking into this combination
>
> ** Test results
> John's test results are in. He confirmed A+B will be successful and
> C+D has failed crucial requirements:
>
> [table of experimental results, graphs, etc.]
>
> Based on these results, the team decided to move forward with a small
> scale pilot run of material.
>
> ** Voice of customer feedback
> *** Team proposed week of [date] to move forward with voice of
> customer feedback for prototypes using A+B.
>
> ** Business plan
> *** Voice of customer will feed into value proposition and help
> determine sale price
>
> #+end_src
>
>
> So... you get where I'm going, hopefully. I've thought of trying to
> switch to an outline format by subject rather than date simply because
> I think it makes waaaaay more sense. I'm constantly digging through
> date trees for updates on the same subject matter that span several
> team meetings. What I find neat is that I could publish my org-mode
> file as the team leader to html and perhaps create some sort of
> iterative snapshot view for the team. They could click through
> hotlinks for each revision date in some sort of header that would
> feature all new tree items in bold or something. It could create an
> "OS X like time machine" view of the project history and make it easy
> to see when things happened.
>
> Thoughts? I'm open to suggestions on how to organize my information
> better as well and am curious whether orgmoders typically opt for time
> based entries (like mine far above) or a more outline/subject-focused
> approach. For now, I've just been trying to get everything entered
> *somewhere* -- having done that for a while, I'm realizing that my
> current system is tedious for mining and think I'm headed toward an
> outline/subject oriented approach.
>
>
> Thanks for feedback (and for reading a rather long post),
> John

Re: Organizing by time or by subject and an idea

[Bernt Hansen]

John Hendy <jw.hendy@gmail.com> writes:

> I got food feedback as far as the "snapshots" inquiry, but am still
> not settled on the time vs. topic hierarchy strategy (definite thanks
> to Bernt and Eric Fraga!). I thought of a specific situation that
> might help with receiving feedback.
>
> I think were I solely working as an individual, the structure Bernt
> suggested would work. Essentially:
>
> * todo Some bigger task
> ** todo subtask 1
> ** todo subtask 2
>
> And so on. Basically -- lay out the steps you think you need to do to
> complete it... and complete it. Store notes under the todos and you're
> good to go.
>
> But I work with a team. Some todos are dependent on input from the
> team... Consider this example:
>
> * todo some bigger task
> ** todo decide on what color to make the widgets for the three field tests
> ** todo subtask 2
>
> Now, let's say I have a team meeting where my marketer tells me the
> decision for the widget colors:
> - field test 1: red
> - field test 2: blue
> - field test 3 green
>
> I have [at least] two options:
>
> * todo some bigger task
> ** done decide on what color to make the widgets for the three field tests
> - field test 1: red
> - field test 2: blue
> - field test 3 green
>
> or...
>
> * Team Meeting Summaries
> ** [timestamp] Team Update
> Alice informed us of the color decisions:
> - field test 1: red
> - field test 2: blue
> - field test 3 green
>
>
> I feel stuck in situations like this... I need to reproduce minutes
> and thus it makes sense to keep the information with the chronological
> event in which it occurred. I also know that it fits a larger project
> structure and fulfills some task. I don't think duplicating it is the
> way to go...

Hi John,

In situations like this I keep the notes from the meeting in my
'meeting' task and create duplicate TODO tasks from the items in the
meeting.  This way my meeting notes are coherent and complete, and I'm
free to do whatever I want with the created subtasks without touching my
meeting notes.

ie.

** DONE Meet with team
   Notes from team meeting go here
   field test 1: red
   field test 2: blue

then if I have another task for

** TODO Determine colour for field test 1

I'll make it done and either link it to the team meeting task, or just
copy in the details I need so I can see immediately from the task what
colour was chosen.

HTH,
Bernt

Re: Organizing by time or by subject and an idea

[John Hendy]

On Fri, Feb 10, 2012 at 8:03 PM, Bernt Hansen <bernt@norang.ca> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> I got food feedback as far as the "snapshots" inquiry, but am still
>> not settled on the time vs. topic hierarchy strategy (definite thanks
>> to Bernt and Eric Fraga!). I thought of a specific situation that
>> might help with receiving feedback.
>>
>> I think were I solely working as an individual, the structure Bernt
>> suggested would work. Essentially:
>>
>> * todo Some bigger task
>> ** todo subtask 1
>> ** todo subtask 2
>>
>> And so on. Basically -- lay out the steps you think you need to do to
>> complete it... and complete it. Store notes under the todos and you're
>> good to go.
>>
>> But I work with a team. Some todos are dependent on input from the
>> team... Consider this example:
>>
>> * todo some bigger task
>> ** todo decide on what color to make the widgets for the three field tests
>> ** todo subtask 2
>>
>> Now, let's say I have a team meeting where my marketer tells me the
>> decision for the widget colors:
>> - field test 1: red
>> - field test 2: blue
>> - field test 3 green
>>
>> I have [at least] two options:
>>
>> * todo some bigger task
>> ** done decide on what color to make the widgets for the three field tests
>> - field test 1: red
>> - field test 2: blue
>> - field test 3 green
>>
>> or...
>>
>> * Team Meeting Summaries
>> ** [timestamp] Team Update
>> Alice informed us of the color decisions:
>> - field test 1: red
>> - field test 2: blue
>> - field test 3 green
>>
>>
>> I feel stuck in situations like this... I need to reproduce minutes
>> and thus it makes sense to keep the information with the chronological
>> event in which it occurred. I also know that it fits a larger project
>> structure and fulfills some task. I don't think duplicating it is the
>> way to go...
>
> Hi John,
>
> In situations like this I keep the notes from the meeting in my
> 'meeting' task and create duplicate TODO tasks from the items in the
> meeting.  This way my meeting notes are coherent and complete, and I'm
> free to do whatever I want with the created subtasks without touching my
> meeting notes.
>

Gotcha. So keep things with the "event" in which they occurred/action
was taken and recreate what is necessary elsewhere for documentation
or coherence (as in, why the todo is able to be marked done due to the
meeting).


> ie.
>
> ** DONE Meet with team
>   Notes from team meeting go here
>   field test 1: red
>   field test 2: blue
>
> then if I have another task for
>
> ** TODO Determine colour for field test 1
>
> I'll make it done and either link it to the team meeting task, or just
> copy in the details I need so I can see immediately from the task what
> colour was chosen.
>

Thanks for clarifying, and this squares with what I saw the options as
-- recreate or link.

I don't know why, but I just have these mini-existential crises about
org-mode organization. I continually feel like once I *finally* get my
de-facto system in place I can just shut up and use the tool rather
than thinking about *how* to use the tool all the time. Sigh...

Thanks for helping me!


John

> HTH,
> Bernt