Analyze bridges in the "reserved" bucket
I'm interested in learning whether keeping a certain fraction of bridges unassigned, that is not distributing them via email or HTTP, is a good idea. AIUI, the idea was to have a small set of fresh bridges in case we come up with a new distribution channel or want to give out fresh bridges manually. This idea might fail if people who run a bridge that ends up in the unallocated pool decide that their bridge is not being useful. They might turn off their bridge or delete their keys in order to get a new fingerprint and end up in another pool. If many people do so, we might better allocate all bridges to pools directly and start a new pool whenever there's a new distribution channel. Given the high churn of bridges, we might have a sufficient set of fresh bridges in that pool very soon. Also, if we want to give out bridges manually, we might give out bridges from the other pools which may have higher uptime than bridges in the unallocated pool. Allocating all bridges also means we don't have to explain to bridge operators why their bridge is also useful even if it doesn't have any users right now.
(This description comes from #2372 (moved) where we started with the same question, but then focused on making the pool assignments publicly available. Now that we have the assignments we can focus on this question again.)