For an online event like this, the "tech staff" basically boils down to
the folks who will launch and host scheduled Zoom sessions.
Peoples' experience with the host-level controls in Zoom still varies quite
a bit, so we ran several training sessions to review various documents and
give some examples.
These meetings became more productive as time went on and more people could
help contribute changes to the host procedures.
Since none of the Arisia-owned Zoom accounts were made available under this new architecture of machine-driven session launch, we weren't able to set up some test meetings and webinars for people to play with on their own time and really get this stuff into muscle-memory. That should be made available to *anyone* who isn't yet sure how it works, to run some tests in a sandbox environment and bring in multiple devices as hosts, participants, crash-dummies, etc and learn how it plays out. |
Silence of the hands
Frankly, the hands of the tech staff were tied in a few ways, not just in Zoom testing. Prior events usually made sure to have a couple of voice/video chat channels in the associated Discord specifically for Tech use, but the IT team for Arisia as a whole had put the kibosh on having *any* voice channels on the Arisia server. Why? Because of mythology. The fear was that voice channels would detract from "server bandwidth" somehow, and gum up the works for the text participants. This is essentially untrue -- voice connections, including one-to-one personal voicechats, simply cause a user's *client* to go off to completely differrent parts of the Discord infrastructure to set up those connections. It has little or no impact on the traffic to and from the "guild" itself, which is really just part of a long URL pointing into the vast cloud of Discord endpoint links. However, this groundless restriction could not be negotiated away, but having kept my own connections to prior event servers that were still set up and available, I simply pointed to a batch of them with instructions on how to join and find their voice channels if anyone needed a quick conference with more than two people. The value of having that kind of communication at times cannot be overstated, and having a quick convo right there on Discord can be far easier than the overhead of trying to set up a one-off external Zoom meeting. Where Zoom is still necessary for tech chat, in past events I've set up recurring, "hostless" meetings with simple passcodes that anyone could jump into any time as an alternative. Other crews have used services like gather.town for tech backchannels. The point is to have *something* available for voice-chat when needed. Zooming between spaces? Not... Techs and convention participants alike were repeatedly told to go fetch the "latest version" of the Zoom client for their platforms. However, this was not entirely applicable to the Linux variant, which relatively few people run anyway but could hose them in various annoying ways if they bought into that. When Zoom moved to the 5.3.x level release, the Linux platform was now able to self-select meeting breakout rooms and support that functionality when hosting. That was great, and allowed shenanigans like the kids playing "hide and seek" through a batch of breakout rooms in virtual house-parties. Then Zoom brought in the 5.4.x revision, which among other things enabled the end-to-end session encryption option. However, something in the Linux client broke in an odd way for moving between breakout rooms, and it turned out later, switching status from attendee to panelist in a webinar. [They're quite similar, and evidently handled in a rather klunky way -- you basically detach from one meeting space, and reattach to another one as internally directed.] The maddening thing was that the failure wasn't consistent, and doing such moves would either succeed or kick the user completely out of the meeting and back to the startup screen, completely at random. So now the Linux users had a problem: for participating in a meeting with breakouts, they'd want to back off to a 5.3 level client and happily party-hop all night with it. But if someone set up a meeting and enforced the E2E encryption, that 5.3 client wouldn't be able to join at all. And *every* 5.4.x sub-release of Linux Zoom had the same problem, with no apparent fix in the pipeline, whereas all the Mac and Windows clients were all fine at the lateset revs. This matched a consistent trend of Linux functionality lagging behind the other platforms in the Zoom development/release cycle. Fortunately, it didn't affect ability to *host* sessions, so I was fine in that role regardless. |
With my efforts to reach Zoom all for naught so far, the least I could do was clarify what I knew to our own tech team, to cut through some of the negative hype and get everyone on the same page. This is part of what I sent to our Zoom-hosting crew; the full revised text is provided here. |
Getting down to the order of business
Hit the [schedule] running
And at some point the person who'd offered to work up our bumper slides came through, and we had a whole set of 'em as typical high-res JPEGs. Contained in a folder structure like this, it's easy to "download all" as a .zip file and have them ready to go locally. |
We had one main "tech-ops" Discord channel to report various things into, like session start/stop, all-panelists-present, peak attendance if we noticed, any problems, etc. One channel for this was enough. Other events had things like tech channels *and* a separate "program" section where such reports were also appropriate, but that just made things more confusing. For Arisia we also had a sideline "tech chat" type channel for idle geekery when needed, but it didn't get too much use. |