Who should control the club-night rotation?

Every rotation method delegates the same decisions somewhere: who is due, which four should play, who partners whom, whether a preference can override the normal order, and what happens when the obvious answer is a bad game.

No method makes those questions disappear. The difference is whether the answer lives in a physical queue, a volunteer's judgement, the players' negotiation or a configured system.

Five things you are choosing

Compare rotation methods on these five axes:

1. Transparency: can a player understand why they are - or are not - next?
2. Consistency: will Tuesday's rule still be Thursday's rule when a different organiser is present?
3. Game quality: can the method avoid obviously poor matches?
4. Player autonomy: how much say do members have over their own partners/opponents?
5. Volunteer load: how much attention does the method consume while the session is live?

A sixth is sometimes forgotten: recoverability. What happens when the board is wrong, the organiser is absent, the tablet loses connection or somebody disputes the choice?

Those are tendencies, not scores. A badly configured app can be less transparent than a brilliant organiser; a well-run pegboard can include plenty of player choice.

Pegboard: put trust in a visible queue

The physical pegboard's enduring strength is epistemic: everybody can see the same state.

Your peg is here. Those pegs are ahead. Court 3 contains these four. Nobody needs to trust an organiser's memory or an invisible algorithm.

A strict first-four queue also has excellent reproducibility. Given the same board, two different organisers should make the same next call.

The weakness is that order is not game design. A queue can tell you who is due; it cannot by itself tell you whether the first four should be split 1+4 versus 2+3, whether two of them partnered ten minutes ago or whether the player fifth in line would transform a hopeless mismatch.

Many successful pegboard clubs therefore already use a hybrid without calling it one: the queue determines eligibility, then a player or organiser chooses the actual four/teams from a small window.

Use it when: the group values visible order, standards are not too difficult to mix, and the remaining human judgement is manageable.

Organiser: put trust in judgement

A skilled organiser sees information no board contains.

They know Priya has a shoulder problem, Ben and Marcus are practising for Saturday's match, Ana is new but clearly stronger than her self-described "intermediate", and two players have asked not to partner after an argument nobody wants formalised in club settings.

That context is valuable.

The cost is that the organiser becomes infrastructure.

If their method is mostly tacit knowledge, another volunteer cannot reproduce it. If they play a game, the next selection waits. If they unconsciously favour louder or more familiar players, there may be no audit trail. And after two hours, human working memory is not going to contain every recent partnership and wait accurately.

Use it when: the club has a capable willing organiser and values contextual judgement more than formal consistency.

Then document at least the basic principles so the night does not collapse when that person goes on holiday.

Self-selection: put trust in the room

Unstructured self-selection gets criticised because it can create cliques. It can also be delightful.

Six friends on one court do not need a scheduling engine. A small group of similar standard may negotiate games faster than any board. Players can request rematches, coach one another and form partnerships without asking permission.

The method becomes fragile when access to court time depends on social confidence.

The player who says, "Right, you three with me" gets games. The newcomer who does not know whether they are allowed to insert themselves waits. Strong players can gravitate towards one another; nobody owns the responsibility for the person left over.

So the relevant variable is not just group size. It is social symmetry: do all members have roughly equal confidence and standing in the group?

Use it when: the room is small, socially integrated and capable of noticing its own exclusions.

Software: put trust in explicit policy

Software's strength is not superior wisdom. It is memory and consistency.

A system can retain:

• actual wait duration;
• games played;
• player ratings;
• recent partners/opponents;
• sit-outs;
• late arrivals;
• fixed-pair requests;
• and whatever constraints the club has configured.

Its failure mode is different: the system may optimise a rule the club never consciously chose.

If a player who waited longest is skipped because a much closer game exists without them, was that fair? There is no technical answer. The club needs a policy.

ePegboard, for example, treats waiting, expected closeness, queue position and variety as signals, while allowing organisers to turn some preferences into hard constraints and to override any proposed game. That is valuable only if those controls match how the club wants to operate.

Use software when: the desired rules exceed what the room can track comfortably and you are willing to make those rules explicit.

The hybrids are often better

The interesting designs sit between the four columns.

Queue + front-player choice

The longest-waiting player must be included, then chooses three players from the next six or eight. Court-time priority remains visible while the player gets agency over game style.

Software suggestion + organiser veto

The system handles routine memory; the organiser intervenes for context the data does not know. This is often a better division of labour than either fully manual or unquestioned automation.

Self-selection + maximum-wait rule

Players arrange games freely, but anyone crossing a published wait threshold gets priority into the next suitable court. Social freedom exists inside a fairness guardrail.

Normal rotation + requested court

Most courts follow standard rotation while one court occasionally hosts a league pair, coaching game or player-requested four. The exception is explicit rather than secretly distorting the queue.

Hybrids work because the two parts can compensate for each other's failure modes.

Choose by failure mode, not feature list

Ask what is currently going wrong:

"Nobody knows whose turn it is."
You need more visible queue state.

"The order is fair but the games are awful."
Keep the queue; improve team/game selection.

"Only one person can run the night."
Externalise their rules into a process or system.

"Members hate being told whom to play."
Increase bounded player choice rather than abolishing fairness.

"Newcomers stand around."
Give someone or something explicit responsibility for incorporating them.

"The app makes odd choices nobody understands."
Improve explainability/configuration or choose a simpler method.

Do not replace a pegboard whose only problem is that it looks old.

How to change without provoking a culture war

A club-night process becomes part of the club's social contract. Changing it can feel larger than the technology deserves.

So preserve one familiar invariant.

If moving from a pegboard to software, keep longest-wait priority initially. If moving from organiser picks, let the organiser review suggestions. If adding player choice, restrict it to a known eligibility window.

Then compare the result against the failure you set out to fix.

Our separate ePegboard rollout guide goes deeper into that transition, but the principle applies to any new system: change the decision process deliberately, not merely the display it runs on.

Frequently asked questions

Is a pegboard fair?

A pegboard can be very fair at queue order if everyone follows the same rule. It does not automatically make fair games or remember previous partnerships. Its fairness therefore depends on what job you expect the board to do and what judgement remains with players or the organiser.

Is an organiser better than an algorithm at making games?

An experienced organiser has context software may not know - injuries, friendships, coaching goals and who is having a bad night. Software has better memory and consistency across waits, ratings and repeated pairings. A strong hybrid is often software proposing the routine game while a human keeps override authority.

Should the front player be allowed to choose the next game?

It can work well if the choice is bounded. For example, the longest-waiting player must be included and may choose from the next several eligible players. That preserves player autonomy without turning the whole room into unrestricted self-selection.

Does software remove the need for club rules?

No. It makes the rules more explicit. A club still needs to decide whether queue order is hard or soft, how much game balance can justify a skip, whether fixed pairs are allowed and how long someone can wait. Software executes policy; it should not invent the policy silently.

When should a club change its rotation method?

When the failure mode of the current method is recurring and material: the organiser never plays, queue disputes keep returning, games are repeatedly poor, newcomers cannot understand the process, or the system depends on one person being present. Do not change merely because a more modern tool exists.