What Program Committees Actually Do (and Where I Try to Help Them)

Every NOG event has a program, and every program comes from a program committee: a handful of volunteers who spend weeks in a shared inbox arguing about which submitted talks deserve a slot. Nobody signs up for a PC because it sounds fun. You do it because someone asked, and because you care whether next year's agenda is worth anyone's flight.

I want to describe what that work actually involves, partly because people outside these committees assume it's more automated than it is, and partly to be honest about where the tool I built fits into it and where it plainly doesn't.

A call for papers goes out. Submissions trickle in as abstracts, sometimes with a slide draft attached, sometimes just a title and a hopeful paragraph. The PC reads all of them, start to finish, because a badly written abstract can hide a strong talk and a polished one can hide nothing underneath it. You're trying to guess, from a few hundred words, whether this person can hold a room of operators for their allotted slot and say something they'll actually use afterward. That's an odd kind of judgment to expect from volunteers with day jobs and zero formal training in evaluating conference talks, and the whole program rests on it anyway.

Then there's fit. A submission can be well written and still wrong for a specific event, too introductory for a room of veterans, or a near-repeat of something covered a year earlier at a sister event. A PC is supposed to catch that. In practice nobody carries the last few years of every regional NOG's agenda around in their head. You remember the sessions you personally sat through and maybe skim a past program if it occurs to you. Coverage gaps slip through this way, mostly because remembering what an entire community has already covered is a hard bookkeeping problem that nobody is paid to solve.

And then the part that never makes it into a PC's job description: chasing people. The strongest potential speakers rarely submit on their own. Someone on the committee has to email an engineer who gave a sharp answer on a mailing list months ago and talk them into turning that answer into a talk. That's cold outreach, unpaid, squeezed in between reviewing a stack of other people's abstracts.

Where I try to help

NOGnet's PC-support module exists for the first two problems. I haven't found a way to automate persuading a stranger to get on stage, and I'm suspicious of anyone who claims they have. It ranks incoming submissions using signal that's tedious to reconstruct by hand, things like whether an abstract is specific about content or just vague about ambition, so the committee can spend its limited attention on the borderline cases instead of relitigating the obvious yeses. And it checks topic coverage against other events' past programs, so if a subject already got a thorough treatment elsewhere recently and nobody on the PC happened to notice, that gets flagged before the agenda goes out looking repetitive.

What it doesn't do, and I've given up trying to make it do, is judge whether a talk will be good. It can tell you an abstract reads thin or that a topic looks oversaturated. It can't tell you that the nervous writer behind a rough submission is a magnetic speaker in person, or that the boring-sounding title belongs to the one person in the room who ran the incident everyone else is speculating about. That read comes from having sat through enough of these talks yourself to develop a feel for it, and I don't think a feature roadmap gets you there.

So the module saves the committee time on the parts of the job that are genuinely mechanical, and leaves the hard part exactly where it always was: a handful of unpaid people making a call on a stranger's abstract, hoping they got it right.