How Many BC Staff Does It Take To Run a National Fencing Tournament?

I realized from some of the comments on Fencing.net after my Playing With Numbers post that there are still a lot of misconceptions about how the bout committee works. One comment suggested that a more useful statistic than the ones I’d come up with would be the number of bout committee staff per total fencers—that more BC staff would make tournaments easier to run. Another suggested that splitting the hall in half and having two separate BC tables and staffs would ease tournament operations.

Neither is true.

(Don’t think for a minute, though, that we don’t need more BC staff. However, what we need is a larger pool of qualified staff to hire from, not more people up on the platform at any given time. We need more staff so we have time to train current staff to handle jobs like lead computer and BC chair, and time to train new people at the entry level. With more regional tournaments, we need that larger pool to help those organizers staff their events—we ought to have (and are already planning) a BC staff list like the referee list the FOC has on FRED.)

For a typical NAC, we hire a BC chair, a computer lead, three computer operators, and three table staff. If the NAC is very large, as the November and January NACs were this season, we’ll add another table person. If there are many events—say, more than 18 over 4 days, as in March this season, with all those Vet age-levels—we’ll also add a fourth table person. If there are team events, as at JOs or the March NAC, we’ll hire both a fourth table person and a fourth computer operator, because teams are run on a separate computer at a dedicated floor-level team table.

During the week or two before the tournament, the BC chair and computer lead use the strip management spreadsheet (which gives us the number of pools, DE bouts, and estimated times for each round of each event, among other useful information), to plan the staff schedule, which is sent out to all staff a few days before the tournament. Usually, computer staff each day work one computer with all the events in a single weapon. Table staff assignments vary a bit more—one person might work a single huge event, or one morning and one afternoon event, or one morning and several simultaneous small afternoon events.

The BC chair and computer lead normally fly in late Wednesday or early Thursday to be able to work on set-up day at the venue, usually along with a couple of other BC staff whose flights are early enough, unpacking the big black BC crate (just like the ones strips are shipped in). The computers are unpacked and the network set up: there is a master computer and three laptops set up as slaves; if there are team events, another laptop is set up as a team computer for when it will be needed.

(On tournament days, you’ll usually see quite a few more computers up on the platform. Tanya has one with access to Railstation, so she can check (and correct) entries and fencer profiles. The BC chair and computer lead usually bring their own laptops—I use mine to run the strip management spreadsheet for planning throughout the tournament. The head referees often bring their own machines, too. This proliferation of electronics got so bad, what with all the referees who want to charge phones or other devices, too, that this season we seriously upgraded our power strips; the tournament computers are always on a separate circuit from everything else.)

Here’s how an event typically runs:

Before the event closes, the table staff person (we’ve never figured out a good title for this position—event manager? competition coordinator? generic BC person?) retrieves the event sign and bio forms from the event folder, picks a marker color for the event, and stakes out a place at the BC table to hang the sign and set up the table side of the event. At close, she (usually a she, though by no means always) receives the printout of the no-shows from the registration desk and calls them over the PA system. Once that’s done, the list is given to that weapon’s computer operator to withdraw the no-shows, update the seeding list, and create the format sheet.

When the final seeding and format sheet are printed, the operator gives them to the table staff for copying and posting; once it’s posted, she announces that it’s up. Meanwhile, the computer operator sets the pools, checking for unresolved conflicts and that the larger pools are the higher-seeded pools. If solutions to the unresolved conflicts can be found within about 20 minutes, that is done; otherwise, they are left standing as unresolvable. (This process can be far more complicated than it first looks, requiring frequent reference to the seeding list and multiple cascading swaps.) Then a seeded copy of the pools is printed and given to the referee assigner, and a randomized copy of the pools and an alphabetical pool list are given to the table staff. The BC chair, by this point, has informed the table person of the strips her event is assigned to, and those are penciled onto the pool assignment sheet before it is copied and posted. (We prefer to post the seeding and pools separately, especially for point events, in order to allow a bit of time for fencers to verify their final seeding; unfortunately, few take advantage of the opportunity.)

Once the pool and strip assignments are posted and announced, the table person adds the strip numbers to the pool sheets, which she’s already marked with the event color to distinguish from the other events running that day. We usually try to spread any pools of 6 around among the 7s, to allow double-stripping the 7s more easily once the 6s are done. Then, all that’s needed are the referee assignments; some assigners (most, so far this season) are fairly quick at this, while others can take 30–40 minutes to allocate 50 or 60 referees to 30 or 40 pools. On occasion, the referees have not yet finished their morning meeting by the time the BC has events ready to go; some head referees make a point of getting to the platform in plenty of time, while others are not so conscious of the passage of time and therefore get calls from the BC chair asking if they are on their way yet.

When the assigner provides the referee list, the table person adds the referee names to the pool sheets; for a big event, we often split the list, and two or even three people will copy the referee names. Then the referees are called to pick up their sheets, and for the next 5 or 10 minutes, they’ll come in person or call to ask for second calls on fencers who’ve not yet shown up. Once the fencing is underway, the BC staff—both computer and table sides—for this event are free for most of the next 90–150 minutes, depending on the weapon.

What do we do with the free time? Read email and web-surf for those with connected devices, play computer games, read books, knit or cross-stitch, make group coffee runs if there’s a Starbucks or Peet’s in the convention center, shop at the vendors in the hall, work on other fencing matters (check seeding for the next day’s events, create training materials, other projects). Sometimes we even go watch fencing.

Ideally, about halfway through the pools, the table staff will tour the pools to see how many bouts are left on most strips and whether any have fallen significantly behind the rest, in which case, the assigner is informed and extra referees might be sent out to take bouts, if there is an extra strip available. Some assigners—but not all—keep a close watch on their events and handle this themselves. Sometimes, though, head referees get pulled into what we fondly refer to as “Things” (as in, “Sharon got called out to a strip for a Thing”)—requests to observe a particular referee or mediate a rules dispute or see that a black card is handled properly, so it never hurts for the BC to keep an eye on progress, too.

Once the pools start coming in, the table person checks them off on her master sheet and hands them to the computer operator for entry. Once all are entered, the operator prints out the round results, on which the table person draws a line between the ups and outs if there is a cut, and gets it copied, posted, and announced. While that is done, the operator prints the DE tableaux, once with divisions for the assigner and one without for posting. The assigner and the chair have usually already decided on the number of strips to be used for the DEs and how they will be grouped (in pods, in pairs or (preferably not) as singles), so the table person writes the strip assignments on the table and gets it copied, posted, and announced, too.

Meanwhile, back at the computer, the operator prints out the bout slips (at 4 per page, a full 256 table would be 32 pages for the first round alone), marks the sheets with the event color, and slices and sorts the bout slips in stacks for each bracket of the table, the process we refer to as “slicing and dicing.” When the assigner gives her the tableau with the referee assignments, the table person makes two copies and returns the original to the assigner. One set will be used at the table for recording bouts as they come in; the other is split up and given to the assigned referees with the bout slips for that section of the table.

After the slips have been sent out with the referees, the table person organizes her tableau. Most of us lay the pages out vertically in pairs—a table of 128 prints out in four pages, so pages 1 and 2 would be on the left and pages 3 and 4 to the right. The table person then numbers the bouts on the tableau (XSeed puts bout numbers on the bout slips but not on the tableau, so if we want to match them up, we need to do our own numbering) and then sorts the slips for each round into quadrants (or octants, in the case of an 8-page table of 256) so that there’s a stack for each page.

As bouts come in, the table person verifies that the winner is actually the fencer the slip says it is (you’d be amazed at how many fencers sign slips that say their opponent won), records the winner and the score on the paper tableau, writes up the next bout slip if there is one, and stacks the returned bout slips for the computer operator, who usually comes to pick them up more often than the table person gets a chance to take them over to the operator.

Why do we even run the paper tableaux? Why don’t we just enter results directly into the computer? When there are four or five events at once in the same weapon on a single computer, there’s less waiting for the fencers if there are separate lines to turn in bout slips for each event. It’s easier for the computer operator to enter the data accurately if she’s insulated from dealing directly with several hundred fencers. And with all the paper we produce, even marked with its distinguishing colors, it’s easy for bout slips to be misplaced, and the paper tableau gives us an additional record of each bout in such cases, rare though they are.

A table of 128 (or fewer) can be run easily by a single person; using two for an event that size is overkill. Only if we’ve got a BC trainee will we split a 128 table, so they can see how the event is done without it being overwhelming. For a table of 256, it’s nice to have two people for at least the early rounds of the DEs—8 pages of tableau is a bit of a stretch for one person to cover, though it’s nowhere near impossible. Sometimes, if there aren’t too many other things going on, we’ll have a computer operator or a volunteer act as a concierge of sorts, to check fencers’ bout slips as they arrive and direct them to the proper half of the tableau. (For a table of 512, which the BC has done once and hopes never to do again, we’d need at least 3 people—preferably 4—to run the 16 pages of tableau, and a concierge would be a necessity rather than a luxury.)

But those extra bodies are only useful for the first few rounds. From time to time, I’ve run a 256 saber table alone, and it’s always a rather breathless experience getting through the the first few rounds, because the bouts just keep coming and coming. (But it’s fun, too!) Big tableaux in foil and epee are easier to keep up with, because in those, the fencers tend to come in small waves—the bouts are longer and more of them go to time. But by the time any event fences down to the 64, one person is plenty for running the table. Getting the strips and referees assigned for the round of 8 is a snap (though less so than it used to be for events using replay these days); once the fencing is completed, all the table person needs to do is arrange and mark the bio forms according to placement for the medal presentation and then make sure the bio forms are returned to the computer operator for the event folder.

For tournaments with many smaller events (in Detroit we held 44 events), it’s common for a table person to run two or three events simultaneously. When events are only two or three pools, if that, and the DEs fit on a single page, it’s easy to run multiple events as long as each has its own color, and it’s far less stressful than adding extra people to the crowd already on the BC platform.

But what about that idea of having two separate BCs in the same hall? Wouldn’t that solve the crowding problem? I’ll talk about that next time, along with running teams and a few other ideas.

Advertisement

5 Comments

Filed under Fencing

5 responses to “How Many BC Staff Does It Take To Run a National Fencing Tournament?

  1. Andrew Lambdin-Abraham

    Meanwhile, the computer operator sets the pools, checking for unresolved conflicts and that the larger pools are the higher-seeded pools. If solutions to the unresolved conflicts can be found within about 20 minutes, that is done; otherwise, they are left standing as unresolvable. (This process can be far more complicated than it first looks, requiring frequent reference to the seeding list and multiple cascading swaps.)

    There has got to be an algorithm that can be defined as officially correct, accounting for all the rules of seeding and deconflicting. We need to find it, publish it, and have it adopted by all US tournament software (at least as an option) so that we know conflicts are always dealt with properly.

    Of course, this wouldn’t handle the massive number of fencers with incorrect or not provided data, but once we have the algorithm as justification we can start really working on data integrity.

  2. I don’t know—with all the variations in event size and the number of protected fencers, and the number of possible clubs and clubmates, it may be that there are in fact some combinations for which there truly is no solution.

  3. R

    Thanks. Gives insight and ideas for running local events.

  4. Peter Gustafsson

    Mary wrote:

    it may be that there are in fact some combinations for which there truly is no solution.
    —-

    Well, of course, if there is at least one club that has more entrants than the #poules, then a club conflict is impossible to avoid. However, that is so obvious so that I can not believe that Mary meant that. Tell us: what do you mean by the more difficult-to-envision cases without solutions?

    • No, that was just careless wording to recognize that some people do seem to believe that all conflicts can be resolved, which is clearly not the case. XSeed, however, has a hard time both protecting the top seeded fencers and avoiding conflicts, so there are some conflicts it doesn’t fix that humans can resolve, but often only with the aforementioned cascading swaps.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s