Brussels / 3 & 4 February 2024


Devroom Managers Manual

Please help keeping this manual up to date, sources are on github!

Key dates

Devroom expectations


FOSDEM uses the devroom-manager mailing list for communications with the people who are organising devrooms. Please make sure you read this list and keep the messages for reference.

The FOSDEM Devrooms team can be contacted using Please try to remember to send individual requests to that address and keep this devroom-manager mailing list for messages and discussion that may be of interest to other devrooms.

Secondly, we create mail aliases <room> that provide a convenient way for us to contact each other, for example to discuss moving proposed talks between devrooms. Note that these alias expansions also include Again, please make sure you read those messages. A list of mail aliases can be found in pretalx (this list is only accessible to devroom managers), so you can contact other devrooms, eg for moving talks to another room.

Thirdly, we can create additional mailing lists for devrooms to use either for a wider team of organisers or for visitors and these may be public or private. Contact for this.

Devroom managers

Each devroom needs to send to the list of the of email adresses for any room organisers who need to be granted access. Note that is for full access including scheduling later in the conference.

Devrooms managers list can be tracked on the devroom managers report. We request every devroom to have two people in this list, to make sure there is a backup in case of issues. Devroom managers status grant access to:

People who only review should not be made devroom manager: you can add them to a review team on your devroom dashboard.

Before the event

Call for Participation / call for papers

Devrooms issue a Call for Papers.

If you wish, you can ask for review on the devroom-manager list before publication or on devrooms at

We can also make adjustments to the names of devrooms at this early stage - particularly if related proposals got combined or you want to emphasise some little change of focus.

Full details of all talks and speakers that you schedule must be submitted into our ‘pretalx’ database which is used to generate our website and schedules no later then 15th December. Please try to complete this earlier. It is better to find out scheduling conflicts early, and by the end of December it is hard to reach people. By running late, you also give your presenters less work to prepare their talks.

All submissions must go through pretalx:

Note that this is a new system and accounts from pentabarf were not migrated: Presenters will have to create a new account.

Staff and devroom managers can access the submitted content through the organisers site which sits at:

Adding a devroom description to the website

Optionally you can add a small description of the devroom on top of the page. See the example at

Add a .html file in the website/content/schedule/devrooms/ folder in the git repo for this description. Keep it concise.

Reviewing talks

Review page

In addition to devroom managers, you can invite extra reviewers for your track by using the devroom dashboard. Note invited members have to open the link in the mail they receive in order to get access. As an alternative, you can send them the link next to their invitiation also using any other way.

Note that devroom managers are able to review also proposals in other tracks. This to spot talks which might be better suited for your devroom or to spot people who submit the same talk to different tracks.

Accepting and Rejecting talks

After the review phase a selection of talks must be made from the proposals page. When accepting or rejecting a talk, a mail will be generated in the outbox in the bottom left. Please review these mails quickly: it will be confusing for other devroom managers if mails are stuck there. You can edit the mails if you want to add some personalised content or discard them if you inform speakers another way (this is not recommended). In any case, leave the reply-to address to that of the devroom team, so questions get to the track organisers.

send/edit/discard mails

In the image above the highlighted buttons on the right allow send/edit/discard mails.

You can also mark a decision on accept/reject as pending. In that case the submitter will not see a change in status if they log in.

You can also change the duration of the talk when accepting it. This will make the next step (scheduling) somewhat easier.

Scheduling talks

After a talk has been accepted it can be scheduled. The easiest way to do this is by going to the schedule page. Choose your track on the top left dropdown and your assigned room in the bottom right (check the mailing list archive if in doubt).

schedule editor

You can now drag and drop your talk to the schedule. By default the schedule will show the time in 30 minute granularity, but you can click on the time bar to make this 5 minutes. After a talk was added to the schedule, you can adjust it duration by double clicking it. Take care for any warning in the editor.

After you finish scheduling, click the Check bottom in the top right. If this page mentions any errors concerning your track, please review them and fix them. As long as errors are mentioned, no new schedule will be released. If there are no errors, releases of the schedule will be generated automatically and are picked up by the FOSDEM website/apps/…. Only talks which are confirmed will be shown.

Alternatively, if the scheduling interface does not work for you, you can manually add start and stop times and a room to proposals. Note that there is a larger chance to make error if you use this method.

Scheduling hints

Website schedule

The website is generated from the data in pretalx. This runs automatically every few minutes.

You can see when it was last updated near the bottom of the events page.

Note that the data gets pulled from the database slightly before this timestamp is generated - sometimes a few minutes before. If nothing on this page changed, the date won’t be updated. shows the last modified date for every page on the site.

If the system detects an inconsistency in the data, it stops updating the site until this is corrected in the database.