From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: org-mode for knowledge management
Date: Mon, 13 Oct 2014 10:42:28 +0800 [thread overview]
Message-ID: <871tqc3d2j.fsf@ericabrahamsen.net> (raw)
In-Reply-To: CA+M2ft_d=izsMtgO4iquOYfCQ3F4iZjaE=N=4XaO9=KhUOQtgw@mail.gmail.com
John Hendy <jw.hendy@gmail.com> writes:
> On Fri, Oct 10, 2014 at 9:53 PM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> On Fri, Oct 10, 2014 at 10:46 AM, Daniel Clemente <n142857@gmail.com> wrote:
>>>>> >
>>>>> > I've been using org-mode for a variety of purposes for a few years. I find
>>>>> > that it suffers from the same problem that other such tools do. The
>>>>> > problem is me. I can't remember week to week how I may have classified
>>>>> > some scrap of information. Did I drop it into notes/someproduct.org or was
>>>>> > it procedures/someprocess.org?
>>>>
>>>> 1. Every information should have a single location, not two. Mix sections fast
>>>> if you detect repetitions. Use links extensively (C-c l) to connect one header
>>>> with another, specially after you get lost once. Don't bother too much about
>>>> finding the right place at the first time, you'll eventually reorder or move
>>>> headers to the correct place.
>>>
>>> I'm curious about this. Is this a well-known recommendation/best
>>> practice? I actually struggle with this a great deal. Often a bit of
>>> research or testing for a specific project at work is very possibly
>>> relevant to any number of future projects. So, working in product
>>> development, I find it hard to decide what the best "single location"
>>> is, and would love for it to act as though it were in multiple
>>> locations.
>>
>> Isn't this what tags are good for, though? Sort of providing a secondary
>> structure to your information, orthogonal to Org's subtree structure?
>
> Agreed, and have tried that, though that has issues as well, unless
> I'm missing something (see below).
>
>>
>>> When the current project is done, I'd like to archive everything
>>> specifically related to it while keeping around the general knowledge
>>> I've accumulated for use with future efforts.
>>
>> You could organize a project by subtree, but put generally-useful
>> research elsewhere, and tag that research by theme. Then give the
>> project subtree its own tag, but also add tags to the relevant research
>> themes. Open an Agenda with a "projecttag|themetag" tag search to see
>> both general research and project-specific stuff.
>>
>> When the time comes, the project subtree gets archived, but the thematic
>> stuff stays.
>
> This is the bit I'm not sure about...
>
> * project_a
> ** experiment about blah :proj_name:theme:
> [2014-10-11]
>
> Did x, y, and z today. Will analyze results tomorrow.
>
> [2014-10-12]
>
> Wow. Interesting finding. This will help a lot and may be relevant to
> future projects!
>
> So... when I archive project_a, don't I lose the thematic information
> from my experiment? This is sort of the conundrum I often find myself
> in. I work in product development, and many of the difficulties,
> experimental findings, or even contacts/information for a given
> project seem like they'd be really helpful to recall/go back to for
> future projects. The learning is uncovered only because I'm working on
> launching *this* product... but isn't inherently relevant *only* to
> this project.
I guess my assumption is that the "interesting finding" bit would be its
own heading, and would *not* live in the project_a subtree at all, but
rather in a different subtree that was dedicated to whatever the "theme"
is. So the heading for the experiment would just be about the experiment
itself, and you'd make a new "note" about the generally-useful finding
elsewhere.
Perhaps both links and tags are what you're after then: you could leave
a link to the general finding inside "experiment about blah" (to remind
yourself you took that note), but also use the tags to open Agendas on
both project and theme, so you can see all the relevant information in
one place.
Dunno!
> I've migrated from one file per project like I used to do to the big
> 'ol one-file method (except for a contacts.org file and miscellany).
> Thus, I tend to like to archive, but for whatever reason have an
> aversion to agenda-ing on archived stuff. I find I only look in
> archives when someone asks something really specific about a past
> project and I think I have notes on it.
>
> Anyway, that was my thought.
>
> I saw Daniel replied as well; you both understand my struggle -- you
> tackle it with tags and he's suggesting lots of links (more on that in
> a sec).
>
>
> Thanks!
> John
>
>>
>> Anyway, I'm sure you've considered all this, just curious what your
>> thoughts on tags are...
>>
>>> Or is this what you mean by using links? Are you just saying that
>>> individuals should not be copying the same text around in multiple
>>> places?
>>>
>>>
>>> Thanks,
>>> John
>>>
>>> [snip]
>>
>>
next prev parent reply other threads:[~2014-10-13 2:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 22:17 org-mode for knowledge management Louis
2014-10-09 23:54 ` Marcin Borkowski
2014-10-10 15:46 ` Daniel Clemente
2014-10-10 21:40 ` mbork
2014-10-10 21:48 ` John Hendy
2014-10-11 2:53 ` Eric Abrahamsen
2014-10-12 4:54 ` John Hendy
2014-10-13 2:42 ` Eric Abrahamsen [this message]
2014-10-13 3:15 ` Daniel Clemente
2014-10-13 5:17 ` Samuel Wales
2014-10-14 3:47 ` Daniel Clemente
2014-10-14 1:14 ` Eric Abrahamsen
2014-10-11 11:36 ` Daniel Clemente
2014-10-11 19:45 ` Brady Trainor
2014-10-12 4:29 ` Daniel Clemente
2014-10-12 5:03 ` John Hendy
2014-10-12 7:48 ` Daniel Clemente
2014-10-14 2:14 ` John Hendy
2014-10-10 0:18 ` Thomas S. Dye
2014-10-10 2:32 ` Louis
2014-10-10 2:34 ` Louis
2014-10-13 19:29 ` Louis
2014-10-13 19:36 ` Thomas S. Dye
2014-10-13 23:10 ` Louis
2014-10-13 13:11 ` Brett Viren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871tqc3d2j.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).