It is mostly that last component, Zoom, which the rest of this focuses on.  Other folks were managing the Discord, I know nothing about the Zambia scheduler or exporting of data from it, the website was handled by the folks within NESFA who always did it, so I stuck with what I knew.  Like the previous year, I took care of all the advance Zoom configuration, which was made easier by the fact that a lot of that infrastructure was still in place from last year -- all the "runtime" user logins were valid, the email alias tree to receive messages from Zoom needed minor updates, and once the webinar add-on licenses were assigned, I found that some of our old recurring webinars were even still present.  I re-used as much of that as needed, and cleaned up the rest.  I tweaked a few meeting/webinar settings for all the run-time accounts, using the group mode where possible and locking various settings to propagate them down.  Then I pre-generated all the convention webinars and put the resulting join-links in a google-file, where the scheduling folks could pick them up and salt them into the Zambia database.

[See this condensed checklist for more specific guidelines on preparing a Zoom environment for this kind of event, which I wrote up a little later.]

The other half of my purview was people.  I started with a hand-me-down list of volunteers from the prior year, and trimmed out the ones I already knew wouldn't be able to help us this year.  I was grateful that those remaining on the list, about half of what I started with, were all experienced people who I had worked with on events like this before, hinting that we wouldn't need a whole lot of arduous "training".  As I've done with other events, I wanted to give our prospective session hosts as much hands-on pratice as possible, and set up a couple of sandbox webinars that they could log in and play with.  I had seen the pure "lecture" format of Zoom-host training fail in many ways, and watching their discovery process as they got to work through the real controls told me that messing with the real thing themselves was the best learning tool.  Muscle-memory counts for a lot when comes crunch-time.

As it turned out, we never had any training meetings, not even a final "all-hands" gathering before the con started.  I had asked several times if anyone wanted something like that as a refresher, and got crickets.  It was actually a little frustrating as people stepped up and confirmed their ability to participate fairly late in the game, but I kept pushing folks to reply to my numerous broadcast emails and actually sign up for session slots.

The signup mechanism was super-simple, starting from a method I'd learned from other folks.  A Google-drive spreadsheet was set up so that random people on the internet could go to its link and add *comments* to specific cells under a "zoom host" column, but not modify the sheet contents.  Doing that leaves a tiny red trianglular tick in a corner of the cell, which I could then go hunt down and copy the person's name out of the comment and pop it into the cell for real as the Zoom host assigned for that session.  The available sessions were listed as a simple spreadsheet row per, rather than the more confusing "grid" format others have used, and was a simple copy-paste from another sheet I got from Programming and filtered down to the virtual sessions.  Much more straightforward than "signupgenius" or other services, where I'd need to create yet another username and password just to get started.  I already had access to create some public files within the Boskone GDrive, so that was sufficient.  For all the information our hosts would need, I sent out a SINGLE link to a GDrive folder, and everything else was findable inside that including a running log of all the email I had sent out to the volunteers -- in case we got someone new in, and they needed to catch up.  I used a folder link because I had worked too many events where I had to save and reference a pile of links to individual files, and found it to be a pain in the ass.  Google-drive does not foster good organization.

For completeness and offering some realtime help anyway, I ran a couple of days of "office hours", where I'd start one of the sandbox webinars for a specific time-block and then just sit in it waiting for anyone to show up.  Only one or two people took advantage of that, but it was valuable for them.

One significant workflow change was that we didn't bother trying to generate magic webinar join-links for the individual panelists themselves.  The initial idea was to have no join-links at all, and just bring *everyone* in as attendees and then promote to panelists/co-hosts as needed.  Later, I generated one special panelist join-link per webinar anyway, because it was much more convenient for session hosts to use that and just pop in such that they could immediately talk to me and get my attention more easily.  As part of setup, a file with all the magic join-links and generic attendee links for the whole weekend became part of the standard kit I distributed out to all the Zoom client laptops in our tech-ops area in the Boardroom, aka Network Operations Center [NOC].

The other workflow change, visible to everyone, was that we would simply run one webinar per slot per day, and keep them open the entire time -- letting attendees see the "sausage being made" in the half-hour breaks while we brought new panelists in and got them set up.  While this does grate on the nerves of "professional video production" folks, where the norm is to never go live on a session until everyone's ready to roll, prior virtual conventions had found that having that changeover time visible on the stream gave everything a much more "human" and real-life feel -- just like would happen in a real hotel function space.  It also made for fewer, albeit larger, recording files to be downloaded later.  Another significant advantage was that we didn't need any of the session hosts to mess with logging their Zoom clients into run-time user accounts.  This helps avoid getting bit by the stupid "forced 2FA" emailed-code rigamarole that Zoom has been imposing on user logins more frequently, even if we try to tell them that yes, we're sharing user logins across multiple hosting volunteers and Zoom just needs to stay out of our goddamn way.  Their warped idea of "security" simply does not apply to all client needs -- we can evaluate our own risk profile, thankyouverymuch.

What was especially interesting, harking back to Zoom's bizarre behavior around panelist join-links that we observed last year, was that when attendees got promoted to panelists, they showed up in the backend webinar setup at the web portal.  It is still insane to think that any single-session changes should affect the permanent *backend* setup of a recurring webinar, but that's how Zoom insists on doing things.  Since the temporarily-promoted users were just random personal Zoom accounts or a typed-in email address, sometime mid-session I would delete them from the portal -- which didn't affect their presence in running sessions, it just made sure they were back to attendee status after they left and returned later.  Obviously, I left our one magic co-host join-link alone so it would still be valid.

The hardware infrastructure was somewhat interesting, but relatively straightforward.  One of our tech colleagues has crates full of low-end laptops with Windows and Zoom and browsers and various other common components loaded, specifically for bringing to conventions to run various aspects.  I set up three of these in the NOC as the Zoom host platforms, with my personal laptop in the middle because I wanted *my* familiar Linux-based work environment on hand as the management hub.  This means that I had to actually touch Windows again, ewww, but I came up with a small but useful set of configuration steps to keep its major annoyances out of the way.  I spent a while going through that on all of them identically, and downloading a .zip of my additional pieces from a "fake-webserver" script on my machine.  That included some generic bumper slides, and a clickable .html file on the desktop with all the preset session join-links.

   ___________
   |    |    |
   |____|____|

In retrospect it's been suggested that the booths were a bit more work to set up and run than was really warranted, but the panelists who used them were just gushing about how well they worked -- much better than being sent to their own rooms on crappy hotel wifi.  The concept will undoubtedly come under further debate in the ramp-up to next year.

Two *more* laptops [we're up to eight total now...] went over to main tent, for the stream-feeding Zoom at the back of the room and another one at the front for a program volunteer to take questions from the virtual-side Q&A and relay them to the panelists at the head table.  A "dark VLAN" provided by the hotel relayed all the network traffic to our main switch in the NOC, and a simple firewall gatewayed all of that to the outside world.  The hotel gave us the correct thing for the purpose -- a completely open and unfiltered feed on their front-end public network, a /23 or so sized chunk of Windstream's customer edge, which seemed very sparsely populated so we could just pick any free address on that we wanted and run with it.  I measured the available bandwidth at something like 800 Mbit up and down -- about an order of magnitude more than most of what we were going to throw at it over the weekend.  It was obvious that the external net wasn't too full the instant I plugged a network monitor into it, because I saw an immediate whirlwind of ARP requests -- from the upstream router desperately trying to find all possible host IPs, as the netblock received countless automated scan attempts from outside.  This is just a fact of life on the open internet nowadays -- numerous ill-intended sources, most of them offshore, are ceaselessly trying to find vulnerable public endpoints for further compromise and malfeasance, and these downstream ARP storms are one visible result.

I wound up running the "Zoom nest" the entire weekend, but I didn't mind that as there were clear opportunities to take a break, get some food, and run around the con a little.  The general workflow was to get each session's new hosts in and co-hosted up, and in theory, at that point I could walk away and others would handle the top-of-hour startup.  As noted, the webinars were live to the world the entire time, including the one streaming from main tent.  In most cases I also stuck around to share up the session bumper-slides for main tent, as nobody over there was really thinking about that part, they just needed to make sure the output from the video switcher was getting into Zoom right.  I also turned on the Zoom auto-captioning, because it generally works better than what Youtube does in post, and those captured .VTT files were re-timed and merged with the final Youtube session recordings after the fact.  We tried to make sure to use the recording resolution trick to ensure that the videos would look good.  [If you aren't familiar with that, you should give it a read.]

At the on-site feedback session, the convention leads were praising Tech for "taking things to the next level" this year.  Well, it wasn't really that much more than we did last year, perhaps a bit more streamlined now because we'd done it before.  What we still didn't quite pull together was true "hybrid" -- with panelists in both the in-person and virtual spaces at once, freely bridging the gap and interacting back and forth in a relatively seamless way.  We do have the technology to do that, it just requires a little planning -- but more importantly, more staff than we had available.  While many conventiongoers did not notice, we barely held things together with the number of volunteers that we did have.