turn the ship

[chadwhitacre]

Last week, Gratipay stopped processing payments because of legal concerns with our old terms of service that became apparent after our processor, Balanced, announced that they're going out of business, and Stripe wouldn't take us. So in addition to migrating our processing infrastructure (#3377), we also have to change our business model at the same time. No 😓, right? :)

We hashed out our new business model on gratipay/inside.gratipay.com#180 and gratipay/inside.gratipay.com#192. This ticket is to track implementation. See also the Pivot milestone.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

I'm stuck thinking about the relationship between individuals, groups, and projects. I think #3337 is the cleanest way to go:

Users optionally have Projects.
Projects optionally have Payroll.

Projects would be what you give money to.

But right now Users are what you give money to. We don't want to drop existing funding streams if we can at all help it. We want to give Users a way to migrate to a Project. Forcing migration before we process payments is okay since we're requiring acceptance of our new terms anyway.

[chadwhitacre]

I'm not sure how to pull off this pivot without #3337. That's a fair chunk of work.

[chadwhitacre]

Let's think about Participants (Users above) and Teams (Projects above).

Currently Teams are a kind of Participant (those with plural number and > 0 takes), but I think we should promote Teams to a first-class citizen with a new teams table.

A Team is a group of people (some of whom may even be Participants) working together to deliver a given product or service.

Teams have Members (Participants of ours who are part of the Team). Some Members are Owners.

(Note that Participants can still be singular or plural.)

Right now, Tips attach to Participants. How do we migrate Tips from Participants to Teams? We basically need Participants to create a new Team, to which we will reattach their Tips.

Since giving to Participants has been ambiguous in regard to products or services delivered, migrating giving to a single-purpose Team will be a judgement call for our users. If I have 100 supporters, and 60 would say they were giving to me because of one product or service I provide, and 30 because of another, and 10 just because they love me, then how should I migrate? I don't even know who my supporters are, so it's not like I can manually review and make assignments ("Oh, this person is a Fizzbuzz user, that's probably why they've been supporting me. Let's move their payment to the new Fizzbuzz Team"). No: I have to guess at the 60-supporter product/service, and migrate all of my giving to a new Team dedicated to that. Then I can make a second Team for the 30-supporter product/service.

[chadwhitacre]

Can a Team give to another Team?

[chadwhitacre]

Can a Team give to another Team?

I think not, but I think the Owner of a Team can give to other Teams. Let's say that Exchange Routes still attach to Participants. The Owner of a Team is a Participant, and that's where the leftover money drains after Payroll, so we still have the chance to offset their giving with their receiving in a given cycle.

[chadwhitacre]

The approach I'm considering is to make new tables teams, subscriptions, payroll, payments that are parallel to participants, tips, takes, transfers. We no longer write to the old tables, but they're available to use for migrating. Migrating happens when a Participant takes the initiative; we're not migrating all tips at once.

[chadwhitacre]

Where do we put Teams in our URL structure? And in our IA, for that matter?

Do we demote Participants? https://gratipay.com/whit537 → https://gratipay.com/~whit537. Does that redirect? Almost certainly, or we'd break lots of inbound links.

But then does https://gratipay.com/~Gratipay redirect back to https://gratipay.com/Gratipay? Do we have a single namespace for Participant and Team slugs, even if we differentiate them in the URL? Probably. It doesn't seem right to allow someone to register https://gratipay.com/~Gratipay. On the other hand, we're saying that we want an Owner Participant for a Team, so I guess we should allow ~Gratipay to be the Owner of Gratipay. Right?

[chadwhitacre]

In terms of IA, I think we're looking at the following changes as the absolute minimum to pull this off this week:

• /$USERNAME/ → /~$USERNAME/
• Add $TEAM at /$TEAM/, with a Profile at top level.
• /$USERNAME/members/ → /$TEAM/payroll/.

[chadwhitacre]

How do Participants register new Teams?

[chadwhitacre]

How about adding /new for that? Then we add /dashboard/teams for the new Teams review queue.

[chadwhitacre]

The first time a Participant with Tips creates a new Team, we should migrate all their Tips to Subscriptions for the Team (with prompting and confirmation, of course).

[chadwhitacre]

This feels good. I like how this is coming together, it's an evolution of Teams, a pretty natural step.

[chadwhitacre]

• replace UI over tips & takes with UI over subscriptions & payroll (promote Teams to first-class citizenship #3400)
• implement UI for making/migrating to a new team
• revise payday to use subscriptions & payroll instead of tips & takes

[chadwhitacre]

• unroll the interaction of number w/ takes
• text fields on teams want to be i18n'd like statement
• implement is_approved
• implement closing a team
• sort out interaction with take_over
• don't forget about the API, especially tips.json
• should be able to search over teams
• don't forget about db self-checks
• don't forget OG headers
• don't forget about fake_data

[chadwhitacre]

After bashing around on #3400 all day yesterday, I'm starting to get a better idea of how to approach this. I've made three clean PRs:

• move profiles to /~username/ #3402 makes room in the URL structure for Teams
• kill pledging #3403 cuts out pledging
• kill goal #3405 cuts out goals

We should be able to clean up tip limits based on number as well. Is there any other code we can simply cut out?

Beyond that, here's a review of work based on looking at a profile (hard, medium, easy):

• Dashboard - Quarter-baked as it is. Copy is all wrong but nothing besides that.
• Profile - Teams section will need to work with new Teams.
• Members - This will be moved entirely to Teams. I'm not sure how anonymous_receiving interacts with this but that's probably out of scope for this ticket.
• Receiving - Still want this, but it should only show payments from teams under the new system. It should also continue to respect anonymous_receiving.
• Giving - Still want this, but it should only show payments to teams under the new system. It should also continue to respect anonymous_giving.
• History - This should show history under both the old and new systems.
• Widgets - Widgets are going to have to change somehow as part of this transition. How?
• Identity - We almost certainly want identity information for any Team Owner. Right now we store this info at Balanced (they verify it with some API we don't know about). Do we need to start storing identity info locally as part of this ticket, even if we don't programmatically verify it yet?
• Settings - I think this is pretty much fine. Notifications looks goofier than every without the "notify patrons" option, but I'm not going to worry about it here.
• Events - No references to other tables here, so I think we're good.

[chadwhitacre]

What should we do with tips.json? I think we should make a new API that uses team id instead, and just let tips.json go 404. How are we supposed to interpret tips to usernames from the old tipping system under the new system?

[chadwhitacre]

In which case, I think I'll rip out tips.json for this week, and reticket bringing back something similar.

[chadwhitacre]

URL structure

1. move /username/ to /~username/ (move profiles to /~username/ #3402)

Reduce Surface Area

1. remove pledging entirely (kill pledging #3403)
2. turn off giving in the UI/JSON (reduce surface area #3406)
3. remove goal (kill goal #3405)
4. turn off taking in the UI/JSON (turn off taking #3407)

Rewrite Payday

1. make new subscriptions, payroll, and payments tables
2. promote _mixin_team to a Team class
3. rewrite payday to use new teams (rewrite payday #3414)

Wire Up Teams

1. application/approval/migration for teams (Team creation #3412)
2. set payment to team
3. set take from team
4. rewrite History

[chadwhitacre]

I have the feeling that I'm going to be doing most of this work myself. I'm not even sure we'll be able to wait for proper review before merging and deploying. I'm at least going to keep using PRs, even if I end up merging them myself.

[chadwhitacre]

I went ahead and merged/deployed #3402, to get the ball rolling.

[chadwhitacre]

From #3406, here's a census of the parts of the user experience that touch the tips table:

• closing, merging, and archiving accounts
• updating team takes (turn off taking #3407)
• adding/updating exchange routes
• setting tips (reduce surface area #3406)
• the pricing, stats, receiving, and giving pages
• tips.json (reduce surface area #3406)
• the old button widget (reduce surface area #3406)

Here's the details:

  _check_tips
  _check_orphans_no_tips

  Participant.update_number
  Participant.clear_tips_giving - close
  Participant.clear_tips_receiving - close
  Participant.update_giving - team takes, exchange routes, setting tips, take over
  Participant.update_receiving - team takes, setting tips, take over
  Participant.set_tip_to - {tip,tips}.json, close, throughout the test suite
  Participant.get_tip_to - tip widget, old button widget, pricing
  Participant.get_tip_distribution - stats, receiving page
  Participant.get_giving_for_profile - giving page, tips.json, close
  Participant.get_tips_receiving - unused!
  Participant.get_current_tips - tips.json
  Participant.take_over - take over
  Participant.final_check - archive, close

  www/about/stats.spt
  www/about/tip-distribution.json.spt

[chadwhitacre]

Alright, let's bring this in for a landing. We have 24 tickets still open on the Pivot milestone, and this is the main ticket.

[chadwhitacre]

I've been looking at site copy (#3398) today, specifically the About pages. I guess I was feeling overwhelmed and that seemed like an easy place to start that will certainly provide value when we drive traffic for #3539. It also solidifies the work we did to standardize nomenclature, and queues us up to revise the Team application in #3677.

[webmaven]

@whit537:

Echoing @ehmatthes comments at gratipay/inside.gratipay.com#251 (comment), I'm using the term "open company" loosely. A non-profit can definitely be "an open company in gratipay's eyes."

So, perhaps 'open organizations' could be an improvement? This would be inclusive of companies, non-profits, co-ops, and (potentially) eventually other more exotic arrangements (such as decentralized autonomous organizations). We can link the term to the glossary, although a tooltip would perhaps be even better.

[webmaven]

It would also likely be helpful if the gratipay and inside.gratipay.com repos were to have 2.1 milestones.

[tshepang]

👍 @webmaven for "open organisations"

[chadwhitacre]

+1 for "open organizations"

[mitar]

Hm, but how does PayPal handle the fact that they keep money in their accounts and not immediately transfer the money? Are they incorporated as a bank?

[rohitpaulk]

Paypal is registered as an MSB (money services business), yes. https://www.paypal.com/webapps/mpp/licenses

[chadwhitacre]

Still, PayPal's licensing applies to the transfer of money, not to the storage of it. As best I can tell, they avoid regulation as a bank in the U.S. largely by asserting that they're not a bank. :-)

We've talked about this elsewhere, I believe. I'm not sure this is the best place for this convo.

[chadwhitacre]

So, perhaps 'open organizations' could be an improvement?

You anticipated Jim Whitehurst, @webmaven. ;-)

https://www.redhat.com/en/explore/the-open-organization-book

cf. gratipay/inside.gratipay.com#672

[chadwhitacre]

We have 24 tickets still open on the Pivot milestone, and this is the main ticket.

We're now down to eight!

[chadwhitacre]

Well, we did pivot another degree, but towards projects instead of open companies:

We still believe in open work, but our new goal is to onboard a million projects with 10% offering open work, instead of ten thousand with 100% offering open work.

Now the Pivot is down to one last ticket: this one. Time to close it out!

Congratulations, everyone! We have successfully turned the ship! 💃 🌻