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