Re: [Snowdrift-discuss] How the limit works
On 08/03/2016 05:19 PM, Aaron Wolf wrote: > Whenever there needs to be a carry-over, we use the difference > between a month's charges and any outstanding carry-over from > previous to reach up to the max, and thus widdle-away the carry-over > over multiple months if need be. Error in my wording: I meant "the difference between the max and the current month's charges as the amount of any carry-over that is available to be charged in a given month" signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On Wed, Aug 3, 2016 at 8:19 PM, Aaron Wolf wrote: -snip- Though I don't think it's the best, I'm satisfied with this plan for MVP. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On 08/03/2016 04:50 PM, Stephen Michel wrote: > Paraphrasing all my quotes because context is way too long already. > > mray said: >> Having a rollover cause unmatching is an extreme edge case > > If that's true, going over your limit from a rollover is an extreme edge > case, too. > > I think this is an edge case, but not an extreme one. If my limit is $3 > and the minimum is $2, and my current pledges total just over $1.50, I > will encounter the unmatching scenario every other month. That's > possible in any scenario where the limit is less than double the maximum. > > Aaron said: >> 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." > > Disagreed. There is nothing new or confusing about combining charges. Do > you pay for each item at a grocery store individually? No, they're > itemized on the same receipt. Let's present our history like a receipt, > where it just so happens that you can break each item down further. > Example: > > /--April 2016--\ > | | > | Project Z with long name 987$0.98 | > | | > \-$0.98/ > > /--May 2016\ > | | > | Project Name X 6543 $6.54 | > | Project Y 842 $0.84 | > | Payment processing fee: Stripe $0.66 | > | | > \-$10.39---/ > > /--June 1, 2016\ > \---Credit card charge$11.37---/ > > /--June 2016---\ > | | > | Project Z with long name 987$1.08 | > | | > \-$1.08/ > > <--Lorem Ipsum Charges pending*---$1.08> > > *Or, "outstanding balance" or something. > > A little prettiness added here would go a long way towards intuitive > understanding (eg, credit card charge is in gold while other numbers are > in black), but I think this is good enough to communicate the vision. > > mray said: >> >> If we let the user set a limit we need a darn good reason to ignore it >> *ever*. This is not a good reason. > > I've been under the impression we are going to present this as a monthly > limit on your **pledges** (for all intents and purposes, fees are a part > of the pledge). That's totally different than a limit on the amount we > will charge your credit card at one time. > > If we present the history as such (ie, like the example above), I think > it's abundantly clear that no month's charge has exceeded the limit and > thus we have broken no promise. > >> >> So, here's my proposal: -snip- >> >> >> I see zero downsides to this approach. > > I think the downside is, this is significantly harder/more complicated > to explain and to display a history of. > > "April's amount was under the minimum, so its charge has been spread out > between May, June, and July." Certainly do-able. Certainly much less > simple. > I'd like to state my conclusion and move on: Stephen's argument which matches my initial view is so reasonable that it reinforces my impression that Robert's arguments are hyperbolic. Effectively, I see it as unreasonable after hearing the reasonable views from Stephen that the combining of months is as extremely bad as Robert's wording insists. It's as though Robert is refusing to at all acknowledge the reasonable perspective Stephen is presenting. I don't think Robert's approach to express his views helps his argument and is instead leading to this tangential continuation of the argument. Basically: it doesn't help the discourse to just insist on one dogmatic interpretation. But it happens that I think Robert's interpretation is the best one, just not dogmatically so. I want to propose my solution as the *final* one for MVP: The limit is accepted as a hard limit for any charge in any given month, because it makes things as easy and reliable as possible for the patrons. Whenever there needs to be a carry-over, we use the difference between a month's charges and any outstanding carry-over from previous to reach up to the max, and thus widdle-away the carry-over over multiple months if need be. A carry-over of $2 could take two or three months to widdle away if a patron is very close to their limit otherwise. That's not a problem. And the patron gets to just be certain no charge ever will surpass their monthly limit. Even though it is *okay* to combine months it *will* result in the need for care in the explanation and still have room for mistaken understanding. By spreading out the carry-over over as many months as necessary (which will usually
Re: [Snowdrift-discuss] How the limit works
Paraphrasing all my quotes because context is way too long already. mray said: Having a rollover cause unmatching is an extreme edge case If that's true, going over your limit from a rollover is an extreme edge case, too. I think this is an edge case, but not an extreme one. If my limit is $3 and the minimum is $2, and my current pledges total just over $1.50, I will encounter the unmatching scenario every other month. That's possible in any scenario where the limit is less than double the maximum. Aaron said: 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." Disagreed. There is nothing new or confusing about combining charges. Do you pay for each item at a grocery store individually? No, they're itemized on the same receipt. Let's present our history like a receipt, where it just so happens that you can break each item down further. Example: /--April 2016--\ | | | Project Z with long name 987$0.98 | | | \-$0.98/ /--May 2016\ | | | Project Name X 6543 $6.54 | | Project Y 842 $0.84 | | Payment processing fee: Stripe $0.66 | | | \-$10.39---/ /--June 1, 2016\ \---Credit card charge$11.37---/ /--June 2016---\ | | | Project Z with long name 987$1.08 | | | \-$1.08/ <--Lorem Ipsum Charges pending*---$1.08> *Or, "outstanding balance" or something. A little prettiness added here would go a long way towards intuitive understanding (eg, credit card charge is in gold while other numbers are in black), but I think this is good enough to communicate the vision. mray said: If we let the user set a limit we need a darn good reason to ignore it *ever*. This is not a good reason. I've been under the impression we are going to present this as a monthly limit on your **pledges** (for all intents and purposes, fees are a part of the pledge). That's totally different than a limit on the amount we will charge your credit card at one time. If we present the history as such (ie, like the example above), I think it's abundantly clear that no month's charge has exceeded the limit and thus we have broken no promise. So, here's my proposal: -snip- I see zero downsides to this approach. I think the downside is, this is significantly harder/more complicated to explain and to display a history of. "April's amount was under the minimum, so its charge has been spread out between May, June, and July." Certainly do-able. Certainly much less simple. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On 08/03/2016 03:48 PM, Stephen Michel wrote: > On Wed, Aug 3, 2016 at 6:46 PM, Aaron Wolf wrote: >> On 08/03/2016 03:29 PM, Stephen Michel wrote: >>> Clean slate because context is getting absurd and this is important >>> regardless of rollover mechanism. >>> >>> What happens if someone wants to set their limit lower than the minimum >>> credit card charge? >>> >> >> We would not allow such a low limit. The range of allowable limits will >> start high enough minimum to be sensible. > > What is the current thinking on the minimum value? I've seen $2 and $5 > thrown around. > There's no more clarity than that. I guess I'll go ahead and propose we start with $5 as minimum budget. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On Wed, Aug 3, 2016 at 6:46 PM, Aaron Wolf wrote: On 08/03/2016 03:29 PM, Stephen Michel wrote: Clean slate because context is getting absurd and this is important regardless of rollover mechanism. What happens if someone wants to set their limit lower than the minimum credit card charge? We would not allow such a low limit. The range of allowable limits will start high enough minimum to be sensible. What is the current thinking on the minimum value? I've seen $2 and $5 thrown around. ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On 08/03/2016 03:29 PM, Stephen Michel wrote: > Clean slate because context is getting absurd and this is important > regardless of rollover mechanism. > > What happens if someone wants to set their limit lower than the minimum > credit card charge? > We would not allow such a low limit. The range of allowable limits will start high enough minimum to be sensible. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
Clean slate because context is getting absurd and this is important regardless of rollover mechanism. What happens if someone wants to set their limit lower than the minimum credit card charge? ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
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
Re: [Snowdrift-discuss] How the limit works
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
Re: [Snowdrift-discuss] How the limit works
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!" 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. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
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. > 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. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On Wed, Aug 03, 2016 at 10:27:18AM +0200, Robert Martinez (mray) wrote: > > >> On 08/02/2016 06:48 PM, Stephen Michel wrote: > >>> I think the cleanest initial way to go is "No more than $limit will be > >>> added to your outstanding balance each month." That is, carried over > >>> matches should *not* be counted towards your monthly limit, but fees > >>> should, in their entirety. > >>> > > 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 think this is very reasonable, and I totally agree with mray's way of framing the idea of a "limit". I.e. I think it should be stated as, "This is the maximum we will charge your credit card on any given month." So simple. Anything else is really hard to phrase clearly. Stephen said it pretty well: > I think the cleanest initial way to go is "No more than $limit will > be added to your outstanding balance each month." But even that has to be clarified: > That is, carried over matches should *not* be counted towards your > monthly limit, but fees should, in their entirety. Basically the only way to say it with complete clarity is, "Your limit is fuzzy". :) > 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. This, I disagree with. IF we could somehow make the situation totally clear, I would be open to providing the behavior in an opt-in way. It is not necessarily "desperate" or "needy" to give people the option to manage their budget in the way Aaron and Stephen would like. However, I personally find it unlikely we'd hit on something absolutely clear and understandable. There are other ways to handle it, anyway. E.g. maybe the best thing to do is neither exceed the limit nor suspend a pledge, but just charge them $LIMIT and call it good! Or, maybe the best way to provide the option is to HIDE it until the event actually occurs! Then you could tell the user, "Look, we had to / because you rollover from last month PLUS your contribution from this month was greater than your limit. You can fix this by increasing your limit, or by making a one-time monthly payment over your limit, or by choosing to call your limit a "contribution" limit, so your rollover balance doesn't count towards your limit". Yeah, that's terrible. Let's just stick with the limit being a hard limit. Remember that most (Americans) have less than $1000 savings. I'm barely over that number myself, now. If we really want to support people of all economic means, we can't expect them to comfortably plan a year's budget in advance, or even three months' budget in advance. I need a monthly limit to be a hard limit. signature.asc Description: Digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
Re: [Snowdrift-discuss] How the limit works
On 03.08.2016 04:13, Stephen Michel wrote: > On Tue, Aug 2, 2016 at 10:03 PM, Aaron Wolf wrote: >> On 08/02/2016 06:48 PM, Stephen Michel wrote: >> >>> I think the cleanest initial way to go is "No more than $limit will be >>> added to your outstanding balance each month." That is, carried over >>> matches should *not* be counted towards your monthly limit, but fees >>> should, in their entirety. >>> >> >> Well said. Even though I have some willingness to defer to Robert and >> see his view… > > Me, too! Curious about Michael's view as well. > 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. This corner case of a corner case is *NOT* worth breaking the *ONE* limit the user trusts us with! 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". If we let the user set a limit we need a darn good reason to ignore it *ever*. This is not a good reason. signature.asc Description: OpenPGP digital signature ___ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
