Building consensus on crowdmatching options for a single goal

I like @mray’s thoughts. We should have a logical decision, a box within which options are chosen.

yes, to make choice easier. we are the experts here

I suggest:

  • 1$ so everyone can contribute
  • 5$ typical subscription cost i guess
  • 10$ more ambitious option if you really like the project
  • Custom - don’t limit patrons without good reason

Yes, but it’s not really a restriction becauese of Custom option (So, No?)

don’t limit to whole dollars only for no good reason. when it makes them happy to contribute 13.37$ or 4.20$, let them do that

i guess less that 1$ don’t makes much sense

YES, else it would have a too big impact on a project if they stop donating

consider a patron donating 1000$ each month stops. the project might have to fire an employee because of that!

i guess 100$ has not too much impact and would still be a sane amount to contribute (for me. more wealthy people might see that differently)

but when the project goal is 1000$, that would be 10%. that might be too much impact again. maybe 1% is ok?

So my suggested limit is 100$ or 1% of goal, whichever is less.

In case of a crowd-size goal, use the minimum option 100%? So when goal is 1000 patrons and 1$ is minimum, use 1000$.

WE should decide!

Again, we are the experts that have thought this through. We have reasons for this choices that projects might not value. For example, we promote our platform to be democratic, don’t let projects disable that.

Again, generally, there has to be a good reason to convince me that projects should have a choice here.
Also, less options make our platform simpler for projects and users.

1 Appreciation

I first liked this, because it is only one value instead of 2 in my proposal, but then i thought if it solves the problems i see.

I think with that, a 1000$ donation could be possible.

First patron choose 10$
Second 20x 10$ = 200$, Median = 105$
Third 105$ x20 = 2,100$

This is unrealistic, but shows that it don’t solve the problem.

when the goal is 1000$ and the third patron can theoretically donate 2,100$, it’s more than 200%!!!

And by using less than 20x, it takes only longer to reach crazy high numbers, in theory.

1 Appreciation

I really don’t think putting a specific limit like $100 is a good idea. Percentages make sense because they actually relate to how reliable the funding is. But any specific dollar amounts we come up with are heavily determined by our particular individual perceptions of money. I don’t see how it helps for us to impose our perceptions on everyone else in this way. A percentage relates objectively to how much the funding can be affected by any one person dropping out, but the difference $100 would make vary greatly between different projects. It also adds complexity to have both the percentage and dollar amount limits.

5 Appreciations

I like your arguments.

I use the 100$ for cases where 1% is a lot of money (more than 100$), so a patron donating that much and drops out has a high impact. When a project use every cent of the funding (what they better not do, but keep a buffer), that could mean that they have to fire an employee or can’t pay other expenses. I want to prevent that.

Say the goal is 10,000,000$ and someone donates 1% (100,000$). Can you see that it can cause problems when that is missing?

Everybody wants to prevent projects from losing money. But at the same time we insist on people paying less. And at the same time we agree that we don’t want big single influences that could donate huge amounts of money.

The problem is that any single specific value ($100) of a maximum might be wrong or right in some cases, even when it is just one of two. Having two numbers and an extra rule of which actually applies adds complexity. Having a single value (Percentage, multiples of the average donation, a median, …) that fits seems to avoid this the best.

4 Appreciations

The main reason I see is:

  • Different projects may benefit from different sized suggestions
    • Ex: a program targeted at professionals may expect larger donations, on average, than one targeted at amateurs/hobbyists. It is useful to be able to express this.
  • We cannot allow variation within projects and apply the same rules equally to all projects without giving projects a choice.
    • That choice could be something like, “Here is a set of 10 options; you may choose 5 to show as suggestions” (or more complex options, not worth mentioning). I don’t see any value in this compared to letting projects choose (possibly with restrictions along the lines of “options can’t be too close together”) and suggesting defaults.

I think a pledge below $1 stops making sense. It becomes hard to explain the mechanism without talking in fractions of a cent. And it is problematic if we go with the patron-goal mechanism.

More principles

  • Patrons should be presented with suggested pledge levels
  • Projects should be able to choose their suggested levels
  • If we place restrictions, they should apply equally to all projects (“part of the mechanism”)
  • We should set a $1 minimum donation
  • We should set a maximum pledge (not specified how to calculate it)
    • Edit:[1] The goal of the maximum pledge is to prevent hugely disproportionate amounts of influence on a project (jeopardizing its ability to serve the public instead of a few big donors).

Do we have alignment on these?

  • Fully aligned
  • Not yet
0 voters

  1. Since nobody has voted yet ↩︎

Restricting pledge amounts

…to specific options

Playing devil’s advocate here… I’m mostly convinced that we should have a custom option, but would like to see counter-arguments to this:

If there is no good option, then the choices are an obstacle. On the other hand, so is choice paralysis. If I can afford around $7/month, and the only options are 1 | 5 | 10, then my choice is clearly $5. If I can choose a value, then — assuming that I’m here because I want to donate — I have to make a hard choice about how much I can afford ($6? $8?…)

Offering only a fixed set of choices also makes it easier to express “levels” of support, for projects that may want to offer (rivalrous) perks to patrons at certain tiers. You can approximate that by rounding pledges [down] to tiers, but it’s a lot (socially) simpler to send a t-shirt to anyone giving $20/month or higher when the level below is $10 and you don’t have to decide what to do about the person giving $19.99. This could be partially addressed by…

If not, should we restrict them to a specific granularity (eg, whole dollars only)?

If we go with a $-goal mechanism, sticking with whole dollars[1] makes it easier to express progress and avoid ugly fractions, which keeps things more simple/approachable. Less of an issue if we go patron-based (except for discrete tiers, as above).

For now, we no longer need to discuss default suggested levels.

If my argument in the previous post convinces @davidak, so far we all agree that we should let projects choose their suggested levels. This means offering defaults is no longer necessary / core to the design. So, adding them is a regular feature, competing for time with other features, and we shouldn’t discuss further until we start working on them.

I wrote out some different options before I realized this, below. I think they include all combinations that make sense (except where noted). I went up pretty high; any sequence can be cut short.

Bold+italic last number = find the one like it and continue with its nested bullets (otherwise the list would have waaay too many entries). Ex: 1, 5, 10, 15, 25, 50, 100

  • 1, 5
  • 1, 2, 5
    • 10, 20
      • 40, 80
      • 50, 100
      • 30
    • 10, 15, 25
    • 12, 25
      • 40, 65, 100
      • 50, 100
  • 1, 3, 9, 18, 30
    • 45, 75, 120
      There are more options in this vein, but I’m not going to bother listing them unless there’s interest in this oddball approach. I think it creates better (smoother) increments in terms of budgeting, at the cost of using oddball numbers instead.

…within limits

We need to be specific about our goals, here. Mine[2] is to prevent a single person or small group from having a hugely disproportionate amount of influence on a project. Disproportionate influence is the result of having a patron (or small group) whose support the project cannot afford to lose.

Agreed on different relationships with money — if a Mozilla-scale organization loses a $1000-monthly patron, it’ll hurt, but they have the cash reserves to weather that loss for a while. However, this goes two ways. For an organization like Google or Amazon, losing 1% of their revenue is a Big Deal. For someone making $2500/month, $25 is likely within normal monthly fluctuation. At $5/month, it’s nothing :haha:.

The % limit fails to prevent disproportionate influence at some size because fewer and fewer people can afford to spend money at that scale, so those that can become irreplaceable.

The median limit does better.[3] But it changes over time. What happens if my donation which was allowed becomes over the limit? If I want to give above the current limit, do I have to keep checking back to find a window when I can raise it? There are solutions — mostly the same ones as with changing goals — but together it becomes complicated; I don’t want to spend our complexity budget here unless there is no other option.

Fortunately, I think there are other options:

  • Use a non-linear function to calculate the maximum pledge. Eg, square root or log.

  • Limit the maximum pledge based on the minimum pledge (and allow projects to raise the minimum). Linear (100x) or non-linear (100*log(x))


  1. Or even further restrictions, like “2 significant digits” ↩︎

  2. copied from above; this is why I edited it in, because if we don’t agree on this goal we’ll be talking past each other. ↩︎

  3. The case where it fails is outside our scope: A small number of millionaire patrons giving huge donations (high median, but patrons are irreplaceable). In this case, due to the small number of patrons, there is no collective action problem; the millionaires don’t need crowdmatching to coordinate their donations. ↩︎

2 Appreciations

I voted aligned anyway, assuming this bit gets interpreted fairly. I don’t like the language. There are restrictions possible that would not make sense equally for all projects. I can only really say that I support universal restrictions on a per-restriction basis.

Please remove or clarify this one bullet.

Do you have examples?

Like Blender is used by professionals (earning money with it), but i guess most users don’t earn money with it, because it’s gratis and easy to try out. For those, my default suggestions should be good.

Adobe Photoshop costs $20.99/month. So a program with similar quality (not gimp i guess, lol) could have an additional 20$ option.

We could add the 20$ option on request, when the project actually receive many 20$ pledges.

Do you see another option that would make sense?

I want to keep the options simple to not overwhelm patrons! Maybe max. 5 (including Custom).


What do you (all) think about the option to pledge the current average (more popular concept than median)? When people want to contribute and don’t know which option is right, just do the same as everyone else would be a good answer. (I don’t know how that would be presented)

that is a whole different discussion if we allow that

the math is clear here: no t-shirt

if they know 20$ get’s them a t-shirt and they choose $19.99, it’s their choice to not get that t-shirt

when you would have full dollar, you could ask the same with $19. it don’t makes it easier

@smichel17 so consider the situation that you want to support 10 projects and all have different options. it is always a new situation for you. you might give up because it’s just too much random information…

i would call that putting up obstacles that make people feel conflicted about proceeding

I suggest the principles:

  • All projects should have roughly the same pledge levels

They can request 2 additional, like 20$ and 3$ and we grant it if they provide good reasons. Or request to change some.

For example, a youtube channel about cannabis legalization should have 4.20$ instead of 5$. That number is very appreciated in the culture and having that on a funding platform shows love to detail. That would make the day of every visitor.

I wouldn’t mind if 1% of the projects on our platform end up with a set of completely different values, IF there is still the Custom option where you can choose 1$ (so no one get’s excluded). But don’t make everything a complete mess!

So when i pledge to 10 projects, just one has different values.

  • More than 6 pledge levels are not allowed

Science says humans can’t grasp more than 6 items, they have to count them, which costs 500% more cognitive resources. https://youtu.be/Iwpi1Lm6dFo?t=950

That is, again, what i call an obstacles that make people feel conflicted about proceeding.

1 Appreciation

It applies equally to any sort of acknowledgment.

It also applies to us displaying how many people are giving at what amount, if we decide to do that.

They might not know. Maybe it is just a one-time thank-you from the project, not an ongoing “anyone who pledges at this level gets a t-shirt”.

Sure it does. $1 is a lot different than $0.01. Imagine if the only options were $1, $10, $20, $30… nobody would sincerely[1] argue that they should get the t-shirt because they gave at $10, “just one step” below $20.


  1. Some people might make a bad-faith argument because they want a free t-shirt… ↩︎

For me

is completely clear.

You have to draw the line somewhere. I see no value in discussing this.

Projects are still free to do whatever they like.

I think this adds strange fuzziness and a new dynamic. The average is a moving target even within a month (supposed you take the current average, not the one from last month), I haven’t put too much thought into it, but is seems like it is harder to explain an possibly a lever to game the system.

1 Appreciation

I think this is about a project where many “rich” people have a niche-intereset - like software to operate very big very pricey machinery that generate big benefits. Say MRT-scanner software or software that operates tunnel drilling machines. There aren’t many possible patrons to begin with – but the few that do exist might be willing to give MUHC MORE than 5€ :stuck_out_tongue: .

As said, i have no problem when in such a case, the project can get different options. But i guess that applies to only very few projects on our platform. So the majority can still have mostly the same options.

You’re not explicitly proposing it but: I think having a single mechanism is important. Different ways to treat projects add complexity and tensions.

2 Appreciations

I agree. Every project has the right to ask for different pledge options then the default. We might need rules for accepting it, to be totally fair, but it might be very individual.

Maybe practice shows that many Custom values on projects prefer one particular amount, like 3$, then i’m open to add it to the default.

Like said, my goal is to make it simple for patrons to understand the pledging and having roughly the same options across projects is important for that.

I also want to prevent that a project choose settings that give them less funding in the end than our defaults! They might claim our platform don’t work, even tho it’s their own fault.

So our goal as a platform should still be:

  • All projects should have roughly the same pledge levels
Do you agree?
  • yes
  • no
0 voters

It don’t has to be part of the mechanism. We could even just let the projects set it within limitations in the backend, but show an explanation/warning that we think our defaults should give good results in most cases. Also document in what cases other options make sense.

So i generally agree with

  • Projects should be able to choose their suggested levels

but we have to discuss how that looks like in practice. There has to be limitations!

Given our interest in eventually funding a wide range of public goods, even outside of software, I’m just not ready to say that all project pledge levels should be the same. Projects are so different and so are patrons.

2 Appreciations

A post was merged into an existing topic: Patron based proposal for mechanism 1.1 (instead of $-based goals)