On 07/31/2017 06:16 AM, mray wrote: > > > 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 > >
While I share the concerns and have expressed them myself in the past, I simply think this doesn't directly counteract the core mechanism. It's perfectly reasonable for people to say, "I'm only up for spending $5/mo on entertainment, but I'll spend up to $20/mo on scientific research" in the same way as saying "I only want to spend $10/mo at Snowdrift.coop". Yes, this lets users potentially weight things along the lines of "Between GIMP and Krita, if the community consensus goes more for GIMP, I'm only in the crowd up to $2/mo, but if the consensus goes for Krita, I'm good for up to $5/mo" If someone doesn't want to support GIMP *that* much, they would drop their pledge anyway manually. But the point is that I agree with the main concern: We don't want people to take the mindset of saying "yeah, I'll give $X to project A and $Y to project B" in the way that feels liks non-consensual non-matching traditional donating. I don't support adding budget categories until after *full* launch (post-beta even). I would like to delay discussing it too much until then. I think it's okay to *consider* offering after we're established enough for people to really get the whole crowdmatching concept. And in light of all the feedback and experience we have after full operations, we may decide that it makes sense to offer. The only point that matters for now is that I've switched from going *out of my way* to make *sure* nobody imagines a per-project budget to simply saying that if some people have that mistaken idea at this time, it's not worth worrying about too much. Any questions that come up, we just can say, "for now and the foreseeable future, we only offer a simple system-wide budget" and we can emphasize the consensus crowdmatching points. So, I think it's okay to say either "there's a budget limit" or "there's a system-wide budget limit" and not worry that we *always* have to say the latter. I'm comfortable enough with the idea that some misunderstanding here doesn't fundamentally break the crowdmatching idea in any way, even though we'd prefer no misunderstanding. I'd rather emphasize the crowdmatching core concept and not worry too much about the budget besides the assurance that there's a limit. The rest should play out when we're actually successful enough for people to hit budget limits. Then, we'll have real-world experience from which to decide things going forward.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
