On 08/03/2016 04:56 AM, mray wrote:
> On 03.08.2016 12:48, Aaron Wolf wrote:
>> On 08/03/2016 01:27 AM, mray wrote:
>>>
>>>
>>> By definition the carry over is lower than the limit where fees make
>>> sense - I expect this to be low.
>>> For this low amount of money to trigger an unfortunate un-matching the
>>> total would have to be full to the brim already. This will hardly
>>> happen, and IF it happens it is only an indicator of a bad situation
>>> that will soon get an auto-un-match anyway. There is not much to gain.
>>>
>>
>> I was going to make this point myself. I agree, it just happens when
>> we're already approaching the limit, which is already an issue, this
>> just triggers it sooner.
>>
>>> This corner case of a corner case is *NOT* worth breaking the *ONE*
>>> limit the user trusts us with!
>>>
>>
>> I must say, I get *less* sympathetic with your views when they are
>> expressed hyperbolically. Charging 2 months at once instead of in two
>> separate charges does not break the limit or the trust. I actually
>> *agree* with you that the experience is cleaner if we make the limit
>> even harder and have less to explain. When you equate "we have to
>> explain combining two months into one charge" with "we broke the trust",
>> it actually makes me less respectful of your view because I disagree
>> with what you are saying.
>>
>> So, to be clear: when you give exaggerated or even bad justifications
>> for something that might be the correct approach, it makes me more
>> skeptical. So, please, try not to use this sort of hyperbole.
> 
> You're welcome to be skeptical about my opinions. Everything that may
> find flaws in reasoning about the mechanism is a good thing. Don't
> decide on that matter on sympathy please, though.
> 
> But I honestly can't see an exaggeration in my statement.
> 
> We only ask for 2 things:
> 1. what projects to match
> 2. ONE limit where to stop the monthly flow of money
> 
> Given the simplicity of a mechanism like ours I think it is really a
> stretch to give room for interpretation about what "monthly limit" might
> mean. There is no doubt that with a fitting explanation we could make it
> mean anything and charge accordingly and "correctly"!
> But the most straight forward interpretation is:
> 
>  "Just don't spend more than that!"
> 

Right, and I agree that all other versions of the limit are problematic
in requiring explanation such as "we may charge multiple months in one
charge." But describing that as seeming desperate or as violating trust
is not a view I think a all sensible for someone who understands the
system to have. It's just inferior because it requires more explanation
and more potential confusion.

It would just be better discourse between us if you'd say "some people
may see it this way…" or "to play devil's advocate, someone who missed
the explanation may feel some loss of trust…"

Those ways of talking show that you, Robert, someone who understands all
the details, recognizes that there's no desperation or untrustworthiness
and you're just worried about what others may think. It also clarifies
that you are speculating about a possibility (which may not occur). It's
a speculation worth being concerned about.

I'm just saying that describing it that way, as speculation about what
others *might* think, will lead to much better internal discussions than
just asserting exaggerated claims.

> With our background of good intentions and devotion to simplicity and
> clarity I do regard it as a hard break to diverge from those qualities
> and see it as our duty to protect them – especially touching the core
> part that relates to trust between us and the user. Even if we "explain"
> and charge "correctly".
> 
>>
>>> I would want to be able to make a promise to honor the limit *without
>>> any restraints*. We can do that. Not doing it makes us look desperate or
>>> needy. People setting a $10 limit should never find a $11 transaction
>>> fee in their payment processors accounting. No matter what wordplays we
>>> come up on our site to differentiate between "monthly pledge" or
>>> "monthly total".
>>
>> So, in the end, you are right that keeping the limit totally clear means
>> less confusion, less to explain (maybe), and I'm okay with going this
>> way. I think you're simply entirely wrong that it makes us look
>> desperate or needy.
>>
>>>
>>> If we let the user set a limit we need a darn good reason to ignore it
>>> *ever*. This is not a good reason.
>>>
>>
>> Well, again, I think it may just be simplest and best user experience to
>> not combine two month's charges into one if that results in a higher
>> than one-month-limit charge. But I don't doing so is *not* correct to
>> describe as ignoring their monthly budget limit, it's just that it's
>> more confusing to have to explain the slightly weaker form of limit, and
>> I agree that making it the very hardest and easiest-to-explain approach
>> is indeed best.
>>
>> So, here's my proposal:
>>
>> If there is a carry-over: *never* make the carry-over result in *either*
>> over-1-month-limit charge *and* never make the carry-over result in
>> suspension of pledges. Instead, just charge a *portion* of the
>> carry-over that the monthly limit will allow.
>>
>> Example: $2 carry-over and $1 fee and $7.50 of
>> current-month-pledge-values with a $10 limit: Charge precisely $10
>> total. Now the remaining carry-over to be included with the following
>> month is $0.50.
>>
>> Basically: we will charge the *entire* limit (and no more), in order to
>> slowly widdle-down the carry-over. That's the right way to do the corner
>> case. Thus, carry-over will never be a factor for suspensions and we
>> never violate hardest limit version: absolute monthly-charge limit.
>>
>> I see zero downsides to this approach.
>>
> 
> I agree.
> Let's just never go over the limit. I don't even have hard feelings
> about the other details.
> 
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Reply via email to