Milestone 3 PixelPerfect TrustIdea 1: Social Graph System

From crowdresearch
Jump to: navigation, search

Social Graph System

Compatibility


In an attempt to make worker-requester relations more transparent and important, we apply the Facebook social graph model to conceptualize worker-requester relations. We create a crowdworker graph whose nodes are requester and workers, and the extent of their relation (compatibility) is modeled by the edge weights.

Compatibility plays a role in how visible a given requester’s HIT is, to various workers. Workers having higher compatibility with the requester are more likely to see the HIT and therefore take it up.

Compatibility develops through a feedback system between workers and requesters after completion of a task. It is centralized around a simple Yes/No question :

  • Would you like to do a task from this requester again? [For workers]
  • Would you delegate a task to this worker again? [For requesters]

Picture5.png

Feedback System


We could characterize a good feedback system by :

  • Feedback forms must be designed to be simple and as non-disruptive to the workflow as possible. Ideally only mouse interaction should be required to fill in the forms.
  • Could be compulsory for novice and mature users and optional for expert users.
  • Unfilled answers should not affect the rating of the requester/worker in any way.

Picture4.png

Worker Feedback

There will be a two-stage feedback – one during completion of task and the other, after its completion.

  • First stage of feedback for workers involves them rating the clarity of the instructions, if the task was appropriately priced and whether optimum time was given for the task.
  • Second stage involves requesters being rated on the promptness of their payment and their professionalism in general (mass rejections, feedback given to workers)
  • An upvote/downvote option inspired from Quora, signifies the overall experience of the worker with that requesters, querying whether he would like to work for said requester again. This can be implemented through a radio/flat button.

Requester Feedback

Requester feedback has only one stage which involves him rating his satisfaction with the submitted work.

  • Promptness can be judged by the system.
  • There is no during-task feedback.
  • A similar upvote/downvote option signifies the overall experience of the requester with the worker, querying whether he would like the worker to do another task for him.

Addendum : Role of Compatibility in HIT Visibility


HITs can be modeled as posts on Facebook, liking or commenting a post is analogous to accepting a HIT by the worker. On Facebook, the posts visible to users are determined by the EdgeRank algorithm, which is a function of affinity, weight and time decay. On the platform we develop, the HIT visibility is determined by :

  • Worker-requester compatibility determined from the Social Graph (Affinity)
  • Importance of task to worker determined from skillset, task preference and time/money payoff (Weight)
  • Tasks whose deadlines are approaching given more preference (Time Decay)

Finally a randomized algorithm scrambles and sorts these HITs and chooses which ones are visible to the worker, in which order. Picture3.jpg