emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* How to deal with small projects which are often changing their status/ person
@ 2013-01-22 20:19 M
  2013-01-22 21:14 ` Thorsten Jolitz
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: M @ 2013-01-22 20:19 UTC (permalink / raw)
  To: emacs orgmode-mailinglist

Hi,

I'm working with org-mode to document my work and to keep track of tasks and
projects.

At the moment there are many little projects where I

* get a text from someone (or write it myself)
* have to read and edit it
* send it oer email to 1 or 2 other colleagues which have to read / edit it
* get it back and check the changes
* maybe send the text again to the original author
* then finally release the text for publication

... and you imagine, there is not only 1 such text at once but several of
them.

I wonder what is an approriate way to keep track of such workflows with
org-mode..

I'm using MS Outlook for mails and so when I receive a mail, I store a
hyperlink pointing to that mail in Outlook.

For a process like the one above I would have a task

* TODO Write Text about topic XY and send it to colleague(s)...

then
* WAIT Colleage(s): Feedback on Text about topic XY
* TODO check feedback/changes of Colleagues and edit again, and send for
approval 
* TODO send to original author
* WAIT for Feedback of original author

(if changes, repeat process above)

* TODO send text to publishing colleague

or similar...

I hope it is clear what I mean, there are a lot of small steps and each time
creating a new task takes much time and I have to copy the name of the
"project" again and again...

Maybe it would be better to add all the notes about the progress as notes in
the Logbook and change the Heading of the task each time, but that also
seems strange to me...

Would there be a way to make the "children" inherit automatically a text
from the project name, e. g.

* Text about topic XY for publishing in ABC
** WAIT John: Feedback on Text about topic XY for publishing in ABC
** Send Text about topic XY for publishing in ABC to Ellen for approval
...

in a way that " Text about topic XY for publishing in ABC" is filled in
automatically by a placeholder?

Or what is your way for tracking such workflows in org-mode?

Kind regards

Martin 
   

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 20:19 How to deal with small projects which are often changing their status/ person M
@ 2013-01-22 21:14 ` Thorsten Jolitz
  2013-01-22 21:39   ` Nicolas Richard
  2013-01-22 21:40   ` M
  2013-01-22 21:39 ` How to deal with small projects which are often changing their status/ person Thomas S. Dye
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 13+ messages in thread
From: Thorsten Jolitz @ 2013-01-22 21:14 UTC (permalink / raw)
  To: emacs-orgmode

M <Elwood151@web.de> writes:

Hi, 

> At the moment there are many little projects where I
>
> * get a text from someone (or write it myself)
> * have to read and edit it
> * send it oer email to 1 or 2 other colleagues which have to read / edit it
> * get it back and check the changes
> * maybe send the text again to the original author
> * then finally release the text for publication
>
> ... and you imagine, there is not only 1 such text at once but several of
> them.
>
> I wonder what is an approriate way to keep track of such workflows with
> org-mode..

this doesn't sound so different from several programmers working on the
same source code file, so I suspect that GIT is the best and the most
popular solution for collaborative work on plain text files. 

If you/your fellow workers don't use GIT or another VCS, there is still
dropbox - put your project text files in your dropbox folder and share
them with other, there are automatic backups of older versions by
Dropbox. 

Or you wait for colorg to be released, that would probably fit your
needs exactly 

-- 
cheers,
Thorsten

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 20:19 How to deal with small projects which are often changing their status/ person M
  2013-01-22 21:14 ` Thorsten Jolitz
@ 2013-01-22 21:39 ` Thomas S. Dye
  2013-01-22 22:27   ` M
  2013-01-23  1:59 ` Eric Abrahamsen
  2013-01-23  9:15 ` Julian Burgos
  3 siblings, 1 reply; 13+ messages in thread
From: Thomas S. Dye @ 2013-01-22 21:39 UTC (permalink / raw)
  To: M; +Cc: emacs orgmode-mailinglist

Aloha M,

M <Elwood151@web.de> writes:

> Hi,
>
> I'm working with org-mode to document my work and to keep track of tasks and
> projects.
>
> At the moment there are many little projects where I
>
> * get a text from someone (or write it myself)
> * have to read and edit it
> * send it oer email to 1 or 2 other colleagues which have to read / edit it
> * get it back and check the changes
> * maybe send the text again to the original author
> * then finally release the text for publication
>
> ... and you imagine, there is not only 1 such text at once but several of
> them.

A terrific source of ideas about how to organize projects with Org mode
is Bernt Hansen's web page, http://doc.norang.ca/org-mode.html

See especially his section 6 about adding tasks quickly with Capture.

I organize projects something like this, where the first level heading
names the project and sub-headings are tasks or task groups for the
project:

* Topic XYZ

** DONE Create text

** WAITING Revisions by Colleague ABC

** TODO Finalize text

** TODO Submit text

When something comes in via email, I quickly file it to refile.org, read
other emails, etc. Then, when convenient, I go through refile.org and
put things where they should go. Bernt's setup using ido makes it
possible to get to Topic XYZ quickly, where the choices can be narrowed
and the appropriate file location easily found.

I try to discipline myself so a DEADLINE or SCHEDULE is always attached
to a TODO item.  It is easy for me to skip the weekly project review
that the GTD approach recommends, and attaching DEADLINE and SCHEDULE
means that fewer things fall through the cracks.

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:14 ` Thorsten Jolitz
@ 2013-01-22 21:39   ` Nicolas Richard
  2013-01-22 21:56     ` Thorsten Jolitz
  2013-01-22 21:40   ` M
  1 sibling, 1 reply; 13+ messages in thread
From: Nicolas Richard @ 2013-01-22 21:39 UTC (permalink / raw)
  To: emacs-orgmode

Thorsten Jolitz <tjolitz@googlemail.com> writes:
> If you/your fellow workers don't use GIT or another VCS, there is still
> dropbox - put your project text files in your dropbox folder and share
> them with other, there are automatic backups of older versions by
> Dropbox. 

I use one trick which might be of interest to some people : when I have
a dropbox folder with text (in my case, these are .tex and related
files) files that will be worked on collaboratively, I first follow
these steps in the directory :

dropbox exclude add .git
git init
git add .
git commit -m "Initial commit"

(it is important that the first step comes first, this avoids the .git
directory from being synched to everyone sharing the folder)

From that moment on, I can monitor changes using git diff which I find
much easier (in particular thank to magit) than Dropbox's own
facilities. Everytime there are new chages, I usually commit them in
order to have some history saved locally (though less complete than the
history in dropbox, since I probably won't commit after every single
change).

(As a side note : another way to use git + dropbox is to have your .git
directory sync'd between your different computers, but I don't like this
very much, and obviously this would be for a completely different
purpose.)

-- 
Nico.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:14 ` Thorsten Jolitz
  2013-01-22 21:39   ` Nicolas Richard
@ 2013-01-22 21:40   ` M
  2013-01-22 21:55     ` Thorsten Jolitz
                       ` (2 more replies)
  1 sibling, 3 replies; 13+ messages in thread
From: M @ 2013-01-22 21:40 UTC (permalink / raw)
  To: Thorsten Jolitz, emacs-orgmode

Thanks Thorsten for your reply!

it is not about programming and it is not about plain text files, but MS
Office (Word) files..

Dropbox is not an option, maybe a document management system (DMS) with
versioning, but it is not in place yet.
And even if there is, how could  I then track my workflow with Emacs?

Kind regards

Martin



> Von: Thorsten Jolitz <tjolitz@googlemail.com>
> Datum: Tue, 22 Jan 2013 22:14:42 +0100
> An: <emacs-orgmode@gnu.org>
> Betreff: Re: [O] How to deal with small projects which are often changing
> their status/ person
> 
> M <Elwood151@web.de> writes:
> 
> Hi, 
> 
>> At the moment there are many little projects where I
>> 
>> * get a text from someone (or write it myself)
>> * have to read and edit it
>> * send it oer email to 1 or 2 other colleagues which have to read / edit it
>> * get it back and check the changes
>> * maybe send the text again to the original author
>> * then finally release the text for publication
>> 
>> ... and you imagine, there is not only 1 such text at once but several of
>> them.
>> 
>> I wonder what is an approriate way to keep track of such workflows with
>> org-mode..
> 
> this doesn't sound so different from several programmers working on the
> same source code file, so I suspect that GIT is the best and the most
> popular solution for collaborative work on plain text files.
> 
> If you/your fellow workers don't use GIT or another VCS, there is still
> dropbox - put your project text files in your dropbox folder and share
> them with other, there are automatic backups of older versions by
> Dropbox. 
> 
> Or you wait for colorg to be released, that would probably fit your
> needs exactly 
> 
> -- 
> cheers,
> Thorsten
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:40   ` M
@ 2013-01-22 21:55     ` Thorsten Jolitz
  2013-01-23  8:59     ` Tomas Hlavaty
  2013-01-23 10:20     ` OT: using ZIP based files with git (was: How to deal with small projects which are often changing their status/ person) Karl Voit
  2 siblings, 0 replies; 13+ messages in thread
From: Thorsten Jolitz @ 2013-01-22 21:55 UTC (permalink / raw)
  To: emacs-orgmode

M <Elwood151@web.de> writes:

> it is not about programming and it is not about plain text files, but MS
> Office (Word) files..
>
> Dropbox is not an option, maybe a document management system (DMS) with
> versioning, but it is not in place yet.
> And even if there is, how could  I then track my workflow with Emacs?

Maybe I shouldn't say this on this list, but this actually sounds to me
like a perfect use case for Google Docs, which is very similar to Word,
can import and export to Word (or simply replace it if the Docs are not
too complex), and is very well suited for collaborative work on the same
documents with automatic backup in the clouds and versioning. 

I think its all about avoiding to work locally on different copies of a
document and then send it back and forth by email. Thats just too
old-school in my eyes. 

-- 
cheers,
Thorsten

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:39   ` Nicolas Richard
@ 2013-01-22 21:56     ` Thorsten Jolitz
  0 siblings, 0 replies; 13+ messages in thread
From: Thorsten Jolitz @ 2013-01-22 21:56 UTC (permalink / raw)
  To: emacs-orgmode

"Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:

> I use one trick which might be of interest to some people : when I have
> a dropbox folder with text (in my case, these are .tex and related
> files) files that will be worked on collaboratively, I first follow
> these steps in the directory :
>
> dropbox exclude add .git
> git init
> git add .
> git commit -m "Initial commit"
>
> (it is important that the first step comes first, this avoids the .git
> directory from being synched to everyone sharing the folder)
>
> From that moment on, I can monitor changes using git diff which I find
> much easier (in particular thank to magit) than Dropbox's own
> facilities. Everytime there are new chages, I usually commit them in
> order to have some history saved locally (though less complete than the
> history in dropbox, since I probably won't commit after every single
> change).

Thats a nice way to enable Emacs/Org-mode/Magit users to work with
fellows from the Microsoft universe - thanks for the tip. 

-- 
cheers,
Thorsten

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:39 ` How to deal with small projects which are often changing their status/ person Thomas S. Dye
@ 2013-01-22 22:27   ` M
  2013-01-22 22:49     ` Thomas S. Dye
  0 siblings, 1 reply; 13+ messages in thread
From: M @ 2013-01-22 22:27 UTC (permalink / raw)
  To: Thomas S. Dye; +Cc: emacs orgmode-mailinglist

Hi Thomas,

thanks for your reply!

Sure I know Bernt Hansen's web page and I'm already using his configuration
for my system. (I'm still learning Emacs and org-mode, so it was easier to
start with an existing setup).

I already know and use the capture and refile feature,
my problem is that I have the feeling to do more administration of tasks
than really doing them if I track such projects like the one described with
org-mode and create a sub-task for each step.
Especially as I'd have to re-type each time again the name of the project if
I want it to appear in my agenda explicitly and not only:
WAITING John: Feedback
(and I would not know which text it is about).


> Von: "Thomas S. Dye" <tsd@tsdye.com>
> Datum: Tue, 22 Jan 2013 11:39:13 -1000
> An: M <Elwood151@web.de>
> Cc: emacs orgmode-mailinglist <emacs-orgmode@gnu.org>
> Betreff: Re: How to deal with small projects which are often changing their
> status/ person
> 
> A terrific source of ideas about how to organize projects with Org mode
> is Bernt Hansen's web page, http://doc.norang.ca/org-mode.html
> 
> See especially his section 6 about adding tasks quickly with Capture.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 22:27   ` M
@ 2013-01-22 22:49     ` Thomas S. Dye
  0 siblings, 0 replies; 13+ messages in thread
From: Thomas S. Dye @ 2013-01-22 22:49 UTC (permalink / raw)
  To: M; +Cc: emacs orgmode-mailinglist

M <Elwood151@web.de> writes:

> Hi Thomas,
>
> thanks for your reply!
>
> Sure I know Bernt Hansen's web page and I'm already using his configuration
> for my system. (I'm still learning Emacs and org-mode, so it was easier to
> start with an existing setup).
>
> I already know and use the capture and refile feature,
> my problem is that I have the feeling to do more administration of tasks
> than really doing them if I track such projects like the one described with
> org-mode and create a sub-task for each step.
> Especially as I'd have to re-type each time again the name of the project if
> I want it to appear in my agenda explicitly and not only:
> WAITING John: Feedback
> (and I would not know which text it is about).

Good news.  With Bernt's setup you are off to a good start.

Perhaps Properties will do what you want?  These are inherited by
sub-trees, so they will follow Task 1, Task 2, etc.

* Topic XYZ
:PROPERTIES:
:CATEGORY: XYZ
:END:

** DONE Task 1

** TODO Task 2

The CATEGORY property shows up in my Agenda, so I would know that Task 2
belonged to XYZ.

This is how I manage the dozen or so open work projects I have at any
one time.  We assign each project a number, which I put in the CATEGORY
property.  When I generate my daily agenda, I see the project number
beside each TODO task.

See Chapter 7 of the manual for details.

hth,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 20:19 How to deal with small projects which are often changing their status/ person M
  2013-01-22 21:14 ` Thorsten Jolitz
  2013-01-22 21:39 ` How to deal with small projects which are often changing their status/ person Thomas S. Dye
@ 2013-01-23  1:59 ` Eric Abrahamsen
  2013-01-23  9:15 ` Julian Burgos
  3 siblings, 0 replies; 13+ messages in thread
From: Eric Abrahamsen @ 2013-01-23  1:59 UTC (permalink / raw)
  To: emacs-orgmode

M <Elwood151@web.de> writes:

> I hope it is clear what I mean, there are a lot of small steps and each time
> creating a new task takes much time and I have to copy the name of the
> "project" again and again...
>
> Maybe it would be better to add all the notes about the progress as notes in
> the Logbook and change the Heading of the task each time, but that also
> seems strange to me...

This is exactly what I do, and it works great for me. If you enable
state-change logging for the TODO keywords you use most, you can keep a
fully annotated and time-stamped history of how the TODO has progressed.
I make the heading something generic (ie, "Article XYZ") and note what
has to be done next in the logbook.

I like the idea of a single TODO for a single "thing", even if that
thing has multiple steps. I often don't know what those steps are going
to be (arguments over email, waiting for someone to get back from
vacation, blocking on another task, etc) so I need flexibility.

In practice, most of my complex tasks start at TODO, bounce back and
forth between NEXT and WAITING, and finally end up at DONE. Changes
between WAITING and NEXT are logged, so I end up with a LOGBOOK full of
neatly stamped changes, each one with a description (plus links to
emails and all) of progress. This "feels right" to me.

My main custom agenda view has a block each for WAITING and NEXT
headings.

> Would there be a way to make the "children" inherit automatically a text
> from the project name, e. g.

Wouldn't this be best taken care of with tags and tag inheritance? I
also put colleagues' names in tags, when something requires their
participation, which makes it easy get a view of "stuff John should be
doing".

The problem with the logbook approach is that logbook entries are fairly
limited beasts (you can't tag them, for instance), and I'm probably
already on the verge of abusing them. Next on my list would be sorting
agenda items by timestamp of most recent log entry, and also an agenda
hotkey to display the most recent log entry for the TODO under point.

Possibly what I should be considering is a state-change trigger that
actually creates a sub-heading TODO, rather than a logbook entry.

Hope something in there's useful!

Eric

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 21:40   ` M
  2013-01-22 21:55     ` Thorsten Jolitz
@ 2013-01-23  8:59     ` Tomas Hlavaty
  2013-01-23 10:20     ` OT: using ZIP based files with git (was: How to deal with small projects which are often changing their status/ person) Karl Voit
  2 siblings, 0 replies; 13+ messages in thread
From: Tomas Hlavaty @ 2013-01-23  8:59 UTC (permalink / raw)
  To: M; +Cc: emacs-orgmode

Hi M,

> it is not about programming and it is not about plain text files, but
> MS Office (Word) files..
>
> Dropbox is not an option, maybe a document management system (DMS)
> with versioning, but it is not in place yet.  And even if there is,
> how could I then track my workflow with Emacs?

I find convenient to convert doc files to text using antiword or wvtext
and then I can follow the changes easily using usual tools.

Tomas

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: How to deal with small projects which are often changing their status/ person
  2013-01-22 20:19 How to deal with small projects which are often changing their status/ person M
                   ` (2 preceding siblings ...)
  2013-01-23  1:59 ` Eric Abrahamsen
@ 2013-01-23  9:15 ` Julian Burgos
  3 siblings, 0 replies; 13+ messages in thread
From: Julian Burgos @ 2013-01-23  9:15 UTC (permalink / raw)
  To: M; +Cc: emacs orgmode-mailinglist

Hi Martin,
I think that you should be using tags for this.  For example:

* Project XYZ       :projectxyz:J.Smith:
** TODO Write Text
** WAIT Feedback on Text
** TODO check feedback
** TODO send to original author
** WAIT for Feedback

In this case you are adding a tag with the project name and another with
the author (for example).  Then when you export this to the agenda, or
generate a list of pending tasks, all the subnodes of this tree will
inherit the tags and you will see them associated to each task.

Another option is to use a different file for each project (maybe not too
practical if you have many of them).  When generating a list of task you
get the file name with each task.  If you name the file as your project
(say projectxyz.org), then you know where that task is coming from.  You
can add something like this to your .emacs file so you do not have to add
all these small files "by hand" to the agenda list:

;----------------------------
(load-library "find-lisp")
(add-hook 'org-agenda-mode-hook (lambda ()
(setq org-agenda-files
      (find-lisp-find-files "/home/documents/smallprojects" "\.org$"))
))
;----------------------------

With this all org files in the "smallprojects" folder will be added to the
agenda.

Hope this helps...

Julian

-- 
Julian Mariano Burgos, PhD
Hafrannsóknastofnunin/Marine Research Institute
Skúlagata 4, 121 Reykjavík, Iceland
Sími/Telephone : +354-5752037
Bréfsími/Telefax:  +354-5752001
Netfang/Email: julian@hafro.is

> Hi,
>
> I'm working with org-mode to document my work and to keep track of tasks
> and
> projects.
>
> At the moment there are many little projects where I
>
> * get a text from someone (or write it myself)
> * have to read and edit it
> * send it oer email to 1 or 2 other colleagues which have to read / edit
> it
> * get it back and check the changes
> * maybe send the text again to the original author
> * then finally release the text for publication
>
> ... and you imagine, there is not only 1 such text at once but several of
> them.
>
> I wonder what is an approriate way to keep track of such workflows with
> org-mode..
>
> I'm using MS Outlook for mails and so when I receive a mail, I store a
> hyperlink pointing to that mail in Outlook.
>
> For a process like the one above I would have a task
>
> * TODO Write Text about topic XY and send it to colleague(s)...
>
> then
> * WAIT Colleage(s): Feedback on Text about topic XY
> * TODO check feedback/changes of Colleagues and edit again, and send for
> approval
> * TODO send to original author
> * WAIT for Feedback of original author
>
> (if changes, repeat process above)
>
> * TODO send text to publishing colleague
>
> or similar...
>
> I hope it is clear what I mean, there are a lot of small steps and each
> time
> creating a new task takes much time and I have to copy the name of the
> "project" again and again...
>
> Maybe it would be better to add all the notes about the progress as notes
> in
> the Logbook and change the Heading of the task each time, but that also
> seems strange to me...
>
> Would there be a way to make the "children" inherit automatically a text
> from the project name, e. g.
>
> * Text about topic XY for publishing in ABC
> ** WAIT John: Feedback on Text about topic XY for publishing in ABC
> ** Send Text about topic XY for publishing in ABC to Ellen for approval
> ...
>
> in a way that " Text about topic XY for publishing in ABC" is filled in
> automatically by a placeholder?
>
> Or what is your way for tracking such workflows in org-mode?
>
> Kind regards
>
> Martin
>
>
>
>
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* OT: using ZIP based files with git (was: How to deal with small projects which are often changing their status/ person)
  2013-01-22 21:40   ` M
  2013-01-22 21:55     ` Thorsten Jolitz
  2013-01-23  8:59     ` Tomas Hlavaty
@ 2013-01-23 10:20     ` Karl Voit
  2 siblings, 0 replies; 13+ messages in thread
From: Karl Voit @ 2013-01-23 10:20 UTC (permalink / raw)
  To: emacs-orgmode

* M <Elwood151@web.de> wrote:
>
> it is not about programming and it is not about plain text files, but MS
> Office (Word) files..
>
> Dropbox is not an option, maybe a document management system (DMS) with
> versioning, but it is not in place yet.

I do not have experience by myself but I've read that other people
are using the git versioning system with ZIP-based file formats (like
docx) as well:

http://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/
http://stackoverflow.com/questions/8001663/can-git-treat-zip-files-as-directories-and-files-inside-the-zip-as-blobs
http://stackoverflow.com/questions/3298525/version-control-for-docx-and-pdf

-- 
Karl Voit

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2013-01-23 10:21 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-22 20:19 How to deal with small projects which are often changing their status/ person M
2013-01-22 21:14 ` Thorsten Jolitz
2013-01-22 21:39   ` Nicolas Richard
2013-01-22 21:56     ` Thorsten Jolitz
2013-01-22 21:40   ` M
2013-01-22 21:55     ` Thorsten Jolitz
2013-01-23  8:59     ` Tomas Hlavaty
2013-01-23 10:20     ` OT: using ZIP based files with git (was: How to deal with small projects which are often changing their status/ person) Karl Voit
2013-01-22 21:39 ` How to deal with small projects which are often changing their status/ person Thomas S. Dye
2013-01-22 22:27   ` M
2013-01-22 22:49     ` Thomas S. Dye
2013-01-23  1:59 ` Eric Abrahamsen
2013-01-23  9:15 ` Julian Burgos

Code repositories for project(s) associated with this 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).