Devroom Managers Manual
Key dates:
- 20 September
- deadline for developer room proposals
- 30 September
- accepted developer rooms announced
- 15 October (or earlier)
- developer rooms issue Calls for Participation
- 15 December (or earlier)
- developer rooms publish complete schedules
Devroom expectations
The demand for devrooms far exceeds the supply so we do not want rooms to be planned to be empty during the event. By applying for a devroom you are making a commitment to fill the schedule.
Devroom coordinators must enter a complete schedule into our conference system by 15th December. It is particularly important to be available and to respond promptly to emails about the schedule for about a week either side of this date.
- Saturday devroom schedules should contain between 7.5 and 8.5 hours of content, beginning at 10.30 and running until between 18.00 and 19.00.
- Sunday schedules should contain between 7 and 8 hours of content and start between 09.00 and 10.00 and run through until 17.00.
- No lunch breaks should be scheduled.
If you don't think you can fill a full day, please try to join up with another project and submit a joint devroom application or indicate on this submission form that you are requesting only half-a-day and would like FOSDEM to try to pair you up with another similar request for half-a-day.
Because our room capacity is limited, we will record and stream all devrooms live. The recordings will be published under the same licence as all FOSDEM content (CC-BY). If, exceptionally, there is a reason why any particular speaker or discussion should not be streamed or recorded, you must seek our agreement before including this in your schedule as such permission is unlikely to be granted.
You also agree to find:
- one (or more) volunteers to take responsibility for the devroom at times you are not present, such as when you go for lunch;
- one (or more) volunteers to manage the microphone handover and camera through the day. Full instructions will be supplied.
Devroom allocation (2020)
Saturday | Name | Seats |
---|---|---|
Game Development | K.3.201 | 80 |
RISC-V / Retrocomputing | K.3.401 | 80 |
LLVM | K.4.201 | 80 |
Graphics | K.4.401 | 80 |
Hardware-aided Trusted Computing / Open Source Firmware, BMC and Bootloader | K.4.601 | 80 |
Quantum Computing | H.1301 (Cornil) | 189 |
Free Java | H.1302 (Depage) | 206 |
Software Defined Networking | H.1308 (Rolin) | 148 |
DNS / Web Performance | H.1309 (Van Rijn) | 146 |
Hacker room | H.2111 | 40 |
Open Source Computer Aided Modeling and Design | H.2213 | 100 |
MySQL, MariaDB and Friends | H.2214 | 100 |
Security | UA2.114 (Baudoux) | 207 |
Legal and Policy Issues | UA2.220 (Guillissen) | 292 |
Testing and Automation | UB2.147 | 91 |
Python | UB2.252A (Lameere) | 532 |
Backup and Recovery / Dependency Management | UD2.119 | 50 |
Infra Management | UD2.120 (Chavanne) | 446 |
Containers | UD2.208 (Decroly) | 174 |
Embedded, Mobile and Automotive | UD2.218A | 363 |
Collaborative Information and Content Management Applications / Coding for Language Communities | AW1.120 | 74 |
Erlang, Elixir and Friends / Graph Systems and Algorithms | AW1.121 (not wheelchair accessible) | 82 |
Ada | AW1.125 (not wheelchair accessible) | 76 |
Open Source Science and Research Tools | AW1.126 | 82 |
Open Document Editors | UB4.136 | 96 |
Sunday | Name | Seats |
Distributions | K.3.201 | 80 |
Rust | K.3.401 | 80 |
Debugging Tools | K.4.201 | 80 |
Hardware Enablement | K.4.401 | 80 |
Microkernels and Component-based OS | K.4.601 | 80 |
Kotlin | H.1301 (Cornil) | 189 |
JavaScript | H.1302 (Depage) | 206 |
Software Defined Storage | H.1308 (Rolin) | 148 |
Virtualization and IaaS | H.1309 (Van Rijn) | 146 |
Hacker room | H.2111 | 40 |
Open Source Design | H.2213 | 100 |
PostgreSQL | H.2214 | 100 |
Mozilla | UA2.114 (Baudoux) | 207 |
Decentralized Internet and Privacy | UA2.220 (Guillissen) | 292 |
Open Media | UB2.147 | 91 |
Go | UB2.252A (Lameere) | 532 |
Free Tools and Editors | UD2.119 | 50 |
Monitoring and Observability | UD2.120 (Chavanne) | 446 |
Real Time Communications | UD2.208 (Decroly) | 174 |
Internet of Things | UD2.218A | 363 |
Free Software Radio | AW1.120 | 74 |
BSD | AW1.121 (not wheelchair accessible) | 82 |
Minimalistic Languages | AW1.125 (not wheelchair accessible) | 76 |
Geospatial | AW1.126 | 82 |
Continuous Integration and Continuous Deployment | UB4.136 | 96 |
HPC, Big Data, and Data Science | UB5.132 | 306 |
Community | UB5.230 | 192 |
Before the event
Call for Participation/Call for Papers
Devrooms normally issue a Call for Papers.
- Note the deadline: 15/10
- Send a copy to the FOSDEM mailing list .
- We'll put a link to this on our website news article. Here is the current one: https://archive.fosdem.org/2020/news/2018-10-01-accepted-developer-rooms/
- Browse examples from previous years if you need inspiration. If you wish, you can ask for review before publication on this list or on devrooms at fosdem.org.
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 'pentabarf' database which is used to generate our website 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. The schedule at the 1st of January is used for the booklet.
The half-day rooms should divide the available time by two and allow a gap of about 30 minutes in the middle for switchover.
IMPORTANT - Nothing should be scheduled outside these hours: Saturday 10.30-19.00 Sunday 09.00-17.00 Every year some devroom schedules ignore this and have to get fixed!
To avoid entering everything yourself, ask people to propose talks through https://penta.fosdem.org/submission/FOSDEM20 reminding them that if they already have an account from a previous year they should reuse it. (Our website links speakers to all their talks across all the years of FOSDEM.) Then you can use the system to review and select talks, and transfer them between devrooms if appropriate.
Reviewing talks
Use this to view and review proposals assigned to your devroom track. You can add ratings and remarks in the Rating tab. These will not be accessible to the speaker.
Use these fields for your workflow:
- Event state
- Progress
- Notes
Ultimately, all 'events' in your devroom track either need to be rejected, or accepted and (re)confirmed. Obviously, don't change the state of events in other tracks.
If there are any talks proposed for your devroom which seem attractive for a very large audience, consider asking to program@ if they could be included in main.
Please don't change the tracks assigned to any Main Track / Keynote / Lightning Talks at this stage as we have not reviewed them yet and it's only fair that we consider them under the track that the submitter selected before considering transferring them to a different track.
(And we won't object if any of you help us out by adding your own review comments or scores to events in these tracks as long as you are being reasonably objective and not just giving your friends' talks top scores!)
Scheduling talks
When scheduling tasks in pentabarf: please stick to these rules:
- Saturday devroom schedules should contain between 7.5 and 8.5 hours
of content, beginning at 10.30 and running until between 18.00 and
19.00.
Split devrooms have to make sure there is a break between both sessions.- first session: 10:30 - 14:30
- second session: 15:00 - 19:00
- Sunday schedules should contain between 7 and 8 hours of content and start between 09.00 and 10.00 and run through until 17.00.
- No lunch breaks should be scheduled. (Otherwise we'd make the queueing-for-food problems even worse than they already are.)
- Schedule every talk - titles are used for video.
Scheduling in Pentabarf
To schedule a task in pentabarf you have to:- In the general tab:
- Make sure event state is "accepted"
- Set a unique slug.
Please set the 'Slug' to a unique memorable string (without spaces or non-ASCII characters) based on the title of the event. The URL generated for the event is then: https://fosdem.org/2020/schedule/event/<slug>/
To group things to together nicely, you could put the same devroom prefix on them all, e.g. https://fosdem.org/2020/schedule/event/ada_.../ - Set the progress to "confirmed" or "reconfirmed" if you want it to appear on the website.
- Set Day, start time, duration and room.
- Make sure Public event is checked
- In the persons tab
- Make sure the authors full name is present. There's also some understandable confusion about the name fields.
- The 'Public Name' field should normally be left blank, and then "Firstname Lastname" is generated automatically.
- To show a person's nickname, set the Public Name field to
"Firstname Lastname (Nickname)".
Unfortunately, the form Firstname "Nickname" Lastname is not currently supported by the code. - (Only in rare cases will we hide the speaker's real name - e.g. if their real name and nickname are not yet connected when you search the internet.)
- If a talk is presented by more than one author, you can add an extra speaker here (they must create a pentabarf account).
- Make sure the authors full name is present. There's also some understandable confusion about the name fields.
-
In the description tab:
- Make sure the abstract is not duplicated in the full description - both are concatenated. It is okay to leave the full description.
- Make sure the title is short and stands on its own. Long titles will get truncated in the booklet.
Inform your speakers
- Keep in mind that pentabarf does not send automatical emails. You have to inform your speakers yourself. Note that you can use this utility provided by the Go devroom managers (thanks!) to get an export of all talks of your track with contact details of the speakers.
- Encourage your speakers to upload photographs and to write short biographies. If you add a speaker to the system yourself, make sure you include a contact email address.
Scheduling hints
- For the main tracks we change over on the hour and there we suggest the speakers talk for about 45 minutes, with 5 minutes of questions. That gives us a 10-minute buffer for changeover and means a slightly-late finishing talk shouldn't prevent the next talk from starting on time.
- Related / nearby devrooms should consider synchronising their time-slots to reduce the disruption as people move around.
- If your speakers are travelling long-distance and you're not sure whether or not they're arriving a day or two early, schedule them later in the day in case their journey is delayed. Similarly, consider the home time-zone of speakers when scheduling and allow for jet-lag.
- Keep a couple of talks in reserve in case speakers drop out at the last minute. Choose these from speakers you know will be attending the event anyway and have the details in pentabarf ready so you can swap them in with very little effort if you need to do so.
- If you spot a rejected talk in the system that you are interested in, please be aware that the proposer might not yet know his talk was rejected. Contact the original devroom manager proposer to see if you can move it to your devroom, and only contact the presenter afterwards.
The easiest workflow is to change the track and change the status back from rejected.
If you do this, add a note in the Notes box at the top to say what you did (with username and date). e.g. "Moved from Main Tracks to Lightning Talks - agk, 2016/12/10" -
So some of the lightning talks are in the PB system. How would we
schedule these? It seems crazy to create a bunch of 5-minute slots.
- That's not crazy at all. Please do this. The video information gets generated from this, so it's the simplest way to make sure the videos are tagged correctly. It would help for the booklets that the titles are very short.
Website schedule
The website is generated from the data in pentabarf. 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. https://fosdem.org/2018/sitemap.xml 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.
Troubleshooting
Pentabarf still does not detect if a speaker has been allocated two slots that overlap so do watch out for that!
- "Event with incorrectly named tag"?
- You've perhaps got some invalid characters in the slug? First one I looked at with that message had spaces in it which I removed. Don't put '?' in a slug.
- Event with missing unique tag (slug)
- Make sure you use a valid SLUG
- There is NO replacement.
- Add the prefix CANCELLED to the title.
- Not in brackets - exactly that one word in front followed by one space character.
- That's all. Do NOT change any other state of the event, because we want these events still to appear in the schedule.
- Add a note to the abstract so that it is absolutely clear it has been cancelled. E.g. Top line might be "Please note that this talk has been cancelled as <speaker> is no longer able to attend FOSDEM."
- Notify speakers@fosdem.org ideally giving the URL to the pentabarf event that was changed e.g. https://penta.fosdem.org/event/edit/4147 (We will try to check the steps were followed and fix where necessary)
- There IS a replacement.
- Add the prefix CANCELLED to the title.
- Not in brackets - exactly that one word in front followed by one space character.
- Set 'progress' to 'canceled' (keep it 'accepted').
- For each speaker or moderator on the person tab, set 'role state' to 'canceled'.
- On the schedule tab, set the room to blank (top of the list) and uncheck 'public event'. *Leave the day and time unchanged.* Save those changes. The event will no longer appear in the schedule on the website.
For the replacement, enter the details in the normal way but:- Add the prefix 'AMENDMENT' to the event title.
- At the *end* of the abstract, include some text that describes exactly the talk it replaced, with the full title and speaker matching that of the cancelled event. Whether or not to give an apology or reason will depend on the circumstances. Example: "Please note that this talk replaces one entitled "title" that was due to have been given by <speaker>, who has sent his apologies but is now unable to attend as he has fallen ill. We wish him a speedy recovery."
- Email speakers@fosdem.org with details, for example, the penta URLs for both events.
- Add the prefix 'AMENDMENT' to the event title.
- At the end of the abstract explain the change e.g. "Please note that this is a late addition to the schedule, and the programme will now be starting 30 minutes earlier than originally scheduled."
- Email speakers@fosdem.org with details e.g. the penta URLs for the events.
- Add the prefix 'AMENDMENT' to both event titles.
- At the end of each abstract explain the change e.g. "Please note that this talk was originally scheduled to be given at... The talk originally in this slot, >title hi< by >speaker< will now take place at..."
- Email speakers@fosdem.org with details e.g. the penta URLs for the events.
Last weeks before the event
Once the booklet sent to the printer and the schedule is imported in all apps, all changes to the schedule will be recorded in this page: https://fosdem.org/2020/schedule/amendments/.
For any changes you make from now on, please follow these instructions. (You should NOT do this for any changes you made already - just for future changes.)
Take a look at last year's page to understand better what we're trying to achieve with this: https://archive.fosdem.org/2019/schedule/amendments/
From now on, all changes to the schedule - i.e. topics/speakers - must be tracked and explained on the website, with both old and new shown. (Abstracts, biographies, URLs etc, can continue to be edited and improved without doing anything special. Event titles should only be changed in minor ways - otherwise it counts as an AMENDMENT below.)
Wherever a person looks on the website, there should be no confusion about what is cancelled and what has been changed.
If a talk is cancelled:
We have two cases.
For a completely new session or a minor timing adjustment, e.g. filling a gap in the published schedule or before or after the original schedule, enter the details in the normal way but:
If two speakers swap slots:
You should use the 'Notes' field in pentabarf to explain what's happened (eg "Email from speaker 2020/01/24 - too ill to travel - agk") and add any further information / cross-references.
It is important to continue to follow this process during the event itself so that correct information appears to people watching the live streams and to the volunteers performing the video cutting.
If you have talks in reserve, it's a good idea to put them into the system in advance in state 'undecided/candidate' so you can quickly publish them as an AMENDMENT if the need arises.
During the event
Timekeeping
One of the problems that has surfaced in some of the feedback from
previous years is poor timekeeping in a small number of developer rooms.
Taking the size of the event, the desire of some people to switch
between tracks, the live video streaming and the need for easy video
cutting and review all together, it is absolutely essential that every
room keeps strictly to time this year.
No talk may start early, for any reason - not even 10 seconds early,
please. Wait for the new minute to begin! If you have an unexpected
gap, fill it with Q&A or discussion or ad-hoc lightning talks from your
audience. Make sure the timepiece being used is synchronised.
The published start times of talks must be adhered to.
If a speaker starts late for any reason, you should politely inform them
that this means they just have less time to speak or to take questions
and may need to go faster or to cut out some material. Discuss what
time signals they need, and be prepared to cut them off if need be so
that the next speaker will be able to begin on time.
Talks need to finish in sufficient time for people to leave/enter the
room and for the next speaker to be set up and ready to start on time.
If time is tight, the next speaker can set up their laptop during the
Q&A of the previous speaker.