On 08/03/2016 04:24 AM, mray wrote:
> 
> 
> On 03.08.2016 12:52, Aaron Wolf wrote:
>> On 08/03/2016 01:31 AM, Bryan Richter wrote:
>>> On Wed, Aug 03, 2016 at 01:55:44AM +0200, Robert Martinez (mray) wrote:
>>>> On 01.08.2016 23:30, Michael Siepmann wrote:
>>>>> We discussed this in today's meeting.  Here's a revised mockup,
>>>>> also attached in .ods format. This shows payment processing fees,
>>>>> two successive months of carry-over, and an example where a pledge
>>>>> was suspended:
>>>>>
>>>>
>>>> Thanks for clarifying via the mockup. I think it can be simplified
>>>> in several ways:
>>>>
>>>> https://snowdrift.sylphs.net/prototypes/mray/#history_page
>>>>
>>>> * a pledge value/month next to a total/month isn't necessary. It
>>>> only matters what you actually paid that month. So I would only show
>>>> one sum/month.
>>>
>>> This is different from how all receipts and bills work, which show the
>>> sum-of-goods subtotal, then any fees and taxes, then a final total. Do
>>> we want to keep that just so it's more familiar?
>>>
>>>> * items that did not contribute to a months spending can be omitted for
>>>> clarity.
>>>
>>> Hm. I guess we should ask, is the purpose of this page to show *just*
>>> payment history? I don't think so. I think it is a history of
>>> participation within the mechanism. In that case, omitting items that
>>> don't contribute leads to a *lack* of clarity.
>>>
>>> Also, our hope is that we will be able to sum up a patron's
>>> contributions to all their projects, so they would only be hit by a
>>> single payment charge. In that case, it is impossible to get charged
>>> in April, but have other donations roll forward from April to May.
>>> Either a patron contributes to *all* their projects in a month, or
>>> they contribute to none of them.
>>>
>>> So: whether there is one project, or many projects, there is only one
>>> thing that matters: What do we show for a month where a patron is
>>> pledged, and contributes, but is not charged?
>>>
>>>> Suspended projects are not treated different as non-pledged and should
>>>> not show up specially. Notifications can be used to communicate all 
>>>> details.
>>>
>>> I think the same critique applies. If this page is to show a history
>>> of participation, suspended projects need to show up.
>>>
>>>> * I also like keeping the history tab consistent with the running months
>>>> matching tab.
>>>
>>> +1.
>>>
>>> FYI, I have created a US to track this story, and have pasted in the
>>> mockups so far.
>>>
>>> https://tree.taiga.io/project/snowdrift/us/454
>>>
>>> I've named it according to my understanding that we are talking about
>>> a history of participation rather than just a history of payments, but
>>> please consider that point "open for discussion" still. :)
>>>
>>
>> Just to note: I agree with everything Bryan posted. The numbers should
>> be done in a way that's relatively standard. The purpose of the history
>> page is not just to focus on charges but to emphasize the amount of
>> support and the history of the matching.
> 
> What is the difference of "charges", "history of matching" and
> "emphasize the amount of support" in that context?
> To me they easily translate all to the same.
> 
> You seem to want some extra info that wouldn't be MVP.
> 

Yes, I'm just saying that post-MVP we want to make sure history
emphasizes pride in being a long-term patron. The strict MVP could have
no history. The nice-for-MVP history is just the minimum you describe
that allows auditing ("okay you charged this and it went there, got it").

>>
>> Many projects that accept donations have a leader-board of sorts
>> honoring the folks who've donated the most to the project. I would like
>> to see that sort of thing post-MVP. It should especially honor at the
>> top those patrons who have supported for the longest time and emphasize
>> their time-length of support as the main item.
>>
>>

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