emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Neil Jerram
Subject: Re: [O] Best practice for providing an Org-based application?
Date: Tue, 10 Sep 2019 22:34:53 +0100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]