compute "receiving" more accurately

[chadwhitacre]

Right now we estimate future receipts based on givers who have credit cards on file. We should include givers with a balance. Ideally we would match the actual payday algorithm.

Reticketed from #1118 (though isn't this a dupe?).

[ceboudreaux]

Receiving amount in top right corner does not include take I receive as part of a team.

[cakey]

Team receiving should be visible both personally and somehow as part of someone's profile.

[chadwhitacre]

+1 from @mvdkleijn on #1367.

[rummik]

+1 from me too

[zbynekwinkler]

Any further thoughts on the implementation of this? The payday algorithm isn't described anywhere except the code, right?

The point of the "receiving" number is to look to the future or the past? We could relatively easily show how much user has received during the last payday. If the point is to estimate how much would be received in the next payday, that is not going to be easy (with "kids eat first", attached credit cards, existing balances and such).

[chadwhitacre]

@zwn Maybe if we refactor the Payday object we can use it to compute the receiving amount for a single participant while still being useful once a week to run payday for everyone? The trick here is to balance accuracy and speed. We put that number at the top of every page for every signed-in user. If we can't compute it quickly using the full payday algorithm then we'll need to find some shortcuts. Yes, the code is the best place to go to understand the payday algorithm.

[zbynekwinkler]

@whit537 Even when refactored, to account for teams we would have to get every team the user is a member of and simulate the distribution 'kids eat first'. Before that we would have to calculate how much each of the teams will most likely receive. So not impossible - but is it worth it? Wouldn't be showing the result of the last payday more correct and future prove?

[chadwhitacre]

You know what, @zwn, you're right. That idea came up before and I think it's a good one: let's think about only ever showing last week's actual numbers. That will spare us from ever having to compute estimates at all.

What are the implications of that?

[zbynekwinkler]

@whit537 I think one query for the ts_{start,end} of the last payday and another one in the transfers table should give us the number. Shall I implement it like this? We already query the paydays for the new header implemented for #703, so only the transfers would be a new db hit and that would replace the current hit for the tips table.

[zbynekwinkler]

However, updating the tests is going to be another challenge. What would be the easiest way? Create the users with enough balance, set up the tips, run payday?

[zbynekwinkler]

I've prepared some simplistic tests. Am I heading in the right direction?

[chadwhitacre]

+1 from @ericholscher in IRC PM.

[zbynekwinkler]

I am starting to question the decision #1413. Looking at @ericholscher use case of writing a blog post and watching that number immediately move, I see it has some merit. Thoughts?

[chadwhitacre]

@zwn Good point. It wasn't really a +1 from @ericholscher, now that you mention it. He was wondering why his receiving figure wasn't higher than it was, but he wasn't asking for it to still be what he got last week.

Maybe we want both numbers? Maybe a sparkline or other chart showing progress over time, with the latest figure as a projection? Anyway, out of focus atm.

[chadwhitacre]

For a team the receiving amount is important because it is what members use to determine their take. For example I set up a tip from Gittip to the Aspen team, but there is no cc attached to Gittip so the Aspen team doesn't see the proper amount at the top of the members page.

[chadwhitacre]

+1 from @mmerickel over on #1604.

[chadwhitacre]

+1 from @shanley on Twitter.

[MikeMcQuaid]

👍 from me too, this helps with people who have had others agree e.g. to match all their new contributions.

[chadwhitacre]

+1 from @cczona in private email.

[bruceadams]

+1 from Kyle Simpson, @getify, via [email protected]

[bruceadams]

@getify also says (via email to [email protected]):

May I suggest then that you add an FAQ to this nature, and/or that you consider changing the text to say something to the effect of "receives at least $x.xx", to be more accurate?

[chadwhitacre]

Sounds like @Changaco is interested in working on this. IRC

[chadwhitacre]

I think we should do two things:

• Show actual receipts last week, don't try to estimate at all.
• Implement some sort of "trending" functionality to highlight people who are making a move this week.

Should we get some design sketches going for this?

[pjf]

Show actual receipts last week, don't try to estimate at all.

Yes please! I hope this is relatively low hanging fruit. We can even make it clear in the display that these are historically accurate amounts:

"User received $x.xx last week"
"User gave $x.xx last week"

This would also close the social exploit where someone could pledge thousands of dollars to get on the high-score lists, but then zero it just before payday.

Implement some sort of "trending" functionality to highlight people who are making a move this week.

Nice to have, but I don't think as urgent. ;)

[chadwhitacre]

+1 from @frioux on IRC.

[robsimmons]

+1 for showing last week's receipts somewhere. I'd been confused for awhile as to why some people's "last week's receipts" seemed higher than I'd noticed their pledges ever being. (https://www.gittip.com/ashedryden/ may currently be a dramatic example of this, with ~$50 more in last weeks giving than current pledges.)

I suspect this is more computationally expensive, but what about showing "$#.## in new pledges this week" for people who have received new or increased gittip amounts since the last paycyclething? Might be a reasonable way to address +zwn's (very legitimate, I think) concerns. An asterisk by the new pledges amount might be a good way to link to a public-facing explanation of what on earth is actually going on :)