Sorry, one last piece for the design team: Because the discussion was that we will hard code $5 limit for alpha, I need a revised prototype that either completely removes the UI for changing the limit OR disables this UI (with a note for the site users to understand that the feature is forthcoming).
Thanks! - Jason (JazzyEagle) On Tue, Aug 1, 2017 at 7:37 AM, Jason Harrer <jazzyeagl...@gmail.com> wrote: > Not sure how the dev list got removed, but adding it back in at this point. > > It sounds like there was consensus on this overall limit (just not project > limits). That being said, I'm going to open up a ticket on GitLab so we on > the Dev team can track adding that in. This is a requirement before we can > get the Dashboard page finished. > > Thanks, all, for the discussion!! > > - Jason (JazzyEagle) > > On Mon, Jul 31, 2017 at 11:32 AM, Aaron Wolf <aa...@snowdrift.coop> wrote: > >> 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. >> >> >> _______________________________________________ >> Design mailing list >> Design@lists.snowdrift.coop >> https://lists.snowdrift.coop/mailman/listinfo/design >> >> >
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
