Selection Committee Guidelines

This document contains guidelines for PostgreSQL Europe Conference CfP/Talk Selection Committees.

Responsibilities of the Talk Selection Committee

The CfP/talk selection committee (hereafter refered to as "The Committee") is responsible for curating a balanced, interesting and informative program of talks that will be appreciated by the conference's target audience.

A balanced program will comprise of:

  • Talks on a range of topics.
  • Talks suitable for different experience/expertise levels.
  • Talks suitable for various types of PostgreSQL user.
    For example: DBA, application developer, sysadmin, Postgres hacker, project manager, student.
  • Talks from both new and established speakers (where possible).
  • A diverse group of speakers that represents as many people as possible in the PostgreSQL community.
    For example: people of different genders and ethnic origins, people with disabilities, people from other under-represented groups.
  • No more than one or two talks per speaker.
  • Not too many talks from any single organisation.

Forming the talk selection committee

The conference organisers will appoint a chairperson for the committee. This person (hereafter referred to as "The Chair") will be responsible for the day to day running of the committee, and for the administrative tasks relating to talk selection and creation of the program. The Chair may or may not have a full voting role on the committee.

The Chair and/or the conference organisers will select the remaining members of the talk selection committee.

In order to get a balanced review of the submissions and in order to get a range of views, it is important to select a committee with a variety of backgrounds, interests, roles, experience levels etc.

It can be useful to launch an informal "call for participants" for the talk selection committee.

The committee must follow the rules set out in the Guidelines for Community Conference Recognition which states in particular that the talk selection committee MUST NOT consist of 50% or more members from a single company or group of companies under the same ultimate ownership or management.

Communications

The committee can choose whichever method of communication works best for them.

A method that has been found to work well is a group chat in Telegram or a similar service for day-to-day discussions, combined with voice or video calls during the selection phase. This is just a suggestion; you may choose any method that suits the group.

Roadmap

The Chair should ensure that the committee is aware of the important milestones and deadlines. In particular:

  1. CfP opening date.
  2. CfP closing date/deadline.
  3. Voting deadline.
  4. Talk/program selection calls/meetings.
  5. Date by which speakers will be informed.
  6. Schedule publication date.

During the Call for Papers

It is essential to ensure that there are sufficient submissions, including sufficient diversity of talks and speakers, to be able to select a balanced program.

The CfP must therefore be published widely, especially within groups of people who feel under-represented in the PostgreSQL community. Experience has shown that it will be necessary to do considerable outreach work, encouraging people who are hesitant, but who are interested and who have something to offer the event, to submit talks.

This is the responsibility of the entire organisation team, but The Chair has an important role to play. This work must start before the CfP closes.

Voting

The Chair must ensure that all members of the committee have access to the talk voting system, and must share the link to the system with the committee before the end of the voting process.

Voting can start on or before the CfP deadline. Voting will be at https://www.postgresql.eu/events/admin/conference-short-name/talkvote/

Voting guidelines for committee members

  • Plan to spend a few minutes per abstract.
  • Set aside time to review in batches of 5-10 abstracts.
  • Abstain from voting on your own submissions, submissions from colleagues, or any other submission where you feel you can not offer an unbiased opinion (use the "abstain" option in the drop down list).
  • Select a rating for each talk from 1 (lowest - "this has absolutely no place on the program") to 9 (highest - "this is a must-have talk for this conference!").
  • Use the whole range of values 1 to 9.
  • Request feedback from previous years' committees to find out what does or does not work well for this conference.
  • Commercial talks are more appropriate for the sponsor track and should generally not be rated highly.
  • Talks that are likely to be of interest to a very small audience should generally not be rated highly.
  • Include a short comment (even just a couple of words can he helpful) for each submission explaining why you voted a particular way. This is useful during the selection phase, for example if two talks have the same rating. It also helps to provide feedback if requested by a speaker whose talk is not selected.
  • Where there are multiple talks on a topic, or multiple talks from a speaker, vote on each of the submissions individually. De-duplication will take place during the selection phase.

Selecting Talks

Once the individual voting has taken place, the committee will decide collectively, usually during a (virtual) meeting, which talks to select or reject.

Committee members must be made aware of information such as:

  • The total number of talks required.
  • The different tracks.
  • The number of rooms available.
  • The capacity of each room.
  • The slots available each day.

To assist the selection process, the submissions will usually be sorted by average rating and talks will (generally) be selected from amongst the highest rated submissions.

Note that the ratings are to be used as a guide only - the committee should choose the talks they think will give the best overall program for the event.

The process can take place in different ways, but a common way is to select a cut-off point and create a shortlist of submissions that scored over this cut-off point.

The shortlisted talks will be discussed by the committee, who will decide which to accept/reject/accept as a reserve talk.

Be sure to keep in mind the desire for a balanced program (as discussed above) when selecting talks:

  • Prefer no more than one talk per speaker (potentially two for a multi-day, multi-track event).
  • Avoid multiple talks that are very similar.
  • Ensure there are talks on a range of topics.
  • Select talks aimed at a variety of different types of PostgreSQL user.
  • Ensure that there are talks suitable for different experience/expertise levels.
  • Check that there is a mix of new and established speakers.
  • Ensure that there is a good gender balance within the selected speakers
  • Ensure that different groups within the PostgreSQL community are represented by the selected speakers.
  • Limit the number of talks per organisation.

Talks that are definitely wanted may be accepted at this point without waiting for the deadline for informing speakers.

Talks that are definitely not wanted can be rejected at this point without waiting for the deadline for informing speakers.

The sooner acceptance emails are sent to selected speakers, the better.

If a selected speaker is no longer able to present their talk, the committee must choose and accept another talk to take its place.

Reserve talks

A number of talks should be selected to go on a reserve list.

A reserve talk may or may not be moved onto the schedule to replace a talk that a confirmed speaker is no longer able to present. This could happen at any time between the schedule being published and the day(s) of the conference itself.

It is important to choose sufficient reserve talks to allow you to keep the balanced nature of the schedule that you have created. This means selecting reserve talks from a variety of speakers and on a range of topics.

You want to keep the number of talks per speaker to 1 or 2 as far as possible, even when speakers have to withdraw. This means that you want to have some speakers on the reserve list who do not already have confirmed talks on the schedule.

Unfortunately, however, reserve speakers can not always get travel authorisation unless their talk is actually on the schedule. This means that it is important to know whether or not a reserve speaker plans to actually be at the conference and whether or not their talk will be prepared and ready to go at the last minute.

To allow for last-minute replacements (just before and/or during the actual conference), it is useful to include some talks from confirmed speakers who you know will definitely be at the event, even though this may mean that a speaker ends up giving more than 1 or 2 talks. It is still important to confirm whether or not their reserve talk will be prepared and ready to present at the last minute.

Compiling the Program

Once the talks have been selected and the speakers have confirmed that they can present their talks, the schedule itself can be created.

Use the scheduling tool in the system to create a schedule.

This involves:

  • which room each talk should go in (if multi-track).
  • Checking that talks have been assigned the correct track.
  • Deciding on the order of the talks.

Consider things such as:

  • Do not schedule two talks on the same topic at the same time.
  • Think about scheduling "lighter" talks just after the lunch break.

Final checklist

  • Is each selected talk confirmed by the speaker?
  • Does every selected and confirmed talk have a track?
  • Does every selected and confirmed talk have a room?
  • Does every selected and confirmed talk have a date/time?
  • Is each reserve list talk confirmed by the speaker?
  • Is the schedule created, saved and published?

Suggested Talk Selection Committee Checklist

Note that this is not exhaustive, and is just presented as an idea of the type of information that should be readily available to the committee for a given event.

  • Milestones/Deadlines
    • Date CfP Opens
    • Date CfP Closes
    • Deadline for Voting
    • Talk Selection Call/Meeting(s)
    • Speaker Notification Deadline
    • Schedule Publication Date
  • Tracks (examples)
    • DBA
    • Application Developer
    • Postgres Internals
    • Community
  • Rooms: Name and Capacity
  • Schedule Slots/Times