You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: