Church Rosters Detail

Note that as of 30 Apr 2015 all automatic processing of the rosters as described here has been disabled, as per Council Correspondence 28 Apr 2015, item 5.5. For the substitute scheme, please see here.

Note that this page is intended for roster maintenance, and should not be used as a general reference. The general use version of this page is at ChurchRosters. Further technical information is at RosterTechnicalInformation.

Contents of This Page

Roster Details

Roster / Office Email?

Version

Status

Preferences

Email
remind

Email
alerts

Times (see below, Note 1)

Coordinator

Mailing List

Notes

PsalterRoster

0.3.0

-

-

-

-

-

JohnHurst

-

The Master Class, not used independently

RosterGreeting

{OK}

0.1.4

disabled

GreetingPreferences

{OK}

{OK}

S8,S9,S11,S4,S7

vacant

[email protected]

revised heading

RosterVestry

{OK}

0.1.4

disabled

VestryPreferences

{OK}

{OK}

S9,S11

DavidMorgan

[email protected]

revised heading

RosterCommunion

{OK}

0.1.6

disabled

CommunionPreferences

{OK}

{OK}

S9,S11

FayeWagon

[email protected]

revised heading

RosterDoor

{OK}

0.1.3

disabled

DoorPreferences

{OK}

{OK}

S9,S11

PamGraham

RosterFinance

{OK}

0.1.4

disabled

FinancePreferences

{OK}

{OK}

S9,S11

MattGraham

[email protected]

RosterSound

{OK}

0.1.3

disabled

SoundPreferences

{OK}

{OK}

S9,S11

JohnSnare

RosterMorning

{OK}

0.1.3

disabled

MorningPreferences

{OK}

{OK}

S10

RewaFeenaghty

known as RosterMorningTea, but named RosterMorning

RosterHospitality

{OK}

0.3.2

disabled

HospitalityPreferences

{OK}

{OK}

S10

JanClear

revised heading

RosterKids

{OK}

0.1.3

disabled

{OK}

{X} (2)

S9

vacant

By term

RosterPreaching

{OK}

0.1.4

disabled

{OK}

{X} (2)

S8,S9,S11,S4,S7

MinistryTeamGroup

Service times used to generate worship-related rosters

RosterMusic

{OK}

0.1.3

disabled

{OK}

{X} (2)

S11

RobertFleming

RosterBible

{OK}

0.1.4

disabled

{OK}

{X} (2)

S9,S11

EileenScott

RosterCleaning

{OK}

0.1.3

disabled

{OK}

{X} (2)

Sats

RossLennon

RosterLeisure

{OK}

0.1.3

disabled

{OK}

{X} (2)

Mondays

ElwynPederson

RosterTheHub

{OK}

0.2.2

disabled

TheHubPreferences

{OK}

{X} (2)

Tu10,Tu12,We12,
Th10,Th12

JudithGreenwood

By term

RosterFlowers

{OK}

0.0.0

(no longer) under construction

{X} (2)

Sats

EileenScott

RosterBand

{X}

manual

{X}

S9

JacobDavey

Now showing rest of 2014. Awaiting verification.

RosterEnglishClass

{X}

not on wiki

??

JanClear

Few weeks ahead.

RosterAgedCare

{X}

not on wiki

??

AlisonClarkson

RosterLeafletDelivery

{X}

not on wiki

PeterAnderson

Four deliveries per year. See LeafletDelivery

Introduction

Notes

  1. Times are shown for normal weeks. Special Events and Liturgical Calendar Occasions may change these. Note that regular Sunday times are abbreviated to S8,S9,S11,S4,S7 representing 8am, 9:15am, 11am, 4:30pm, and 7pm respectively.
  2. semi-automatic and manual rosters cannot perform "allocation alerts", as the system has no way of knowing when manual allocations are made. It is left to the responsibility of the person making a manual allocation to alert the rostered person concerned. A one week reminder will still be sent.
  3. automatic rosters with an allocation of 4 weeks are effectively semi-automatic. The 4 weeks is inserted to ensure that there are no vacancies left when the roster is published to the office door. Otherwise, the roster relies upon the roster coordinator inserting names manually.

Further Explanation

Status

The Status field indicates where in the long-term plan for rosters the particular roster is at.

Automatic is the long-term goal, with all information in the roster being supplied automatically once a week. The '+n' field indicates that automatic allocation is done for the next 'n' weeks. This is in fact a minimum figure - individuals specifying longer allocation periods will be allocated automatically for their specified period.

Semi-auto means that the roster is updated once a week as a blank shell to allow manual allocations. Email reminders for next week's duties are sent, however email alerts for new allocations are not sent (since these are done manually).

The boundary between automatic and semi-automatic rosters is simply one of how far automatic allocation goes. Currently, semi-auto has 0 (zero) weeks of allocation, in other words, no automatic allocations are made, but otherwise, email reminders are sent, and the roster blank entries are extended to the standard 52 weeks ahead. Any amount of allocation (1 week or more) makes the roster "automatic", and it is intended that eventually (once everything settles down) all rosters will be automatic for at least 4 weeks.

The sound roster is an example of this. While revision 32 of the roster is indeed marked as an auto-update, no automatic allocations were made, and the only real change was to delete the most recent duties (Good Friday and Easter Day), and to add 2 blank entries for 19 Apr 2015.

This parameter of the number of weeks for which allocations are made is thus the defining criterion for "automatic" versus "semi-automatic". The point of the latter category is just to give roster coordinators the flexibility of making the allocations themselves. I suspect that once everyone understands this, we won't need the semi-auto category anymore, but all rosters will become 13 weeks or more and thus "automatic".

Manual rosters are just that. All entries and adjustments are made by human interaction - no automatic processing is applied.

not on wiki means that all roster maintenance is done outside the wiki. No on-line form is maintained.

Office Email

The thumbs up icon( {OK} ) in the Office Email field indicates that entries from this roster are collected together and automatically forwarded to the ChurchOffice for publishing in paper form on the Office Notice Board, outside the ChurchOffice.

Technical Operation

There are three programs associated with the automatic roster system. Each of these runs at a set time each week. The second two depend upon output from the first one, and hence must always be run after the first, although the order of running the second two (Reminders and Office Roster) is not prescribed.

The Allocation Program

This is the heart of the automatic rostering system. Each roster has its own associated routine, designed to run in a standalone mode, so that allocations for individual rosters can be made independently. Normally, all of these associated routines are run automatically once a week, as specified in a master control routine, called runRosters.sh. This master routine specifies the parameters for each roster routine, such as the number of weeks for which allocations are to be made. When these roster routines are run independently, other parameters may also be specified, such as starting and ending dates of each roster (normally the next Sunday through to 52 weeks into the future), the date beyond which no allocations are made, and whether the wiki pages are to be updated or not.

The operation of this program (or rather, each associated roster program) is as follows:

  1. The previous roster is read in. This roster has the name RosterNamePrevious, and defines the duties for people on the roster for the preceeding 52 weeks.

  2. The current roster RosterName is read in, and the two rosters (previous and current) are combined to make a single roster covering the period from (usually) 52 weeks in the past through to 52 weeks in the future.

  3. Allocation of blank entries in the roster proceeds week by week from the starting date (normally next Sunday), using an algorithm that is designed to give everyone equal turns at the roster, but also making allowances for various factors (described below). The algorithm is described in RosterAlgorithm.

  4. New allocations and duties for the next week only are written to an output file for later processing by the Reminders Program.
  5. Allocations for the next 4 weeks are written to an output file for later processing by the Office Roster program.
  6. The new roster is split into two halves, the preceeding 52 weeks (now advanced by one week from the input version), and the following 52 weeks (also advanced by one week). Each of these is written to an updated wiki page, the RosterNamePrevious and RosterName, as used for input.

  7. The program terminates.

Factors taken into account when making allocations include:

  1. People already allocated within the roster for the current day are excluded (note that this currently does not include other rosters, due to technical reasons).

  2. People listed in the special RosterUnavailable page for this week are excluded from allocation.

  3. People are not reallocated within n weeks of their last allocation, where n is the so-called Exclusion Period (see RosterNewSystems). This value may be set by the user.

  4. Only allocations within the next m weeks are displayed in the roster, where m is the so-called Allocation Period (see RosterNewSystems). This value may be set by the user. Note that once an allocation is published in the roster, it will not be altered by later runs of the Allocation Program.

  5. Allocations against duties are done on the basis of the NamePreferences file, which contains definitions of the values of n and m.

The Reminders Program

This program is responsible for making the mailouts of all reminders for duties in the coming week. Also advised are any new allocations made by the Allocation Program in the most recent allocation cycle.

The Office Roster Program

The program generates the 4 week rosters listing displayed on the office notice board, and mails it to the office.

TODOs (disabled)

  1. revise allocation prohibition over fixed weeks, as well as exclusion
  2. wiki Home Page updater and automatic removal of non-members (deceased, xfers, etc.)
  3. ditto, wrt Carters
  4. Continuation of documentation
  5. opt-out for email reminders
  6. audit of Preference pages against database roster group memberships (underway, pending further preference page creation)
  7. flagging of communion leader (need input/output call backs on allocation lists)
  8. bugs in email reminder code(further fixes on 20141023, still in testing)


CategoryRosters

ChurchRostersDetail (last edited 2015-10-14 04:06:03 by DavidMorgan)