Over-broad Criteria for Team Review

[wrought]

Simply put, the second criterion aka "brand values" is over-broad, unnecessary, and harmful to the gratipay community.

To me, the enforcement of this criterion has already foreshadowed a repeat of the actions and attitudes that lead to the Gratipay 1.0 "controversy". Changing this policy is an opportunity to learn, grow, and change for the better. This is a chance to invest in gratipay's future, it's up to you.

Second, the Team's brand must not clash too strongly with our own brand values. This is obviously much more of a judgement call than the first criterion. Past rejections are the best indicator of how to apply this criterion to new applications. This second criterion is negative: Teams are innocent of brand violation until proven guilty. Anyone who thinks that a Team does clash with our brand has to make a case publicly on GitHub, and we have to leave enough time for the community to weigh in before rejecting a Team. The buck does have to stop somewhere, of course. Currently, Gratipay founder Chad Whitacre is the final arbiter of decisions around brand fit.

http://inside.gratipay.com/howto/review-teams

Proposed change:

• Second, gratipay reserves the right to discontinue service to any user at any time, but this decision shall not be taken lightly, and requires the user to either violate gratipay's Terms of Services Agreement (TOS), or to otherwise pose a serious and clear risk to gratipay, if the user's use were to continue. Anyone who thinks that a Team should be rejected on these grounds has to make a case publicly on GitHub that clearly specifies the TOS violation, or demonstrates how the user's use is both a serious and a clear risk to gratipay if use continues.

[mattbk]

(For context, see gratipay/project-review#108)

[chadwhitacre]

Let's back up.

Gratipay is a commons.

The question before us on this ticket, as I see it, is one of governance: how are we going to govern Gratipay as a commons? Under 1.0, we had no answer to this question. With 2.0 we've put forward an initial answer in our Team review document, and I agree that we can improve what we have.

The best practices for governing a commons are in Elinor Ostrom's Governing the Commons. I've ordered the book (#409); here's the tl;dr:

Ostrom identified eight "design principles" of stable local common pool resource management:

1. Clearly defined boundaries (clear definition of the contents of the common pool resource and effective exclusion of external un-entitled parties);
2. Rules regarding the appropriation and provision of common resources that are adapted to local conditions;
3. Collective-choice arrangements that allow most resource appropriators to participate in the decision-making process;
4. Effective monitoring by monitors who are part of or accountable to the appropriators;
5. A scale of graduated sanctions for resource appropriators who violate community rules;
6. Mechanisms of conflict resolution that are cheap and of easy access;
7. Self-determination of the community recognized by higher-level authorities; and
8. In the case of larger common-pool resources, organization in the form of multiple layers of nested enterprises, with small local CPRs at the base level.

I think Ostrom's Principles provide a solid framework for improving our governance of Gratipay as a commons.

[chadwhitacre]

Gratipay is a commons.

More specifically, Gratipay is a digital commons:

The digital commons are a form of commons involving the distribution and communal ownership of informational resources and technology. Resources are typically designed to be used by the community by which they are created. Examples of the digital commons include wikis, open-source software, and open-source licensing. The distinction between digital commons and other digital resources is that the community of people building them can intervene in the governing of their interaction processes and of their shared resources.

[chadwhitacre]

Gratipay is a digital commons

But Gratipay is more than that: Gratipay is a company.

[chadwhitacre]

Let's start with ...

Principle 1: Clearly defined boundaries.

clear definition of the contents of the common pool resource

It seems to me that the contents of our common pool resource are the assets of Gratipay the company, including:

• our software-as-a-service
• our revenue stream
• our brand—"often the most valuable asset on a corporation's balance sheet"
• our business processes
• our communication channels
• our accounts with vendors
• whatever else can be said to belong to Gratipay

What are others seeing as the boundaries of Gratipay as a common pool resource?

[chadwhitacre]

How do Wikimedia and Mozilla define their commons?

[wrought]

@whit537 This ticket is specifically about the 2nd criterion of the Team Review being over-broad and unnecessary. I posed a specific alternative. If you'd like to back up and discuss the commons, Elinor Ostrom, etc, I get it (you can see I edited her Wikipedia article last year), that's fine--but it's a derailment of this thread and at least deserves its own ticket rather than hijacking this one.

Why won't my actual comments 1 & 2 be directly addressed by any Gratipay members?

I'm getting the strong impression that Gratipay's users / customers / community are invited to participate in debate or dialog in rhetoric alone -- with no real interest of working with the community, communicating in good faith, and addressing concerns directly.

This feels like a war of attrition, in which I am expected to give up participating when I lack the energy to continue being ignored. I've already sank a sufficient amount of time to do my due diligence on this issue following Gratipay's own procedures. If ya'll would prefer to railroad over users like me, you of course are welcome to do so, but it's not a very nice feeling, and if that matters to customers it should matter to the business, shouldn't it?

Due to team-review/issues/108, I created this ticket to propose to change the Team Review policy's Criterion 2 from:
clashes with brand values
to:
violates TOS or poses direct, clear risk to gratipay
Is there any reason not to do so?

Perhaps there is an even better option, but in lieu of one (pending further research for instance), I don't see why not to change the policy now. Or at least, to suspend Team reviews that concern Criterion 2 until a better option is determined.

[mattbk]

@wrought, not to split hairs too finely, but to make these changes, the TOS need to change, since the "clashes with brand" stuff is in the TOS themselves (4.iii).

You can read my opinion on the team application ticket, it hasn't changed, but for the sake of argument and in hopes that @whit537 will find some common ground: Are there any particular repos or subprojects that are less clash-y with Gratipay?

@whit537, you can see that I'm struggling with words here, which might imply in itself that the "brand clash" term is a little too mushy. More thoughts but I don't have time right now.

[chadwhitacre]

(you can see I edited her Wikipedia article last year)

Nice! 💃

This ticket is specifically about the 2nd criterion of the Team Review being over-broad and unnecessary.

I was looking to broaden the context because I think that focusing narrowly will make it harder for us to find common ground. We can try, though ...

Simply put, the second criterion aka "brand values" is over-broad
the "brand clash" term is a little too mushy

Perhaps. I'm happy to find ways to clarify it. Basically: no hot-headed activism or trolling.

unnecessary

I think it's necessary because our users share in and contribute to our brand more than usual, because we're an open company.

and harmful to the gratipay community.

I think allowing off-brand users to share in and contribute to our brand under 1.0 was harmful to the Gratipay community.

Second, gratipay reserves the right to discontinue service to any user at any time,

We tried this with 8chan and it was a train wreck. It was way more painful—for both parties—for us to remove them after they'd been established for months than if we had denied them entry in the first place. It meant loss of income for them, and reputational damage and distraction for us. Same with Shanley. She was never a good fit for Gittipay, but we had little coherent community or brand management at the time, so we let her essentially grab the reins, and it took a unilateral spaz out on my part to grab them back. Uuuuuugggglllyyyyy!!!!!!!! Compared to the pain of those two experiences, I love our new review process. It's much more orderly. We're no longer making these decisions idiosyncratically behind closed doors, and we come out knowing and feeling good about all of our customers.

(To be honest, Riseup is kind of in this boat, too, since they were a Gittipay user before applying for a 2.0 Team. Compare Techraptor (gratipay/project-review#17), which brought some kerfuffle, but probably less hard feeling than with Riseup, and no-where close what we went through with Shanley or 8chan.)

but this decision shall not be taken lightly, and requires the user to either violate gratipay's Terms of Services Agreement (TOS), or to otherwise pose a serious and clear risk to gratipay, if the user's use were to continue. Anyone who thinks that a Team should be rejected on these grounds has to make a case publicly on GitHub that clearly specifies the TOS violation, or demonstrates how the user's use is both a serious and a clear risk to gratipay if use continues.

It doesn't work to discuss publicly in these scenarios for two reasons:

• Once the user in question is established, emotions run so high that it's really hard to have a productive conversation on the public Internet (see: process Shanley's feedback #49, curate users #118).
• A "serious and clear risk" seems more likely to be a legal issue that we won't be able to fully discuss in public anyway.

As to why we want to filter out teams based on brand fit in the first place ... well, that's a really big wave that started with gratipay/gratipay.com#1425, swelled through #319, crested with #118, and then broke in the private https://github.com/gratipay/violations/issues/1 where we decided to kick out 8chan.

Basically it comes down to the fact that Gratipay, for better or for worse, has this weird brand of willful naïvete, unabashed optimism, and sweet idealism, and we have to inhabit that together with our users, because, as an open organization, we have a more porous boundary between our users and our company. We're not a common carrier or a platform of libertarian neutrality. We are a commons, a community of users and contributors with a collective identity, and for better or for worse we have to spend the energy to maintain that.

This will cause occasional discomfort. It may not work in the long run—maybe Liberapay is right, and principled neutrality is the better option. At this point, what I see is that we should let Liberapay run with that, and over here we should direct our energy into improving how we understand, communicate, and select for our own brand.

[chadwhitacre]

Tying in another thread from gratipay/project-review#108 ...

To turn away the likes of riseup.net is to continue the legacy of the previous controversy

... with this thread:

To me, the enforcement of this criterion has already foreshadowed a repeat of the actions and attitudes that lead to the Gratipay 1.0 "controversy".

What do you see as the legacy of the previous controversy (and which controversy? we've had several :) and how does turning away riseup.net continue it?

[chadwhitacre]

Closing with https://gratipay.news/from-teams-to-projects-45c46718507b.