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