Clarify team application process and parameters on application page

[mattbk]

Reticketed from gratipay/project-review#17 (comment), which I think is a great, civil discussion about how the team application process is perceived and fuzzy and open to misunderstanding.

In particular,

• team application guidelines should be spelled out explicitly on the team application page, and
• legal reasons behind requiring applications should be explained in the site documentation, not solely on blog posts.

I ask that discussion of the application policies be kept in a separate ticket at inside.gratipay.com and this ticket be retained for implementation or rejection of this change. Hopefully this will avoid confusing the two subjects.

[mattbk]

Some thoughts on text.

This application is only required if you want to receive money. You can give to existing teams without creating your own team.

Applications are now required for teams to receive money due to U.S. financial regulations about money transmission. You can read more about this here [and that link should go to real documentation, not a GitHub issue].

^This is important. People are confused about why: gratipay/project-review#11 (comment)

Your application will be reviewed at [applications queue] and you will receive an email confirming receipt. The following criteria will be used to accept or reject your application:

• a
• b
• c

[mattbk]

Copying from Gratipay 2.0 to have here:

Furthermore, we’ve implemented an application and approval process for new teams on Gratipay. We want the teams receiving money on Gratipay to understand our mission and our brand values, and to be on board with the concept of open work. Therefore, our application asks these four questions:

• What product or service does your team provide?
• What is your revenue model?
• How can other people get involved with your team?
• How do you share revenue with contributors?

Clearly, mission and brand values have been treated as guidelines in the past, but the present application process treats them as rules to be applied to applicant teams.

[mattbk]

The mission and brand values pages, if part of the application process, need to be on the main Gratipay website, not just inside.gratipay.com.

http://inside.gratipay.com/big-picture/mission
http://inside.gratipay.com/big-picture/brand/

[mattbk]

A how-to page about reviewing team applications should be created at http://inside.gratipay.com/.

[mattbk]

Aha! Here is a draft of possible criteria from May 9: #3390 (comment)

[mattbk]

And here is how they are stated in the TOS:

'4. Rules for Gratipay Teams

• Teams may accept payments on the Service only for Open Work, meaning that they provide a clear path for any individual to voluntarily begin contributing to the Team's work, and to share in any revenue the Team generates.
• A Team can only begin receiving payments from Participants once it has provided a working withdrawal mechanism for receiving payments (e.g. bank account information).
• Teams and their Open Work must be consistent with Gratipay's Brand Guidelines and Acceptable Use Policy.
• Gratipay reserves the right to reject, suspend, or remove a Team at any time, and for any reason.
• Establishing a Team on Gratipay involves an application and approval process. As part of this process, the Gratipay community will have the opportunity to publicly evaluate and provide commentary about the Team. However, all decisions regarding whether to accept, reject, suspend, remove, or take any other action regarding a Team belong solely to Gratipay.

[mattbk]

We're in the process of revising the team application, so the questions listed above may change.

[chadwhitacre]

Folding in discussion from #3679 ...

Now that we have received 79 applications, let's think about some tweaks to the application to make sure it's doing what we want.

I think the product or service question is pretty straightforward and I think it's fine.

Revenue model tends to see these three responses:

• "We ask people for money."
• "We have no revenue model." "I either don't grasp, or willfully reject, the concept of a revenue model."
• @wout's answer :)

This question is controversial, but I think that means it's working as intended. The point of this question is to filter out people who are thinking in terms of building a viable open business from those who aren't.

For Contributing I think we can drop back from an open-ended textarea to a link to contributor documentation or at least an issue tracker. We should specify that this is where we expect to find a list of available open work that's ready to start without having to explicitly apply first.

Paying contributors really comes down to "kids eat first" or "parents eat first." I think we should allow both when we bring back payroll (#3433), and this part of the application will simply be a select between those two options. One pattern we're seeing is that nobody is making any revenue, so they aren't at a place where they can really think about sharing it. They're reluctant to make promises to share revenue when they themselves are not receiving enough yet. I think we want to keep "everyone sets their own take" but allow for "parents eat first."

[chadwhitacre]

@mattbk at #3679 (comment):

The point of this question is to filter out people who are thinking in terms of building a viable open business from those who aren't.

This implies that you only want people who have any sort of business sense and are focused on that area rather than doing whatever it is that they do. If the goal of Gratipay is to help push open projects (meaning minimum barrier to contribution), why are we setting a barrier to entry of "treating this project as a moneymaking endeavor"?

That's not to say we shouldn't ask about revenue model, but maybe it should be phrased in such a way as "Many teams currently have no revenue stream. If your team started generating revenue through Gratipay, how would you spend it?" But what is the answer that "fits" with Gratipay's mission and brand guidelines?

Contributing looks good, and I think the criteria of "Does this team have a well-documented method for new people to contribute" is much stronger for accept/close team choices.

(The TechRaptor model of "Send us your contribution and we'll decide whether it fits" is, IMHO, within the bounds of Gratipay in the same way I can submit a PR to any project on GitHub--although not all GitHub projects have documentation explaining how people can get involved.)

[chadwhitacre]

"Many teams currently have no revenue stream. If your team started generating revenue through Gratipay, how would you spend it?"

This makes the same fundamental mistake that's behind the "We have no revenue model" sort of answers. A revenue model is not how you would spend money, it's how you want to make money. It's a plan for income, not for expenses.

A revenue model is a framework for generating revenues. It identifies which revenue source to pursue, what value to offer, how to price the value, and who pays for the value. It is a key component of a company's business model. It primarily identifies what product or service will be created in order to generate revenues and the ways in which the product or service will be sold.

Without a well defined revenue model, that is, a clear plan of how to generate revenues, new businesses will more likely struggle due to costs which they will not be able to sustain. By having a clear revenue model, a business can focus on a target audience, fund development plans for a product or service, establish marketing plans, begin a line of credit and raise capital.

We absolutely want people who understand what a revenue model is at the helm of the teams on Gratipay, because we want the teams on Gratipay to be viable, and they can't be without "a clear plan of how to generate revenues."

[chadwhitacre]

Now, one problem with the revenue model question as it stands is that Gratipay only really supports one model: voluntary subscriptions (hence the first class of answers, "We ask people for money"). What if we changed this to something like:

Please describe the revenue model that Gratipay supports.

Or:

Gratipay implements the voluntary subscription revenue model. What does that mean to you?

Or even:

What is your business plan?

[mattbk]

Understood on the explanation of revenue model.

The second or third wording make sense. The first is either a gimme or a gotcha, which makes it meaningless as team approval criteria (and especially meaningless on a team description profile).

[mattbk]

"Gratipay teams must publicly state revenue sources" is one of those TOS-y statements that could be easily translated to the team application/team profile.

[chadwhitacre]

[Y]ou only want people who have any sort of business sense and are focused on that area rather than doing whatever it is that they do.

Substitute "as well as" for "rather than" and you've nailed it.

We are building viable open businesses. We are building viable open businesses. We are building viable open businesses.

[chadwhitacre]

The first is either a gimme or a gotcha, which makes it meaningless as team approval criteria (and especially meaningless on a team description page).

True.

The second or third wording make sense.

What if we combine them?

Gratipay implements a voluntary subscription revenue model. How does that fit into your business plan?

[chadwhitacre]

I ask that discussion of the application policies be kept in a separate ticket at inside.gratipay.com and this ticket be retained for implementation or rejection of this change. Hopefully this will avoid confusing the two subjects.

P.S. I seem to have violated this, sorry. :-(

Are we okay to continue here? We'll have a PR separate from this to track the implementation details.

[mattbk]

Are we okay to continue here?

The scope of the ticket has changed anyway, so it's fine with me.

Gratipay implements a voluntary subscription revenue model. How does that fit into your business plan?

I like that one.

Substitute "as well as" for "rather than" and you've nailed it.

I don't think Gratipay needs to be all things to all people, but the more we can help people grok business, the better. So the open-cum-business explanation has to be clear at the outset (front of the website) rather than brought up after an application is submitted, because it's a big shift
from the gittip model, where any money made here was a bonus, not a path toward growing real revenue.

We believe teams can use openness to grow revenue, and we want teams to believe it too. That's why we ask this question.

Now.

None of these questions addresses those nebulous items of "matching the mission and brand values/guidelines of Gratipay", except maybe the product or service question.

• How do we explain what this means on the team application page?
• How do we explain what this means to contributors who are reviewing teams?
• If assessment of a team includes detailed inquiry into what that team is doing in their own space/website, how will it be possible to keep up? In the interest of applying our hopes of growth/revenue for teams to Gratipay itself, say we get 10 teams applying every day. That's 70 teams to review every week. Are we seriously opening ourselves up to reviewing 70 teams a
  week in more detail than is provided on the application itself? tl;dr: "does it scale?"

[chadwhitacre]

The scope of the ticket has changed anyway, so it's fine with me.

Okay, sorry.

[chadwhitacre]

I like that one.

One issue: it brings back that word, "subscriptions," that we moved away from in gratipay/inside.gratipay.com#117.

[chadwhitacre]

the more we can help people grok business, the better.

Agreed. See also: #1273.

[mattbk]

We're working with concepts that don't have good names yet. Subscription implies a set reciprocity you receive.

"Gratipay implements a voluntary recurring revenue model. How does that fit into your business plan?" ?

voluntary = "good until canceled" (GIC implies subscription, though)
recurring = self-explanatory?
revenue = money

Or in simple words:
"Gratipay lets people voluntarily give money to your team every week. How does that fit into your business plan?"

[chadwhitacre]

We're working with concepts that don't have good names yet.

Indeed.

Subscription implies a set reciprocity you receive.

Well, but you do receive a more or less set reciprocity. It's just that you receive it (at least conceptually) before you pay instead of after.

Gratipay implements a voluntary recurring revenue model.

I kind of like the idea of linking out to Wikipedia to explain these concepts. Would we still link "recurring" to https://en.wikipedia.org/wiki/Subscription_business_model?

[mattbk]

Both of those payroll links go to this ticket, is that intended? I imagine the first will go to the rewritten Payroll page and the second to the ticket.

That looks good to me. It also makes it very transparent to potential contributors, which is nice.

[mattbk]

How about if we link to the (soon-to-be-written) howto from the Team application, and then spell it out in detail on the "Application received" page under #3568?

Perfect.

[chadwhitacre]

Both of those payroll links go to this ticket, is that intended? I imagine the first will go to the rewritten Payroll page and the second to the ticket.

Yeah, sorry. Placeholder links.

[chadwhitacre]

Okay! I think we're about ready for a PR here. :-)

[mattbk]

Re: business models for open companies: https://twitter.com/balupton/status/633962999363932160

[chadwhitacre]

This application is only required if you want to receive money. You can give to existing teams without creating your own team.

Have we actually had people get confused about that, @mattbk? Links?

[mattbk]

No.

[chadwhitacre]

No.

Okay, I think with the new About pages maybe things are clearer there.

[chadwhitacre]

I'm going back over this ticket to see what other changes need to be made on #3694.

[chadwhitacre]

If assessment of a team includes detailed inquiry into what that team is doing in their own space/website, how will it be possible to keep up? In the interest of applying our hopes of growth/revenue for teams to Gratipay itself, say we get 10 teams applying every day. That's 70 teams to review every week. Are we seriously opening ourselves up to reviewing 70 teams a
week in more detail than is provided on the application itself? tl;dr: "does it scale?"

We can certainly handle our present volume, and a fair bit more. Certainly up to 70/wk. For a while I was reviewing almost 100 users per week under Gratipay 1.0.

When the time comes, we'll find a way to optimize. For example, we could add a fast track, where if you have a dozen or a score of current Team owners vouch for you (and no blockers), then you are approved without explicit "central" approval.

[chadwhitacre]

For a while I was reviewing almost 100 users per week under Gratipay 1.0.

... and that was private. Team review is public, so I won't have to be the bottleneck.

[chadwhitacre]

New team application is live. Reopening here until we can write the Review howto and link it: gratipay/inside.gratipay.com#311.

Besides that, any other todos to close this out, @mattbk?

[mattbk]

We can come back as needed. Let's see how this works.

[chadwhitacre]

I apparently failed to actually reopen this. Rectified! :-)