How to Run a Ballot Meetup

I ran the Astral Codex Ten ballot meetup in Boston that produced the 2026 primary voting guide. (Previously, I helped run the 2024 and 2025 ballot meetups.) Here’s my attempt at summarizing how I went about doing it, and anything else I thought of that might be useful for anyone else trying to run one.

Note that the way we did this in Boston was pretty paperwork-heavy, in ways that I’ll get into below. I’ll mention more lightweight alternatives when I think of them, but I’m also interested in building an app to automate the paperwork parts and let groups focus on discussion and writing. If you would potentially be interested in using or collaborating on such an app, please join the Discord that I’ve set up for this purpose; I’d find it valuable to hear from potential users and get a better sense of what they’d hope to get from it.

Basic Organizing Logistics

This mostly works the same way as with other kinds of meetups. The one major difference is that you might want to be thoughtful about where and how you advertise it; it’s important to attract people who are willing to apply careful thought to political questions, rather than just blind partisanship or similar. You probably already have a sense of whether your existing group is capable of doing this (and if they’re not, you might want to reconsider running a ballot meetup), so this is mostly a question of where you advertise externally. Think carefully before doing so anywhere high-visibility that draws an unselected audience.

You also need to decide how long you want your meetup to run for. I think three or four hours is probably the right length here (we did three in Boston). Shorter than that probably doesn’t leave enough time to get through the races and referenda and have good discussions of them; longer is likely more than people will tolerate.

I’m also assuming here that you’re doing just one meetup. (There are reasons to consider alternatives, which I’ll discuss below.)

Scope

The question of which races and referenda you should discuss at the meetup turns out to be surprisingly complicated.

The U.S. has a lot of different levels of government, with a lot of different kinds of offices, some fairly obscure. Here in Massachusetts, there are six different kinds of districts just for state elections, before even getting into municipal ones, and the district boundaries often do not align with municipal borders. This makes it complicated to figure out which exact races are going to be on a person’s ballot; they usually have to enter their address into a government website or a tool like VOTE411 in order to answer that.

So you’ll first need to list all the races and referenda that are potentially in scope. This may be relatively simple if you limit your scope to a single municipality, and in some cities that might make sense, but in others (like Boston and the East Bay) it’s more likely that your meetup draws in people from other parts of the metro area, and you’ll want your guide to be useful to them too. I had Claude Code help me write a Python script to do this for Greater Boston; if you’re not technical, you could look to Ballotpedia, or you could just ask an AI to do the whole thing for you and see what happens. I’m now looking at making it so the app I’m building can do this for you; let me know if you’d find that valuable.

This left me with a list of 175 races, since a lot of these districts are small. That’s way too many, but fortunately 140 of them were uncontested, leaving 35 we might want to discuss. Unfortunately, that’s still too many to get through in a three-hour meetup.

What I did here was turn again to AI, asking for a ranking of the 35 races by how competitive they were, so that we could focus on the ones where a reader’s vote was most likely to make the difference. The way I did this was arguably overcomplicated; I used a tool from GitHub to have six different models (all from U.S. labs) make rankings and then critique, incorporate, and ultimately vote on each others’ work. The tool is pretty janky and you probably won’t get it to work if you’re not a programmer-type person; I’m hoping to include a better one in the app. In the meantime, asking a single model is probably safe enough if you’re not the paranoid type. There are still hazards, though; in our case, the AIs completely missed how competitive the MA-08 House primary was (possibly because I didn’t give them web search access and their knowledge was out of date), and so we didn’t cover it, which turned out to be a mistake. But it’s still better than nothing.

Alternatively, you could rank by which races are closest according to prediction markets, though this’ll likely only work for larger and higher-profile ones. One might in principle also want to account for which races are highest-stakes in terms of differences between the candidates; that sounds complicated, though, so I didn’t try to do it.

The other factor is which races the specific people who show up to your meetup are eligible to vote in and are interested in. In 2024, we went solely by this, covering only the races that our attendees could vote in; I imagine a lot of groups will find this idea appealing. I personally don’t like it, because it’s likely to result in odd gaps in coverage, but that’s just my opinion. What we did do, though, was allow people (especially if they had to leave early) to request during the meetup that particular races they were interested in be bumped ahead in the queue.

Note that if you go by attendee coverage, you need a way to compile a list of all the races that your attendees can vote in, and you won’t want to grind your meetup to a screeching halt to collect this information. As explained above, a single district number isn’t enough because of the complicated overlapping districts that exist in most states. This’d mean asking attendees to provide you in advance with either their address (if they’re comfortable sharing it), a screenshot of their VOTE411 results (which aren’t directly linkable), or a link to their sample ballot from the state government website (if your state government has a website that makes this possible, as Massachusetts does). Then you’d need to go through and deduplicate everything. Again, I’m hoping the app can help with this, if there’s interest.

If there are referenda on the ballot, you probably want to prioritize those highest; we’ve found those discussions the most fruitful ones and that they’ve drawn the most interest.

I’m assuming here that you’re only including one state in your scope. Many metro areas (by the U.S. Census Bureau definition) extend into multiple states, but if most of the area’s population is in just one state, then you probably want to focus only on that state for the sake of tractability. If you’re in, say, Kansas City, then you’ve maybe got your work cut out for you.

We also included in our scope the discussion of a political values statement, intended to help readers get a better understanding of what general perspective our recommendations were coming from, and of which primary to recommend people vote in (not relevant for a general election ballot meetup).

Running the Meetup

For fairness’s sake, you probably want to figure out in advance how you’re going to run the meetup, and make this information available to attendees. I wrote up a procedures document in advance, though yours doesn’t have to be that fancy (and also we wound up making a few departures from these).

For the next while, I’ll assume your meetup is in the range of around 8–25 people.

You almost certainly want a moderator to keep things on track. It’s probably best if they don’t participate in object-level discussions. (Skyler Crossman did this.)

You probably also want a note-taker, depending on how your guide-drafting process works (see next section). You can either appoint someone to do this or, if the group’s comfortable with it, use an AI transcription service. (We ostensibly did both but wound up relying exclusively on the human notes, which Jackie Bredenberg took.)

You need to determine how long you want to allow discussion of each race or referendum to go on for. We did five minutes for most of them; I feel that this was likely too short for some races and that a lot of nuance probably got missed, but it’s a difficult tradeoff, since the more time you spend on each one, the fewer you can get to.

We started with the values statement (which we handled by giving each person 20 seconds to say what they thought should be in it), and then went down the list of races, in the priority order given by the panel of LLMs, until we ran out of time; the discussion of which primary to vote in came last. There were some races further down the list that got bumped up because people specifically requested them, in some cases because they had to leave early. There was also one race (Norfolk District Attorney) that we wound up skipping even though it was highly ranked, because nobody already knew anything about it and nobody was able to get any kind of decent grasp of how the candidates differed or what was at stake within the time available. (I tried asking the LLM panel to provide context here, but it didn’t help much.)

After discussion of each race, we voted on which candidate to recommend. Undoubtedly to the disappointment of voting system argument enjoyers, I think the obvious system to use here is to require a simple majority for a recommendation; if no candidate gets a majority, then no recommendation is made. We decided that people who abstained from a vote didn’t count as part of the denominator (though people who voted explicitly to make no recommendation did); arguably this meant we made some recommendations with insufficient consensus, but it did make things go more smoothly.

We recorded how each person voted on each question, and then assigned the writeup(s) to someone after each vote; more on that in the next section.

If you have fewer than eight people, you can probably dispense with a lot of the proceduralism and just do the discussions informally. It may also be possible, in this situation, to start writing up the guide collaboratively during the meetup. If you have very few people, there may be concerns about how representative their views are; we ran into this in 2025 when there wasn’t much interest (possibly because there weren’t federal or state elections that year?) and I wound up writing most of both guides myself, with relatively little opportunity for anyone else to push back (though the people who saw it happening didn’t object). I’m not happy about this but I’m not sure what I should have done about it.

If you have more than 25 people, you may need to split the group to keep discussions manageable. We considered doing this in our 15-person group in order to be able to get through more of the list, but we didn’t manage to figure out a way of deciding who should be in which group, or which group should cover each race, in a way that people were happy with. If you have enough people that you have to do this, then in the worst case you could just make those decisions randomly. If you have an idea that you think is better, I’d be interested to hear it.

One other option, that I haven’t looked into in detail but would be interested to hear from others on, is doing some or all of the deliberation process asynchronously over the internet (e.g., by having people write up their cases in advance).

Writing the Guide

When your meetup is concluded, you will have a voting record and discussion notes; your task now is to turn them into a publishable guide. This is probably the trickiest part of the process. A lot of this section is more of a retrospective than a how-to guide because it’s the part I’m least confident you can just follow as-is.

(Note that, although this section is last, it contains a number of details that need to be figured out and communicated with people before and during the meetup.)

For each recommendation your group has voted to make, you probably want there to be an explanation of why you made it; these rationale statements will be the meat of your guide. Because co-writing is hard, you probably want one person to be in charge of writing each such statement. The obvious thing to do is, after each vote, assign someone who voted in favor of the recommendation to write the rationale statement.

In Boston, we have a tradition (started in 2024 and continued since because it was well-received) that, if a candidate or position fails to win a majority but gets more than one vote in favor, the people who voted for it get to write a dissenting opinion that’s also included in the guide. I feel that this has made our guide richer and more informative, so you might consider adopting this, or something similar. These assignments were likewise made after each vote.

You probably won’t have time to start writing the rationale statements during the meetup, at least if you have eight or more people. In principle, you could have a second meetup for writing them, or you could have a second meetup that authors are supposed to bring their draft statements to, during which the statements are discussed, edited, and ratified; at one point I had planned to do this in Boston. However, this is a lot of overhead, and trying to get people to show up again for the maybe-more-boring part is likely a hard sell. So more likely you’ll do as we did, and have people turn in their rationale statements after the fact, generally a few days later, for inclusion in the guide.

This creates a problem, which is how to ensure that each rationale statement, written by one person over the course of days, accurately reflects the true reasons why the people who voted for that candidate or position during the meetup under time pressure did so. In my opinion, this is the hardest part of the whole exercise. I don’t feel we did a great job of it in 2024; those rationale statements introduced a lot of novel arguments that weren’t brought up during the discussions. To fix this in 2026, I came up with a new process that I feel worked far better, although there’s still substantial room for improvement. The downside is that the process was heavyweight; this is one of the areas where I’m most hopeful the app can help.

I created a template Google Doc for each write-up and asked each assignee to put the write-ups in there within the next few days. Once each one was in, I used Google Docs’ approval feature (not available to consumer accounts, so I had to sign up for a free trial of Google Workspace Business Essentials) to send each write-up to the other people who voted the same way, and asked them to approve it. They could leave comments in the Google Doc to discuss things, but the docs were locked for editing during the approval process. (People could request minor editorial changes which I’d apply manually after the fact.) The goal was to get everyone to approve all the write-ups corresponding to their own votes within the week after the meetup; almost everyone did this, with only one person failing to. (I treated this as though they had granted their approval, but wished I’d come up with a procedure in advance for handling this case.)

This involved a lot of checking and re-checking the status of all the docs over the course of a week, seeing who I needed write-ups and approvals from who hadn’t provided them, and repeatedly bugging those people until they did. If I hadn’t been as obsessive about this, or had had less free time, we probably would have had much lower rates of people completing their write-ups and approvals on time. This is one of the parts of the process most amenable to automation, though, except that there might be a need for human reminders to complement automated ones (but the human reminders can be prompted by automation).

I’m generally pretty proud of the guide we got out of this process. The part I’m least happy with is that I still think the rationale statements were insufficiently reflective of voter consensus. Making any change that didn’t count as “minor editorial” meant invalidating all of the approvals that had already been granted for that write-up and restarting the entire process; after a certain point, there just wasn’t enough time for that. In only one case did we try doing it, and only after the previous version of the write-up had already been fully approved, and that previous version was what got published because we didn’t get enough re-approvals before the deadline. This meant there was a lot of pressure on people to grant approval even if they had objections (I know I personally did this). If I could get the software side of it working smoothly enough, what I’d like to do is instead have the approval process work more like an actual deliberation, i.e., people can propose amendments, vote on whether they get incorporated or not, and then vote on final ratification. Probably it should also distinguish “I’d prefer this be changed but am willing to approve either way” from “I’m not going to approve until either this is changed or I’m convinced to change my mind”. I think this is only feasible with a dedicated app; I think it would have been too complicated for people to follow if I’d tried to do it by hand (we were approaching the limit of comprehension complexity as it was).

There’s perhaps a more fundamental difficulty here, which is that we want the write-ups to be comprehensive enough that people find them informative and trustworthy, but also reflective of the considerations that actually determined the outcome of the vote. These goals are sharply in tension, especially if we spend only a few minutes on each race, and I don't know how to reconcile them. Maybe the thing to do is rely more heavily on people doing relevant research in advance and sharing it at the meetup, or maybe it should somehow be possible for people to change their votes after reading the write-ups, though the details there sound thorny.

I also do not think I did a good enough job planning for contingencies like “what if someone doesn’t turn in their write-up” or “what if someone doesn’t respond to a request for approval” or “what if people can’t reach consensus”.

Late in the process, someone proposed a recommendation for the MA-08 race, which as per above we had skipped because the LLMs underestimated its competitiveness. There was reason to believe that this race might have AI safety implications (which the group generally agreed on the importance of) and so shouldn’t be skipped. I decided ad-hoc that we’d send out the write-up for approval and it’d only be included if a simple majority of all participants approved it (so abstentions did count in the denominator for this one). That didn’t end up happening, in part because some people argued in favor of the opposing candidate. I’m not sure what, if anything, we could have done to handle this better, besides not make the mistake in the first place of skipping an important race; perhaps the bit at the end of the last section, about doing some deliberation asynchronously over the internet, is relevant here.

For the values statement, I felt unanimity was important; if there were things we were divided internally on, then the statement should say that so that everyone could sign onto it. Fortunately this did not turn out to be much of an obstacle; we were all pretty ideologically similar (I would not necessarily expect this to generalize to arbitrary ACX meetup groups). I said in the guide that all 15 participants approved; in reality, 14 did, and I made the call to also assume the approval of the one person who had stopped responding to my messages. I think this was substantively fair, but I wish I’d said in advance that it would be the rule.

After all this was done, I put all the rationale statements into the Google Doc template that I’d drawn up in advance, which included information like links to candidate websites (again, Claude Code helped me with that, though I also did a lot of it by hand). Each author could choose whether to be publicly credited by name. For one person’s write-ups, we included a conflict-of-interest disclosure about their work at a company whose business is exposed to state and local politics, this having been brought up and agreed upon at the meetup. I additionally did a round of copyediting (using the AP Stylebook, which you can get a free trial of online).

I also wrote the introductory section, which included information on how to vote, with applicable deadlines; this is important, so don’t forget it! Ideally, you’d publish your guide before your state’s voter registration deadline, so that people whose interest it captures can act on it; we unfortunately didn’t manage this in Boston because I got started too late. In this case, you’ll want to likewise include information on how to register and applicable deadlines.

Finally, I sent the guide to Scott, who included it in the next Open Thread post.

Outreach to Candidates

We realized that it might be helpful to actually ask candidates for their positions on certain issues, particularly AI safety. We reached out to a few after the meetup, and got some responses, which were reflected in the write-ups.

This was a valuable exercise, but it probably could have been moreso if we’d somehow managed to get the responses before voting. I’m not sure how you’d do that; perhaps have a round in advance where people collaborate over the internet on a questionnaire-like thing, which we’d then send to candidates? What we wound up doing was including a “add information based on candidate responses” placeholder to the write-ups, they got approved with that placeholder in place, and then when the responses came in the write-ups were edited accordingly.

One (fairly long-shot) candidate turned out to have a campaign manager who was already involved in adjacent AI safety efforts (they’re part of AISST at Harvard). That campaign took our recommendation as a formal endorsement which they put on their website. After publication, the campaign manager reached out to Scott (who forwarded their message to me) to suggest that, in future, we do more proactive engagement with candidates and more explicitly play the formal-endorsement game, which is an important part of the electoral process here in Massachusetts. I think they were probably overestimating how much of a real thing we are and how interested other candidates are likely to be in engaging with us (this being part of why I used the term “recommendation” rather than “endorsement” in the guide), but it’s worth considering.

I’m incredibly grateful to everyone who participated, wrote write-ups, and helped organize, including Jackie Bredenberg, Skyler Crossman, Chris Lehman, Adam Hesterberg, John Michael Figueroa, Jason Li, Amin Sennour, Joshua Guo, Mark Lemay, and several others who prefer to remain anonymous.