Sometimes you want to predict a number but don't know ahead of time what buckets to use. Maybe you don't even know what a reasonable upper bound might be. For example, yesterday I created a market to predict how many people will follow Scott Alexander's example and donate a kidney. I realized, after it was too late for that market, that there are better ways to do it and started taking notes for future reference. Then I thought to dogfood it, which is what this market is doing. As I learn about new schemes, I'll add them to the following list.

1. Pre-decided partition

By partitition I mean mutually exclusive and exhaustive buckets. This is what I did in the kidney market. There's technically an "Other" option but it's impossible to be chosen unless the answer is somehow a negative number or something. (It just now occurs to me that technically/theoretically that is perfectly possible!)

2. Overlapping thresholds

Use thresholds for the answers and allow them to overlap ("any number of answers chosen"). Then you can start with a guess at the median and make two answers, e.g., "less than 10" vs "10 or more". For every answer that has enough probability mass to be interesting, refine it by adding a new answer. Maybe you end up with "less than 10", "10 or more", and "100 or more". If the final answer is, say, 200 then both "10 or more" and "100 or more" are chosen as correct. HT @JamesGrugett

3. Branch from "Other"

That's what this market is doing! Stick to "only one answer can be chosen" but keep branching off from the "Other" option. So start with just "One" (or "Zero" if that's a possibility) and "Other" and see how the probability mass gets apportioned. Add new options as desired, always keeping them mutually exclusive and exhaustive. HT evanbd on the Manifold Discord.

4. Remap [MIN, MAX] to [0,1]

Make a standard NO/YES market and resolve-to-PROB based on where the outcome falls between MIN and MAX, interpolating linearly.

Resolution Criteria

I plan to only add new schemes on the Pareto frontier. In other words, if there's no possible scenario where anyone could prefer a proposed scheme to the ones already on the list, then I won't add it. If a proposed scheme is a special case of an existing one then we'll argue about it in the comments. For example, scheme 1 above is in some sense a special case of scheme 3. But unless I hear a good counterargument in the comments, I'm deeming it to deserve a distinct place on the list as a baseline scheme that a normal person would think to use. This is based on my own judgment. Pointing to a real-world use of a scheme on Manifold will probably convince me. The goal is to make a useful list. Only things that actually work on Manifold by the close date count.