Moodle Fair Allocation for School Project Days: Scale, Algorithm, and What to Watch on Managed Hosting

ByPriya Nair

The short answer: 600 students across 35 projects is workable

Moodle’s Fair Allocation plugin (mod_ratingallocate) has been deployed at WWU Münster with over 800 participants distributed across 30 choices — without the algorithm failing. The plugin’s own documentation puts distributing 500 users to 21 choices at around 11 seconds of compute time. A school with 600 students and 35 projects falls squarely in this range.

The algorithm does not give up. It always produces an allocation. The real question is whether the server gives it enough time to finish.

What the algorithm actually does

Fair Allocation solves a minimum-cost flow problem using a modified Edmonds-Karp algorithm with Bellman-Ford for finding augmenting paths. Students rate projects — you choose the strategy: yes/no, ranked order, Likert scale, or points — and after voting closes, the algorithm maximises overall satisfaction across all participants rather than any single student’s preference.

Worst-case complexity is O(m²n²), where m and n represent the edges and nodes in the flow graph. Both participant count and project count drive the runtime, and their interaction matters more than either figure alone. Thirty-five projects with 600 students produces a well-connected graph, noticeably heavier than five projects with the same crowd.

The cron risk on shared hosting like Schule@BW

This is where managed hosting changes the picture. Modern versions of mod_ratingallocate run the allocation algorithm as a Moodle adhoc task — a background job triggered by cron, not by the web request. That decouples the computation from the browser’s HTTP timeout. You will not get a 504 gateway error just because the math takes 20 seconds.

On managed hosting, two things can still kill the task mid-run. First, a per-task time limit imposed by the provider that is shorter than the algorithm needs. Second, the cron runner being under memory pressure or heavy load when the job fires. Either scenario produces a partial allocation — some students assigned, some not — usually with no obvious error message pointing to the cause.

Server collapses reported in older German Moodle forums were almost certainly not the algorithm failing to find a solution. The task was terminated before it could finish writing results back to the database. The distinction matters because the fix is different: it is a hosting configuration issue, not an algorithmic one.

What to check before the project days

Contact your Schule@BW support and ask two concrete questions: does the server impose a per-task time limit on Moodle cron jobs, and has that limit been raised for compute-heavy adhoc tasks? If nobody can answer, treat that as a yellow flag and plan accordingly.

Then run a dry test. Set the activity up four to six weeks before the real event. Enrol a representative subset of students — or create test accounts — have them submit votes, then trigger the allocation. If it completes cleanly, you have a green light. If it hangs or returns an incomplete result, you know before it matters.

Minimising manual clean-up afterwards

Every student who only rated already-full projects lands in the unallocated pool. The plugin ships two automatic fallback strategies for these leftovers: fill each project slot in sequence, or spread remaining students evenly. Neither is great for fairness on the margins. The real lever is the voting configuration, not the fallback.

  • Use the Ranking (Reihenfolge) strategy and ask students to rank at least five or six projects, not just their top three. More expressed preferences give the algorithm more room to find a valid match.
  • Set a meaningful gap between minimum and maximum capacity per project. A project capped at a strict 15 seats is much harder to fill than one where 12 to 18 are acceptable.
  • After the algorithm runs, the manual reassignment interface lets you move individual students between projects. It is functional but not fast at scale — budget real time for this step.

Choosing a rating strategy

For project days with 30-plus options, the Ranking strategy tends to produce the cleanest allocations: students provide an explicit preference order and the algorithm has unambiguous signal. Likert scale works but adds noise — different students interpret the same scale label differently. The binary yes/no is the worst choice at this scale. Students approve everything, the algorithm has nothing to differentiate on, and manual cleanup increases sharply.

Sources


Similar Posts