rationalize cached values

[chadwhitacre]

Follow-on from #3599.

[chadwhitacre]

Picking up from #3599 (comment), here is where we are and where we're going:

                sum           count        sharing bit
                ----------------------------------------------
current  ~user  giving        —            anonymous_giving
                receiving     npatrons     anonymous_receiving
                taking        —            anonymous_receiving

         Team   receiving     nsupporters  —
                payroll       nmembers     —       

target   ~user  giving        nrecipients  anonymous_giving
                taking        nteams       -

         Team   receiving     ngivers      —
                distributing  nmembers     —

The one change here from the original comment is that I've dropped anonymous_taking. There is no anonymous taking in Gratipay 2.0. Payroll is public, as are the numbers relative to Teams.

[chadwhitacre]

Here's the diff:

• remove participants.npatrons
• remove participants.receiving
• remove participants.anonymous_receiving
• add participants.nrecipients went with ngiving_to (see message on 7306177)
• add participants.nteams went with ntaking_from
• include owner draws in participants.taking
• rename teams.nsupporters to teams.ngivers
• rename teams.payroll to teams.distributing

For each:

• ALTER TABLE
• add/modify code and tests
• UI

[chadwhitacre]

I think as part of this that we should move away from estimating dollar amounts (receiving, taking) based on the future, and instead base it on the past. Why? The past is more predictable than the future. :-)

This may well obviate is_funded (though does payday depend on that?).

I think we should cache last week's actual amount, and an average of the past four weeks. These two numbers will provide a fine answer to the question, "How much will my Team receive this week?"

[chadwhitacre]

Basing receiving on the past instead of the future also lets us avoid the gymnastics we're currently doing to simulate payday every time someone changes their credit card or whatever. It's going to be simpler.

[chadwhitacre]

I guess we can just update all of the numbers once at the end of each payday, rather than having to update them constantly throughout the week in response to various events (payment instruction changes, route changes).

[chadwhitacre]

The downside is that one won't be able to watch drastic movement that happens inside a week. Especially early on, we paid a lot of attention to intra-week movement. I think that Gratipay has matured, and we are ready to lengthen our attention span. Gratipay is intended to inculcate the long view. You'll get to see this week's amazing growth ... on Thursday.

[chadwhitacre]

How about taking and distributing? Those depend somewhat on the income that a Team receives, but are largely in the control of Team members. Those numbers aren't as squidgy as receiving. Should we refer taking and distributing to the future instead of the past? Should we base those on Team members' payroll_instructions rather than on past payments?

[rohitpaulk]

though does payday depend on that?

No, it doesn't. :)

I don't think going back on cached values is a good idea though... When I tip someone, I expect their receiving amount to increase. Similarly if I was a team, I'd like to know an estimate of how much I'm going to receive. This stuff is very useful, @whit537.

[chadwhitacre]

When I tip someone, I expect their receiving number to increase.

Hmmm ... that's hard to argue with. :)

[chadwhitacre]

I'm working through the tests here and realizing that we have a lot of skips and a lot of JSON endpoint tests that are obsoleted by 1.0 and the move away from tips. I'm finding that I want to cut out all that cruft before proceeding here.

[chadwhitacre]

Starting over with an ordered approach: removing anonymous_receiving.

[chadwhitacre]

I.e., taking each diff item in turn, one at a time.

[chadwhitacre]

The remaining test failures get us into @book's questions on #3666.

[chadwhitacre]

To keep this PR under control I think we should have the cached values reflect whatever the current behavior of payday is. If we want to change the behavior below #3666 then that'll be a separate PR.

[chadwhitacre]

Is the javascript dynamically updating amounts properly?

[chadwhitacre]

No! :-)

[chadwhitacre]

I'm also checking the pricing page and the global cta ...

[chadwhitacre]

Okay! Waiting for Travis ...

[chadwhitacre]

😩

[chadwhitacre]

Code and schema deployed, running the cache refresh script ...

[chadwhitacre]

Done! :-)

[mattbk]

!m @whit537!

[chadwhitacre]

Thanks. :-)

[mattbk]

I had a question about the receiving amount, but this explains it:

I think we should cache last week's actual amount, and an average of the past four weeks. These two numbers will provide a fine answer to the question, "How much will my Team receive this week?"

My one supporter is no longer supporting, according to History.

[chadwhitacre]

Here's what we ended up with ftr:

       sum           count             sharing bit
       ------------------------------------------------
~user  giving        ngiving_to        anonymous_giving
       taking        ntaking_from      —

Team   receiving     nreceiving_from   —
       distributing  ndistributing_to  —