The Roster Allocation Process

This page describes how the new roster allocation process (also known as an "algorithm") works. It is derived from the old Elders' Roster, appropriately modified to reflect the new parameters. Over time, it will evolve to better reflect the workings of our new church structures. These rosters derive from an original concept for the old Elders' Rosters, whereby allocations to the rosters were made on a rolling weekly basis (originally for the next 3 months), and slowly refined with experience and requests from Elders.

Principles of Operation

There are several principles of operation:

  1. The allocations should be "fair". Exactly what constitutes "fairness" is not easy to say, but the original view was that everyone rostered should end up doing the same number of duties of an extended period, such as a full calendar year. However, not everyone in the church brings the same skills, time, energy and ability as everyone else, and the view now is that each should contribute according to their own perceived ability. If some people can only be rostered once every three months, that is their choice, and the church is grateful for their contribution. The name given to this flexibility is the intensity of allocation, and is specified in terms of how many weeks must elapse after a given allocation before a person is rostered again.

  2. People should be able to specify when they are able to be rostered. In a church where many retired people travel widely, absences from the church are frequent, and must be catered for. Accordingly, the rosters maintain an "availability page", in which people can nominate those days on which they will be absent from the church, and not available for rostering.
  3. Not only should people be able to specify their intensity, they should be able to specify how much notice they need for an allocation. Some people like to record their allocations months in advance, and enter them into their diaries so that they can plan around their rostered dates. Others are happy to operate on much short notice, and can fill in, for example, for people who are sick or suddenly called away. The name given to this parameter is the allocation period, and indicates how, once allocated, a person will not have their forthcoming allocations changed or increased, at least within the allocation period.

Basis of Operation

The roster algorithm endeavours to equalize the allocation of duties amongst all the volunteers willing to be rostered, subject to the constraints imposed by the principles outlined above. It looks at past allocations, and computes a "magic number" that reflects how many and how recently an individual was rostered for a duty. If you have done more duties recently than person B, you will have a higher magic number than person B. If you have not been rostered more recently than person C, you will have a lower magic number than person C. The person that has the lowest magic number and is available for a particular duty, will be rostered to that duty. These magic numbers are computed every time that the system has to make an allocation, so that they reflect an up-to-date situation.

Is this "fair"? Not exactly, according to our definition above. In theory, if no one went away, and everyone had the same allocation intensity, yes, it would "average out" over the longer term, and everyone would have the same number of allocations. In practice, long absences and longer intensity periods will distort the evenness, and mean that some people will do more than others. People being away, or unavailable due to low intensities, does mean that those still available end up doing more. A fact of life!

Thus, while the number of duties a particular person does should balance out over the longer term, circumstances may dictate some people get a larger number of duties in a short time. For example, over summer, when many people are away and unavailable, a smaller group of available people will have a higher frequency of allocation. Once the vacationers return, the algorithm will try to "catch them up", subject to the intensity and allocation period constraints. (This is why you tend to get allocated more if you have been away for a while.)

As suggested, all this is subject to the two constraints of allocation intensity and allocation period. You cannot catch up faster than your intensity allows, nor can your allocations be altered within the next allocation period. In practice, these constraints may prevent the algorithm from achieving a perfectly "fair" outcome, but it will get as close as it can to an optimum in the circumstances.

Allocation Horizon

The original version of the elders' roster had a fixed four week allocation, and then a tentative allocation beyond that. User feedback indicated that some people were not happy with this. For example, some people like to enter their allocations into a diary for a 3- or 6-month period ahead, and make swaps themselves if they found that their availability subsequently changed. Others were happy to look at the roster on a more frequent basis, and this allowed them to enter availability constraints in the shorter term, and allow the algorithm itself to find a replacement.

This new version (3.0) allows each salt volunteer to specify the length of fixed allocation that they want. You can change these fixed allocation times in a roster preference page (no longer available). A more recent revision (3.1) displays only those names whose allocations are within their fixed allocation times.

Now, once your name has been published in the roster, it is your responsibility to arrange swaps. Please advise all such changes to the office if you are not confident of updating the wiki yourself. (changed in version 3.1)

Allowing variable preferences for allocation has the advantages of:

While you may change your own fixed allocation preference, note that the program will use a minimum fixed allocation preference of 4 weeks, and a maximum of 26 weeks (6 months). These lengths of time can be changed if enough people agree to the change. Why a minimum? Well, the ministry team and the office both need to know ahead of time who is being rostered, so that in the case of the office, a definitive roster for the next four weeks can be published, and in the case of the ministers, so that they can contact those on duty to inform them of any special needs. Why a maximum? Simply that this limits how far ahead the roster needs to be set up.

Why not have the same fixed allocation time for everyone? Everyone has their own preferences. Personally, I (JohnHurst) prefer to know only the next 4 weeks, since I rely upon the email reminders to keep me up-to-date, and I don't have to transfer dates to my diary. I often fill in for others at short notice anyway, and that would require changing future bookings if they stretched too far ahead. I know others prefer to have the next 6 months locked in, so that they can write it into their diaries. This variable allocation time preference caters to both groups.

If you set a long allocation time for yourself, you have the advantage that you can write these into your diary and know that they will not change without your explicit input. The disadvantage is that you have to arrange your own swaps. If you set a short time, you can be more flexible, and you help the system by being able to respond to the various circumstances that may force other salt volunteers to be unavailable, such as sickness, bereavement or other absences. The big advantage is that you can make late bindings to being unavailable, and the system will find a replacement for you, without you having to do anything.

Allocation Intensity

"Intensity" may not be the best word. The higher the number you specify for your allocation intensity, the less frequently you get allocated.

RosterAlgorithm (last edited 2017-12-11 04:11:32 by JohnHurst)