Closed chadwhitacre closed 9 years ago
payments
is the most generic of the three.
We don't want to limit ourselves to just tips
and/or just gifts
or donations
.
I think this is important because whatever we call them, they're essential to Gratipay, and it muddies our communication to vary our terminology.
Along with this: supporters
, backers
, patrons
, payers
, donors
, givers
, etc.
Paypal is for paying pal
. Is Gratipay for sharing, because you can
? Do we set just for one-off tip
s? Or do we try to balance the flow and express gratitude by diverting it from our own to those who deserves to be shared with?
payment
is more like a compensation for the job done. Is this the direction the Gratipay is heading?
I don't like payments
, because they are knit to bills
and bills
are making me sad.
I, like @techtonik, also don't like payments. It's sad that it's in the name, and that may compel us to incorporate it in the jargon. I like gifts a lot more... payments is too cold.
Even gifts is not ideal... feels too mushy. donation feels too much like charitable giving instead of giving due to gratitude. Why not just call it giving, and call the roles givers and receivers?
I don't like supporter. It's as if you are giving more than you are receiving, like a favor...
I would rather just stay home, but I'll attend my friend's peformance tonight. In addition, I will scream when it's his turn, to show support.
I like gift
, because it has a clear legal definition and tax definition∆.
My thoughts:
money
, always in the past, for which nothing was exchanged**. That is, a one way shift of value; no full consideration in return.money
, always in the past, for which something was exchanged. That is, a two way shift of value; full consideration in return.gift
in the future, automated by Gratipay.payment
in the future with full consideration
in return, automated by Gratipay.gift
. The terms should be used interchangeably according to proper English usage, but receiver should be preferred when either works grammatically.
user
.individual receivers
, who individually choose how much they want to take from the group of what is available to them according to the order in which they joined the group, or however Gratipay may allow users to choose.gift
to a recipient
or receiver
.
user
who gives a gift
.I'm open to using "gifter" instead of giver. "Gifter" is a valid English word, albeit rarely used. I don't know how well it translates, though. I'm pretty sure the other words all translate cleanly to other languages, at least conceptually.
I think I understand where @whit537 wants to keep the use of "payment" on the table, because Gratipay could become a store of sorts in some far-off future. I'm not against that, but _I_ don't think such near enough to merit the inclusion of the term in the Gratipay vocabulary now.
∆: See US IRS Gift Tax FAQ. I think we've talked about this previously. At least within the US, an individual recipient could receive up to the federal gift tax exclusion limit without having to pay taxes on the amount exceeding the exclusion limit. I know Gratipay doesn't claim to do anything with taxes, but a little guidance is useful as long as there is the requisite "contact your tax professional" for further questions.
I think it's important that we let our users decide what to call their givers. From Gratipay's purview, a user who gives to a receiver is a giver.
For an individual receiver, it may make sense for them to be called givers, donors, patrons, supporters, etc. based on what the receiver is doing to earn the gifts.
Simplify things and just call it money, not gift or donation:
A giver gives money to the receiver.
Copying over from https://github.com/gratipay/gratipay.com/issues/3511#issuecomment-122895483:
the word "Subscriptions" just seems ... unilluminating. To me, a subscription is something that I receive in exchange for payment; but the whole point of gratipay is that I'm giving money without expectation of receiving anything in return (unless you count warm fuzzies). So every time I see "Subscriptions", my brain stumbles a little.
I do not like the word subscription for this case as well. Why was it chosen?
I was looking (on https://github.com/gratipay/gratipay.com/pull/3414) for a word to describe the recurring, scheduled payments that people set up, which are then concretely instantiated in actual payments each payday. "Subscription" seemed to capture this, but I can see that it doesn't entirely fit with the idea of voluntary payments:
The subscription business model is a business model where a customer must pay a subscription price to have access to the product/service. The model was pioneered by magazines and newspapers, but is now used by many businesses and websites.
Heh:
There's our exemplar. ;-)
We used to call these "tips," which captures the voluntary nature of the payments, but not the scheduled recurring nature of the payments.
What's a better word to use here?
give I expect that it should be clear to the user that the giving is recurring, especially since there's no once-off giving; when that comes, we can have give and give once options
Comments in light of Gratipay 2.0:
On the one hand, we seem to have fallen out on the Payment side more than the Gift side. On the other hand, we are still emphasizing voluntary payments, which I think is a crucial distinction. We're carving out a niche between strict payments and strict donations. Money moving on Gratipay 2.0 is not primarily a charitable donation, because it is given in view of some value I receive directly (as opposed to value someone else receives, e.g., victims of a natural disaster). However, I receive the value first and then make the payment. The payment is voluntary. That's the important point. Gratipay doesn't offer or optimize for rewards (cf. Patreon, Kickstarter).
Wikipedia really is our best example. While Wikimedia is technically a charity, my payments to them are a response to the value I freely, directly receive from Wikipedia. It's technically a donation, but I think it's more accurately called a voluntary payment. As a gift, it's a reciprocal gift, given in a spirit of gratitude (more so than guilt, one hopes!) for the "first gift" of Wikipedia. From "Resentment":
There are two gifts on Gittip, and the first gift is my free labor. The money on Gittip is a second gift, a reciprocal gift, given in view of the first. Tegan Mulholland was right to call Gittip “the opposite/complement of a gift economy.”
Gratipay 2.0's primary clarification was that the giver of free labor and receiver of voluntary payments is an open group of individuals rather than a single individual.
Payments are clearly monetary, while gifts needn't be monetary. It could be that talking about "voluntary payments" makes way for us to speak of the labor freely shared as the true "gift" on Gratipay. We enable payments motivated by gratitude for gifts freely given and received.
I don't think we should do what @colindean [suggest]() and utilize both terms, Payment and Gift. The only distinction I see you making there, @colindean, is in the motivation of the giver, rather than in any technical consideration, yes? If that's our distinction, I think it's too fine for us to track.
Interesting that I gravitated towards the word "giver" there, while still thinking in terms of "payments."
A giver makes voluntary payments to a receiver.
Post-2.0, we do have the ~user and Team distinction to work with as well.
A ~user makes voluntary payments to a Team.
As far as subscriptions
goes, is this too weird?
intentions
I have an intention to voluntarily pay a Team $1 per week.
We record intentions
to make voluntary_payments
.
ALTER TABLE subscriptions RENAME TO intentions;
ALTER TABLE payments RENAME TO voluntary_payments;
(Note that voluntary_payments
would get subsumed by the ledger
under https://github.com/gratipay/gratipay.com/pull/3618.)
I think intentions
is too weird. We can't use that in the UI: it'll be too confusing to people. WTF does "intentions" mean? I mean, right? What do we want to say in the UI? Back to "Giving" and "Receiving" there? In which case ALTER TABLE subscriptions RENAME TO gifts;
? What about pledge
(Patreon's term)?
We could use intentions
for the table, and "Giving" and "Receiving" in the UI.
Though Receiving is now tied to a Team, not a ~user. For a ~user, the parallel concept is now "Taking."
Quick UI mockup:
Though now that I see it, a "Teams" tab seems more natural. Why?
Then on the Team side:
We could use
intentions
for the table, and "Giving" and "Receiving" in the UI.
Though if we're going to do that, we may as well use subscriptions
under the hood. We could even talk about "voluntary subscriptions," in keeping with "voluntary payments."
ALTER TABLE subscriptions RENAME TO voluntary_subscriptions;
ALTER TABLE payments RENAME TO voluntary_payments;
Would the modifier "voluntary" help at all with "subscriptions" and "payments," @techtonik @tshepang @colindean @mattbk et al.?
If we used intentions
for the table, then we could model one-off giving in there as well. It would become in effect a kind of queue. We would pop the queue during payday (maybe even out-of-band someday?) to find out whom to actually charge and payout to. Each record could include a counter of the number of times it had been fulfilled, and a number of times it is intended to be fulfilled.
ALTER TABLE subscriptions RENAME TO intentions;
DROP TABLE payments; -- folded into `ledger`
Or maybe instructions
:
ALTER TABLE subscriptions RENAME TO instructions;
I instructed my broker to buy the stock.
The ~user is instructing us to charge them for a voluntary payment to a Team.
Conversely, the ~user is instructing us to take a certain amount of a Team's funds for themselves.
ALTER TABLE subscriptions RENAME TO payment_instructions;
ALTER TABLE payroll RENAME TO payroll_instructions;
A giver instructs Gratipay to make voluntary payments to a receiver. A ~user instructs Gratipay to make voluntary payments to a Team. A ~user instructs Gratipay to take voluntary payroll from a Team.
This is actually a pretty important ticket, I think.
payment_instructions
is long. voluntary_payment_instructions
is even longer.
I mean, subscriptions
is kinda long.
Revision of https://github.com/gratipay/inside.gratipay.com/issues/117#issuecomment-67247317 in light of 2.0 and my recent blabbering:
money
, always in the past, from a group or individual to a group, for which something was exchanged. That is, a two way shift of value; full consideration in advance.money
, always in the past, from a group to an individual, for which labor was exchanged, with the individual determining the amount.~user
to Gratipay to send a voluntary payment
in the future with full consideration
in advance, automated by Gratipay.~user
to Gratipay to effect a voluntary payroll distribution
in the future, automated by Gratipay.voluntary payment
. The terms should be used interchangeably according to proper English usage, but receiver should be preferred when either works grammatically. Every receiver
is a Team
; not every Team
is a receiver
.voluntary payment
to a recipient
or receiver
. Every giver
is a ~user
; not every ~user
is a giver
.voluntary payroll
from a Team
. Every taker
is a ~user
; not every ~user
is a taker
.~user
who actively works for/on Gratipay, and generally, but not necessarily, takes a voluntary payroll
from the Gratipay Team
on Gratipay. cc: @colindean et al.
Really vibin' on the _voluntary_ payment. Our special sauce. :sake: :sandal: :santa:
I don't have the spare brain time to review the whole thread, but that summary looks fine to me.
YESSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!
I LOVE YOU, @colindean! :dancer:
We're trying to find that knife-edge between patronization and mutual respect. Gratipay wants you to go to your friend's performance because you love your friend, not because you feel obligated and guilty.
Aaaaaaaand I'm Ballmer Peakin'. :kissing_smiling_eyes:
PR for payment_instructions
in https://github.com/gratipay/gratipay.com/pull/3652.
Hard to argue with https://www.youtube.com/watch?v=d5_r4ORI6j8.
"Gratipay—voluntary payments and payroll for open work."
"Gratipay: Voluntary Payments and Payroll"
My proposal is:
payment_instructions
and payroll_instructions
as our database table names instead of subscriptions
and payroll
.payment_instructions
from the ~user and Team points of view, and Teams and Members will correspond to payroll_instructions
.payments
table to fold into the ledger
under https://github.com/gratipay/gratipay.com/pull/3618.I like voluntary payments; it's a lot less ambiguous than gifts.
Regarding the tagline, how about:
Gratipay: (recurring) voluntary payments for open work
Payroll is not needed there I feel. That's something someone will discover as they find out more. Payroll sounds like it applies people who are formally employed.
I thin we should have payments and payroll... adding _instructions does not help anyone understand these things better, and makes for overlong names.
Payments and payroll are ambiguous with regard to time: are they actual movements of money, or the instructions to do so? Adding "instructions" makes it clear. Code is read more often than written, so a longer name that adds significant clarity is okay.
Payroll sounds like it applies people who are formally employed.
Yes! And, as with payments, voluntary payroll is the crucial distinction. When we bring back our payroll feature (https://github.com/gratipay/gratipay.com/issues/3433), it will fit within the formality of the existing framework of employment law (#242), but with the crucial modifier—voluntary.
Payroll is not needed there I feel. That's something someone will discover as they find out more.
Recall that our primary customer is the Team owner/manager. Our pitch to this person does include both payments and payroll. However, since we don't actually provide payroll right now and aren't going to for a while, it could make sense for us to drop it for that reason.
One concern that should probably be addressed:
If it’s called payroll, someone is going to want to tax it.
If it’s called payroll, someone is going to want to tax it.
Yes! See https://github.com/gratipay/inside.gratipay.com/issues/211#issuecomment-109518669 for a discussion of the alternative, though #242 is the best place to continue the discussion.
It's interesting that we have to appeal to 2 user types: someone that gives and someone that takes. Why are you here, in the tagline, addressing only someone that takes? Removing the payroll addresses both types at the same time.
Also, what about adding recurring in there? I think it would be a good idea.
We call them
tips
,gifts
, andpayments
(at least). I think we should standardize onpayments
.