Debian Conference Infrastructure
Robbertze, Kyle
DebConf has been online for two years using a combination of our in-person infrastructure and new tools. This talk will describe both setups and what has been done to bring DebConf online.
 Hello and welcome to this talk about the Debian conference infrastructure. My name is Kyle. I've been a part of the Debian video team for about six years since 2016. In this talk we'll be looking a bit more about how the video team streams and records the Debian conferences that happen throughout the year. So let's dive in. Just kind of a brief overview of what Debian is. It's the annual Debian conference attended by Debian developers and Debian contributors, even just interested parties every year. It happens in a different country. So the last in-person one was 2019 in Curitiba, Brazil. It changes around different continents, different countries. In 2020 and 2021 the conference was online and we had to develop a new set of systems to manage that. The Debian video team is responsible for recording and streaming all the talks in the rooms that we're covering. So we record each talk. It then gets reviewed and uploaded so that it can be viewed afterwards as well as streaming in real time during the events of people that are remote, can attend and listen to the talks. We also cover other Debian events. So many Debian conferences that we can get to, we cover as well. Generally we cover the ones in Europe because our hardware is based in Europe. So getting to the Europe ones are easier than having to ship that through various other international places. So in in-person DebCup we have generally three recorded rooms, two talk rooms and a bathroom. So of those we cover the majority of the talks in the conference. We also have a video team LAN that we run across those three rooms and a back-end video team server room. We deploy our own streaming CDN network and maintain a local Debian package mirror for the attendees so that they can download packages, manage and do Debian work without having to deal with too much latency to get those packages. So an in-person DebCup relies on volunteers. We use a lot of volunteers for every talk and expand that over three rooms it becomes a lot of people. We need two camera operators, a director and a sound technician, kind of the three core volunteers that we need. We also then need a talkmeister and a room coordinator. Then the room coordinator and talkmeister are merged into one role so that they're covered by a single person. But the talkmeister is responsible for doing the introductions and managing the time, so handling question and answer and getting the speaker know when time is up. The camera operator is responsible for managing a single camera. They cover the shots, make sure that the person that they're filming is in view. It's easy to see for people on stream and all of the shots are mixed by the director who sits behind the VoktaMix PC and controls what's going out on stream, whether that's be one of the cameras, the presentation or a mixture of the three. The sound technician mixes the audio. So we've got an array of microphones and other inputs that they manage. So they ensure the audio levels are well balanced and audible on stream so that the people giving the talk can be heard. And then we've got a core team that's kind of the debconf video team on standby for troubleshooting and working out what happens if things go wrong. So if we dig into a bit more of the hardware, for an in-person room we've got two Sony PXW X70 cameras which are SDI enabled cameras. So we do all of our video transfer over SDI. We use Marta Opsis HDMI capture boards. These are open hardware capture boards that are manufactured and developed by Tim Videos in Australia. And they are run or driven by a Miniboard Turbo single board computer which captures the HDMI audio from the Opsis boards and streams it to VoktaMix which is a rented PC. But it's just kind of easier to rent these machines than to have a set of fleet of them that we ship everywhere. We ship cameras, Opsis and the turbots but the PCs because we use a lot of them, we use encoder nodes, VoktaMix and gateways and kind of our use of the PCs scale as based on the number that we have, it's easier just to rent them locally wherever we are doing the conference. On the sound side of stuff we have a lapel mic, we have two of them for the case when there's two speakers, cordless mics and ambient mics. The cordless mics are used for questions and for the talkmeister. The ambient mics pick up the room sound and catch any questions that may be shouted out so that they still can be heard on the stream. All of the sound is mixed using an analog audio mixer and then fed into the main camera so that we don't have to worry about any audio sync issues or anything like that. It's all handled in camera before we hit the VoktaMix machines. We use Blackmagic Declink SDI capture cards. These are unfortunately proprietary but they're reliable and they work under Linux and we have two per machine, one for each SDI feed and then those are fed into VoktaMix. On the hardware side of it there is the Blackmagic SDI capture software, so the drivers for those Declink cards. HDMI to USB is the firmware and software side of the Opsys boards. That's what's run on the Opsys board and the PC so that we are able to capture and stream the video or the presentations. The Opsys also splits the HDMI feed from the presenters laptop so that we have one feed going to the projector and the other one being captured by the Opsys PC and streamed to the VoktaMix machine. So to do the actual live video switching we use VoktaMix which is developed by CCC and our streaming is all done by Nginx RTMP on the front end with FFMpeg being the driver of that system. For recording review we use S review, same as FOSDEM and that has served us very well the last few years. That's where talks can be reviewed so that they ensure that they start correctly and are audible and visually there the whole talk before they are accepted and uploaded to several places. We upload to the Debian meeting archive, we upload to YouTube and we upload to our own PeerTube instance and all of that is managed through another piece of software that Stefano Mavira wrote called Archive and that manages all of our metadata for our uploads of our video archive. All of our machines are managed using Ansible, that's a pixie boot into a basic setup and then automatically Ansible themselves from a gateway machine so that they have all the configuration required for whatever role they are assuming. Then for online infrastructure we have a slightly different approach, we pay down the volunteers required because we don't need things like cameras or audio, we've just got a director and a talkmeister so the director does the same similar job to what they would do in an in-person conference, they do things like switch between inputs, play a pre-recorded talk and start and stop things as required. While the talkmeister does the introductions and handles the question and answer, we also have the core team on standby with access and knowledge to be able to troubleshoot things as kind of we need them to. Then the software that we use, the streaming pipeline is pretty much unchanged, we're still pushing ffmpeg to nginxrtmp and that to a self-managed CDN network. We built a web interface onto voctomics called Virgil and that's what the director uses to manage the various inputs. We use Jitsie for the live talks and Q&A, the only people in the Jitsie room are the presenter, the talkmeister and the director, they all get streamed or get captured into voctomics to be streamed out to people attending so that we don't have lots of people in the Jitsie room, it effectively acts like the stage and we handle questions using etherpad so each talk has their own etherpad link and in that people during the talk ask questions by typing them and then the talkmeister will read those questions out to the speaker to answer. Then what happens is the attendees will then type the answers into the etherpad underneath each question so that there's a record of what's been asked and what the answer was so we export those etherpads to static html to be displayed and archived for later use once the conference is over. In Sreview's job is extended for online conferences, we use it for previewing and approving pre-recorded talks so that they are start and stop at the right times and are in the right format for us to play as well as the post-conference recording review and talk export process. If you would like any further reading on our infrastructure and our setup you can go to video.dev.com.org that is usually a redirect to the docs site which is the next link there. But during conferences that points to the actual video link on the conference website so that's why I've got the full link there and if you would like more details on our Ansible setup you can see it there as well. Right I'd like to head on to any questions. Thanks so much for attending this talk and if there are any questions I'll take them now. Right if you've got any questions feel free to post them in the chat. I don't really see any yet but maybe I'll just take this time to cover a bit about Wafa which is the conference management system that StepConf uses. It's built by the Cape Town Python user group and we run a somewhat modified version of that. It's used to display the conference website so that includes sharing or being able to view the video streams and things like that as well as all the registration. It's used to track attendees who are interested and who actually attend both live in person and virtual events as well as do things like print out their name, badges and things like that for front desk. And we use it for managing our volunteer system. So as I mentioned all of our systems and talks are covered by volunteers and you can volunteer to do a particular task for a particular talk through Wafa. It imports and manages the system or the schedule and then uses that to generate the list of tasks for each room, for each talk so that people can volunteer and go, yeah, I'm going to do that and do it that way. The front end of that, the conference website is mostly marked out as far as I remember and it's Wafa's or Django and JavaScript's server-side rendered templates so it's all kind of fairly easy to deploy and manage. The CTPunk documentation is pretty good for that. But yeah, we've used it since about, I think 2015 or 2016 was the first time and it's been constantly developed to improve since then after each DevConf there's usually a bunch of changes that go back upstream so that the general Wafa instances or code base can use them but there was, yeah, I'll fair but that is generic to or specific to DevConf that remains as patches on top. And recently Wafa has been extended to support different schedule exports. Recently it was just able to export a PentaBARTH kind of XML structure which used by Penta and a couple other systems that allow us to do some migration and management that way but it has been extended to a couple other formats as well for a bit more integration, visual integration into other apps or websites or things like that. Yeah, are there any questions? I've tried to cover as much of the Debian kind of way of doing conferences as possible. It is a rather complicated setup and definitely not as complicated as FOSDEM but a lot more complicated than maybe just a single bathroom kind of conference style. So yeah, if you need any more of the documentation or any kind of write up of how we do stuff video.devconf.org is generally a good place to start or have a look at the DevConf video team, Salsa group, GitLab group on salsa.dev.org for kind of all of our Ansible scripts, our documentation, our other applications that we've written to support kind of our use cases, things like Vohel are there, the archive and upload tool as well. The R2D R2D kind of all that side. But if there are no questions at this point, I'll think I'll end it there. And yeah, you're welcome to continue asking questions or join the DevConf conference infrastructure room where I'll stick around and we can chat there or in the conference organisation Dev Room. Thanks for the talk. Thanks for attending.
 Hello and welcome to this talk about the Debian conference infrastructure.  My name is Kyle.  I've been a part of the Debian video team for about six years since 2016.  In this talk we'll be looking a bit more about how the video team streams and records the  Debian conferences that happen throughout the year.  So let's dive in.  Just kind of a brief overview of what Debian is.  It's the annual Debian conference attended by Debian developers and Debian contributors,  even just interested parties every year.  It happens in a different country.  So the last in-person one was 2019 in Curitiba, Brazil.  It changes around different continents, different countries.  In 2020 and 2021 the conference was online and we had to develop a new set of systems  to manage that.  The Debian video team is responsible for recording and streaming all the talks in the rooms that  we're covering.  So we record each talk.  It then gets reviewed and uploaded so that it can be viewed afterwards as well as streaming  in real time during the events of people that are remote, can attend and listen to the talks.  We also cover other Debian events.  So many Debian conferences that we can get to, we cover as well.  Generally we cover the ones in Europe because our hardware is based in Europe.  So getting to the Europe ones are easier than having to ship that through various other  international places.  So in in-person DebCup we have generally three recorded rooms, two talk rooms and a bathroom.  So of those we cover the majority of the talks in the conference.  We also have a video team LAN that we run across those three rooms and a back-end video  team server room.  We deploy our own streaming CDN network and maintain a local Debian package mirror for  the attendees so that they can download packages, manage and do Debian work without having to  deal with too much latency to get those packages.  So an in-person DebCup relies on volunteers.  We use a lot of volunteers for every talk and expand that over three rooms it becomes  a lot of people.  We need two camera operators, a director and a sound technician, kind of the three core  volunteers that we need.  We also then need a talkmeister and a room coordinator.  Then the room coordinator and talkmeister are merged into one role so that they're covered  by a single person.  But the talkmeister is responsible for doing the introductions and managing the time,  so handling question and answer and getting the speaker know when time is up.  The camera operator is responsible for managing a single camera.  They cover the shots, make sure that the person that they're filming is in view.  It's easy to see for people on stream and all of the shots are mixed by the director  who sits behind the VoktaMix PC and controls what's going out on stream, whether that's  be one of the cameras, the presentation or a mixture of the three.  The sound technician mixes the audio.  So we've got an array of microphones and other inputs that they manage.  So they ensure the audio levels are well balanced and audible on stream so that the people giving  the talk can be heard.  And then we've got a core team that's kind of the debconf video team on standby for troubleshooting  and working out what happens if things go wrong.  So if we dig into a bit more of the hardware, for an in-person room we've got two Sony  PXW X70 cameras which are SDI enabled cameras.  So we do all of our video transfer over SDI.  We use Marta Opsis HDMI capture boards.  These are open hardware capture boards that are manufactured and developed by Tim Videos  in Australia.  And they are run or driven by a Miniboard Turbo single board computer which captures  the HDMI audio from the Opsis boards and streams it to VoktaMix which is a rented PC.  But it's just kind of easier to rent these machines than to have a set of fleet of them  that we ship everywhere.  We ship cameras, Opsis and the turbots but the PCs because we use a lot of them, we use  encoder nodes, VoktaMix and gateways and kind of our use of the PCs scale as based on the  number that we have, it's easier just to rent them locally wherever we are doing the  conference.  On the sound side of stuff we have a lapel mic, we have two of them for the case when  there's two speakers, cordless mics and ambient mics.  The cordless mics are used for questions and for the talkmeister.  The ambient mics pick up the room sound and catch any questions that may be shouted out  so that they still can be heard on the stream.  All of the sound is mixed using an analog audio mixer and then fed into the main camera  so that we don't have to worry about any audio sync issues or anything like that.  It's all handled in camera before we hit the VoktaMix machines.  We use Blackmagic Declink SDI capture cards.  These are unfortunately proprietary but they're reliable and they work under Linux and we  have two per machine, one for each SDI feed and then those are fed into VoktaMix.  On the hardware side of it there is the Blackmagic SDI capture software, so the drivers for those  Declink cards.  HDMI to USB is the firmware and software side of the Opsys boards.  That's what's run on the Opsys board and the PC so that we are able to capture and stream  the video or the presentations.  The Opsys also splits the HDMI feed from the presenters laptop so that we have one feed  going to the projector and the other one being captured by the Opsys PC and streamed to the  VoktaMix machine.  So to do the actual live video switching we use VoktaMix which is developed by CCC and  our streaming is all done by Nginx RTMP on the front end with FFMpeg being the driver  of that system.  For recording review we use S review, same as FOSDEM and that has served us very well  the last few years.  That's where talks can be reviewed so that they ensure that they start correctly and  are audible and visually there the whole talk before they are accepted and uploaded to several  places.  We upload to the Debian meeting archive, we upload to YouTube and we upload to our own  PeerTube instance and all of that is managed through another piece of software that Stefano  Mavira wrote called Archive and that manages all of our metadata for our uploads of our  video archive.  All of our machines are managed using Ansible, that's a pixie boot into a basic setup and  then automatically Ansible themselves from a gateway machine so that they have all the  configuration required for whatever role they are assuming.  Then for online infrastructure we have a slightly different approach, we pay down the volunteers  required because we don't need things like cameras or audio, we've just got a director  and a talkmeister so the director does the same similar job to what they would do in  an in-person conference, they do things like switch between inputs, play a pre-recorded  talk and start and stop things as required.  While the talkmeister does the introductions and handles the question and answer, we also  have the core team on standby with access and knowledge to be able to troubleshoot things  as kind of we need them to.  Then the software that we use, the streaming pipeline is pretty much unchanged, we're  still pushing ffmpeg to nginxrtmp and that to a self-managed CDN network.  We built a web interface onto voctomics called Virgil and that's what the director  uses to manage the various inputs.  We use Jitsie for the live talks and Q&A, the only people in the Jitsie room are the  presenter, the talkmeister and the director, they all get streamed or get captured into  voctomics to be streamed out to people attending so that we don't have lots of people in the  Jitsie room, it effectively acts like the stage and we handle questions using etherpad  so each talk has their own etherpad link and in that people during the talk ask questions  by typing them and then the talkmeister will read those questions out to the speaker to  answer.  Then what happens is the attendees will then type the answers into the etherpad underneath  each question so that there's a record of what's been asked and what the answer was  so we export those etherpads to static html to be displayed and archived for later use  once the conference is over.  In Sreview's job is extended for online conferences, we use it for previewing and approving pre-recorded  talks so that they are start and stop at the right times and are in the right format for  us to play as well as the post-conference recording review and talk export process.  If you would like any further reading on our infrastructure and our setup you can go to  video.dev.com.org that is usually a redirect to the docs site which is the next link there.  But during conferences that points to the actual video link on the conference website  so that's why I've got the full link there and if you would like more details on our  Ansible setup you can see it there as well.  Right I'd like to head on to any questions.  Thanks so much for attending this talk and if there are any questions I'll take them  now.  Right if you've got any questions feel free to post them in the chat.  I don't really see any yet but maybe I'll just take this time to cover a bit about Wafa  which is the conference management system that StepConf uses.  It's built by the Cape Town Python user group and we run a somewhat modified version of  that.  It's used to display the conference website so that includes sharing or being able to  view the video streams and things like that as well as all the registration.  It's used to track attendees who are interested and who actually attend both live in person  and virtual events as well as do things like print out their name, badges and things like  that for front desk.  And we use it for managing our volunteer system.  So as I mentioned all of our systems and talks are covered by volunteers and you can volunteer  to do a particular task for a particular talk through Wafa.  It imports and manages the system or the schedule and then uses that to generate the list of  tasks for each room, for each talk so that people can volunteer and go, yeah, I'm going  to do that and do it that way.  The front end of that, the conference website is mostly marked out as far as I remember  and it's Wafa's or Django and JavaScript's server-side rendered templates so it's all  kind of fairly easy to deploy and manage.  The CTPunk documentation is pretty good for that.  But yeah, we've used it since about, I think 2015 or 2016 was the first time and it's been  constantly developed to improve since then after each DevConf there's usually a bunch  of changes that go back upstream so that the general Wafa instances or code base can use  them but there was, yeah, I'll fair but that is generic to or specific to DevConf that  remains as patches on top.  And recently Wafa has been extended to support different schedule exports.  Recently it was just able to export a PentaBARTH kind of XML structure which used by Penta  and a couple other systems that allow us to do some migration and management that way  but it has been extended to a couple other formats as well for a bit more integration,  visual integration into other apps or websites or things like that.  Yeah, are there any questions?  I've tried to cover as much of the Debian kind of way of doing conferences as possible.  It is a rather complicated setup and definitely not as complicated as FOSDEM but a lot more  complicated than maybe just a single bathroom kind of conference style.  So yeah, if you need any more of the documentation or any kind of write up of how we do stuff  video.devconf.org is generally a good place to start or have a look at the DevConf video  team, Salsa group, GitLab group on salsa.dev.org for kind of all of our Ansible scripts, our  documentation, our other applications that we've written to support kind of our use cases,  things like Vohel are there, the archive and upload tool as well.  The R2D R2D kind of all that side.  But if there are no questions at this point, I'll think I'll end it there.  And yeah, you're welcome to continue asking questions or join the DevConf conference infrastructure  room where I'll stick around and we can chat there or in the conference organisation Dev  Room.  Thanks for the talk.  Thanks for attending.
conference_debconf_0_167.png conference_debconf_168_1091.png conference_debconf_1092_1163.png conference_debconf_1164_1823.png conference_debconf_1824_3491.png conference_debconf_3492_4031.png conference_debconf_4032_4139.png conference_debconf_4140_4211.png conference_debconf_4212_4391.png conference_debconf_4392_4631.png conference_debconf_4632_4811.png conference_debconf_4812_6239.png conference_debconf_6240_6431.png conference_debconf_6432_7007.png conference_debconf_7008_7067.png conference_debconf_7068_7667.png conference_debconf_7668_16079.png conference_debconf_16080_16655.png conference_debconf_16656_17423.png conference_debconf_17424_18023.png conference_debconf_18024_19187.png conference_debconf_19188_21023.png conference_debconf_21024_22367.png conference_debconf_22368_23087.png conference_debconf_23088_24971.png conference_debconf_24972_27983.png conference_debconf_27984_29867.png
Hello and welcome to this talk about the Debian conference infrastructure. My name is Kyle. I've been a part of the Debian video team for about six years since 2016. In this talk we'll be looking a bit more about how the video team streams and records the Debian conferences that happen throughout the year. So let's dive in. Just kind of a brief overview of what Debian is. It's the annual Debian conference attended by Debian developers and Debian contributors, even just interested parties every year. It happens in a different country. So the last in-person one was 2019 in Curitiba, Brazil. It changes around different continents, different countries. In 2020 and 2021 the conference was online and we had to develop a new set of systems to manage that. The Debian video team is responsible for recording and streaming all the talks in the rooms that we're covering. So we record each talk. It then gets reviewed and uploaded so that it can be viewed afterwards as well as streaming in real time during the events of people that are remote, can attend and listen to the talks. We also cover other Debian events. So many Debian conferences that we can get to, we cover as well. Generally we cover the ones in Europe because our hardware is based in Europe. So getting to the Europe ones are easier than having to ship that through various other international places. So in in-person DebCup we have generally three recorded rooms, two talk rooms and a bathroom. So of those we cover the majority of the talks in the conference. We also have a video team LAN that we run across those three rooms and a back-end video team server room. We deploy our own streaming CDN network and maintain a local Debian package mirror for the attendees so that they can download packages, manage and do Debian work without having to deal with too much latency to get those packages. So an in-person DebCup relies on volunteers. We use a lot of volunteers for every talk and expand that over three rooms it becomes a lot of people. We need two camera operators, a director and a sound technician, kind of the three core volunteers that we need. We also then need a talkmeister and a room coordinator. Then the room coordinator and talkmeister are merged into one role so that they're covered by a single person. But the talkmeister is responsible for doing the introductions and managing the time, so handling question and answer and getting the speaker know when time is up. The camera operator is responsible for managing a single camera. They cover the shots, make sure that the person that they're filming is in view. It's easy to see for people on stream and all of the shots are mixed by the director who sits behind the VoktaMix PC and controls what's going out on stream, whether that's be one of the cameras, the presentation or a mixture of the three. The sound technician mixes the audio. So we've got an array of microphones and other inputs that they manage. So they ensure the audio levels are well balanced and audible on stream so that the people giving the talk can be heard. And then we've got a core team that's kind of the debconf video team on standby for troubleshooting and working out what happens if things go wrong. So if we dig into a bit more of the hardware, for an in-person room we've got two Sony PXW X70 cameras which are SDI enabled cameras. So we do all of our video transfer over SDI. We use Marta Opsis HDMI capture boards. These are open hardware capture boards that are manufactured and developed by Tim Videos in Australia. And they are run or driven by a Miniboard Turbo single board computer which captures the HDMI audio from the Opsis boards and streams it to VoktaMix which is a rented PC. But it's just kind of easier to rent these machines than to have a set of fleet of them that we ship everywhere. We ship cameras, Opsis and the turbots but the PCs because we use a lot of them, we use encoder nodes, VoktaMix and gateways and kind of our use of the PCs scale as based on the number that we have, it's easier just to rent them locally wherever we are doing the conference. On the sound side of stuff we have a lapel mic, we have two of them for the case when there's two speakers, cordless mics and ambient mics. The cordless mics are used for questions and for the talkmeister. The ambient mics pick up the room sound and catch any questions that may be shouted out so that they still can be heard on the stream. All of the sound is mixed using an analog audio mixer and then fed into the main camera so that we don't have to worry about any audio sync issues or anything like that. It's all handled in camera before we hit the VoktaMix machines. We use Blackmagic Declink SDI capture cards. These are unfortunately proprietary but they're reliable and they work under Linux and we have two per machine, one for each SDI feed and then those are fed into VoktaMix. On the hardware side of it there is the Blackmagic SDI capture software, so the drivers for those Declink cards. HDMI to USB is the firmware and software side of the Opsys boards. That's what's run on the Opsys board and the PC so that we are able to capture and stream the video or the presentations. The Opsys also splits the HDMI feed from the presenters laptop so that we have one feed going to the projector and the other one being captured by the Opsys PC and streamed to the VoktaMix machine. So to do the actual live video switching we use VoktaMix which is developed by CCC and our streaming is all done by Nginx RTMP on the front end with FFMpeg being the driver of that system. For recording review we use S review, same as FOSDEM and that has served us very well the last few years. That's where talks can be reviewed so that they ensure that they start correctly and are audible and visually there the whole talk before they are accepted and uploaded to several places. We upload to the Debian meeting archive, we upload to YouTube and we upload to our own PeerTube instance and all of that is managed through another piece of software that Stefano Mavira wrote called Archive and that manages all of our metadata for our uploads of our video archive. All of our machines are managed using Ansible, that's a pixie boot into a basic setup and then automatically Ansible themselves from a gateway machine so that they have all the configuration required for whatever role they are assuming. Then for online infrastructure we have a slightly different approach, we pay down the volunteers required because we don't need things like cameras or audio, we've just got a director and a talkmeister so the director does the same similar job to what they would do in an in-person conference, they do things like switch between inputs, play a pre-recorded talk and start and stop things as required. While the talkmeister does the introductions and handles the question and answer, we also have the core team on standby with access and knowledge to be able to troubleshoot things as kind of we need them to. Then the software that we use, the streaming pipeline is pretty much unchanged, we're still pushing ffmpeg to nginxrtmp and that to a self-managed CDN network. We built a web interface onto voctomics called Virgil and that's what the director uses to manage the various inputs. We use Jitsie for the live talks and Q&A, the only people in the Jitsie room are the presenter, the talkmeister and the director, they all get streamed or get captured into voctomics to be streamed out to people attending so that we don't have lots of people in the Jitsie room, it effectively acts like the stage and we handle questions using etherpad so each talk has their own etherpad link and in that people during the talk ask questions by typing them and then the talkmeister will read those questions out to the speaker to answer. Then what happens is the attendees will then type the answers into the etherpad underneath each question so that there's a record of what's been asked and what the answer was so we export those etherpads to static html to be displayed and archived for later use once the conference is over. In Sreview's job is extended for online conferences, we use it for previewing and approving pre-recorded talks so that they are start and stop at the right times and are in the right format for us to play as well as the post-conference recording review and talk export process. If you would like any further reading on our infrastructure and our setup you can go to video.dev.com.org that is usually a redirect to the docs site which is the next link there. But during conferences that points to the actual video link on the conference website so that's why I've got the full link there and if you would like more details on our Ansible setup you can see it there as well. Right I'd like to head on to any questions. Thanks so much for attending this talk and if there are any questions I'll take them now. Right if you've got any questions feel free to post them in the chat. I don't really see any yet but maybe I'll just take this time to cover a bit about Wafa which is the conference management system that StepConf uses. It's built by the Cape Town Python user group and we run a somewhat modified version of that. It's used to display the conference website so that includes sharing or being able to view the video streams and things like that as well as all the registration. It's used to track attendees who are interested and who actually attend both live in person and virtual events as well as do things like print out their name, badges and things like that for front desk. And we use it for managing our volunteer system. So as I mentioned all of our systems and talks are covered by volunteers and you can volunteer to do a particular task for a particular talk through Wafa. It imports and manages the system or the schedule and then uses that to generate the list of tasks for each room, for each talk so that people can volunteer and go, yeah, I'm going to do that and do it that way. The front end of that, the conference website is mostly marked out as far as I remember and it's Wafa's or Django and JavaScript's server-side rendered templates so it's all kind of fairly easy to deploy and manage. The CTPunk documentation is pretty good for that. But yeah, we've used it since about, I think 2015 or 2016 was the first time and it's been constantly developed to improve since then after each DevConf there's usually a bunch of changes that go back upstream so that the general Wafa instances or code base can use them but there was, yeah, I'll fair but that is generic to or specific to DevConf that remains as patches on top. And recently Wafa has been extended to support different schedule exports. Recently it was just able to export a PentaBARTH kind of XML structure which used by Penta and a couple other systems that allow us to do some migration and management that way but it has been extended to a couple other formats as well for a bit more integration, visual integration into other apps or websites or things like that. Yeah, are there any questions? I've tried to cover as much of the Debian kind of way of doing conferences as possible. It is a rather complicated setup and definitely not as complicated as FOSDEM but a lot more complicated than maybe just a single bathroom kind of conference style. So yeah, if you need any more of the documentation or any kind of write up of how we do stuff video.devconf.org is generally a good place to start or have a look at the DevConf video team, Salsa group, GitLab group on salsa.dev.org for kind of all of our Ansible scripts, our documentation, our other applications that we've written to support kind of our use cases, things like Vohel are there, the archive and upload tool as well. The R2D R2D kind of all that side. But if there are no questions at this point, I'll think I'll end it there. And yeah, you're welcome to continue asking questions or join the DevConf conference infrastructure room where I'll stick around and we can chat there or in the conference organisation Dev Room. Thanks for the talk. Thanks for attending.
rooms, two talk rooms and a bathroom. So of those of our metadata for our uploads of our video further reading on our infrastructure and our top. And recently Wafa has been extended to