Re: Organizing by time or by subject and an idea

[John Hendy <jw.hendy@gmail.com>]

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