|
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. |
|
Still, I made a couple of attempts to report this, and urge Zoom to get a fix out and maybe pay a little more attention to the Linux stuff in general. I had some pretty solid information as to what was going on, because I run through logging proxies -- the client was mangling the DNS hostnames it received as the next server endpoint to connect to while doing those moves, and then just giving up when it failed to connect. The problem is, my own Zoom account is free-tier and Zoom's support has simply stopped accepting bug reports from that level of subscriber. Not that I didn't try -- I could log in at their website and try to submit a report, and wound up talking to their 100% useless "chatbot" which basically told me to screw off and go read the "help pages". Which I'd already done any number of times, fuckyouverymuch. |
|
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
|
All that aside, we needed people to sign up and take shifts. A demo of how to do this was shared up in some of the trainings, like shown here. Where other events have used "SignupGenius" to fairly good effect, here we were back to the more old-skool spreadsheet format, where anyone could make changes and insert their names in for desired session slots. This carries obvious risks, where someone either less familiar with spreadsheet operation or bent on malice could screw things up, but if someone is taking frequent and time-incremental backups that can be minimized. I wasn't; that seemed to be the job of the technical director(s). Obviously this is also greatly aided by having the master event schedule complete, or someone willing to track changes back into this sheet. |
|
When I finally came up for air out of Discord-land and went to sign up for stuff, the spreadsheet was already a bit of a mess. I spent some time one morning fixing it, adding light alternate-shading to the time blocks and putting the "zoom rooms" in numerical order. Because 1> I could, and 2> I couldn't make any sense out of the thing until I did. Some events were at oddball times and/or in different virtual spaces that we didn't have to manage, so I shaded those in light blue which provided additional section markers. Even in a super-zoomed-out view, the days and time-blocks were now obvious. |
| What was missing from this sheet, which would have taken up only one more column that was already in there but all blank, were the names of our HUMAN captioners that Arisia brought in so they could be let into the sessions. Instead, that info was squirreled off in some other spreadsheet that was even more of a mess. This was nonetheless some serious commitment to accessibility, where some of the "AI" captioning services have been disappointing in the past -- Arisia had employed CART translation in some of the real-life events, and with money saved by not needing hotel function space could afford a lot more in-person captioning. People loved it, as it was more accurate and context-responsive, and hosts loved it because setting it up was so much easier than the dumb dances we had to do with the automated services. Bring the captioners in and greet them, assign them as captioner from the meeting controls, done. I didn't envy their job sometimes, having to make sense out of garbled Zoom audio from a participant on a bad network... | |
Hit the [schedule] running
|
In trainings we were shown what the con schedule would look like to people logged into the site with "tech crew" status. Alongside the normal "join" link that everyone would start seeing closer to the actual session time, we would get a "join as host" link [unfortunately, rammed right up against the other one] which would actually launch the meeting/webinar to begin with. Once that was accomplished, we would be off and running independently for the duration of the session as usual, getting our panelists set up and attendees let into the space and etc etc like we'd been doing all along. Part of our in-session job was to try and encourage people to keep the running chatter and even panelists questions in Discord instead of the Zoom chat, but with the understanding that not everybody would be on Discord and they had no other choice. There was no consistent model given for how to work this, however. As a courtesy we would try to cut-n-paste relay relevant snippets as the panel moderator specified. |
|
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. |