Skip to content
This repository has been archived by the owner on Nov 16, 2022. It is now read-only.

make Gratipay application-only #187

Closed
chadwhitacre opened this issue Apr 16, 2015 · 21 comments
Closed

make Gratipay application-only #187

chadwhitacre opened this issue Apr 16, 2015 · 21 comments

Comments

@chadwhitacre
Copy link
Contributor

Now that we're clear that Gratipay is in fact a community (and not just a common carrier payments platform), we need to wrestle with how to ensure that users align with our mission and values. It's non-ideal to leave this vague and undefined, because that breeds fear: are they going to kick me off next? Let's find a way to be up-front so that Gratipay users can feel confident that they belong on Gratipay.

One option would be to make Gratipay invite-only for receivers. This would harmonize with our plan to narrow the focus to open-source projects, open products, hackerspaces, and open-source community building efforts (#180). In effect we would be turning Gratipay into a member-owned cooperative, with an application process for membership (cf. #72).

@mattbk
Copy link
Contributor

mattbk commented Apr 20, 2015

I'm not sure this would keep out the so-called riff-raff, although I do agree that invite-only may encourage more donations, due to the implicit endorsement of the inviter of the invitee. If you made this information public ("this person was invited by..."/"this person has invited...") it would be a strong social cue that you should only invite people you feel comfortable vouching for.

I'm for openness, and in the case of Gratipay I support the idea of the free market: if you don't like what someone is doing, don't give them your money. I'm still unclear exactly why certain people were banned, but if it's for legal reasons (e.g., "our payment provider has received a complaint and they are uncomfortable with us giving money to X"), that should be stated clearly somewhere. If it's for other reasons, there will still be a fear of banning regardless of how the community is structured.

My two cents as a user.

@tshepang
Copy link

If this happens, would everybody need to re-register (by accepting the invitation)? That would be an interesting approach, especially since being a receiving member would imply that one was endorsed (as @mattbk puts it). It would almost be like starting from a clean slate.

@tshepang
Copy link

@mattbk exposing the invitation info to the open is not kool. We don't want people being shamed in the case where those they invited started behaving badly. I also don't expect people to invite those they don't respect.

@mattbk
Copy link
Contributor

mattbk commented Apr 20, 2015

@tshepang I also don't expect people to invite those they don't respect.

I don't either, but if there's no accountability, there's no reason for me to not invite anyone who asks me, or to post an invite link on an open forum.

Since the whole idea of invite-only is blocking people out, there has to be some sort of accountability for the people who are let in. In some cases this could be a mandatory subscription fee, but since Gratipay doesn't work that way, the only power you can give users is their invite reputation/social standing.

ETA: Of course, this opens people up to potential bullying, as you said, because people respect different people for different reasons. I don't know if there's a good solution that's going to allow the community to police itself without there being bullying, but at the very least the bullying won't be through Gratipay because there's 1) only positive reinforcement (I can't take money from you, only choose to give you less) and 2) there's no communication avenue within the system that enables bullies...?

@tshepang
Copy link

there's no reason for me to not invite anyone who asks me

There is, especially if you are not familiar with their work. For such people, you could even go as far as researching them to see if they fit in with the Gratipay receiver model.

@tshepang
Copy link

there has to be some sort of accountability for the people who are let in

If the invitation system is done okay, it would not be set up such that you could simply post a link somewhere and everyone can just click and get to be a receiver. I imagine it would be done, anonymously, from within Gratipay site, to specific users. The advantage such a system is the implied trust chain... whoever @whit537 trusts is worthy of inviting others, and those in turn are worthy of inviting many more, and so on. This is similar to how the highly-respected Debian trust system works: before being allowed to upload any software into Debian, a person must have their key signed by an existing trusted person.

@tshepang
Copy link

Actually, the Debian trust system differs in that the invitation is not anonymous. Sorry for the noise.

@mattbk
Copy link
Contributor

mattbk commented Apr 21, 2015

The implied trust chain works as long as everyone has a real incentive to only invite people who will be just as responsible and discerning as they are.

How about this: If invites aren't exposed, what about requiring invites from multiple people?

@chadwhitacre
Copy link
Contributor Author

From @techtonik at e12253c#commitcomment-11011600:

Conflict, divisiveness means we have the right to ban any user who do not agree with us. But then, who are we? @Changaco did not agree with you and left. You will also need to ban me, because my persona is highly conflicting in some Internet circles.

I don't see censorship can support openness. It looks like it all started from SJW vs 8chan case, which is probably a result of gamergate, which is probably a result of some political technology testing. And as a result at least one core developer of GP is left and me is considering if I want to support this.

You know, I live in a very dark world, the world that is much closer to Fredrick Brennan than to those people who can earn $3000 a month without a sad feeling.

To resolve this gracefully, the best way is to conduct a thorough case study on this matter, keeping neutrality in the process and pause, not ban, accounts under investigation. From the business side of view, SJW and infinitechan are stakeholders. If government (who need to regulate the stuff) doesn't tell us who is guilty, and both parties provide a revenue, we need to choose one who is more profitable if there is no other choice. Let SJW side proof that infinitechan is illegal and escalate the conflict to the level where we can ban infinitechan without sacrificing our reputation and open culture.

I'd also say that this opens a door for more attacks on GP developers. Many people have their own biases and points of view. It is easy to identify them and attack. I think that GP should protect its developers, because it may happen that all of this is just a competitor's trick.

@chadwhitacre chadwhitacre changed the title make Gratipay invitation-only make Gratipay application-only May 3, 2015
@chadwhitacre
Copy link
Contributor Author

I've changed this ticket to be about making Gratipay application-only. The mechanism for approving applications could be a strong, key-backed web-of-trust system a la Debian, or another mechanism, but we don't need a separate ticket for each possible mechanism (hence I folded #194 back into here).

@chadwhitacre
Copy link
Contributor Author

If this happens, would everybody need to re-register (by accepting the invitation)? That would be an interesting approach, especially since being a receiving member would imply that one was endorsed (as @mattbk puts it). It would almost be like starting from a clean slate.

I don't think we should drop back to a clean slate. I'm thinking something like this: all current receivers have a year to apply. Any receivers that haven't applied and been accepted within a year are converted to non-receivers.

@chadwhitacre
Copy link
Contributor Author

My current thinking is that we would conduct reviews of potential applications on a periodic basis on a public GitHub ticket. I think we should batch these rather than taking them one at a time. We are basically looking for vetoes from current members. We want no -1s, as opposed to a certain number of +1s. By batching applicants together in one ticket we take some of the pressure off any individual applicant. Actually it'd be kind of like Product Hunt, wouldn't it? If one or another of the batch emerged as a controversial case, we could create a dedicated ticket as necessary.

chadwhitacre referenced this issue May 3, 2015
This is useful in light of our decision to start curating users on the basis of brand fitness.
@chadwhitacre
Copy link
Contributor Author

The clearer we can be about our acceptance criteria, the better. This is something that will take some effort to figure out. I think this is vital for the future of Gratipay, but even more vital right now is surviving the Balanced shutdown, so I'm personally going to need to let this simmer until after (if) we land gratipay/gratipay.com#67.

@techtonik
Copy link
Contributor

I thought that this ticket was about making Gratipay strictly a technical platform, with no strings attached as it was before, and with lowest barrier to entry on the Internet. Now I see that it is quite the opposite. I have a mixed feelings about that.

For me the Gratipay value was transparency and openness. Decision based on human factor and biases reduces this transparency and makes GP more like a political influence tool than financial aid instrument. Telling people that "you are behaving bad and will be banned" as well as hearing that is weird. Controlling the behavior is not fun. It is better to avoid this stuff altogether. Make a good instrument first and deal with the community matters later. RTFD is not using GP, PyPy is not using it as well. We need to concentrate on these problems first.

@jonathan-s
Copy link

I would be inclined to agree with @techtonik.

@webmaven
Copy link

webmaven commented May 4, 2015

I see problems with both extremes. A purely neutral platform (albeit one that targets a niche) presents us with branding problems that can only be overcome by liberal application of marketing dollars.

OTOH, Curation of the receivers is a problem that doesn't scale.

Perhaps we should be looking at community/platform hybrids that have managed this successfully?

@mattbk
Copy link
Contributor

mattbk commented May 4, 2015

As I understand it from #122, the platform can't be entirely neutral unless there is [money-moving service provider] willing to deal with the legal ramifications of that.

@chadwhitacre
Copy link
Contributor Author

Telling people that "you are behaving bad and will be banned" as well as hearing that is weird.

Agreed. That's why I think we should not allow poorly behaved people on the platform in the first place, so that we don't have to (inevitably) ban them down the line.

Make a good instrument first and deal with the community matters later.

In my view that's exactly what we've done. Gratipay has struggled mightily with community matters for over a year now, almost half its life.

@techtonik
Copy link
Contributor

That's why I think we should not allow poorly behaved people on the platform in the first place, so that we don't have to (inevitably) ban them down the line.

All people make mistakes by design, because they explore the universe around them. Sometimes they need a chance to recover and get back. Just need to make sure that there is a provision for the most tough of us when the world we will be ready. Because it is impossible to build an economy of gratitude based on exclusion.

Gratipay has struggled mightily with community matters for over a year now, almost half its life.

I think it gave up early. =) But it hit upon the hardest case that is available in the Internet - the conflict of communities. The worst is only the conflict of ideologies.

@webmaven
Copy link

webmaven commented May 9, 2015

@techtonik:

the hardest case that is available in the Internet - the conflict of communities. The worst is only the conflict of ideologies.

You think there wasn't a conflict of ideology between the communities involved?

@chadwhitacre
Copy link
Contributor Author

Done under gratipay/gratipay.com#3399.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants