On 03.08.2016 16:50, Aaron Wolf wrote:
> 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 not playing devils advocate, I'm dead serious.
Since you ultimately agree let's not discuss here any further.

> 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.
> _______________________________________________
> Discuss mailing list
> Discuss@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/discuss

Attachment: signature.asc
Description: OpenPGP digital signature

Discuss mailing list

Reply via email to