The failure is in the queue, not the moderator
In most hybrid Q&A failures, nobody decided to ignore remote attendees. The room queue was visible — a line at the mic, a hand raised in the third row — and the remote queue was a browser tab behind the speaker timer. The chair’s attention became the selection policy, and attention defaults to what is physically in front of it.
That is a design problem with a testable fix. Treat question selection as floor control: one queue, explicit states, a chair who decides in the open, and a log that records the decision. The protocol below can be run for a single session, compared against the previous session’s source mix, and reverted if it does not hold.
What the sources actually establish
Three primary or near-primary sources frame the problem:
- Floor control as a model. The UMPIRE paper describes a moderation architecture built on the Binary Floor Control Protocol (BFCP), in which requests are “stored (in a PENDING state) in the First-Come-First-Served queue at the centralized floor control server” and forwarded to a chair who makes the decisions. The same paper notes that the queue “can be populated with requests coming both from remote participants … and local participants,” and cites a remote-participation requirement that the chair “MUST be able to see all requests from remote attendees to speak at any time during the entire meeting.” (Romano, UMPIRE, arXiv:2206.15416)
- Named failure modes. The Microphone Access Fairness Protocol Internet-Draft lists, among “common failure scenarios,” “queue reordering based on physical proximity, and starvation of remote participants due to unmodeled latency.” It also states that “a moderator declaring a Last Question Promise should either enforce it or clearly label it as aspirational.” The draft is marked Experimental and expires 27 July 2026 — treat it as a vocabulary source, not a standard. (draft-godoy-fischer-mafp-00)
- Practice in the field. An event-platform guide recommends putting “every question, from the room and from the stream, into one moderated queue” and then alternating “one question from the floor, one from online.” A Q&A product page describes the same pattern — one queue for both audiences, with source tagging so a moderator can “take one from the room, one from the stream.” (InEvent guide; Q&A Events hybrid page)
What these sources do not establish: any measured rate of remote-versus-room question selection, any named incident, or any claim that a product guarantees fairness. The protocol below is a recommendation, not a research finding. The numbers in it are starting thresholds to test, not benchmarks.
Why two queues fail and one queue with tags works
Two surfaces produce two queues. The room queue is legible to the chair’s peripheral vision; the remote queue requires a deliberate tab switch. Under time pressure — a 4-minute Q&A slot after a 16-minute talk, as in the IEEE CSR 2023 hybrid instructions — the deliberate action loses to the ambient one. The IEEE instructions themselves tell chairs to ask questions “in the order they were submitted,” which is a defensible rule only if both submission streams are in the same ordered list. (IEEE CSR 2023 hybrid instructions)
A single queue with source tags does not force fairness. It makes the tradeoff visible and auditable. The chair can still favor the room; the log records that choice, and the next session can correct it.
The protocol
Five rules, each reversible, each testable in a rehearsal.
1. One submission pool, two source tags
Every question enters one list. Each entry carries a source tag: room or remote. If the platform supports source tagging, use it; if not, the moderator adds the tag manually in the log. Do not run two lists and merge them at the end — the merge is where the room wins.
2. Explicit queue states
Borrow the BFCP vocabulary: pending, accepted, granted, answered, declined. The chair moves items between states; the audience sees the queue, not just the answered question. A visible queue is the cheapest accountability mechanism available and requires no new software beyond a shared screen or side monitor.
3. A stated alternation rule
Default: alternate room and remote, starting with whichever source has the older unanswered question. State the rule to the audience in the session intro — one sentence. An unstated rule is indistinguishable from bias when the log is reviewed afterward.
4. A logged override
Overrides are allowed and expected: a follow-up, a question that directly challenges the speaker’s claim, a time-critical clarification. Every override gets a one-line reason in the log. The reason field is what turns a non-reproducible moderation decision into a reviewable record.
5. A last-question rule that is enforced or labeled
If the chair says “last question,” the next granted item is the last. If time may allow more, say “one more if time permits” instead. The MAFP draft’s point stands: an unenforced last-question promise is a small credibility leak that compounds across a day.
Worked example (hypothetical, for sizing only)
A 45-minute panel with a 10-minute Q&A window. Suppose 12 room questions and 30 remote questions arrive. Strict first-come selection would produce a room-heavy session because room questions cluster in the first minutes of the talk, when the room is attentive and the remote tab is not yet open. Alternation with a logged override produces a mixed session and a record of every deviation. The counts here are illustrative; the point is that the rule must be chosen before the counts are known, or the counts will choose the rule.
Failure modes to watch in the log
- Proximity reordering. A room question asked at the mic jumps the queue because it is already being spoken. Log it as an override with reason
live-at-mic. - Latency starvation. Remote questions submitted during the talk arrive after the chair has already scanned the queue. Fix: refresh the queue at a fixed interval — every 90 seconds is a reasonable starting point — and log the refresh times.
- Duplicate suppression. The same question from both sources should merge into one entry with both tags, not compete for slots.
- Sponsor-adjacent questions. If a sponsor session feeds questions into the same queue, tag them
sponsorand disclose the tag to the audience. Attendee trust is cheaper to keep than to rebuild.
Copyable artifact: session selection log
For the session chair or moderator. One row per decision. Paste into a spreadsheet or a shared doc; export to CSV at session end.
HYBRID Q&A SELECTION LOG
Session: ____________________ Date: __________ Chair: ____________________
Rule stated to audience (Y/N): ____ Rule text: ______________________________
| time (local) | source (room/remote/sponsor) | q-id | state | decision | reason |
|--------------|------------------------------|------|----------|----------|--------|
| 10:42 | remote | R-014| granted | answer | |
| 10:44 | room | L-003| granted | answer | |
| 10:46 | room | L-007| granted | answer | live-at-mic |
| 10:48 | remote | R-021| declined | defer | time |
| 10:49 | remote | R-022| granted | answer | last question |
End-of-session counts:
room granted: ____ remote granted: ____ sponsor granted: ____
overrides: ____ override reasons: ______________________________
last-question promise enforced (Y/N): ____
Columns are deliberately minimal. q-id is whatever the platform assigns; if it assigns none, number entries as they arrive. reason is required only for overrides and declines.
Reversible rollout
- Rehearse once. Run the protocol in the tech check with two colleagues submitting from a phone on venue Wi-Fi and one from home. Confirm the queue refreshes and the log is writable by the chair, not just the AV operator.
- Run one session. Use the log. Do not change the alternation rule mid-session; log overrides instead.
- Compare. At session end, compare the room/remote granted counts against the previous session’s mix. If the mix moved toward the stated rule, keep it. If not, the rule or the refresh interval is the variable to change — not the chair.
- Revert if needed. The protocol adds no software dependency. Dropping it means returning to the prior selection method; the log remains as a record either way.
Where this connects to the rest of the event
The queue is one handoff in a longer chain. The room-to-chat handoff — where a question asked at the mic has to become a written record, or a written question has to become a spoken one — is where most hybrid events lose coherence. That handoff is covered in Why Hybrid Events Fall Apart at the Room-to-Chat Handoff, and the selection log above is the artifact that makes the handoff auditable.
FAQ
Does this require a specific Q&A platform?
No. Source tagging and a visible queue are available in some platforms, but the log works with a spreadsheet and a shared screen. The protocol is a set of rules and a record, not a product.
What if the chair cannot see the remote queue during the talk?
That is the failure the protocol is designed to catch. Put the queue on a second monitor or a tablet at the chair’s position, and refresh at a fixed interval. If the chair cannot see it, the protocol is not running.
Is alternation always the right rule?
No. Alternation is a default that corrects for the room’s ambient advantage. Sessions with a deliberately room-heavy format — a workshop, a town hall — should state a different rule and log it. The requirement is that the rule is stated before the session and recorded in the log.
How does this interact with sponsor questions?
Tag them separately and disclose the tag. A sponsor question that enters the same queue without a tag is indistinguishable from an attendee question, and that ambiguity is the thing attendees notice.