Re: [O] 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 <address@hidden> 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 | address@hidden |       |               |
> | S | Sue   | Sue De Vere   | address@hidden       |       |               |
> |---+-------+---------------+--------------------------+-------+---------------|
> | A | Fiona | Fiona Kite    | address@hidden         |       |               |
> | A | Gemma | Gemma Johnson | address@hidden          |       |               
> |
> |---+-------+---------------+--------------------------+-------+---------------|
> | T | Don   | Don Bradley   | address@hidden      |       |               |
> | T | Nigel | Nigel Finch   | address@hidden         |       |               |
> |---+-------+---------------+--------------------------+-------+---------------|
> | B | Sam   | Sam Trueman   | address@hidden   |       |               |
> | B | Vince | Vince Lyon    | address@hidden      |       |               |
>
> ** 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 <address@hidden> 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 <address@hidden> 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