standardize nomenclature

[chadwhitacre]

We call them tips, gifts, and payments (at least). I think we should standardize on payments.

[chadwhitacre]

payments is the most generic of the three.

[chadwhitacre]

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.

[chadwhitacre]

Along with this: supporters, backers, patrons, payers, donors, givers, etc.

[techtonik]

Paypal is for paying pal. Is Gratipay for sharing, because you can? Do we set just for one-off tips? 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?

[techtonik]

I don't like payments, because they are knit to bills and bills are making me sad.

[tshepang]

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.

[tshepang]

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?

[tshepang]

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.

[colindean]

I like gift, because it has a clear legal definition and tax definition^∆.

My thoughts:

• User. A person who has created an account on Gratipay, regardless of its state or income.
• Money. Accepted store of value, e.g. government-issued currency (US Dollars) or cryptocurrency (Bitcoin).
• Gift. A single event of movement of money, always in the past, for which nothing was exchanged**. That is, a one way shift of value; no full consideration in return.
• Payment. A single event of movement of money, always in the past, for which something was exchanged. That is, a two way shift of value; full consideration in return.
• Recurring Gift. A pledge to give a gift in the future, automated by Gratipay.
• Recurring Payment. A pledge to send a payment in the future with full consideration in return, automated by Gratipay.
• Receiver or Recipient. A entity that receives a gift. The terms should be used interchangeably according to proper English usage, but receiver should be preferred when either works grammatically.
  • Individual receiver/recipient. An individual user.
  • Group receiver/recipient. A collection of 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.
• Giver. An entity who gives a gift to a recipient or receiver.
  • Individual giver. An individual user who gives a gift.
  • Group giver. A group that gives a gift as the group itself.
• Gratipayers. A user who actively works for/on Gratipay, and generally, but not necessarily, takes a share of the gifts to the Gratipay group on Gratipay.

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.

[colindean]

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.

[tshepang]

Simplify things and just call it money, not gift or donation:

A giver gives money to the receiver.

[chadwhitacre]

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.

[tshepang]

I do not like the word subscription for this case as well. Why was it chosen?

[chadwhitacre]

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?

[tshepang]

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

[chadwhitacre]

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.

[chadwhitacre]

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.

[chadwhitacre]

As far as subscriptions goes, is this too weird?

intentions

I have an intention to voluntarily pay a Team $1 per week.

[chadwhitacre]

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.)

[chadwhitacre]

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)?

[chadwhitacre]

We could use intentions for the table, and "Giving" and "Receiving" in the UI.

[chadwhitacre]

Though Receiving is now tied to a Team, not a ~user. For a ~user, the parallel concept is now "Taking."

[chadwhitacre]

Quick UI mockup:

Though now that I see it, a "Teams" tab seems more natural. Why?

Then on the Team side:

[chadwhitacre]

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."

[chadwhitacre]

ALTER TABLE subscriptions RENAME TO voluntary_subscriptions;
ALTER TABLE payments RENAME TO voluntary_payments;

[chadwhitacre]

Would the modifier "voluntary" help at all with "subscriptions" and "payments," @techtonik @tshepang @colindean @mattbk et al.?

[chadwhitacre]

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.

[chadwhitacre]

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;

[chadwhitacre]

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.

[chadwhitacre]

This is actually a pretty important ticket, I think.

[chadwhitacre]

payment_instructions is long. voluntary_payment_instructions is even longer.

[chadwhitacre]

I mean, subscriptions is kinda long.

[chadwhitacre]

Revision of https://github.com/gratipay/inside.gratipay.com/issues/117#issuecomment-67247317 in light of 2.0 and my recent blabbering:

• ~user. A person who has created an account on Gratipay, regardless of its state or income.
• Team. A company that has applied for and been approved to receive voluntary payments and distribute voluntary payroll on Gratipay.
• Money. Accepted store of value, e.g. government-issued currency (US Dollars) or cryptocurrency (Bitcoin) [https://github.com/gratipay/inside.gratipay.com/issues/201#issuecomment-102010517].
• Voluntary Payment. A single event of movement of 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.
• Voluntary Payroll Distribution. A single event of movement of money, always in the past, from a group to an individual, for which labor was exchanged, with the individual determining the amount.
• Payment Instruction. An instruction from a ~user to Gratipay to send a voluntary payment in the future with full consideration in advance, automated by Gratipay.
• Payroll Instruction. An instruction from a ~user to Gratipay to effect a voluntary payroll distribution in the future, automated by Gratipay.
• Receiver or Recipient. An entity that receives a 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.
• Giver. An entity who makes a voluntary payment to a recipient or receiver. Every giver is a ~user; not every ~user is a giver.
• Taker. An individual who takes a voluntary payroll from a Team. Every taker is a ~user; not every ~user is a taker.
• Gratipayer. A ~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.

[chadwhitacre]

Really vibin' on the _voluntary_ payment. Our special sauce. :sake: :sandal: :santa:

[colindean]

I don't have the spare brain time to review the whole thread, but that summary looks fine to me.

[chadwhitacre]

YESSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!

I LOVE YOU, @colindean! :dancer:

[chadwhitacre]

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.

[chadwhitacre]

Aaaaaaaand I'm Ballmer Peakin'. :kissing_smiling_eyes:

[chadwhitacre]

PR for payment_instructions in https://github.com/gratipay/gratipay.com/pull/3652.

[chadwhitacre]

Hard to argue with https://www.youtube.com/watch?v=d5_r4ORI6j8.

[chadwhitacre]

"Gratipay—voluntary payments and payroll for open work."

[chadwhitacre]

"Gratipay: Voluntary Payments and Payroll"

[chadwhitacre]

My proposal is:

• We use payment_instructions and payroll_instructions as our database table names instead of subscriptions and payroll.
• In communication with users, we take care to refer to "voluntary payments and payroll."
• In the UI we present "Giving" and "Teams" tabs to ~users, and "Receiving" and "Members" tabs to Teams. Giving and Receiving will correspond to payment_instructions from the ~user and Team points of view, and Teams and Members will correspond to payroll_instructions.
• We expect the payments table to fold into the ledger under https://github.com/gratipay/gratipay.com/pull/3618.

[tshepang]

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.

[tshepang]

I thin we should have payments and payroll... adding _instructions does not help anyone understand these things better, and makes for overlong names.

[chadwhitacre]

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.

[chadwhitacre]

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.

[colindean]

One concern that should probably be addressed:

If it’s called payroll, someone is going to want to tax it.

[chadwhitacre]

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.

[tshepang]

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.