On Wed, Aug 31, 2016 at 12:08:54PM -0400, Stephen Michel wrote:
> On August 31, 2016 6:38:46 AM EDT, Bryan Richter wrote:
> >On Sat, Aug 20, 2016 at 10:03:38AM -0400, Stephen Michel wrote:
> >> On August 20, 2016 8:27:09 AM EDT, mray wrote:
> >> >On 16.08.2016 00:03, Aaron Wolf wrote:
> >> >> On
On August 31, 2016 6:38:46 AM EDT, Bryan Richter wrote:
>On Sat, Aug 20, 2016 at 10:03:38AM -0400, Stephen Michel wrote:
>>
>> On August 20, 2016 8:27:09 AM EDT, mray wrote:
>> >
>> >On 16.08.2016 00:03, Aaron Wolf wrote:
>> >> On 08/10/2016 01:27 AM, mray
On August 20, 2016 8:27:09 AM EDT, mray wrote:
>
>
>On 16.08.2016 00:03, Aaron Wolf wrote:
>> On 08/10/2016 01:27 AM, mray wrote:
>>>
>>>
>>> On 09.08.2016 22:43, Aaron Wolf wrote:
On 08/09/2016 12:59 PM, Bryan Richter wrote:
>> Also, I strongly support displaying it
On 16.08.2016 00:03, Aaron Wolf wrote:
> On 08/10/2016 01:27 AM, mray wrote:
>>
>>
>> On 09.08.2016 22:43, Aaron Wolf wrote:
>>> On 08/09/2016 12:59 PM, Bryan Richter wrote:
>>>
> Also, I strongly support displaying it publicly that way "we only
> charge
> if the fee to processor is
On 09.08.2016 22:43, Aaron Wolf wrote:
> On 08/09/2016 12:59 PM, Bryan Richter wrote:
>
>>> Also, I strongly support displaying it publicly that way "we only
>>> charge
>>> if the fee to processor is less than 10% of the total".
>>
>> I will admit that the argument about sudden fee changes is a
On Tue, Aug 09, 2016 at 09:56:30AM -0600, Michael Siepmann wrote:
> On 08/09/2016 08:09 AM, Aaron Wolf wrote:
>
> > On 08/09/2016 06:31 AM, Stephen Michel wrote:
> >> On August 9, 2016 8:59:16 AM EDT, Bryan Richter wrote:
> >>>
> >>> I suggest we specify it as a maximum fee percentage, however,
On 08/09/2016 08:09 AM, Aaron Wolf wrote:
> On 08/09/2016 06:31 AM, Stephen Michel wrote:
>> On August 9, 2016 8:59:16 AM EDT, Bryan Richter wrote:
>>>
>>> I suggest we specify it as a maximum fee percentage, however, to help
>>> adapt to future fee differences. That being
On 08/09/2016 06:31 AM, Stephen Michel wrote:
>
>
> On August 9, 2016 8:59:16 AM EDT, Bryan Richter wrote:
>> On Wed, Aug 03, 2016 at 03:55:42PM -0700, Aaron Wolf wrote:
>>> On 08/03/2016 03:48 PM, Stephen Michel wrote:
On Wed, Aug 3, 2016 at 6:46 PM, Aaron Wolf
On Wed, Aug 03, 2016 at 03:55:42PM -0700, Aaron Wolf wrote:
> 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
On 08/03/2016 06:19 PM, Aaron Wolf wrote:
>
> 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,
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
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
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
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
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
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
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
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
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
On Tue, Aug 2, 2016 at 9:08 PM, Aaron Wolf wrote:
On 08/02/2016 05:58 PM, James Sheldon wrote:
When are transaction fees charged? When you add money or when it is
assigned to a project?
This is assuming a charge-in-arrears approach where we avoid holding
money which
On 08/02/2016 05:58 PM, James Sheldon wrote:
> When are transaction fees charged? When you add money or when it is
> assigned to a project?
>
This is assuming a charge-in-arrears approach where we avoid holding
money which has all sorts of legal challenges once we go beyond our one
project. So,
When are transaction fees charged? When you add money or when it is
assigned to a project?
On Tue, Aug 2, 2016 at 5:21 PM, Aaron Wolf wrote:
> On 08/02/2016 05:05 PM, mray wrote:
>> During the last meeting we discussed details about how the limit works.
>> I just want to
On 08/02/2016 05:05 PM, mray wrote:
> During the last meeting we discussed details about how the limit works.
> I just want to voice my opinion on how the limit should work:
>
> I strongly believe we should make the limit sacrosanct and not touch it
> *never ever*. A decision by the user to set a
On Tue, Aug 2, 2016 at 8:05 PM, mray wrote:
During the last meeting we discussed details about how the limit
works.
I just want to voice my opinion on how the limit should work:
I strongly believe we should make the limit sacrosanct and not touch
it
*never ever*. A decision by
During the last meeting we discussed details about how the limit works.
I just want to voice my opinion on how the limit should work:
I strongly believe we should make the limit sacrosanct and not touch it
*never ever*. A decision by the user to set a monthly limit trumps
"hidden costs" always,
25 matches
Mail list logo