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