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
overall.
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.
-Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
