From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: Organizing by time or by subject and an idea Date: Fri, 10 Feb 2012 13:47:34 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:56295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvwRW-0005uV-FC for emacs-orgmode@gnu.org; Fri, 10 Feb 2012 14:47:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvwRU-0002Gm-O3 for emacs-orgmode@gnu.org; Fri, 10 Feb 2012 14:47:38 -0500 Received: from mail-bk0-f41.google.com ([209.85.214.41]:43630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvwRU-0002Gg-CB for emacs-orgmode@gnu.org; Fri, 10 Feb 2012 14:47:36 -0500 Received: by bkty12 with SMTP id y12so390246bkt.0 for ; Fri, 10 Feb 2012 11:47:34 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode 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 <> * 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 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :mtg: > Summary > > **** [2011-11-22 Tue] Weekly project update =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :mtg: > > *************** todo action item 1 > *************** done action item 2 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CLOSED: [2012-01-= 11 Wed 18:01] > *************** cancelled action item 3 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CLOSED: [2011-12-= 26 Mon 11:05] > > **** [2011-11-28 Mon] Met with Person to go over test methods =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :mtg: > Summary > > *** 2012 January > **** [2012-01-03 Tue] Weekly project update =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 :mtg: > **** [2012-01-10 Tue] Weekly project update =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :mtg: > **** [2012-01-11 Wed] Analytical testing > **** [2012-01-17 Tue] Weekly project update =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 :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 tre= e: > #+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