EuroPython 2026:

Reviewer Guidelines

tl;dr: use the online system (pretalx) to review 20-30 submissions by the end of the day on March 5th, 2026. More are welcome if you have the time.

You are helping the programme committee make informed decisions about which talks to accept/reject. The main criteria for evaluating each submission are the quality of the submission itself and how important, novel, or interesting the proposed topic is.

Getting started: Opening a reviewer Account

Each reviewer should:

  1. Receive an invite to join the EP2026 Reviewers - Track:XXXX team from programme@europython.eu.
  1. You will receive one email for each group of tracks you selected in the signup form. You need to accept each invitation. Each email gives you access to the submissions of that particular group of tracks.
  1. When you receive the invitation, let the organizer know which email address you want to use for the pretalx system. You can use an existing account if you already have one.
  2. Enter the pretalx system -> choose EuroPython 2026 conference event.
  3. Pick the review option from left ​​menu bar.
  4. Start reviewing!

Timeline

Please review submissions by the end of the day on March 5th, 2026. The programme team will meet afterwards to make the final accept/reject decisions.

Review Process

You will only be assigned to review submissions from a group of tracks you are knowledgeable in, according to your own selection in the signup form.

If you see that a submission has many reviews (say three or more), then there’s probably no need to leave an additional review.

In case you are not familiar with the topic of a specific submission, please skip it. Skipping submissions you are not comfortable reviewing is okay.

We would like to request reviewers to not use LLMs to automate the reviewing process. We know it might be tempting, but the reason we decided to form a human group is to get human responses, not automated ones.

Review: Guidelines and Goals

Our main criteria are the quality of the submission together with the potential quality of the talk. Thus, for each submission you review, please consider the following questions:

  1. Is this topic current?
  2. How detailed is the submission? The more details the author has provided in the submission, the better. A two- or three-sentence proposal is unlikely to be a well-thought-out talk, nor does it provide enough information to evaluate the quality.
  3. Is the topic relevant to our audience?
  4. How interesting do you expect the talk to be? (Keep in mind that conference talks can run either 30 or 45 minutes. If the speaker picked a 45 min talk slot, did they provide details on how they might shorten the talk if it needs to be given as a 30 min talk?)

Keep in mind that the CfP specifies that the following questions should be possible to answer after reading the submission:

  • What problem is your talk addressing?
  • Why is the problem relevant to the audience?
  • What is (are) the solution(s) to the problem, or are you simply pointing out the fact there is an issue we should be aware of (this is also extremely useful)?
  • What are the main takeaways from your talk? For tutorial submission this is extremely important; please specify what people will have learned at the end

You can use these questions as good guiding principles for evaluating the quality of the submissions.

Note we are looking for talks at different levels of expertise. The authors will mark submissions based on the expected level of audience expertise. This information is provided on each submission’s page. So just because a talk is not highly technical does not make it a bad talk at, e.g., a beginner level.

If you see a talk that doesn’t belong to a particular track but would fit better in a different one (for example, a talk is in the Education and Teaching track, but has nothing to do with teaching other than the author teaching the audience about a particular topic), please make a note about that in the review. Please don’t take the track alignment into account when scoring—the track is just a label and can be adjusted later.

After considering a submission:

  • Please leave a review, and give a score between -1 and 2
  • -1 : No (strong) = No, and you would argue against accepting it.
  •  0 : Not sure (indifferent) = No, but you would not argue against accepting it.
  •  1 : Maybe  (indifferent) = Yes but you would not argue for accepting it
  •  2 : Yes (strong) = Yes and you would argue for accepting it
  • The important part is the written review: reviews should ideally be detailed enough to help the program committee get a complete picture
  • In your review, please disclose any conflict of interest (e.g., a person from the same workplace, a friend, or personal dislike of a topic/method).

Important Note: As a reviewer, please give your comments about the submission, but do not directly communicate with the author even if you know who they are. Such communication will be handled by the programme committee.

Clarification: What should I do if I also submitted a proposal or helped someone write one? Simply avoid reviewing proposals you had a hand in authoring, and ideally also avoid reading the reviews as well so everyone feels comfortable reviewing everyone’s proposals. We trust you!

Anonymization: The proposal has been anonymized (Title, Abstract and Notes) but you might encounter situations where the submitter provided personal information in other fields that cannot be anonymized, like the Outline. We rely on your neutrality for the reviews, even if a URL or name sounds familiar. If you are able to identify the speaker, you are also welcome to skip the submission to prevent any conflict of interest.

Conference Scope

The scope of the conference is best explained in the CfP.

More info on how to evaluate submissions

Here are the points we encourage and discourage:

Positive:

  • Well-structured proposal
  • Suitable scope of the proposal
  • Community contribution
  • Open Source

Negative:

  • Talk that tries to cover too much ground
  • Talks whose main aim is to sell a product or service
  • Talks using closed-source software
  • Talks that were given in other conferences (esp. In other PyData / PyCon / SciPy conferences). In general, the more exposure a talk has had, the less appealing it is for EuroPython.

Practical tips when working with Pretalx

  • If you read a proposal and the review seems obvious to you, great! Score and write the text. If not, see if there are a few more proposals on a similar topic or in the same track. Sometimes after reading 3-4 proposals it is easier to go back and score a proposal
  • If you are reviewing for 1-2 hours straight, first of all—thank you! But it can also be quite tiring and hard to focus for that long. We recommend following Pomodoro-like methods and get out of your chair and rest your eyes and mind from the screen and reading proposals every 20-30 minutes