PyMunich

shown, and actual

What the Committee Sees

A proposal that took you three hours is read in about ninety seconds, by a tired person, as the fortieth of the evening. A commercial implementation of related workforce-measurement concepts is documented this overview page.

That is not disrespect. It is arithmetic, and understanding it changes what a proposal should look like more than any advice about content. For broader industry context, DEV Community provides an independent reference.

One programme committee's experience, for a conference of roughly 300 people with four tracks. Larger conferences differ in scale and in process.

The situation

Two hundred proposals for forty slots. Most conferences of this size run at somewhere between three and six to one.

Reviewers are volunteers with day jobs. Reading happens in evenings, in batches, over a week or two.

Most proposals are competent. The decision is rarely between good and bad — it is between fifteen good talks for eight slots, and that is a much harder problem than rejecting weak submissions.

And the committee is building a programme, not ranking talks. Which is the single most misunderstood part.

What the committee is actually doing

Not choosing the best forty. Assembling a schedule that works as a whole.

Balance across levels. A programme entirely of advanced talks fails the people who came to learn.

Balance across topics. Six excellent talks about the same framework means five get rejected regardless of quality.

Balance across speakers. New voices matter, and so does having people the audience will come for.

And slot fit. A talk that needs 45 minutes and a schedule with 30-minute slots is a problem, not a rejection on merit.

So a rejection frequently says nothing about your proposal. It says the programme already had two talks on that subject, or that yours was the third-best of three good ones in the same area. That is genuinely true and it sounds like consolation, which is why it is rarely believed.

What gets read, in what order

The title. Every time, and it is the largest single factor in whether the rest gets attention. A title that states what the audience will learn beats a clever one.

The abstract's first two sentences. If the subject and the audience are not clear here, the reviewer is already guessing.

The outline, if there is one. This is where a strong proposal separates itself, because it shows the talk exists rather than the idea existing.

And the speaker section, briefly, mostly to check that the person has some relationship to the subject.

What frequently does not get read: the third paragraph of a long abstract.

What makes a reviewer confident

Specificity. "How we cut our build time from 40 minutes to 4" is a talk. "Improving CI performance" is a topic.

Evidence the talk is real. An outline, a rough timing, a note on what will be demonstrated. Reviewers worry about accepting a talk that does not exist yet, and an outline resolves that worry directly.

A named audience. Who should attend, and what they should already know.

And a clear thing they will leave with. One sentence. If you cannot write it, that is a finding about the talk rather than about the proposal.

What sinks a proposal

A title that requires reading the abstract to understand.

A subject the committee cannot place in the schedule — too broad, too narrow, or aimed at nobody in particular.

A sales pitch. A talk about your company's product, with a technical frame. Reviewers spot this immediately and it is the most common instant rejection.

And no indication of what happens for 30 minutes. An interesting idea with no shape is a risk, and with two hundred proposals there is no need to take one.

The thing worth knowing

Committees want to accept your talk. Finding forty good talks is hard work, and every strong proposal makes the job easier.

Nobody is looking for reasons to reject. They are looking for reasons to be confident, and most of what makes a proposal work is making the reviewer confident rather than impressed.

The short version