Week 7 Session: Reading the queue

Naming a real queue's apparent rule, watching what actually happens, and being honest about what you could and couldn't verify.

Week 6 put you in a room with other people. This week asks about the order they’re moving in. Instead of another field on the running log, this week’s task is a small case study: one queue, one rule, one honest comparison.

Before the session#

Read the Week 7 lecture first. Keep its distinction in mind: a queue’s structure — how its lines are arranged — isn’t the same thing as its rule — what’s supposed to decide who goes next. This week is about whether you could actually verify the rule from where you stood.

Finding a queue#

Pick one ordinary, real queue you can watch safely and without getting involved — a café counter, a shop checkout, a bus stop, a campus service window. Not a medical facility, an emergency service, or anything sensitive. Observe only: don’t join it to test it, don’t change your position, and don’t photograph, name, or otherwise identify anyone in it.

Reading the rule#

Answer three questions, in order:

1. What’s the rule? Stated outright — a sign, a ticket machine, a “form one line” instruction — or inferred from watching? Write down what you believe it to be, and how you know.
2. What did you see? Record at least three consecutive instances of who got served or moved forward next.
3. Do they match? Compare the sequence to the rule: consistent, inconsistent, or too ambiguous to tell.

A worked example (a model of the reasoning, not a real observation):

Queue: a café counter, one line, two baristas. Rule: no sign, but everyone forms one line and is called to whichever barista is free — inferred first-come-first-served. Observed: three customers served in the order they joined. Comparison: consistent, as far as I could tell — though I could only see the front clearly, so I can’t rule out something I missed further back. That’s a limit on what I checked, not evidence the rule held perfectly.

If you find a genuine inconsistency, treat it as a legibility question first — could you actually see enough to be sure, or is there a plausible reason you didn’t observe (a phone order, someone returning to a held spot)? Don’t call it a broken rule unless you have real grounds to. If you found nothing inconsistent, or had no way to check, say that plainly — “I couldn’t verify it” is a legitimate finding here, not a failed one.

Connecting to the lecture#

Say whether your case fits the pattern Rafaeli et al. found — that a queue’s structure, not just an actual broken rule, can lower reported perceived justice — or departs from it. One entry can’t confirm or refute that finding; it can only show whether your case is consistent with it. Any judgement about fairness is your own reading, not a verdict on the queue.

In the session#

Bring your rule, your observed sequence, and your comparison. We compare across the room: whose rule was stated versus inferred, whose sequence matched, and what “too ambiguous to tell” looked like for different people’s queues.

What this can and can’t show#

One queue, however carefully read, can’t establish that any structure or rule is fair or unfair in general — only whether your case is consistent with a pattern found in a different, controlled setting. This stays smaller than the Week 9 Queue Case Study: one queue, one rule, one observation window, one comparison. Don’t intervene, don’t manufacture an inconsistency, and don’t identify anyone you watched.

Afterwards#

Keep the log running. Week 8 asks what happens when a queue’s rule isn’t the same for everyone in it.