On 08/12/2016 06:58 PM, Stephen Michel wrote:
> 
> 
> On August 12, 2016 6:54:28 PM EDT, Michael Siepmann 
> <m...@techdesignpsych.com> wrote:
>>  On 08/12/2016 04:08 PM, Michael Siepmann wrote:
>>
>>> On 08/12/2016 03:59 PM, Michael Siepmann wrote:
>>>> <snip>
>>>
>>> Here's what I had in mind, from the "How the limit works" thread:
>>>
>>> On 08/03/2016 06:34 PM, Aaron Wolf wrote:
>>>> 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"
>>>>
>>>
>>> That's what I intended to depict, but I see that how June 2016
>> doesn't
>>> do that correctly and instead depicts a situation that shouldn't ever
>>> exist.  Thanks for catching it, Stephen.  The "widdle-away" approach
>>> means we *can* carry over to the next month to avoid exceeding the
>>> limit, but only from any amount carried over to this month from the
>>> previous month.  I'll update it to depict that scenario.
>>
>> How about this?:
>>
>> http://snowdrift.sylphs.net/f/83aacffd4f/?raw=1
>>
>> I've tried new wording to try to make it clearer, and updated the
>> numbers to show a realistic "widdle-away" scenario for a couple of
>> months.  Fortunately most of the time this complex a scenario won't
>> arise.
> 
> I think that this scenario is really hard to parse. It could also result in a 
> display where you have a carryover from may and a carryover from June 
> displayed in July, and that gets really busy really quickly (especially if 
> one or more are also carried over to august).
> 
> I suggest that we aggregate all carryover charges. The small loss in detail 
> is totally worth the simplicity, imo.
> 

Absolutely! Describing the carry-over from several months with separate
list of carry-overs would be crazy. But the aggregated sum can be
described as month-month e.g. "March-July carry-over". Effectively, most
carry-overs will only happen at the early stage of projects and patrons,
when they first start on the system. A new project with some new patrons
may have a period of carry-overs, and then no more of that going
forward. So, it's just this contiguous set of months that will have
carry-overs in almost all cases.

To cover all possible scenarios, we could just say "carry-over from
earlier months with charges too low to be worth charging" effectively.

In any case, it should be one sum number.

> Any charges that will roll over (the negatives) will always be the bottom 
> item in the list, so it's fairly easy to eyeball the rest of the list and 
> verify that it is below the limit. I'm tempted to put charges from a previous 
> month below fees for that reason, as well, but that feels odd to me. 
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Reply via email to