Mechanism Proposal: Stacked Goals

Starting point:

And additional context:

Let’s explore some incremental changes… :smirk:[1]

  1. Restrict patrons to common goals.[2]

    Instead of picking any number, they’d only be able to pledge @ 1000, 2000, or 3000. Yellow and blue would shift to 1000, and otherwise the system would stay the same.

No more complex evaluations — you know that you’re being matched by anybody who pledged to your goal or higher.[3] edit: although some of this is lost with (3); how complex it gets depends on how much flexibility we give patrons/projects to choose goals/levels.

  1. Only match people up until their goals.

    Green’s pledge ($80@2000) would act like two separate $40 pledges:

    • One towards matching anyone who pledged@1000+.
    • Another towards matching anyone who pledged@2000+.
    • People count towards the highest category they fit into.

    In this case, if a bunch of new patrons pledge@1000 even though it’s already been reached, it would not affect green’s donation level; the second $40 would still be withheld to encourage people to pledge@2000. And anyone who did pledge@2000 would add to that incentive, even if they weren’t actually that ambitious and were just doing it to get extra matching from green.

By pledging to an ambitious goal, you encourage others to be as ambitious, which in turn provides more incentive for folks coming after them. This addresses the problem explored at the top of the post.

  1. Enable spread-the-burden for over-capped goals. Anyone pledging at a higher goal keeps their same total pledge, increasing their matching at higher levels.

    Say a bunch of new patrons pledge@1000 until that goal is 2x fulfilled; ie, without spread-the-burden the project would get to 2000 from pledges@1000 (reminder: this includes part of any pledges at higher levels).

    • Anything pledged@1000 would shrink by 50%
      • Including the first $40 of Green’s pledge, which shrinks to $20
    • The rest of Green’s pledge takes up the slack, growing to $60@2000+

This allows crowdmatching to continue indefinitely at all levels (indirectly). Spreading the burden at a lower goal causes anyone who pledged toward a higher goal to shift some of their pledge into those the goals, where crowdmatching is still active. This results in more matching overall.[4]

It also allows visualizing the goals without awkward “overflow,” along with other nice things.

Optional change: simpler, at the cost of flexibility.
  1. Restrict everyone to the same match-rate.

    This brings us closer to the live version of the mechanism with a per-project limit, but instead of dropping out of the crowd at your limit, you switch to spread-the-burden when you’ve reached your goal (which is automatically calculated based on your limit).

  1. This is the evolution of the multiple-goals ideas I've been hinting at for a long time — excited to finally open this bag of worms :grin: ↩︎

  2. Actually, this is not technically required; we really just need patrons to set goals at round-enough numbers that the math is understandable (e.g. multiples of 1000). ↩︎

  3. The total available for matching is sum<patrons>($withheld). ↩︎

  4. The project gets less money overall, since it no longer receives the overflow. But the overflow wasn't being matched anyway, so there is the same amount of matching happening at that goal remains the same. Meanwhile, there is more matching at the higher goals. In short, non-matched overflow gets shifted into matching at higher goals. ↩︎

Can you boil this down to a description that is short and stands on its own?

We’ll have to start selling this sooner or later – so why not start now to work on a concise phrasing…

I am not going to do that right now.

In our long chat, I decided that I am not going to pursue this for the next iteration of the mechanism. With that, there’s hundreds of hours of work that is more important for me to do than polishing how this is presented.

1 Appreciation

@smichel17 Supposing you seriously consider this proposal, I’d love see this mechanism outlined like the proposal found in the mechanism repo: / Mechanism · GitLab.

I know it takes a lot of time to condense everything to just its moving parts, but it would be helpful to have a single place store (and maintain) and compare mechanism objectively and without discussion.

2 Appreciations