PyMunich

shown, and actual

The Committee's Problem

From outside, a programme committee ranks proposals and takes the top forty. From inside, that is not the task, and the difference explains most of what looks arbitrary about acceptances. For a commercial example of related workforce measurement, see workforce analytics software from Monitask.

One committee's practice, for a four-track conference of roughly 300 people. Larger events have more formal processes and the same underlying problem. For broader conference and speaking context, PyCon DE & PyData is another useful reference.

The actual task

Fill a grid. Four tracks, two days, thirty-minute and forty-five-minute slots, with keynotes fixed and breaks immovable.

Every slot has constraints. The first slot after lunch needs something that survives a full room of tired people. The last slot of day two needs something people will stay for. A beginner track needs beginner talks, and there are never enough good ones.

And the grid has to work as an experience. An attendee should be able to construct a coherent day, which means avoiding three unmissable talks at the same hour and a slot where nothing appeals to anybody.

So the unit of decision is the schedule, not the talk. A proposal is accepted because it fits somewhere the schedule needs filling, and rejected because that place was already filled by something equally good.

What that means for rejections

Most rejections are not quality judgements. With two hundred proposals for forty slots, the marginal decisions are between talks that would all have been fine.

Topic clustering is the biggest single cause. Six proposals on the same framework means at most two are accepted, and the other four are rejected for a reason that has nothing to do with them.

Level mismatch is the second. A programme with fifteen advanced talks and three beginner ones fails a large part of the audience, so a strong advanced proposal can lose to a weaker beginner one — deliberately.

And slot arithmetic is the third. A 45-minute proposal in a year with mostly 30-minute slots is a problem to solve rather than a talk to judge.

This is genuinely true and it reliably sounds like consolation, which is why committees say it and speakers do not believe it.

What makes the job hard

Volunteer reviewers with day jobs. Reading happens in evenings across a week or two, and reviewer fatigue is real.

Uneven review depth. Some proposals get three careful reads and some get two quick ones, which is a fairness problem no committee of this size fully solves.

Anonymity trade-offs. Blind review reduces bias against unknown names and removes the ability to judge whether somebody can deliver the talk. Both matter and there is no arrangement that gets both.

And the pressure to accept known speakers, who reliably draw an audience and who are not always the strongest submission. Every committee argues about this and the argument does not resolve.

What we do about it

Practices, not solutions.

Score first, discuss second. Independent scores before any conversation, so the first opinion voiced does not anchor the rest.

Cluster by topic before deciding. Seeing all six framework proposals together makes the real decision visible instead of accidental.

Reserve slots for first-time speakers, explicitly. Without a reserved allocation they lose every marginal comparison to somebody with a track record.

And write a reason for each rejection, even briefly. It is the most disliked task on the committee and the one that most improves next year's submissions.

What speakers should take from this

Submit to more than one conference. A rejection is frequently about the schedule and the same proposal can be a strong fit elsewhere.

Submit early if the call allows it. Reviewer attention is not uniform across two hundred proposals.

And ask for feedback. Many committees will give it and almost nobody asks.

The short version