On 30.07.2017 20:24, Aaron Wolf wrote:
> ... Because
> it's user-adjustable, they could make per-project budgets or choose to
> budget separate amounts for music, art, software, etc. as fits their
> priorities.
> The key point is that there's nothing wrong with C.

The way I see this kind of "fitting their priorities" is in conflict
with our goal to use consensus as a lever in crowdmatching. Limits on a
per-project or per-category basis are in direct contradiction with the
idea to let a consensus decide, as it decreases the power structure we
set up in the first place. One _already_ has ultimate control over
supporting a project or not – and can make use of _that_ tool inside our
mechanism to reflect on personal priorities.

I imagine the most useful application to multiple limits would be this
scenario: There is an inverted interest in projects compared to their
current success. So there are 2 questions:

 1. How do I support the "big" one just a little?
    You don't! It obviously is bigger than you feel comfortable, you did
    stick with it long enough. Drop your pledge, your work is done.
 2. How do I support the "small" one more?
    You don't! Projects grow by consensus, so talk to people and make
    them join. As long as _you_ stick to it your work is done.

In both cases the mechanism makes people spend *less than they would*
but encourages willingness to keep sticking to projects, donating more

Also per-category limits are problematic due to unclear assignment. It
would start to give benefits to projects that "cover" more categories,
raising the question who has the power to assign them – and by what
metric. It also complicates things to have more levers in general.

But my key point remains:
Priorities should be consensus.
Support should be choice.


Attachment: signature.asc
Description: OpenPGP digital signature

Design mailing list

Reply via email to