From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: Best practice for providing an Org-based application? Date: Tue, 10 Sep 2019 19:11:45 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35798) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i7pIf-0001vE-A5 for emacs-orgmode@gnu.org; Tue, 10 Sep 2019 19:11:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i7pId-0006IT-ER for emacs-orgmode@gnu.org; Tue, 10 Sep 2019 19:11:53 -0400 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]:38815) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i7pId-0006IN-7e for emacs-orgmode@gnu.org; Tue, 10 Sep 2019 19:11:51 -0400 Received: by mail-qk1-x744.google.com with SMTP id x5so18873209qkh.5 for ; Tue, 10 Sep 2019 16:11:50 -0700 (PDT) In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" 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 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 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 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