Skip to content

CfP with Pretalx¤

Warning

This document is a work in progress. Please check back later for updates.


This is our set-up for the Call for Proposals (CfP) using Pretalx with best practices to help you get the most out of your CfP.

Our guidelines are based upon our experience made with a team of:

  • 2-3 program chairs
  • 10 committee members
  • 30-50 reviewers

Creating the Event¤

A super-admin creates the event.

The super-admin is an account with our roof organization, the Python Softwareverband e.V.
They can see all events and all data. They can also create new events and assign other admins to them.

Best Practice

We copy the event from the previous year and adapt to our learning and needs.

The team handles it directly

We do not want the super admin to manage other CfP related tasks to avoid bottlenecks. The committee handles everything else directly: The super-admin added the admins who are part of the committee. They get the rest of the team on board: committee members and reviewers.

Inviting the Team¤

Due to our team size, we assign different roles to your team members:

The super-admin invites the initial admins to the event.

Group readability

We run a yearly event and use the year as prefix for all groups for readability, e.g., '2025-Admins' or '2025-Reviewers'

Go to Organiser/Event/Teams/

Admins¤

The committee chairs are the admins, as they know best about the team and the process.

Set-up by super-admin.

  • Restrict the permissions to the respective event (select the event in the drop-down list).

  • Can change teams and permissions

  • Can change organiser settings
  • Can change event settings

Not checked:

  • Can create events
  • Is a reviewer (this is an implicit role anyway)

Program Committee¤

These are the people who will review and decide on the submissions. Committee members also work with invited talks like keynotes and add or edit content in the system.

Set-up by admins.

Check the permissions are restricted to the respective event already.

  • Can change event settings
  • Can work with and change proposals
  • Is a reviewer

Not checked:

  • Can create events
  • Can change teams and permissions
  • Can change organiser settings

Review settings - not checked:

  • Always hide speaker names

Hiding speaker names / blind review

It is good practice for the program committee members to see the names of the submitters, but not the reviewers.
Remember: the proposals are just a text, other references will help determine if the submitter is qualified (and not just good at prompting chatbots).
Culture beats restrictions: Openly communicate conflicts (‘submitter is a close friend’) of interest to the team and refrain from reviewing these submissions.

Reviewers¤

These are the people who will review the submissions. They can see the submissions, review them, and leave comments.

Check the permissions are restricted to the respective event already.

Set-up by admins.

The only items checked are:

  • Is a reviewer

Review settings:

  • Always hide speaker names

Data Protection¤

For data protection, it's a best practice to only add the people to the current event and remove them after the event is over.

Content¤

We provide concise instructions about the CfP with information what the event is looking for.

We make sure the information is consistent with the Call for Proposals (CfP) published e.g., on the website.

CfP description

It's not easy to navigate conciseness and a lot of information. We consider linking outside sources.

Editor¤

We always give concise instructions what should be added in each field.

We point to where the information is used or not :("will be displayed on the website" or "will never be published")

We set the field lengths in Content, tab "Fields".

Field lengths

We made a plan where we want to use information collected in the CfP.
It's easier to re-use information than to ask for or edit it later.
For example, it's handy to have a short description that works well for social media.

Proposal Title¤

We use a limit to 100 characters for readability in other context (e.g., the schedule).
Platforms as YouTube have a 100-character limit for titles, and it'd be hard to shorten titles later.

Session Type¤

See below.

Proposal Abstract¤

  • The abstract should give a concise overview of the talk.
  • Ranges from 200 to 1,500 characters are work well.
  • Point to not include speaker names or affiliations.

Proposal Description¤

  • Ranges from 400 to 5,000 characters are work well, consider tutorials might need more space.
  • Point to put detailed outline here
  • Point to it will be published on the website
  • Point to not include speaker names or affiliations.

Notes¤

  • Point to it will be published on the website and is only visible to the program committee not including the reviewers.

Recording opt-out¤

Make sure to have a policy in place if you want to allow recording opt-out.

Session Image¤

If your website does not create event branded images this might be useful.

Duration¤

Allowing custom durations adds a lot of complexity to the schedule, better to have fixed durations handle via the session types.

Custom Questions¤

Custom questions help to bring more context to the proposal. They are also helpful to filter and sort the proposals.

Always include who will see the information and if it will be published.

Custom Questions

Consider which information you actaully need, answering many questions can be exhausting for the submitter.
On the other hand, it's hard to collect required information later.

Not all information is required now

No need to collect all information now, consider which information is not required for the review process and will be collected later anyway.
For example, dietary restrictions of a speaker are not required for the review process and is usually collected via the tickets.

We add the following questions to the proposals (1).

  1. There are also custom questions to be added for the speaker profile.

Expected audience expertise: Domain¤

The domain expertise your audience should have to follow along.

  • Novice
  • Intermediate
  • Advanced

Visible to: world

Expected audience expertise: Python¤

How experienced should the audience be in Python programming?

  • Novice
  • Intermediate
  • Advanced

Visible to: world

Prerequisites¤

Things the attendees should know before visiting for the talk

We want to promote speakers spend the talk time on the content and not start on the basics.

Visible to: world


Abstract as a tweet (X) or toot (Mastodon)¤

Short description of your abstract one could tweet

Text to promote the session on social media. Maybe LLMs can do this for us in the future.

Visible to: world


Notes for reviewers only¤

Anything you like to share with the reviewers only - will not be published. Do not include any personal information.

Text

Visible to: committee members and reviewers only

Optional, material to support the proposal.

Visible to: committee members and reviewers only

Optional, material to support the proposal.

Visible to: committee members and reviewers only


Fresh content¤

  • [Y/N] Was this proposal presented already and recorded?

We try to avoid repeating content that is already available. This is not a strict policy, depending on the topic the on-site discussion might be valuable.

Visible to: committee members and reviewers only

Would you give this talk at a local meetup?¤

Perfect your presentation by giving it at a local meetup and support local communities.

The conference gives us a lot of exposure. We want to use this to support local communities that often lack speakers. (1)

  1. Location is required for matching a question in the speaker profile.

Visible to: committee members and reviewers only


Honor-code original work¤

  • I hereby declare that this proposal is my own original work

Confirmation of being original content

Quality assurance: presenting other people's blog posts or work is not considered original content.

Visible to: committee members and reviewers only

No-Remote¤

  • I will present my talk on site

Accepted speakers are required to present on site.

Double-confirmation to manage expectations.

Visible to: committee members and reviewers only

Code of Conduct¤

  • I have read and agree to the Code of Conduct

This is a must to attend the conference. Must be accepted.

Visible to: committee members and reviewers only


Speakers¤

Speakers need to answer questions only once.

Speaker questions are simple questions.

Private Questions¤

All text answers except where noted, visible to: committee members and reviewers only

  • How should we address you? (pronouns)
  • Company / Institution
  • Job title
  • Country of residence
  • City of residence
  • Do you identify as a member of an underrepresented group?
  • Are you a first-time speaker?
  • Community contributions (organizer, open-source, etc.)
  • Age, ranges:
    • 18-25
    • 26-35
    • 36-45
    • 46-55
    • 56-65
    • 66 and older

Public Questions¤

All text answers, visible to: world

  • Name
  • Biography
  • Homepage
  • LinkedIn
  • X
  • GitHub
  • BlueSky
  • Threads
  • Mastodon

Session Types¤

We use the following descriptive session types:

duration
talk 30 minutes
talk (long) 45 minutes
tutorial 90 minutes

Some sessions are invited or organized not via the CfP.

Private types are:

duration
keynote 45 minutes
sponsored talk 30 minutes
sponsored talk (long) 45 minutes
sponsored tutorial 90 minutes
panel 60 minutes

Sponsored talks are a great way to support the conference and get your message as a sponsor out.

The Program Committee will work actively with the sponsors to ensure the content is valuable to the attendees.

Sponsored content is moderate and accounts for about 10% of the overall program.