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


- Jason (JazzyEagle)

On Tue, Aug 1, 2017 at 7:37 AM, Jason Harrer <> 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 <> 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".
>> 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
Dev mailing list

Reply via email to