Improve general ticket sales scramble

[russss]

General ticket sales end in seconds, with the fastest people to refresh getting the tickets. This sucks, but there's not a huge amount we can do about it.

We will be selling some of the tickets for 2020 using a voucher system (see #815), so the aim here is primarily to make it as fair and as smooth as possible for those coming to EMF for the first time.

I'll try and summarise the possible approaches:

Lottery

Any kind of lottery system suffers from the following issues:

• It is susceptible to gaming (e.g. by using multiple email addresses to sign up for the lottery), unless we collect and verify identity data, which is not an option.
• Applying for individual tickets in a lottery is not attractive to people who want to come to EMF as a group, perhaps for the first time; allowing people to apply for more than one ticket incentivises everyone (or at least people with money) to apply for as many tickets as possible and resell them.

So my presumption is against a lottery unless anyone has any amazing ideas.

Queuing

A queuing system may be beneficial in terms of managing load and contention on the capacity lock. But it doesn't immediately solve the issue of the quickest people to refresh getting tickets.

We could randomly select people from the queue, but this is potentially also subject to gaming by people using multiple browsers, where a FIFO queue isn't. This might not be as much of a problem though?

Other Misc Tweaks

• Being able to add tickets to your basket before the sale starts (but this may be annoying to implement because we'd probably need another type of basket which doesn't reserve capacity...)

[marksteward]

I'd like to reconsider the idea of rounds where were alternate between random allocations (to allow everyone a fair chance of getting a ticket) and then letting people with tickets pass vouchers to friends/family. The random allocation prevents the scramble, and we could say the vouchers aren't allowed to be transferred until nearer the event.

There's a lot of overlap between different groups, particularly as people will talk to each other, so maybe an equal three-way split between volunteer, lottery, and vouchers? Using a lottery means we get an estimate of how many people want tickets before the later rounds, but on the flip side probably means more unused accounts in the system.

There's a risk that people won't understand it, and won't care about the reasoning behind it. It might just look fussy or faceless and arbitrary.

Other things that might factor into the final design:

• We still don't want all tickets to go on sale at once. It puts load on us, and people plan holiday at different times of the year
• We want people to be able to "apply" for a ticket at different times of the day and week. It's unfair to have all rounds during the evening or weekend
• We'll want to be able to guarantee tickets/vouchers for invited people, and the earlier the better
• I think we should be more open about how many tickets have been sold, as this affects whether people think it's worth risking
• We could include the diversity question into the lottery stage, so we have a view of how many people express interest but don't follow through
• We could help people arrange to arrive together if they've used vouchers. It could also feed into the village stuff

[russss]

I think you're conflating quite a few issues here - I'd like to keep this issue about public sales rather than any voucher components (which are discussed in #815).

I am unhappy going ahead with a random/lottery sale without solving the issues mentioned in the first post, and I'm honestly not sure it's possible to do so.

[marksteward]

I don't think you can separate these things out. My suggestion is that to avoid the scramble, we have no public sales periods (or if we do, they're right at the end). Instead we have people sign up interest, with the knowledge that they'll be able to bring friends, and use a lottery to allocate at random. It's an honesty system to seed in people who aren't linked to someone who's already going.

[russss]

For the avoidance of doubt, by "public sales" I mean "sales to people who don't have vouchers".

I guess maybe I'm being too pessimistic and we should try some kind of random sale.

[unknowndomain]

If we're worried about groups we should let people group buy/link interest sales.

[Pezmc]

While it's not perfect, the Glastonbury system of "random" i.e. getting a place in a queue and allowing people to place a deposit for up to X tickets, is effective and helps ensure people's friends and family can come along.

We could adapt that to "register for an invite" i.e. lottery, allocate those randomly, and invite people to book tickets for up to X family members as our public sale, rather than relying on a first to refresh wins system.

We could limit the gaming of the lottery by having an entry cost money (a deposit)? To be refunded once tickets have been sold out if you're unsuccessful? It's likely extra work, but I'd like to think it can mostly be automated.

[jellybob]

One possible solution to the issue of groups not wanting to only get a couple of isolated tickets might be a hybrid public sales/voucher system, where buying a ticket then generates a number of vouchers to allow other members of your group to buy tickets. This would probably be something that we'd get people to request when buying a ticket to avoid having a bunch of tickets reserved for people who are actually going on their own.

We'd probably want to release any reserved vouchers before the next round of ticket sales to avoid the entire pool of tickets being drained by people reserving tickets for people who then don't go on to buy one, but I think it has potential to make things at least a little fairer than the fastest form fillers winning.

[SamLR]

Just found we have more notes on this in #643

[marksteward]

First step is to allow previous volunteers to buy tickets, limited to two per person + kids. Does this mean pre-storing email addresses, or do we generate a token per email and then dump them?

[marksteward]

So:

Start outreach and volunteer (orga or last year) issuance now, make them available for x amount of time (e.g. a month). Potentially repeat this depending on uptake. This could be a wider classification of volunteer. Then preannounce scramble dates at various days/times.

Reduce interaction requirement to one click. No price changes.

[marksteward]

As a minimal fix, I'm now pondering a queue designed to issue tickets evenly over a minute, with recaptcha to discourage abuse. Would recaptcha be a blocker?