How rostering works: Generate, draft, publish

Generate a draft roster runs the scheduler: it looks at who is eligible, who opted in, who is away, who did what last time, and the policies your ecclesia has set, then fills every slot it can. It is doing in a few seconds what a coordinator does by hand over an evening. This page explains what it is deciding and why — so you can tell a sensible roster from one that needs a nudge. Reading time: five minutes.

It makes a draft, not a roster

A run writes a draft. Nobody is rostered and nobody is notified until you publish it. Until then you can drag people around, open slots to volunteers, re-run it, or discard it, and no member sees a thing. Three things are worth knowing:

Already-published dates are left alone. A run never changes an occurrence you have already published; it fills only the un-published gaps and tells you how many it skipped. To re-roster a published date, unpublish it first.
The same shuffle gives the same roster. A run with the same inputs and the same shuffle produces the same result; a fresh run shuffles again, so ties fall differently.
It counts this run only. Fairness and “once every so often” caps look at the duties inside the dates you are rostering — not what someone carried last quarter — unless your ecclesia has turned on a look-back (see below).

How it decides: the ladder

When more than one person could take a slot, the scheduler works down a fixed ladder, strongest first. A rule higher up always wins over one below it:

Eligibility — the role’s own rule (age, sex, baptism, qualifications). Always enforced; it can’t be switched off.
Policies set to Hard — rule the person out entirely.
A standing assignment — a person tied to that slot wins it whenever they are willing and available.
Already on the published roster — on a re-run that keeps existing assignments, the current holder keeps the duty.
Same person across a weekly duty — a weekly duty stays with one person across that week.
Household grouping — a role set to fill from one household (or all singles) keeps its slots together.
Preferred sex — chosen when anyone of that sex is available.
Policies set to Soft, and fairness — traded off against each other by weight.

Open Roster runs → How rostering works inside the app to see this ladder with your ecclesia’s exact policy wording.

Hard, Soft, and weight

Every policy is set to one of three modes:

Hard — a rule the scheduler will not break. A slot stays open rather than break it.
Soft — a strong preference it will break only when keeping it would cost more than the policy’s weight.
Off — the policy is ignored.

A soft policy’s weight is measured in duties: 100 means the scheduler would rather hand the duty to someone already carrying one more than break the rule; 50 is half a duty; 1000 (the maximum) is ten. That is how two soft rules are weighed against each other and against fairness.

By default, “only roster people who opted in” is Hard — the scheduler leaves a slot open rather than roster someone who never put their hand up. An administrator can change any mode or weight on the Scheduling policies page, for the whole ecclesia or per activity.

Why this person?

In the draft, each filled slot shows a short reason the scheduler chose that person — so you never have to guess:

Lightest load — of everyone who could take the slot, they were carrying the fewest duties.
Only candidate — nobody else could take it.
Tie-break — several people were level on load, and the shuffle decided.
Chosen over someone lighter — a preference or a soft rule (a standing choice, a preferred sex, keeping a household together) weighed in their favour even though another person was carrying fewer duties.

Two things coordinators ask about

“The same person came up five weeks running.” Fairness spreads the load, but it is one soft rule among several, and it counts only the run in front of it. If a role has few willing people, or a standing assignment or preferred-sex preference keeps pointing at the same person, they will recur. Set the back-to-back policy to Hard to forbid consecutive weeks, widen the willing pool, or turn on a look-back so last month’s duties count too.

“One member got ten turns while others got none.” Usually the others weren’t eligible or hadn’t opted in, so they were never candidates — fairness can only balance people who could actually do the role. The draft’s run report shows, per role, who was used and who was kept out and by which rule, so you can see whether it was a willing-list gap or a cap doing it.

Counting across runs

By default each run starts fresh: a January–June run doesn’t know who carried duties in November. An administrator can set a look-back on the Scheduling policies page so the scheduler seeds each person’s load (and each “once every so often” cap) from their published duties in the months before the run. Then “once per six months” really means six months, and fairness carries over.