By Doctor Science: This is a first draft. I don’t know all the arcane rituals for submitting something to the WSFS Business Meeting, but I hope to get to that in due course.

Proposal: that there should be a permanent Hugo Tech Working Group

This Working Group shall be answerable to the WSFS, either in the form of the Business Meeting, or in the form of some other committee or group.

The Hugo Tech Working Group (HTWG) doesn’t set rules for the Hugo Awards software, it actually does the work (hence the name). The HTWG is not a directly elected group, but it must report and be answerable to elected groups. The HTWG will include:

• one or more “Gurus”: people who had a major role in writing the open-source software currently being used (hi Chris!)
• one or more “Scribes”: responsible for documentation, manuals, and reports
• 1 person from Worldcon N-1
• at least 3 people from Worldcon N
• 2 people from Worldcon N+1

where N is the current Worldcon.

The “Hugo Awards software” is whatever performs the following functions:

1. validates that a given person has the right to nominate or vote. This is a function of the registration system, which is handled by Worldcon N
2. accepts nominations
3. canonicalizes nominations, i.e. makes names uniform
4. calculates finalists
5. accepts final ballots
6. calculates winners

What problems am I trying to solve with this proposal?

One of the (many) shocking revelations in Chris Barkley’s interview with Dave McCarty was that the software McCarty wrote to determine the final ballot was erroneous, and he knew it: “The SQL query from from the data for the ballot counts in each category actually has a fucking flaw and it’s and it’s mistaken.”

I said, “Why is Dave talking about SQL? Is each Worldcon re-inventing the vote-counting wheel?”

Chris Rose/Chris_R/offby1, who’s worked on the software for numerous Worldcons, replied:

in my observation, convention committees all seem to have at least one person on them, in a position of authority, who wants to be the one to invent the software suite to rule them all that will solve all future fannish endeavours henceforth. I’ve seen it result in thousands of hours of volunteer software development in the short time I’ve been in this community, and I don’t foresee it [stopping].

Then Mary Robinette Kowal said she’d learned that McCarty had not only written his own Hugo Awards software, but it’s proprietary, he won’t show anyone else the code.

Unlike what we’ve had so far, the Hugo Awards software (HAS, hereafter) needs to have these characteristics:

transparency: HAS cannot be a black box. It has to be clear to qualified nerds (of which SFF fandom has a plethora) how the results are generated, at each step. This almost certainly means it has to be an open-source project. I understand that many major tech companies have vampiric employment contracts that make it impossible for their workers to contribute to open-source projects on their own time, but this shouldn’t be a limiting problem for the WSFS. We are literally Nerd Central, we can cast a net a little wider than the Usual Suspects and find people who aren’t hamstrung by their employers.

checkability: it must be possible for each step to be audited. It must be possible for a recount to take place, if necessary. This would mean coming up with some way to break the connection between a particular ballot and the person who cast it, something comparable to the separation of a mail-in paper ballot from its identifying envelope.

dependability: if HAS worked in year N, it should work in year N+1. Voters and conrunners should be able to treat HAS as a reliable utility, not a box of surprises.

flexability: it should be possible to make small modifications and extensions to HAS without starting over. This is another reason it probably has to be some variety of open-source project.
Every decade or two technical debt and technological change will probably mean that HAS will need to be re-done, but since the Working Group has a lifespan longer than that of a single Worldcon, the project will have a chance to be done rationally.

I’m making this proposal because I don’t have a horse in this race. I don’t have the technical experience to work on HAS, but I’ve been married to a guru-level database and software consultant for 35 years, I used to develop websites, I understand the desire to be the Mighty Wizard of HAS. But I can see that this desire to be perfect has been the enemy of the good, and at times even the functional.

So one big purpose of a Hugo Tech Working Group is to make HAS boring, to discourage people who have a Grand Vision while encouraging those who just like to do work that gets done. It makes it lower-stakes, maybe even reducing the load on the Worldcon tech team, so they can do a better job and yet still have time for fun, without massive burnout (a gal can dream).

Structurally, people have been talking about splitting WSFS Worldcon functions from Hugo Awards functions. The HTWG would be part of the Hugo Awards half, but mostly staffed by people from Worldcons.

My idea is that most of the HTWG staff are the tech people from current Worldcon N, the ones who set up the software, run it, do the hand-checking for canonicalization, and so forth. There’s one person from Worldcon N-1, whose job is to say “this is what we did last time that worked, this is what we tried that didn’t work.” There are also 2 people from Worldcon N+1, who are there to learn the ropes and to start setting up their instance of HAS.

The real working group part of the HTWG comes when HAS has to be modified. The Gurus are there to know the details of the code, what’s actually easy or difficult to do with this software, Worldcon N-1 person to talk about what changes would have helped most, Worldcon N+2 people to talk about problems they see on the horizon.

Mr Dr Science advises me that this is the sort of situation where holy wars can start, which I’m sure is part of why HAS has kept being changed in the past. I’m eager for advice on how to structure the HTWG to avoid holy wars and other purity contests, so that it keeps focused on: Does this work? Is it transparent, checkable, dependable? Does the HTWG need non-technical members or overseers, for instance?

I eagerly invite comments and suggestions, especially on how to structure this proposal for presentation at the Business Meeting in Glasgow. For instance: can it be presented as a stand-alone, or does it go as a subset of some larger Splitting-the-WSFS proposal? Is the position of Scribe necessary, to do the documentation, put together reports, etc?

Some objections that have already been raised:

When I first made this suggestion on File770, Nicholas Whyte said:

It is my firm belief that institutionalising tech solutions for WorldCons in a standing committee, as proposed above, will be disastrous. It will blur accountability and demotivate volunteers. … The “permanent Tech Team” already exists informally. The pool of knowledge is not wide but it is deep.

I’m not sure what about the HTWG he was objecting to, or if he was talking about something in the discussion more generally.

As proposed, the core of the HTWG is the tech subcommittee from Worldcon N. Yes, it constrains them, by saying “this is the software suite we’ve been using and that you’re going to have to use”, but it also helps them, bringing them in as soon as they win the bid, listening to their needs and suggestions, training them, and making them part of the Tech Team in a way that’s *not* informal and based on friendship networks. Informal networks are great if you’re not being covered by major news outlets, but we’ve passed that point.