-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TechRaptor #17
Comments
No, for two reasons:
Objections? |
Hearing none ... |
Subject: your Gratipay Team application for TechRaptor
|
Response from TechRaptor: https://gratipay.freshdesk.com/helpdesk/tickets/2735 (login required). |
TechRaptor has posted some more detailed feedback at http://techraptor.net/content/a-warning-on-gratipays-application-process. I don't think this post qualifies TechRaptor as "haters," which is why I am including it here. I'm glad you reopened this issue, @whit537, because I think there does need to be a little more rigor to the selection process. My suggestion going forward would be to reach out to the applicant if the assessment is bending towards a rejection (at this point). This might require a somewhat different timetable for reviewing applications in order to keep "application in progress" time to a minimum. |
Okay! First, a point of order: I shouldn't have reopened this post, because that makes it seem like the application is un-rejected, back in a "pending review" state. In fact, I had only meant to have it hit the queues again so I remembered to deal with it. Sorry. Reclosing ... |
Second, I agree, and I believe this will be ably handled by gratipay/gratipay.com#3568. Once we land that, these review tickets will be generated automatically when the user clicks "Apply," they will be cross-linked in the database with the Team application, and the owner will immediately be shown a message describing the team review process and linking to the review ticket (rather than the cryptic "we will email you" we currently display). |
Third, I think our ideal with team review is in fact to come to a mutual understanding with applicants about whether or not we're the right fit for each other. Therefore, engaging applicants in the review process as early as possible is important. That said, the applicants we'll reject are precisely those with whom we'll have the least "shared language" (as it were), and are therefore the ones with whom prolonged conversation will become a waste of everyone's time. It is not the purpose of team review to convert applicants to Gratipay's worldview, but rather to identify applicants who already share our worldview. |
Fourth, it's okay to let applicants chew on a rejection, potentially in public, as a way to take it on board. With the caveat that we should engage them in conversation, or at least make them aware of where our conversation is happening (namely, here), much earlier in the process than we have been—I say, with that caveat, nothing requires us to continue conversing with applicants once we reject them. Think of it this way: conversing with rejected applicants takes precious time and attention away from the teams we accepted, whom we clearly ought to prioritize. |
Now, fifth, to Rutledge's post: it's a great demonstration of why this was an appropriate rejection, because, while he does have an inkling why we rejected TechRaptor, he's prevented from fully assenting to it because his worldview is so at odds with Gratipay's. The post starts by wrestling with our first assertion, "identify[ing] with the #GamerGate/anti-#GamerGate conflict [...] clashes too strongly with our own brand identity." Predictably, Rutledge gets hung up on thinking that we're pegging TechRaptor to one side or another in the conflict. But then, a glimmer of understanding:
Ooh! So close! But then he slips back into the mental rut: "The problem with that is the fact that we don’t identify as being pro or anti GamerGate." "The link they provide is just a tag of various GamerGate related events we have covered. We likely don’t need to go into why that doesn’t make a lot of sense[.]" It can't make sense, within the worldview of TechRaptor, that once a conflict has passed a certain threshold of violence and vituperation, most who name it, feed it. Reconciliation is a delicate art, and journalism is not well-structured to practice it. What's more, Gratipay's value of "discussion and deliberation as means of reconciling wills and making decisions" assumes the context of a deliberating body in a decision-making forum: a context alien to journalism, nearly by definition. As to our second reason, that TechRaptor doesn't provide open work, Rutledge's post contains a number of questions (I count 10) which together show a basic unfamiliarity with open culture:
What if the answer was ... yes!? 💃
This was my favorite part. Yes! It would be really cool! Wouldn't it? And would you believe there's people out there who would actually do that!? 👯
Depends. How much money are they taking? If relatively little, then what's the harm? They get to learn, and, more importantly, to belong.
Then eventually prune them from the team.
No.
No, it is not no longer considered Open Work.
Yes.
Yes, they can be asked not to be a part of the Team any longer. It would not go against Open Work.
No. You could ban problem contributors in extreme circumstances.
No, that is not enough. People need to be able to contribute meaningful work without your explicit permission. Practically speaking, that means you need a public listing of available work (e.g., an issue tracker on GitHub, etc.), and some kind of self-onboarding documentation. In other words, Rutledge is right:
I'm not saying he couldn't come around. I'd love it if he did! Collaborative society needs journalists. Again, though, it is not the purpose of team review to convert one another.
!m TechRaptor :-) |
To: [Rutledge]
|
I think a major issue here is you're not communicating this to prospective clients. You answered several good questions in response to TechRaptr's article, but this is the first and only place answers like that have seen the light of day. You're coming off a major transition of brand, and at no point have you stopped and defined exactly who is still welcome and who is not. So far as I can tell, you define "Open Work" a grand total of twice. Once in your T&C and once on a page labeled "Manage Risk," a single page among dozens that is not directly navigated to for prospective team owners. You define Open Work in the following two ways: "Open Work means that the Team provides a clear path for any individual to voluntarily begin contributing to the Team's work and to share in any revenue the Team generates." and "We define “open work” as work that individuals can begin to perform without requiring explicit permission from the company offering it, with a clear path to further engagement and eventual compensation." What constitutes contributing? Where's the cut-off when team owners are too protective of the end-product that it no longer qualifies as Open Work? How does this apply to projects whose scope is not easily quantifiable? To creative content, to journalistic endeavours? And, more to the point, how does this apply to the people who formerly enjoyed your service under Gratipay 1.0? The people to whom you promised "We are hoping to quickly approve as many users of the old Gratipay as possible." It is possible for a Team Owner to have a different definition of 'contribution,' 'Open Work,' and 'revenue sharing' than you do. In fact, it's extremely likely that their definition will be different because you don't seem to publish yours. The problem arises when you start denying service on the grounds of those differing definitions with no explanation or hope for reconciliation. This is precisely what you have done to TechRaptr, but you've then stated that having a conversation about those differences of opinion is " a waste of everyone's time" despite your brand value of "direct interpersonal communication." You have answers scattered in a hundred different places. You have some here, some (VERY few) on gratipay.com, some on medium.com/gratipay-blog and yet here you are ridiculing--yes, ridiculing, an action directly against your proposed values--applicants for "a basic unfamiliarity with open culture," a concept which you yourself repeatedly fail to define in any real terms. Your brand values are flowery words that offer no real guidelines. You have no concrete grounds for extending or denying service to applicants other than what appears to be a gut feeling on whether your worldview is shared by them. You have no document that you can point to and say "You were denied for reasons X, Y, and Z." You do not practice the value of open communication that you so espouse. Your website has no logical roadmap that can guide potential clients to an educated decision. These words come from a place of love, but also from a place of frustration. I hope you take them as the constructive criticism as they are intended, but I fear you will simply label me a "hater" and refuse to acknowledge your own flaws. You are alienating client through sheer lack of information and communication and you are utterly failing to live up to the brand values you espouse. |
Hturing hits it on the head, one of the reasons I opened gratipay/gratipay.com#3670. |
Sysadmin of TR here (not owner, just the tech guy) I actually really like how your group is helping opensource developers! That's pretty awesome! I think the core problem here is the specific wording of the definition of open work. "Open Work means that the Team provides 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 "clear path" meaning a transparent, obvious, fairly straightforward, and reasonable path. You submit work to the project, initially via email, and if it matches quality standards, it is included, and you are given login credentials to have direct access to the whole platform (WordPress). If it doesn't match standards, the work is rejected and you're welcome to fork the project by installing whatever platform you choose on your own server, and make your own contributions to the journalism or review community. We currently have no custom in-house codebase to share, as we use opensource, primarily FOSS, and the opensource we don't share is because we are licensing a few minor technologies ( a redirect manager from yoast for example) that really aren't necessary. As TR's overall goal is to improve Technology and Gaming journalism in general, there are absolutely no issues with alternative domains existing, and infact we often give free direct technical support to alternative sites. It seems like there is a hangup because the initial work contribution is over email instead of automated account creation. I'm not asking you to include TR in your project, I'm asking if you can reword your definition of openwork to be more concise and specific as to what you mean. This is your project, and you're welcome to run it however you want, but please, please just clarify your documentation for requirements. |
Comments on neutrality of TechRaptor toward #GamerGate: https://gratipay.freshdesk.com/helpdesk/tickets/2834 (login required). |
https://gratipay.com/techraptor/
The text was updated successfully, but these errors were encountered: