-
Notifications
You must be signed in to change notification settings - Fork 38
make Gratipay application-only #187
Comments
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. |
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. |
@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. |
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...? |
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. |
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. |
Actually, the Debian trust system differs in that the invitation is not anonymous. Sorry for the noise. |
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? |
From @techtonik at e12253c#commitcomment-11011600:
|
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). |
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. |
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. |
This is useful in light of our decision to start curating users on the basis of brand fitness.
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. |
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. |
I would be inclined to agree with @techtonik. |
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? |
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. |
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.
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. |
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.
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. |
You think there wasn't a conflict of ideology between the communities involved? |
Done under gratipay/gratipay.com#3399. |
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).
The text was updated successfully, but these errors were encountered: