Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Jason Harrer]

Sorry for the late response.  I've been focusing on work lately.

My apologies, as I didn't realize that the crowdmatch code was already
checking for this.  I'm surprised, though, that the decision was made to
hard code the value up front, as I don't think it'd be much more difficult
to add the value to each user in the db, default it to 5, and just access
that variable in the crowdmatch logic.  Even though users wouldn't be able
to change it up front, it would at least set up the framework for the beta
changes.  But, if hardcoding is the way we want to go fine.

I was checking to see if the UI to change the limit has been removed.
Unfortunately, the latest master isn't building, so I can't 100% confirm.
Looking at the template, it appears on quick glance that iko removed it.
Hopefully she did.  If that's the case, then I think this discussion is
wrapped up.

On Sat, Aug 5, 2017 at 10:56 AM, Aaron Wolf  wrote:

> On 08/05/2017 08:07 AM, Bryan Richter wrote:
> > On Tue, Aug 01, 2017 at 07:37:59AM -0500, 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.
> >
> > Can you explain why it's a requirement?
> >
> > As far as I understand it, the page simply has to say that a limit
> > exists.
> >
> > My point, that I'm making here and elsewhere, is that implementing an
> > automatic cutoff is not a necessary step for alpha. The process can
> > remain manual for the time being.
> >
> > There are a lot of other manual things I'd rather automate first.
> >
> >
>
> I agree with Bryan. The requirement is that the limit actually is
> respected, not that it be in the code per se. Since we face little
> real-world risk of hitting the limit during alpha and will know for sure
> if we're approaching it, we're fine. No extra requirement needed for alpha.
>
> For beta, it will matter more because people could then pledge to
> multiple projects and thus approach their limit with fewer patrons in
> the system.
>
>
> ___
> 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

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Bryan Richter]

On Tue, Aug 01, 2017 at 07:37:59AM -0500, 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.

Can you explain why it's a requirement?

As far as I understand it, the page simply has to say that a limit
exists.

My point, that I'm making here and elsewhere, is that implementing an
automatic cutoff is not a necessary step for alpha. The process can
remain manual for the time being.

There are a lot of other manual things I'd rather automate first.


signature.asc
Description: PGP signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Jason Harrer]

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  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 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 

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

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

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[mray]

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




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 07/30/2017 09:07 AM, Stephen Michel wrote:> Here's what I remember
from the discussions a few months back:
>
> On Sun, Jul 30, 2017 at 1:32 AM, Jason Harrer 
> wrote:
>>
>> There are two major concerns with this part of the prototype:
>>
>> 1) This goes against the philosophies that Aaron has talked about
>> numerous times, all the way back to when I first started on the
>> project 3-4 years ago.  He was strongly against the concept of
>> applying a cap/limit at all.
>
> The objection was against a *per-project* limit, not a site-wide limit,
> which I think everyone agrees is necessary to make people comfortable
> with pledging (even if the "pledge amount explosion" scenario is not
> very likely).
>
>> 2) There is currently no back-end support for a limit of any dollar
>> amount.
>
> We knew this. Plan at the time being:
>
> - Adding a limit function in the backend is a priority
> - Until we make an official announcement, we expect pledge numbers to be
> low, so we should have plenty of time before we're getting enough money
> to actually do a crowdmatch event.
> - If for some reason we get to the point of doing a crowdmatch event
> before the limit is implemented, we will enforce the limit manually
> (just check to make sure nobody's being charged over $5.
>
I have a changed view on the limits and it's reflected in the simplified
video script actually.

I think a per-project limit isn't a fundamental problem or a
misunderstanding we need to worry about.

I see the limit plan like this:

A. express that we *have* a budget limit and set it at $5 in the backend
as a starting point

B. make the limit adjustable system-wide (not an alpha requirement, but
if someone decides to do this before the rest of alpha is complete, it's
welcome enough)

C. Long-term plan (in light of real-world alpha experience, and fine to
express publicly as a long-term consideration): offer budget-categories
that users can each define. Let users name a category and put any
selected projects in it. This is comparable to folders/directories such
as how a service like AuctionSniper lets users group a bunch of eBay
items into a folder where you stop once you've won a set number. 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. So, for now we are
FINE with just saying "there's a budget limit" and if someone says "oh,
I can set a budget for each project?" the answer is "for now, it's just
system-wide, but we hope to offer separate budgets like that
eventually". (People could set up multiple accounts to get a similar
effect anyway, but that would mean extra charge accounts, more charges
and fees, and all the hassle of maintaining multiple accounts).

In short: I've DROPPED my big worry about making sure people don't
imagine per-project budgeting.






signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design