Difference between revisions of "Milestone 3 researchinprogress TrustIdea 2:Rejection Lock"

From crowdresearch
Jump to: navigation, search
 
Line 3: Line 3:
 
----
 
----
  
[[File:T2.png|1000px|thumb|left|Flow chart of trust idea 2, Rejection Lock.]]
+
[[File:T2.png|1000px|thumb|center|Flow chart of trust idea 2, Rejection Lock.]]
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
  
 
The question should be clearly given, in a clear language, so that a Worker knows what the exact task is. The possibilities which could lead to rejection should be mentioned.  
 
The question should be clearly given, in a clear language, so that a Worker knows what the exact task is. The possibilities which could lead to rejection should be mentioned.  

Latest revision as of 14:09, 18 March 2015

Rejection Lock (Rejection reasons should be valid)


Flow chart of trust idea 2, Rejection Lock.

The question should be clearly given, in a clear language, so that a Worker knows what the exact task is. The possibilities which could lead to rejection should be mentioned.

Workers should not be rejected for petty reasons, that is, if there is a small error in the job, the requestor should be elaborate on the mistake the worker has committed and should be helpful in resolving the issue in a “x” manner.

This is because a job rejection puts a permanent rejection mark on the profile of the worker and affects their reputation for other jobs. Workers should be able to know why they got rejected, if they feel they should’ve been paid. The worker should have the confidence that in case he faces a problem, he can freely question the requester in an easy manner. Requesters should thus be available to be contacted and should respond to the workers properly, and within a certain time. This can be done by introducing easy chat-like portals on sites like MTurk.

Sometimes it might happen, that a worker completes a task, but not within the time limit. However, there is a possibility that the work quality is very high and the time limit exceeds only slightly. Requester should not reject the work then but rather offer this much flexibility to the workers and pay them even if the time limit exceeds for quality work. Requesters should thus be provided with an option to accept certain ‘exceptional’ cases if they like. Similarly, the requester should be able to change the HIT prices for exceptionally good work.