Skip to content
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

Mediation of disagreements on Daemo #35

Open
mbernst opened this issue Dec 22, 2017 · 0 comments
Open

Mediation of disagreements on Daemo #35

mbernst opened this issue Dec 22, 2017 · 0 comments

Comments

@mbernst
Copy link

mbernst commented Dec 22, 2017

Problem

As we start to have requesters on the platform who we don't know, there will inevitably be disagreements over work quality. Currently the system says for the worker to email [email protected] if they wish to contest a return/rejection decision, but this is clearly not the right move: we may be making ad-hoc decisions without a strong policy articulated yet, we don't have the bandwidth to do a ton of these, etc. And AMT's approach is worse, giving the requester final say.

We don't yet have an articulated, fair approach for dealing with disagreements.

Proposal

This proposal suggests that we more formally develop a mediation strategy for these disagreements. As a starting point, I would suggest going with the workers' idea (I think it was Spamgirl's?) for contestation to convene a jury of workers/requesters to determine who is right. We would need to think through a policy on how contesting a result / mediation will work, if anyone will be paid and if so by whom, and if appeals are possible.
I think it's important that we have such a policy in place as we grow. It protects workers. We can of course begin by wizard-of-ozing some of this (recruiting the jury, etc.) and eventually build up a code path for it as we become certain it's the right approach.

Further down, we would generalize this to other kinds of disagreements beyond disagreements about work quality on a single project.

(This proposal is not about disagreements within the SRCC --- this is about disagreements between platform users.)

Implications

Short-term: This increases the time burden on us to develop this policy, even though we don't have a firm need for it with a disagreement this week. So we trade off some time short-term.

Long-term: not having a clear policy here is a ticking time bomb of trust. It just takes one poorly-handled case to explode and give the platform a bad reputation. Getting ahead of it will be very, very important in my opinion.

Contact

  1. Add your Slack username, and if appropriate, a Slack channel where discussion is taking place.

To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.

@mbernst mbernst added this to the Strategy milestone Dec 22, 2017
@mbernst mbernst self-assigned this Dec 22, 2017
@markwhiting markwhiting self-assigned this Dec 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants