Best practice for providing an Org-based application?

Best practice for providing an Org-based application?

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Is there a best practice or recommended approach for preparing and
providing an Org-based application so that others could make use of it?

I've been using Org for a few years to keep track of the membership and
'fixing' for my choir - where 'fixing' means finding out and recording who
can sing in each concert, who will be there for rehearsals, and so on.
This involves a mix of data that is private to my choir, and workflows and
code that are potentially generic.  I don't know how many people in the
world are both choir organisers and Emacs users, but it seems to me that it
could be useful to separate out and document the generic code and
workflows, so that others could use that as well as me, and that it would
also be an interesting technical challenge.

Has anyone else done something like this?  I wonder if you have
recommendations for how to document, structure and publish this kind of
thing?

Many thanks!
   Neil

[-- Attachment #2: Type: text/html, Size: 1082 bytes --]

Re: Best practice for providing an Org-based application?

[Marcin Borkowski]

On 2019-09-08, at 19:37, Neil Jerram <neiljerram@gmail.com> wrote:

> Is there a best practice or recommended approach for preparing and
> providing an Org-based application so that others could make use of it?
>
> I've been using Org for a few years to keep track of the membership and
> 'fixing' for my choir - where 'fixing' means finding out and recording who
> can sing in each concert, who will be there for rehearsals, and so on.
> This involves a mix of data that is private to my choir, and workflows and
> code that are potentially generic.  I don't know how many people in the
> world are both choir organisers and Emacs users, but it seems to me that it
> could be useful to separate out and document the generic code and
> workflows, so that others could use that as well as me, and that it would
> also be an interesting technical challenge.
>
> Has anyone else done something like this?  I wonder if you have
> recommendations for how to document, structure and publish this kind of
> thing?

That looks pretty interesting, and I suspect that it could be useful not
only for choirs but for other teams as well.  I'd love to see this, even
though I'm probably not a potential user.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Best practice for providing an Org-based application?

[Bob Newell]

Although I don't have an answer to your question, I'm also
interested, as it's been suggested to me that I somehow publish
my code and workflow for substantially easing the somewhat
painful process of taking and inputting registrations for
USCF-rated chess tournaments.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Best practice for providing an Org-based application?

[John Kitchin]

It would be helpful to get a better sense of what is the private data,
e.g. is it something like org-contacts, or some structured data in a
heading? and what are the workflows that might be generic.

I have used org for lots of organizational things in the past, ranging
from conference organization, teaching classes, running job searches,
organizing special issues in scientific publications and lately to
organize some things for a cub scout troop. They have all been pretty
different, but I am sure I have reinvented pieces of it each time. I am
interested in learning more about what you are doing.



Neil Jerram <neiljerram@gmail.com> writes:

> Is there a best practice or recommended approach for preparing and
> providing an Org-based application so that others could make use of it?
>
> I've been using Org for a few years to keep track of the membership and
> 'fixing' for my choir - where 'fixing' means finding out and recording who
> can sing in each concert, who will be there for rehearsals, and so on.
> This involves a mix of data that is private to my choir, and workflows and
> code that are potentially generic.  I don't know how many people in the
> world are both choir organisers and Emacs users, but it seems to me that it
> could be useful to separate out and document the generic code and
> workflows, so that others could use that as well as me, and that it would
> also be an interesting technical challenge.
>
> Has anyone else done something like this?  I wonder if you have
> recommendations for how to document, structure and publish this kind of
> thing?
>
> Many thanks!
>    Neil


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Best practice for providing an Org-based application?

[Jean Louis]

* John Kitchin <jkitchin@andrew.cmu.edu> [2019-09-09 18:48]:
> It would be helpful to get a better sense of what is the private
> data, e.g. is it something like org-contacts, or some structured
> data in a heading? and what are the workflows that might be generic.

My personal problem is that Org files are scattered around, in the
file system. Some people choose to have one or few Org files for many
activities. I have it different, I have one Org file per person, per
company and per more complex project, such project alone produced PDF
of 116 pages or more. I cannot mix various activities in one or few
Org files.

All my contacts are in the database, thus opening of Org file does not
depends on my decision, rather on a simple algorithm, so I am not
"finding a file", rather "finding a person" and then deciding to open
the Org file belonging to the person, or to open the directory
belonging to person, or to account (group, company).

It is based on ID numbers, thus /some/directory/People/1/1.org becomes
the Org file for the person. I am not browsing directories to find it,
computer does that and just opens the file for me.

Org-contacts would never work for me, I have 192,000 contacts to
manage. It works only with the SQL (PostgreSQL) database in the
background. 

> I have used org for lots of organizational things in the past,
> ranging from conference organization, teaching classes, running job
> searches, organizing special issues in scientific publications and
> lately to organize some things for a cub scout troop. They have all
> been pretty different, but I am sure I have reinvented pieces of it
> each time. I am interested in learning more about what you are
> doing.

As you mentioned structured data, I know that I work better with
structured data, for me is that very necessary. For purposes of finely
grained hyperlinking, which can be done with the Org mode, I am
developing system HyperScope, when it becomes ready for public I will
publish it.

It is based on principles as envisioned by Doug Engelbart:
http://dougengelbart.org/content/view/140/000/ -- but the system he
had for finely grained hyperlinking was proprietary software, and
later sold to somebody.

This system could be considered finely grained data tree based driven
menu of hyperlinks. It is based on easier, structured data in the
database, opposite to files.

One video is demonstrating how it is using author names to find other
entries of the same author:
https://open.tube/videos/watch/ed9c47e9-29b7-4624-8d71-3bca68078a0e
and same is valid for tags.

Hyperlinks can be to anything possible, it could be notes, web links,
YouTube links, PDF links, especially PDF by query links or PDF by page
number links.

It is a thought processor that helps in finely grained navigation,
viewing and linking of documents or collections of documents.

If I write a link in the Org file, that link is just written in that
one Org file. There are searches that can be performed, but the link
is usually nowhere else indexed or classified. Same link I need to
repeat for many other people in their Org files, so that means I would
need to keep them somehow in Org files indexed, or in any other
system, so that I can find the link and place it to their Org file
when necessary.

Instead, I keep links in the structured SQL database, PostgreSQL and
collections of documents are organized in the data tree. When
necessary, I can quickly choose structured groups of links by their
tags, categories, groups, and create an Org file, which then can be
inserted or moved to better location.

Here is video demonstrating quick creation of Org files:
https://open.tube/videos/watch/d6a03e79-8b33-4d1f-b840-6a5df0f5f802

Then of course I can have database backed Org files as well.

Or I can link from one list of hyperlinks to various other Org files
by their section heading or by query search or similar.

More important than software is the concept of finely grained
hyperlinking. You read a PDF file, but there is just few pages that
you wish to bookmark. Rarely some PDF reader allows some bookmarking,
but even then, such is not centrally managed, bookmarks are rather
somehow related to files. They cannot be easily shared or published,
or converted into something usable.

Then there are hundreds and thousands of PDF files with their
corresponding thousands of pages, but not all of the knowledge in one
book is useful, maybe just few pieces could be useful in certain
application.

It would be nice to write it all in the Org file, yet for me such
data shall better be in the database. And links are then copied from
central place to Org files or any other files finally, or to email, or
shared by SMS, or published as web pages when necessary.

Jean

Re: Best practice for providing an Org-based application?

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

Thanks Jean for your reply...

On Tue, 10 Sep 2019 at 14:53, Jean Louis <bugs@gnu.support> wrote:

> [...] It would be nice to write it all in the Org file, yet for me such
> data shall better be in the database. And links are then copied from
> central place to Org files or any other files finally, or to email, or
> shared by SMS, or published as web pages when necessary.
>

I think you touch on a couple of interesting points here.

Firstly, it could be difficult to separate out a particular application
from one's Org usage overall.  For me, for the particular case of this
choir role, that is not the case; but I can see that it might be for
others.  I guess that means that the application will be better if it
doesn't force you to move your fundamental data into a form specifically
for that application, but is able to work well with data across your Org
usage as a whole.

Secondly, when one thinks this kind of thing through, it all boils down to
just two things
- tables of fundamental data
- code for operating on that data and generating summaries and derived
tables.
One might then think: why still be in Org mode?  As opposed to a
traditional database.  I think the answer, for me, is that keeping in Org
and plain text means that there are so many levels of possibility that I
can fall back on, if my coding and workflows turn out to be deficient in
some way.  Working in Emacs and Org mode just feels nice.  Also, in my
case, there isn't the massive scale that might motivate using a more
scalable database.

Best wishes,
    Neil

[-- Attachment #2: Type: text/html, Size: 2006 bytes --]

Re: Best practice for providing an Org-based application?

[Marcin Borkowski]

On 2019-09-10, at 23:49, Neil Jerram <neiljerram@gmail.com> wrote:

> One might then think: why still be in Org mode?  As opposed to a
> traditional database.  [...]

Why not both?

Did anyone consider writing a foreign data wrapper (see
e.g. https://wiki.postgresql.org/wiki/Foreign_data_wrappers) so that
PostgreSQL could reference Org tables directly?

I'm not sure how /useful/ that would be, but we're here for cool, not
useful, no? ;-)

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Best practice for providing an Org-based application?

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 6937 bytes --]

Thanks Marcin, Bob and John for your interest and replies; I hope you don't
mind me choosing this one to follow up to.

To try to provide a more detailed idea, I've appended below an Org file
that is part documentation sketch, part me trying to remember and write
down what all of my procedures are for this role.  So that is a first
attempted representation of the public and potentially generic aspect of
this work.

The private or choir-specific data would include:
- singers' names, voices and emails
- the choir's upcoming programmes, and rehearsal and concert dates for each
of those
- details and summaries of which programmes and dates each singer plans to
do
- actual attendance and participation, notes about particular
circumstances, etc.

I hope that helps to explain further what I have in mind, and would
appreciate any further thoughts.

Best wishes,
    Neil


* Org Choir

Org Choir is an Org mode application for choir 'fixing'.  That means
tracking the membership of a choir, recording who can sing in each
concert and which singers are expected at each rehearsal, noting who
is actually at each rehearsal, and so on.

** Membership

We begin with a list of singers, in an Org table like this.  (Please
note: all of the names and emails used in this documentation are made
up.)

|   | Name  | Full name     | Email                    | Notes | More notes... |
|---+-------+---------------+--------------------------+-------+---------------|
| S | Alice | Alice Liddell | aliceliddell@hotmail.com |       |               |
| S | Sue   | Sue De Vere   | suedevere@mail.com       |       |               |
|---+-------+---------------+--------------------------+-------+---------------|
| A | Fiona | Fiona Kite    | fionakite@me.com         |       |               |
| A | Gemma | Gemma Johnson | gemma@email.org          |       |               |
|---+-------+---------------+--------------------------+-------+---------------|
| T | Don   | Don Bradley   | d.bradley@talky.net      |       |               |
| T | Nigel | Nigel Finch   | nigelf@gmail.com         |       |               |
|---+-------+---------------+--------------------------+-------+---------------|
| B | Sam   | Sam Trueman   | samtrueman18@gmail.com   |       |               |
| B | Vince | Vince Lyon    | vincelyon@bigco.com      |       |               |

** Procedures

*** Fixing for a new concert

- Dates for the concert and rehearsals, and rules for if any
  rehearsals can be missed.
- Set up a doodle with those dates.
- Email singers to ask about their availability
- Fixing: singers fill in doodle, or email me, to say if they can do
  the concert, and if they need to miss any rehearsals.
- Collating the fixing data to determine what singers we have for the
  concert.
- Recording each singer's intentions in a log for that singer, so that
  we can check against actual attendance, and more generally review
  that singer's participation over time.
- Identifying any queries that need to be resolved, i.e. singers that
  want to sing but aren't strictly meeting the rehearsal rules.
- Recording the resolution (by the conductor) of any queries.

Changes later on...
- Handle any updates to availability that occur over the lifetime of
  the programme.  (Which might change any of the above.)

*** Maintaining a useful summary for the conductor and other choir organisers

- Who is participating in each upcoming programme
  - Summarised by voice
  - Flagging any queries that still need resolution
- Who is expected at the next rehearsal
  - Summarised by voice

*** Processing actual attendance

- Apologies received shortly before the rehearsal/concert:
  - Responding.
  - Recording.
  - Letting the conductor know, if there's time.
- Note actual attendance at the rehearsal/concert.
- Reconcile against expected attendance:
  - Enquire about any discrepancies.
  - Record the outcome.
  - Handle if singer's overall availability and participation is
    affected.

*** Post-concert actions

- Record programme as done, so it no longer appears in current summaries.
- Decide and handle probation, if choir has that.

*** Longer-term review things

- When did each current member join?
- When did past members join and leave?
- How have overall membership numbers changed over time?
- For each programme, how many members actually sang in it?

*** New applications

- Keep track of singers applying to join
- Agree possible audition dates with them
- Send standard emails to let applicants know audition details
- Include upcoming auditions in fixing summary for choir organisers
- Welcome procedures for successful applicants
  - Standard introductory information
  - Add to membership table
  - Resend fixing emails for all the future programmes that there is
    still time for them to participate in.
  - Handle their responses as in 'Fixing ...' above

** Complications

- Rehearsals with time shared between work for more than one
  programme.


On Mon, 9 Sep 2019 at 17:49, John Kitchin <jkitchin@andrew.cmu.edu> wrote:

> It would be helpful to get a better sense of what is the private data,
> e.g. is it something like org-contacts, or some structured data in a
> heading? and what are the workflows that might be generic.
>
> I have used org for lots of organizational things in the past, ranging
> from conference organization, teaching classes, running job searches,
> organizing special issues in scientific publications and lately to
> organize some things for a cub scout troop. They have all been pretty
> different, but I am sure I have reinvented pieces of it each time. I am
> interested in learning more about what you are doing.
>
>
>
> Neil Jerram <neiljerram@gmail.com> writes:
>
> > Is there a best practice or recommended approach for preparing and
> > providing an Org-based application so that others could make use of it?
> >
> > I've been using Org for a few years to keep track of the membership and
> > 'fixing' for my choir - where 'fixing' means finding out and recording
> who
> > can sing in each concert, who will be there for rehearsals, and so on.
> > This involves a mix of data that is private to my choir, and workflows
> and
> > code that are potentially generic.  I don't know how many people in the
> > world are both choir organisers and Emacs users, but it seems to me that
> it
> > could be useful to separate out and document the generic code and
> > workflows, so that others could use that as well as me, and that it would
> > also be an interesting technical challenge.
> >
> > Has anyone else done something like this?  I wonder if you have
> > recommendations for how to document, structure and publish this kind of
> > thing?
> >
> > Many thanks!
> >    Neil
>
>
> --
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>

[-- Attachment #2: Type: text/html, Size: 8307 bytes --]

Re: Best practice for providing an Org-based application?

[John Kitchin]

This sounds like an interesting application with a lot of complexities.
It definitely blurs the lines between a database where you could run
queries to find/update records, and a human readable, structured data
file that also does this.

I still don't have a clear grasp on how you structure your data, or
if/how you use code to facilitate this process. E.g. do you have
functions you have written to do this, like prepare an attendance check
list from the people you know should be there? or functions that
generate emails to the singers? Do these generate followup tasks for you
in your records?

It seems like org-contacts would make a lot of what you feasible, e.g.
you can store join date and status as properties/tags, which would allow
you to map over them and aggregate information like current membership
numbers.

You could use headings as data containers sort of, since they can have
properties and tags. If you have conventions for table names, you could
do something like have a heading for a concert, and a named table in the
heading containing singer information. From that table a function could
generate an attendance checklist with statistics, and maybe also make it
a task to be completed so you can find it in an agenda. Many of these
functions would be specific to this application though.

Building applications like this for running job searches or teaching
classes in the past, I guess you are looking at several months of
development work if you haven't started yet, and that is assuming you
know what you want and how to write it!

Neil Jerram <neiljerram@gmail.com> writes:

> Thanks Marcin, Bob and John for your interest and replies; I hope you don't
> mind me choosing this one to follow up to.
>
> To try to provide a more detailed idea, I've appended below an Org file
> that is part documentation sketch, part me trying to remember and write
> down what all of my procedures are for this role.  So that is a first
> attempted representation of the public and potentially generic aspect of
> this work.
>
> The private or choir-specific data would include:
> - singers' names, voices and emails
> - the choir's upcoming programmes, and rehearsal and concert dates for each
> of those
> - details and summaries of which programmes and dates each singer plans to
> do
> - actual attendance and participation, notes about particular
> circumstances, etc.
>
> I hope that helps to explain further what I have in mind, and would
> appreciate any further thoughts.
>
> Best wishes,
>     Neil
>
>
> * Org Choir
>
> Org Choir is an Org mode application for choir 'fixing'.  That means
> tracking the membership of a choir, recording who can sing in each
> concert and which singers are expected at each rehearsal, noting who
> is actually at each rehearsal, and so on.
>
> ** Membership
>
> We begin with a list of singers, in an Org table like this.  (Please
> note: all of the names and emails used in this documentation are made
> up.)
>
> |   | Name  | Full name     | Email                    | Notes | More notes... |
> |---+-------+---------------+--------------------------+-------+---------------|
> | S | Alice | Alice Liddell | aliceliddell@hotmail.com |       |               |
> | S | Sue   | Sue De Vere   | suedevere@mail.com       |       |               |
> |---+-------+---------------+--------------------------+-------+---------------|
> | A | Fiona | Fiona Kite    | fionakite@me.com         |       |               |
> | A | Gemma | Gemma Johnson | gemma@email.org          |       |               |
> |---+-------+---------------+--------------------------+-------+---------------|
> | T | Don   | Don Bradley   | d.bradley@talky.net      |       |               |
> | T | Nigel | Nigel Finch   | nigelf@gmail.com         |       |               |
> |---+-------+---------------+--------------------------+-------+---------------|
> | B | Sam   | Sam Trueman   | samtrueman18@gmail.com   |       |               |
> | B | Vince | Vince Lyon    | vincelyon@bigco.com      |       |               |
>
> ** Procedures
>
> *** Fixing for a new concert
>
> - Dates for the concert and rehearsals, and rules for if any
>   rehearsals can be missed.
> - Set up a doodle with those dates.
> - Email singers to ask about their availability
> - Fixing: singers fill in doodle, or email me, to say if they can do
>   the concert, and if they need to miss any rehearsals.
> - Collating the fixing data to determine what singers we have for the
>   concert.
> - Recording each singer's intentions in a log for that singer, so that
>   we can check against actual attendance, and more generally review
>   that singer's participation over time.
> - Identifying any queries that need to be resolved, i.e. singers that
>   want to sing but aren't strictly meeting the rehearsal rules.
> - Recording the resolution (by the conductor) of any queries.
>
> Changes later on...
> - Handle any updates to availability that occur over the lifetime of
>   the programme.  (Which might change any of the above.)
>
> *** Maintaining a useful summary for the conductor and other choir organisers
>
> - Who is participating in each upcoming programme
>   - Summarised by voice
>   - Flagging any queries that still need resolution
> - Who is expected at the next rehearsal
>   - Summarised by voice
>
> *** Processing actual attendance
>
> - Apologies received shortly before the rehearsal/concert:
>   - Responding.
>   - Recording.
>   - Letting the conductor know, if there's time.
> - Note actual attendance at the rehearsal/concert.
> - Reconcile against expected attendance:
>   - Enquire about any discrepancies.
>   - Record the outcome.
>   - Handle if singer's overall availability and participation is
>     affected.
>
> *** Post-concert actions
>
> - Record programme as done, so it no longer appears in current summaries.
> - Decide and handle probation, if choir has that.
>
> *** Longer-term review things
>
> - When did each current member join?
> - When did past members join and leave?
> - How have overall membership numbers changed over time?
> - For each programme, how many members actually sang in it?
>
> *** New applications
>
> - Keep track of singers applying to join
> - Agree possible audition dates with them
> - Send standard emails to let applicants know audition details
> - Include upcoming auditions in fixing summary for choir organisers
> - Welcome procedures for successful applicants
>   - Standard introductory information
>   - Add to membership table
>   - Resend fixing emails for all the future programmes that there is
>     still time for them to participate in.
>   - Handle their responses as in 'Fixing ...' above
>
> ** Complications
>
> - Rehearsals with time shared between work for more than one
>   programme.
>
>
> On Mon, 9 Sep 2019 at 17:49, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>
>> It would be helpful to get a better sense of what is the private data,
>> e.g. is it something like org-contacts, or some structured data in a
>> heading? and what are the workflows that might be generic.
>>
>> I have used org for lots of organizational things in the past, ranging
>> from conference organization, teaching classes, running job searches,
>> organizing special issues in scientific publications and lately to
>> organize some things for a cub scout troop. They have all been pretty
>> different, but I am sure I have reinvented pieces of it each time. I am
>> interested in learning more about what you are doing.
>>
>>
>>
>> Neil Jerram <neiljerram@gmail.com> writes:
>>
>> > Is there a best practice or recommended approach for preparing and
>> > providing an Org-based application so that others could make use of it?
>> >
>> > I've been using Org for a few years to keep track of the membership and
>> > 'fixing' for my choir - where 'fixing' means finding out and recording
>> who
>> > can sing in each concert, who will be there for rehearsals, and so on.
>> > This involves a mix of data that is private to my choir, and workflows
>> and
>> > code that are potentially generic.  I don't know how many people in the
>> > world are both choir organisers and Emacs users, but it seems to me that
>> it
>> > could be useful to separate out and document the generic code and
>> > workflows, so that others could use that as well as me, and that it would
>> > also be an interesting technical challenge.
>> >
>> > Has anyone else done something like this?  I wonder if you have
>> > recommendations for how to document, structure and publish this kind of
>> > thing?
>> >
>> > Many thanks!
>> >    Neil
>>
>>
>> --
>> Professor John Kitchin
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> @johnkitchin
>> http://kitchingroup.cheme.cmu.edu
>>
>>


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Best practice for providing an Org-based application?

[Marcin Borkowski]

On 2019-09-11, at 01:11, John Kitchin <jkitchin@andrew.cmu.edu> wrote:

> This sounds like an interesting application with a lot of complexities.
> It definitely blurs the lines between a database where you could run
> queries to find/update records, and a human readable, structured data
> file that also does this.

This reminds me of this:
https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/

I just had a minor enlightenment why Org-mode is so successful (within
its niche, of course).  It implements a bunch of very general data
structures - a tree, a table, a dictionary - and a few slightly more
specific - a clock table, TODOs/tags, markup...

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Best practice for providing an Org-based application?

[SYOGM Management]

* Marcin Borkowski <mbork@mbork.pl> [2019-09-11 09:17]:
> This reminds me of this:
> https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/
> 
> I just had a minor enlightenment why Org-mode is so successful (within
> its niche, of course).  It implements a bunch of very general data
> structures - a tree, a table, a dictionary - and a few slightly more
> specific - a clock table, TODOs/tags, markup...

Exactly, it is well integrated. The tree is extremely useful.

And maybe it is popular because of... because of propaganda. There is
the manual and few demonstrations and then people get the "Aha" moment
sooner. THere are other hierarchical note editors.

Org mode I have discovered very late and I remember using `hnb' the
hierarchical notebook program that was written in curses, look here:
http://hnb.sourceforge.net/Screen-shots/ since its inception. 

Yet such does not have good propaganda and it not implemented in the
Emacs editor.

There is also Cherrytree https://www.giuspen.com/cherrytree/ beautiul
application for note taking, just missing few features from Org mode.

Yet the beauty of it all is that Org mode has the simple text as its
foundation and no special format.

Jean

Re: Best practice for providing an Org-based application?

[Martin Alsinet]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Neil,

You could use transient[1], the tool used to build the menus of magit[2].
I really like magit's discoverability and ease of use.

There is a video of a talk where it is used to control kubernetes from
inside emacs in magit style:
https://www.youtube.com/watch?v=w3krYEeqnyk

[1] transient: https://github.com/magit/transient
[2] magit: https://magit.vc


On Wed, Sep 11, 2019 at 2:17 AM Marcin Borkowski <mbork@mbork.pl> wrote:

>
> On 2019-09-11, at 01:11, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>
> > This sounds like an interesting application with a lot of complexities.
> > It definitely blurs the lines between a database where you could run
> > queries to find/update records, and a human readable, structured data
> > file that also does this.
>
> This reminds me of this:
> https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/
>
> I just had a minor enlightenment why Org-mode is so successful (within
> its niche, of course).  It implements a bunch of very general data
> structures - a tree, a table, a dictionary - and a few slightly more
> specific - a clock table, TODOs/tags, markup...
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>

[-- Attachment #2: Type: text/html, Size: 2160 bytes --]

Re: Best practice for providing an Org-based application?

[Thorsten Jolitz]

Neil Jerram <neiljerram@gmail.com> writes:

Hi,

> Is there a best practice or recommended approach for preparing and
> providing an Org-based application so that others could make use of it?
>
> I've been using Org for a few years to keep track of the membership and
> 'fixing' for my choir - where 'fixing' means finding out and recording
> who can sing in each concert, who will be there for rehearsals, and so
> on.  This involves a mix of data that is private to my choir, and
> workflows and code that are potentially generic.  I don't know how many
> people in the world are both choir organisers and Emacs users, but it
> seems to me that it could be useful to separate out and document the
> generic code and workflows, so that others could use that as well as me,
> and that it would also be an interesting technical challenge.
>
> Has anyone else done something like this?  I wonder if you have
> recommendations for how to document, structure and publish this kind of
> thing?
>
> Many thanks!
>    Neil

long time ago, but I once started a little project called org-bandbook,
its on my tj64 account on github.
The interesting part about is its importing funcionality for lilypond
songs from another github repo (open book I think), where a guy
transposed hundreds of popular standard (real book) tunes to lilypond with
some Ruby framework code, which I replaced by ob-lilypond code. The idea was to manage songs, band, concert
rehearsals etc in Org-mode, and to be able to easily transpose songs
(its ob-lilypond) for Bb or Eb instruments or so.

OTOH isn't managing a choir or band quite similar to managing a project,
and thus (ob-)taskjuggler would be a very helpful tool here?

-- 
cheers,
Thorsten