Add team receiving page

[rohitpaulk]

#3705, #3779

[rohitpaulk]

Screenshots:

Payment distribution:

[rohitpaulk]

I've made the team pages visible to only admins and the team's owner. My reasoning here is that the values we are exposing aren't polished enough to show to the general public. For example, the below graph would make sense to the owner of a team who is aware of charging in arrears - but to others, it'd just look like the number of payments reduced drastically over a week.

Here are a few pages generated from our DB (team names hidden):

[rohitpaulk]

The estimated next week's payment for Gratipay looks out of line though...

Probably a bug somewhere, I'm going to write a few simple test cases to see if something pops up

[rohitpaulk]

The values of unfunded dues are pretty high for most teams, that's due to #3818

[mattbk]

Nice!

[rohitpaulk]

Rebased on master after #3787

[rohitpaulk]

The values of unfunded dues are pretty high for most teams, that's due to #3818

Fixed that in #3876, lets look if these values look better after those changes...

[rohitpaulk]

Before:

After:

[rohitpaulk]

The estimated payment is definitely closer, but still pretty high. The last bar in "Dollars received per week" is ~$275.

[rohitpaulk]

Everything looks right from my side, I guess we'll find out how good this 'estimated' value is tomorrow :)

[rohitpaulk]

I'm going to run a script to generate the estimated values for all teams - And I'll write another one to compare them once we run Payday.

[chadwhitacre]

@rohitpaulk My main concern after one read-through of this PR is that hiding the receiving amount sets a precedent. If we would rather have team receiving be public then we should make it that way from the outset.

[rohitpaulk]

If we would rather have team receiving be public then we should make it that way from the outset.

There's a reason behind this, mentioned at #3873 (comment)

I've made the team pages visible to only admins and the team's owner. My reasoning here is that the values we are exposing aren't polished enough to show to the general public. For example, the below graph would make sense to the owner of a team who is aware of charging in arrears - but to others, it'd just look like the number of payments reduced drastically over a week.

Once I've worked on #3851, I'll work on #3705 (comment) and then this will be ready to be shown to the public.

(said the same over at #3705 (comment))

[rohitpaulk]

I'm not confident that this is a good enough user experience for the public - but it certainly is for a team owner. And we know from our own experience that huge PRs don't make it to production, hence the attempt to make incremental improvements :)

[chadwhitacre]

I'm not confident that this is a good enough user experience for the public - but it certainly is for a team owner.

Right, but it doesn't seem right to roll this out as a private page and then automatically make it a public page at some point in the future. If we roll it out as private that'll become the default by default, and we'll have to add a switch to opt in to sharing it publicly once that's ready. I don't think we want that, because openness should be the default for Teams on Gratipay. I'm disinclined to even offer private receiving as an option, actually.

And we know from our own experience that huge PRs don't make it to production,

Well, that's true. 😞

hence the attempt to make incremental improvements :)

In the past, of course, we've simply "released early and often" even if the UX is half-baked (at best). If we want to start raising the bar on what we're willing to release, then one pattern we could try is to make PRs against PRs—PR inception! <:-) That keeps our batch size small for the primary review queue so we can process it efficiently, while giving us a chance to aggregate work units for release based on user-centric concerns. See saxifrage/cityasacampus#364 for an example.

The three options I'm seeing are:

• Deploy this as-is. Team receiving pages are private by default.
• Make Team receiving pages public, and then deploy. They're confusing for the general public.
• Block this on Improve schema for dues history #3851 and make the receiving page public by default #3705 (comment), using PRs against this PR as necessary.

How do you think we should proceed, @rohitpaulk?

[rohitpaulk]

I'm against option 3, PRs against PRs don't really solve the core problem, which is PRs going stale. Everything works fine as long as we're moving fast - but if someone decides to create the second PR (on top of one) 3 months later, it's still going to be difficult to rebase and update the base PR. What PRs against PRs does solve, is huge PRs that are difficult to review. Since we make our commits oh-so-atomic, I don't think that's a big problem for us :)

Although I think that option 1 is the way to go, both option 1 and 2 are fine with me. Thoughts, @mattbk @webmaven @techtonik @rorepo @kzisme et al?

[chadwhitacre]

I'm against option 3, PRs against PRs don't really solve the core problem, which is PRs going stale. Everything works fine as long as we're moving fast - but if someone decides to create the second PR (on top of one) 3 months later, it's still going to be difficult to rebase and update the base PR.

Agreed.

both option 1 and 2 are fine with me.

I'm fine with option 2 if no-one else objects. To soften the blow we could add a note to the chart like we used to have about "minimum charge upped to $10 in week 8" or whatever. There may still be a note CSS class hanging around for this occasion.

This PR is good work and we should get it out there! :-)

[mattbk]

I see option 1 as a "beta" to allow team owners to give feedback on how accurate it seems ("truthiness," not actual math). If it's deployed privately with a statement that it will be made public in the future (when we decide it's out of beta), it should end up being opt-out, rather than opt-in.

Vote is option 1, second-ranked vote is option 2.

[chadwhitacre]

it should end up being opt-out, rather than opt-in.

Why opt-anything? Options are confusing.

I see option 1 as a "beta" to allow team owners to give feedback on how accurate it seems ("truthiness," not actual math).

I could maybe see that if we turned it off entirely for a while to rework it based on feedback before releasing publicly.

[chadwhitacre]

If we roll it out as private that'll become the default by default, and we'll have to add a switch to opt in to sharing it publicly once that's ready.

@mattbk @rohitpaulk I haven't seen you directly address this. Do you admit this consequence of option 1 yet accept it? Or do you not admit this consequence? Or ... ?

[rohitpaulk]

I haven't seen you directly address this

I think this depends on how we present it... As long as we make it clear (by adding a note, as @mattbk suggested) that we intend to make it public in the near future, we won't be deceiving anyone. If we face significant pushback on the same, it's probably a sign that we should reconsider providing anonymous receiving options.

I see option 1 as a "beta" to allow team owners to give feedback on how accurate it seems ("truthiness," not actual math). If it's deployed privately with a statement that it will be made public in the future (when we decide it's out of beta), it should end up being opt-out, rather than opt-in.

Why opt-anything? Options are confusing.

Shouldn't we consider deciding this based on the feedback that we receive from team owners? Rather than forcing this upon them - why not open this to them and see what they have to say?

[rohitpaulk]

Rebased on master at @ec2c732d822cb446dd8c43540c5a7c3a9ea8522a. Previous head was @673475357000a7f0bf8e5fd4a6fff58843734a0f

[rohitpaulk]

#3980 and #3981 are out, this is no longer blocked.

[rohitpaulk]

Rebased on master.

[rohitpaulk]

Did a bit of browsing through on a recent backup, the charts look okay to me.

[chadwhitacre]

Alright, this is super-rough but we know that. I'm merging in order to keep our velocity up. I've reticketed #3992 for further iteration, still on Finish Team Basics.

!m @rohitpaulk

[chadwhitacre]

(P.S. Also this is read-only so it's low-risk.)