opened
mattbk
username_0
Stub out a PR for changes.

Related milestones:
- IG: https://github.com/gratipay/inside.gratipay.com/milestone/9
- G: https://github.com/gratipay/gratipay.com/milestone/22
Edit TOS to decouple payins and payouts
issue
created
mattbk
username_0
The way this reads to me is that TWYW is not required, only optional.

That leaves the open work descriptions. Are we loosening "open" to mean "transparent" (as in https://github.com/gratipay/inside.gratipay.com/issues/432#issuecomment-243245667)? If so, how do we allow Level 0--is it enough that the _goal_ of Gratipay is to encourage Level 0 Teams to increase openness?
comment
created
mattbk
username_0
If I get a chance I'll try to work Levels 1-3 in there, otherwise anyone else is welcome to try.
comment
created
mattbk
username_0
Or do we drop "open" entirely, and leave that under [brand fit](http://inside.gratipay.com/big-picture/brand/), with the intention of later separately adding in official support for levels of openness for teams that are approved under brand fit?
comment
created
mattbk
username_0
Closing in. Need to define "Take-What-You-Want" payouts, or leave TWYW out and leave payout method open-ended.
comment
created
mattbk
username_0
from https://github.com/gratipay/inside.gratipay.com/issues/432#issuecomment-243937519.
comment
created
mattbk
username_0
I think we can leave TWYW out of the TOS.
comment
created
kaguillera
username_1
Looks good to me...do have to get it cleared by our legal department 😉  before we merge this??
comment
created
mattbk
username_0
Yeah, we said we'd [send a version](https://github.com/gratipay/inside.gratipay.com/issues/432#issuecomment-243522286) to look at. I think the idea is to get all the Decouple PRs ready to go and then merge them all at once (this milestone spans multiple repos, otherwise I imagine we could do it as one PR).
comment
created
kaguillera
username_1
I figured that we would have wanted to finish the Decouple PR before making this public...so I guess this is blocked for now then.
comment
created
whit537
username_2
Rebased on latest master. Previous head was f8d5a22f2d66d1e846962a3b554cd3ea3571c58c.
comment
created
whit537
username_2
Hmmm ... so "Teams" doesn't really fit anymore, is one thing. That made sense when we required open work, but for "teams of one" shouldn't we just call them something besides teams?
comment
created
whit537
username_2
Maybe "Project" instead of Team?
comment
created
mattbk
username_0
"Project" seems pretty standard and self-explanatory. Does it cover "teams of one" who do multiple things? E.g., "Alice's Truckstop, Shoe Repair, and Gumball Factory" isn't a "project," it's another type of entity.
comment
created
whit537
username_2
"Organization"? "Receiver"?
comment
created
whit537
username_2
When a team of one signs up, they don't want to sign up twice (Participant and Team). They want to sign up once and start accepting payments. Hmm ...
comment
created
whit537
username_2
Do we wanna get into https://github.com/gratipay/gratipay.com/issues/3852 here?
comment
created
whit537
username_2
On the other hand, we do have bbatsov with ~~three~~ four(!) teams:

http://gratipay.com/~bbatsov

https://gratipay.com/cider/
https://gratipay.com/rubocop/
https://gratipay.com/Prelude/
https://gratipay.com/Projectile/

That's a pretty clear "person" and "project" distinction.
comment
created
whit537
username_2
At one point I think I suggested "Brand" as the thing that receives money. Would that cover CIDER as well as Alice's TS & G?
comment
created
whit537
username_2
The Participant is really about the _legal_ entity, the "Alice Enterprises, LLC" that is _DBA_ "Alice's Truckstop, Shoeshine, and Gumballs"
comment
created
mattbk
username_0
bbatsov seems to have made the explicit choice to [do what we intended and] make a team for each project.

We have at least a few people under "blocked by 432" like https://github.com/gratipay/team-review/issues/122. Some of the comments on those teams have been "I don't even know if any of my tiny repos are going somewhere, so why set up a team for each one?"
comment
created
whit537
username_2
Except that the Participant _does_ also have a social (brand) identity, especially once we get into https://github.com/gratipay/gratipay.com/issues/236.
comment
created
whit537
username_2
Well, I don't think we want to get into a deep rabbit hole trying to change our database model here (like trying to fold Teams back into Participants).
comment
created
whit537
username_2
Renaming "Team" to "Project" would still take some work, but not as much.
comment
created
whit537
username_2
As I skim through the team review tickets that are [blocked on 432](https://github.com/gratipay/team-review/labels/Blocked%20on%20432), I am reminded that our purpose here is to remove friction in our receiver onboarding. We've got the dial tuned too high, we need to relax it a bit. Yes, that will create pressure in terms of anti-fraud ([cf.](https://github.com/gratipay/inside.gratipay.com/issues/820#issuecomment-247396054)) and brand fit tension, but that goes hand in hand with growth!

I think we could maybe rename "Teams" to something else, but I don't think we should countenance folding Teams back into Participants. That would be more trouble than it's worth.

"Projects" might work. Even with larger orgs like Wikipedia, Mozilla, or Archive.org, the distinction between the parent entity and their projects seems to make sense:

Wikimedia &rarr; https://wikimediafoundation.org/wiki/Our_projects
Mozilla Foundation &rarr; Firefox
Archive.org &rarr; https://archive.org/projects/
comment
created
whit537
username_2
The main thing I think skimming through those blocked on 432 is, "I don't want to think about this. I wish I could just approve these folks and move on." The next thing I think is that I _do_ want to promote certain teams/projects/whatever more than others. But that's separate (some kind of "verified" program or "tiers" like we've [talked](https://github.com/gratipay/inside.gratipay.com/issues/432#issuecomment-167126987) about).
comment
created
whit537
username_2
Or we go a Facebook-ish route and have _multiple_ types.

![screen shot 2016-09-20 at 10 22 56 am](https://cloud.githubusercontent.com/assets/134455/18674386/0d0eff74-7f1d-11e6-8837-

---------------------

5462cb66ff75.png)
![screen shot 2016-09-20 at 10 28 40 am](https://cloud.githubusercontent.com/assets/134455/18674385/0d0d712c-7f1d-11e6-8a02-ff6dabdfc673.png)
comment
created
whit537
username_2
Or don't introduce multiple types, but call them "Pages."
comment
created
mattbk
username_0
So you set up a "Page" to receive money?
comment
created
whit537
username_2
Maybe? Which do you like better, Projects or Pages?
comment
created
whit537
username_2
One can view projects as temporary (rather than permanent) social systems or as work systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints. An ongoing project is usually called (or evolves into) a program.

https://en.wikipedia.org/wiki/Project

Hmm ... "open-source project" is permanent tho ...
comment
created
whit537
username_2
What's the smallest change we can make in order to close gratipay/gratipay.com#432? I think it might be Team &rarr; Project.
comment
created
whit537
username_2
I'm into a revision over here, also dealing with an asymmetry between payins and payouts in the current terms ... commit forthcoming ...
comment
created
mattbk
username_0
Sounds great.
comment
created
whit537
username_2
Okay! Revision made. In reviewing it through the web here, don't forget about GitHub's "rich diff" option for Markdown files.

![screen shot 2016-09-20 at 2 49 37 pm](https://cloud.githubusercontent.com/assets/134455/18684432/2a2d5ee6-7f42-11e6-8da2-1c357de7074e.png)
comment
created
whit537
username_2
I think we're ready to run this by Aaron (our lawyer), ya?
comment
created
mattbk
username_0
Sounds good.
comment
created
whit537
username_2
Thanks, Aaron! :)
comment
created
whit537
username_2
Let me know what you think about these suggestions and we'll go from there.
comment
created
mattbk
username_0
- [ ] come up with an alias for Participants acting as contributors, so that we're never using "Participant" in a context-dependent way
- [ ] more clearly describe the differences between these various roles up from (and clarify that each is a Participant interacting with the platform in a different way)
- [ ] revise the individual sections (e.g. the new 3-5) such that each is limited to describing the obligations of one role. So one section for Owners, one for Participant-contributors, and one for Members
- [ ] rename "Owners" and "Members" to "Project Owners" and "Project Members." "Members" in particular is ambiguous -- since "members," "participants," and "users" could all potentially be used interchangeably in common speech, people may get confused trying to keep them straight when reading through the terms.
- [x] Probably use different language for the "Work" performed by the project and the work performed by Members for Projects 
    - Tried to address in  https://github.com/gratipay/gratipay.com/pull/4117/commits/01e8cb2aa068706354023a7d93e0d74a7f7f8e2e
comment
created
mattbk
username_0
I'll try to go through this again to see how it reads.
comment
created
mattbk
username_0
I think it's ready for review again.
comment
created
whit537
username_2
Looks awesome on first skim, more later ...
comment
created
whit537
username_2
We're [finding new counsel](https://github.com/gratipay/inside.gratipay.com/issues/842), which affects this. It's probable that we'll have _two_ lawyers, one for general corporate and contract issues (and quite comfortable with open source), and one for financial regulatory compliance. I think our process here will then be something like:

1. Have the finance lawyer review our current position to level-set, make sure we did okay during the Gratipocalypse (Aaron was learning on the fly, after all).
1. Work through this PR with the corporate/contract lawyer.
1. Run the new terms by the finance lawyer one more time.
comment
created
mattbk
username_0
Sounds good for new counsel to look it over in order to be familiar.
comment
created
mattbk
username_0
Incorporate https://github.com/gratipay/inside.gratipay.com/issues/857 as part of this to bundle lawyering time?
comment
created
whit537
username_2
We have a lawyer!
comment
created
whit537
username_2
Rebased onto latest master. Previous head was d7437c5a9c042cbdbf18762dcafc350a27f7dc8a.
comment
created
whit537
username_2
How about "Collaborators" instead of "Project Members"?
comment
created
whit537
username_2
Alright, @username_0, I think I'm about good here. You okay with my latest commits? If so then I think we're ready for @username_3's input! :)
comment
created
mattbk
username_0
LGTM. :+1:
comment
created
whit537
username_2
@username_0 Cool, I've emailed @username_3 with links to here and the private ticket as well.
comment
created
whit537
username_2
Let me know what you think about these and we can go from there.
comment
created
whit537
username_2
Okay! We're in a bit of a triage situation [tonight and tomorrow](https://github.com/gratipay/inside.gratipay.com/issues/757#issuecomment-256509327). If I make it far enough on the coding on https://github.com/gratipay/gratipay.com/issues/4148 tonight, I will likely try to incorporate the "start with" suggestions into https://github.com/gratipay/gratipay.com/issues/4117 and land that tomorrow. Then we can pick up the rest next week.

At this point the most likely scenario is that I _won't_ get far enough tonight, and so we won't have the urgency tomorrow to land this.
comment
created
mattbk
username_0
Need to think a little more.
comment
created
mattbk
username_0
This is about the agreement between Project and Collaborator, and is addressed in https://github.com/gratipay/gratipay.com/pull/4117/commits/8ee27be9186c23321d8c44751251d6e382b9d659. I changed it to say that a Collaborator forms the agreement when they become a Collaborator (i.e., when they are added to the Project).

Question: @username_3 questions the specifics of the agreement between Project and Giver, but not between Project and Collaborator. Is this an oversight, or is there a difference in these relationships? (@username_3 can't answer publicly, I'm just adding this here to batch with any additional questions we may have before finishing this up.)
comment
created
whit537
username_2
@username_0 I've topped up my [private thread](https://github.com/gratipay/legal/issues/32) with @username_3 where we're sorting out the privilege question regarding public v. private discussions. Ideally he and you can work on this without me being a bottleneck. Two caveats:

- I'd like a chance for final review before we go live.
- @username_3 Can you get us a project cost for this, so we can plan our cashflow?
comment
created
mattbk
username_0
I wouldn't have it any other way.
comment
created
tieguy
username_3
Hey, @username_2 - sorry for the slow response, was doing some election-related work last week.

Happy as usual to work on a fixed basis, but not sure what you're asking me to cover in this one - all the outstanding questions here, or...?

@username_0 : I was just doing a first pass when I asked that first round of questions. I will take another look at the Project/Collaborator relationship.
comment
created
mattbk
username_0
Thanks @username_3!

@username_2, once you're satisfied we can work out a plan for rolling out [Decouple](https://github.com/gratipay/gratipay.com/milestone/22).
comment
created
whit537
username_2
Rebased on master. Previous head was a270ed00b241db93a9d2188c3cfa02a637ac25be.
comment
created
whit537
username_2
@username_3 Our immediate objective in relaxing the "Open Work" requirement in our terms is to reduce the friction in our onboarding process. Our two bigger-picture objectives are:

1. to relieve ourselves (primarily @username_0) of review busywork, and
1. to make possible growth initiatives such as https://github.com/gratipay/gratipay.com/issues/4148 and https://github.com/gratipay/inside.gratipay.com/issues/436.

Do you see significant work remaining in order to meet these objectives? If so, let's talk about the scope of that work and a price. If not, then let's (stay hourly and) bring this in for a landing! :flight_arrival: 💃
comment
created
whit537
username_2
Hmm ... I can't quite shake the feeling that it _is_ entangled.
comment
created
whit537
username_2
Okay, feeling shaken. 🏀 is in your court, @username_3 @username_0!
comment
created
mattbk
username_0
I like https://github.com/gratipay/gratipay.com/commit/52b096a267a52b6e8b1cac06cbabd014b3442798 because it removes the brand guidelines from review. It may be controversial, but I'm not sure of a better way to put it. It _does_ put the onus on Gratipay in terms of being fair about what constitutes "aggressive," "trolling," and "activism," but that wouldn't be different if captured under the brand guidelines. It's probably the closest we can come to saying "Be a good community member (that means don't be a jerk)."

The other changes look fine to me.
comment
created
tieguy
username_3
I don't think this should be significant - less than an hour unless something unexpected crops up. I'll start diving in to the rebase now.
comment
created
tieguy
username_3
General comment: looks good. Let me know if any of the comments I left inline don't make sense.
comment
created
whit537
username_2
Awesome, thanks @username_3!

Bumping out of the Review queue.

@username_0 This is in your TODO, ya?
comment
created
mattbk
username_0
To fix more, yes?
comment
created
whit537
username_2
Yes! To incorporate the latest from @username_3.
comment
created
whit537
username_2
@username_0 You on it?
comment
created
whit537
username_2
At the risk of stirring the pot, I just discovered https://github.com/gratipay/inside.gratipay.com/issues/204 while combing through our issue backlog. It'd be nice to close that along with this.
comment
created
mattbk
username_0
Made lawyerly changes, will look at https://github.com/gratipay/inside.gratipay.com/issues/204 when I have a chance.
comment
created
mattbk
username_0
comment
created
mattbk
username_0
Ready for review again.
comment
created
tieguy
username_3
- [ ] Re Sec. 11.i ("state laws"), I've opened gratipay/inside.gratipay.com#925 for this.
- [ ] Sec. 9 still looks incorrectly indented.
- [ ] Left one review request.

Otherwise looks good to go.
comment
created
mattbk
username_0
Made changes except for #925, to which I don't know the answer.
comment
created
mattbk
username_0
Ready for a @username_2 review again.
comment
created
whit537
username_2
Lessee here ...
comment
created
whit537
username_2
I've rebased on master (previous head was 526d7a94c3095f79ef2301498ba4025a0218d2c6), and added a commit to reflow per Vim for consistency. Now going through https://github.com/gratipay/gratipay.com/compare/67c8b0c5104cdaac7e840a8b261dcafcc076402a...7f8cdd8646fc9ddda49ce1341a861b94eeeadebd ...
comment
created
whit537
username_2
Alright, I made a pass through! Hopefully we are converging? :-)

Here's the [diff](https://github.com/gratipay/gratipay.com/compare/7f8cdd8646fc9ddda49ce1341a861b94eeeadebd...2594b15ab4fc12c9000b7e05e9be2e11534b356f?short_path=7808a32) with my latest changes. Amidst some tinkering, the two main changes to look for are:

1. Further standardization of the "can {make,receive} payments ... because of ... and for no other reason" paragraphs.
1. Removal of inaccurate terms regarding escrow. This is a [rabbit](https://github.com/gratipay/gratipay.com/issues/1383) [hole](https://github.com/gratipay/legal/issues/10) we can't go down right now, but the terms as they stood were simply inaccurate to how we operate today.

Back to you @username_3 @username_0! 🏀
comment
created
mattbk
username_0
I have no comments.
comment
created
tieguy
username_3
For some reason github is not letting me comment inline, so just a few
quick points:
 - I find the sentence that defines the Work to be quite awkward now. If
you don't like where it was, I might just remove the "may establish a
project" phrase altogether; that's less a part of the agreement and more a
feature of the service, so I don't think it needs to be in the TOS at all.
- If you don't like "may only" in the discussion of making payments, can I
suggest "solely"? ("solely because of their collaboration...", dropping the
"for no other reason".

Otherwise looks good.
comment
created
whit537
username_2
Am I missing a difference between 3.ii and 4.ii that explains why we wouldn't want them to be parallel with each other one way or another?
comment
created
tieguy
username_3
No explanation for the inconsistency re "for no other reason", purely that
on re-read in fuller context I realized my own phrasing was somewhat
awkward. Fine to leave in the earlier phrasing.
comment
created
whit537
username_2
@username_3 Gotcha. In that case, how about e54930312216e6d33a3934291fe1c164b804edc9? :-)
comment
created
whit537
username_2
Woo-hoo! Don't look now @username_3 @username_0 et al., but I'm pretty sure we just finished this PR! 🙀
comment
created
mattbk
username_0
Good job! Three months to the day. :grin:
comment
created
whit537
username_2
Congratulations @username_3 @username_0! We've landed this PR! 💃 

It's now merged into an integration branch under #4221, whence it will go into master and out into production.

Great work! 👏  😄

!m @username_3 @username_0
comment