emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* Best practice for providing an Org-based application?
@ 2019-09-08 17:37 Neil Jerram
  2019-09-08 19:57 ` Marcin Borkowski
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Neil Jerram @ 2019-09-08 17:37 UTC (permalink / raw)
  To: Org Mode List

[-- 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 --]

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

• * Re: Best practice for providing an Org-based application?
    2019-09-08 17:37 Best practice for providing an Org-based application? Neil Jerram
  @ 2019-09-08 19:57 ` Marcin Borkowski
    2019-09-09  1:01 ` Bob Newell
                     ` (2 subsequent siblings)
    3 siblings, 0 replies; 13+ messages in thread
  From: Marcin Borkowski @ 2019-09-08 19:57 UTC (permalink / raw)
    To: Neil Jerram; +Cc: Org Mode List
  
  
  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
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: Best practice for providing an Org-based application?
    2019-09-08 17:37 Best practice for providing an Org-based application? Neil Jerram
    2019-09-08 19:57 ` Marcin Borkowski
  @ 2019-09-09  1:01 ` Bob Newell
    2019-09-09 16:47 ` John Kitchin
    2019-09-18 19:02 ` Thorsten Jolitz
    3 siblings, 0 replies; 13+ messages in thread
  From: Bob Newell @ 2019-09-09  1:01 UTC (permalink / raw)
    To: Org Mode List
  
  
  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 *
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: Best practice for providing an Org-based application?
    2019-09-08 17:37 Best practice for providing an Org-based application? Neil Jerram
    2019-09-08 19:57 ` Marcin Borkowski
    2019-09-09  1:01 ` Bob Newell
  @ 2019-09-09 16:47 ` John Kitchin
    2019-09-10 13:44   ` Jean Louis
    2019-09-10 21:34   ` Neil Jerram
    2019-09-18 19:02 ` Thorsten Jolitz
    3 siblings, 2 replies; 13+ messages in thread
  From: John Kitchin @ 2019-09-09 16:47 UTC (permalink / raw)
    To: emacs-orgmode
  
  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
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• • * Re: Best practice for providing an Org-based application?
      2019-09-09 16:47 ` John Kitchin
    @ 2019-09-10 13:44   ` Jean Louis
      2019-09-10 21:49     ` Neil Jerram
      2019-09-10 21:34   ` Neil Jerram
      1 sibling, 1 reply; 13+ messages in thread
    From: Jean Louis @ 2019-09-10 13:44 UTC (permalink / raw)
      To: John Kitchin; +Cc: emacs-orgmode
    
    * 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
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • • * Re: Best practice for providing an Org-based application?
        2019-09-10 13:44   ` Jean Louis
      @ 2019-09-10 21:49     ` Neil Jerram
        2019-09-11  7:11       ` Marcin Borkowski
        0 siblings, 1 reply; 13+ messages in thread
      From: Neil Jerram @ 2019-09-10 21:49 UTC (permalink / raw)
        To: Jean Louis; +Cc: Org Mode List, John Kitchin
      
      [-- 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 --]
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: Best practice for providing an Org-based application?
          2019-09-10 21:49     ` Neil Jerram
        @ 2019-09-11  7:11       ` Marcin Borkowski
          0 siblings, 0 replies; 13+ messages in thread
        From: Marcin Borkowski @ 2019-09-11  7:11 UTC (permalink / raw)
          To: Neil Jerram; +Cc: Org Mode List, Jean Louis, John Kitchin
        
        
        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
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • * Re: Best practice for providing an Org-based application?
      2019-09-09 16:47 ` John Kitchin
      2019-09-10 13:44   ` Jean Louis
    @ 2019-09-10 21:34   ` Neil Jerram
      2019-09-10 23:11     ` John Kitchin
      1 sibling, 1 reply; 13+ messages in thread
    From: Neil Jerram @ 2019-09-10 21:34 UTC (permalink / raw)
      To: John Kitchin; +Cc: Org Mode List
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • • * Re: Best practice for providing an Org-based application?
        2019-09-10 21:34   ` Neil Jerram
      @ 2019-09-10 23:11     ` John Kitchin
        2019-09-11  7:13       ` Marcin Borkowski
        0 siblings, 1 reply; 13+ messages in thread
      From: John Kitchin @ 2019-09-10 23:11 UTC (permalink / raw)
        To: Neil Jerram; +Cc: Org Mode List
      
      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
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: Best practice for providing an Org-based application?
          2019-09-10 23:11     ` John Kitchin
        @ 2019-09-11  7:13       ` Marcin Borkowski
          2019-09-11  7:35         ` SYOGM Management
          2019-09-11 13:58         ` Martin Alsinet
          0 siblings, 2 replies; 13+ messages in thread
        From: Marcin Borkowski @ 2019-09-11  7:13 UTC (permalink / raw)
          To: John Kitchin; +Cc: Neil Jerram, Org Mode List
        
        
        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
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

      • • * Re: Best practice for providing an Org-based application?
            2019-09-11  7:13       ` Marcin Borkowski
          @ 2019-09-11  7:35         ` SYOGM Management
            2019-09-11 13:58         ` Martin Alsinet
            1 sibling, 0 replies; 13+ messages in thread
          From: SYOGM Management @ 2019-09-11  7:35 UTC (permalink / raw)
            To: Marcin Borkowski; +Cc: Org Mode List
          
          * 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
          
          ^ permalink raw reply	[flat|nested] 13+ messages in thread

        • * Re: Best practice for providing an Org-based application?
            2019-09-11  7:13       ` Marcin Borkowski
            2019-09-11  7:35         ` SYOGM Management
          @ 2019-09-11 13:58         ` Martin Alsinet
            1 sibling, 0 replies; 13+ messages in thread
          From: Martin Alsinet @ 2019-09-11 13:58 UTC (permalink / raw)
            To: Marcin Borkowski; +Cc: Neil Jerram, Org Mode List, John Kitchin
          
          [-- 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 --]
          
          ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: Best practice for providing an Org-based application?
    2019-09-08 17:37 Best practice for providing an Org-based application? Neil Jerram
                     ` (2 preceding siblings ...)
    2019-09-09 16:47 ` John Kitchin
  @ 2019-09-18 19:02 ` Thorsten Jolitz
    3 siblings, 0 replies; 13+ messages in thread
  From: Thorsten Jolitz @ 2019-09-18 19:02 UTC (permalink / raw)
    To: emacs-orgmode
  
  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
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-09-18 19:02 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-08 17:37 Best practice for providing an Org-based application? Neil Jerram
2019-09-08 19:57 ` Marcin Borkowski
2019-09-09  1:01 ` Bob Newell
2019-09-09 16:47 ` John Kitchin
2019-09-10 13:44   ` Jean Louis
2019-09-10 21:49     ` Neil Jerram
2019-09-11  7:11       ` Marcin Borkowski
2019-09-10 21:34   ` Neil Jerram
2019-09-10 23:11     ` John Kitchin
2019-09-11  7:13       ` Marcin Borkowski
2019-09-11  7:35         ` SYOGM Management
2019-09-11 13:58         ` Martin Alsinet
2019-09-18 19:02 ` Thorsten Jolitz

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).