Skip to content

CfP with Pretalx¤

Warning

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

These guidelines will help you set up the Call for Proposals (CfP) using Pretalx with best practices to help you get the most out of your CfP.

The guidelines are based upon experice made with a team of:

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

Creating the Event¤

A super-admin creates the event.

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

Best Practice

Copy the event from the previous year.

Have the team handle it directly

Do not have the super admin manage other CfP related tasks to avoid bottlenecks. Let the team handle it directly: add the Admins first and have them invite the Program Committee and Reviewers.

Inviting the Team¤

Depending on your team size, you want to consider assigning different roles to your team members:

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

Recurring or multiple events

If you run a yearly event, use the year as prefix for all groups for readability, e.g., '2025-Admins' or '2025-Reviewers' If you run multiple events, add a consistent prefix to group representing the event.

Go to Organiser/Event/Teams/

Admins¤

These are the people who have full access to the cFP of the event.

  • 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

Do not check:

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

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

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.

Check the permissions are restricted to the respective event already.

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

Do not check:

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

Review settings - do not check:

  • 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.

The only items to check 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¤

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

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. Consider linking outside sources.

Editor¤

Always give concise instructions what should be added in each field.

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

It's strongly advised to set the field lengths. They can be set in Content, tab "Fields".

Field lengths

Make a plan where you 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¤

Consider a limit to 100 characters for readability in other context (e.g., the schedule).
Platforms as YouTube have a 100-character limit for titles.

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.
  • Point to put detailed outlines in the description

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.

Proposals¤

Some common questions to consider for proposals (1).

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

Some examples:

  • Expected audience expertise
  • Expected audience expertise
  • Prerequisites the attendees should know before visiting for the talk
  • Abstract as a tweet (X) or toot (Mastodon)
  • Public link to supporting material, e.g., videos, GitHub, etc.
  • Link to talk slides
  • Confirmation of being original content
  • Have you given this talk before?
  • Would you give this talk at a local meetup?
  • Remote talk? (Y/N)

Speakers¤

Speakers need to answer questions only once.

Some examples:

  • How should we address you? (pronouns)
  • Company / Institution
  • Job title
  • Homepage
  • LinkedIn / X / GitHub / Mastodon / …
  • Country of residence
  • City of residence
  • What is the format of the talk?
  • Do you identify as a member of an underrepresented group?
  • Are you a first-time speaker?
  • Are you an organizer of the local community?
  • Age (ranges)

Session Types¤

Add descriptive session types, for example:

  • 30-minute talk
  • 45-minute talk
  • 60-minute talk
  • 3-hour workshop

Make sure to set the duration for each type.

Some sessions are invited or organized not via the CfP. Hidden types are useful for this, for example:

  • keynote
  • sponsored talk
  • panel