An empty attendance list can mean that nobody came or that nobody entered the attendance. A report that displays zero has chosen one of those explanations; it needs a reason.
That distinction comes up in the reporting work for the Dayton Hash website. The pilot’s test cases distinguish confirmed empty attendance from unknown rosters and withhold averages when the information needed to calculate them is missing. These are development checks using synthetic records; they don’t establish that the public reports have been converted.
A smaller fictional example may make the arithmetic easy to follow. A group runs drop-in workshops and wants the average number of visitors per session actually held. We’re counting visitors, excluding the facilitators. Four sessions were scheduled:
| Session | What happened | Visitor count |
|---|---|---|
| A | Held; attendance complete | 12 |
| B | Held; facilitator confirmed no visitors | 0 |
| C | Held; attendance not entered | Unknown |
| D | Cancelled | Not applicable |
Sessions A and B give us twelve visits across two sessions, for an average of six. That’s the average for the sessions with complete attendance records. We don’t yet know the average for all three held sessions, because we don’t know how many visitors came to C.
Replacing C’s missing count with zero gives an average of four. Treating the cancelled session as another zero brings it down to three. The arithmetic works, but we’ve supplied information we don’t have or changed which sessions we’re measuring. If C actually had eighteen visitors, the average across the three held sessions would be ten.
The confirmed zero belongs in this average: session B happened, and its facilitator confirmed the count. Session C also happened, so it belongs in the denominator, but part of the numerator is still unknown. Session D doesn’t belong in an average of sessions held. It would belong in a cancellation-rate calculation, but that’s a different question.
Leaving a missing count null doesn’t settle the reporting decision. PostgreSQL’s avg function averages its non-null inputs. Given twelve, zero, and null, it returns six. The database has followed its rules; the report still needs to say whose average that is.
“6 visitors per session with complete attendance records; 2 of 3 held sessions recorded” describes the narrower result. “Attendance pending for 1 session” explains why an overall average isn’t available. Either can be useful, depending on what the reader needs. A simple “6 visitors per session” conceals the missing count.
The distinction starts at data entry. We need to store whether the session was held separately from whether its attendance record is complete. An empty visitor list needs an explicit confirmation before it can support a zero. If someone later discovers an omitted visitor or an unfinished roster, the record needs to support that correction, and the report needs to use the corrected facts.
It also matters when there are no held sessions at all. The number of sessions is zero, but there is no per-session average. Reporting “0 visitors per session” would imply a measurement we never made.
A dash in the finished report could mean missing, excluded, or undefined; that’s a lot of responsibility for a punctuation mark! Use labels that explain the state and, where something is unfinished, tell the reader what would resolve it.
Before building the summary, write down what you’re counting, which records belong in the denominator, and what happens when required information is missing. Work through a small example with a confirmed zero, an incomplete record, and a cancelled session. Then fill in the missing count and check that the report changes from “Attendance pending” to the average those records now support.
—jhunterj