Difference between revisions of "Milestone 6 Sky"

From crowdresearch
Jump to: navigation, search
(Created page with "in Progress ..")
 
Line 1: Line 1:
in Progress ..
+
=== System  ===
 +
 
 +
In this part, we describe how different modules come into play interacting with each other and with the worker and requesters. In the following synopsis we have tried to describe the activation of each module and how each can serve the other modules or receive the service from them.
 +
 
 +
[[File:flow.png|800px|center]]
 +
 
 +
=====Flow-Synopsis:=====
 +
 
 +
The Players of the systems are workers, requesters and modules that are activated in different epochs of the system.
 +
In the first place the requester enters the system and wants to create the task. It starts from the task creation interface. The task creation interface leads the requester to some Validator template Wizard Studio, which is mainly designed to enable automatic and systematic validation of the tasks as well as training the requester to have more reliable, and descriptive tasks over time.  The output of the validator is fed into the quality agreement generator, to help filtering certain parameters in worker selection, and also it leads to creation of a verifiable task, after the creation of the task, the requester is waiting for the workers.
 +
 
 +
The workers start by introducing themselves to the system by subscribing to some task categories, or requester categories based on their interest .The tagging system and subscriber is one of the modules that can updates the recommender module and serves it as an input by matching the worker with the task categories or requester categories that the worker has subscribed in. The recommender module collects the data from CSP database based on previously completed tasks and their statistics as well as worker-requester statistics. The recommender module forwards its data as an input to the task feed. The worker is now ready to search for the jobs.
 +
 
 +
The worker queries the task feed, selects a task that he/she likes and then the worker is forwarded to query the PQM interface. The PQM interface decides whether the worker is “qualified”, “underqualified” or “overqualified”. If the qualifications match, the worker can start a task and  it goes to Quality Requirement Agreement Module. This module enforces some of the requirements that a requester is concerned and strict about. If the worker agrees with the quality agreements then they can accept the task and go to the next level, otherwise the worker can dispute those agreements or express their concerns about these requirements on the Forum. The requirement agreements are generated by on the Quality Agreement Generator. The Quality Agreement Generator itself is generated by the constraints and validations that the requester enforces in the Validator Wizard Studio.
 +
 
 +
If the worker is identified as “overqualified” /(“unqualified” )by the PQM module, then he/she should offer a  higher/(lower) price respectively as well as a justification, reasoning their eminent skill or lack of skill  and sends it to the Three-Price offer System. The worker, based on his/her qualification can bid for the price of a task and waits for the requester to accept.
 +
 
 +
When the worker is accepted, then it starts completing the task, which is by nature validable. The result of the task, goes to the template validator parse. The Validator Template Parser, is generated based on the Validation resources that the requester seeks in the Validator Wizard Studio and provides those resources. If the validator parser, should be given moderators, then it consults the recommender system for moderators, and once given they are asked to review the results and send their reasoning to the Delivery filtering system. If the parser enforces extra workers, then the same task are given to those workers and the results are sent to Delivery Filtering System.
 +
 
 +
In the further step a survey about the task is given to the worker. The survey is created by CSP collector and one of its goals is to evaluate the task.  The evaluation is fed into CSP database, to keep records of the tasks and also it is give as a feed back to task validator modifier, whose job is to train the requester for creating more descriptive and clear tasks. In this way the use of task validators improves over time
 +
and the system guarantees well trained requesters.
 +
After doing the survey, the result of the survey can be imported to CSP database and update the profile for the requester. At any point after the completion of the survey, the worker can receive a quick feedback. The worker can ask questions about the feedback on communities in Micro-Forum and the Micro Forum can reflect the problems to the Validator Module so that the requester knows what has been the problem.
 +
The quick feedback is not the complete feedback and the worker should wait for the complete results to come in.
 +
 
 +
The Delivery system filters the results and send them to preview generator module and now the requester can preview the results. If the requester approves the results which are partially validated automatically by the system and guaranteed to be acceptable, he/she then prepares a payment and a reward to the worker as well as the approval letter. The worker can receive the final feedback report generated by Result Feedback Generator as well as the payment. The requester can now apply the task results to his/her field or purpose and rewards the worker. The worker at this phase is waiting to the get results and feedbacks and in case of approval is provided with money, approval and reward.  If the task is rejected, the feedback generator prepares a rejection letter. In either of these scenarios the results are reflected to CSP database and update the profile builder module and the lifetime of the task is ended.

Revision as of 00:13, 9 April 2015

System

In this part, we describe how different modules come into play interacting with each other and with the worker and requesters. In the following synopsis we have tried to describe the activation of each module and how each can serve the other modules or receive the service from them.

Flow.png
Flow-Synopsis:

The Players of the systems are workers, requesters and modules that are activated in different epochs of the system. In the first place the requester enters the system and wants to create the task. It starts from the task creation interface. The task creation interface leads the requester to some Validator template Wizard Studio, which is mainly designed to enable automatic and systematic validation of the tasks as well as training the requester to have more reliable, and descriptive tasks over time. The output of the validator is fed into the quality agreement generator, to help filtering certain parameters in worker selection, and also it leads to creation of a verifiable task, after the creation of the task, the requester is waiting for the workers.

The workers start by introducing themselves to the system by subscribing to some task categories, or requester categories based on their interest .The tagging system and subscriber is one of the modules that can updates the recommender module and serves it as an input by matching the worker with the task categories or requester categories that the worker has subscribed in. The recommender module collects the data from CSP database based on previously completed tasks and their statistics as well as worker-requester statistics. The recommender module forwards its data as an input to the task feed. The worker is now ready to search for the jobs.

The worker queries the task feed, selects a task that he/she likes and then the worker is forwarded to query the PQM interface. The PQM interface decides whether the worker is “qualified”, “underqualified” or “overqualified”. If the qualifications match, the worker can start a task and it goes to Quality Requirement Agreement Module. This module enforces some of the requirements that a requester is concerned and strict about. If the worker agrees with the quality agreements then they can accept the task and go to the next level, otherwise the worker can dispute those agreements or express their concerns about these requirements on the Forum. The requirement agreements are generated by on the Quality Agreement Generator. The Quality Agreement Generator itself is generated by the constraints and validations that the requester enforces in the Validator Wizard Studio.

If the worker is identified as “overqualified” /(“unqualified” )by the PQM module, then he/she should offer a higher/(lower) price respectively as well as a justification, reasoning their eminent skill or lack of skill and sends it to the Three-Price offer System. The worker, based on his/her qualification can bid for the price of a task and waits for the requester to accept.

When the worker is accepted, then it starts completing the task, which is by nature validable. The result of the task, goes to the template validator parse. The Validator Template Parser, is generated based on the Validation resources that the requester seeks in the Validator Wizard Studio and provides those resources. If the validator parser, should be given moderators, then it consults the recommender system for moderators, and once given they are asked to review the results and send their reasoning to the Delivery filtering system. If the parser enforces extra workers, then the same task are given to those workers and the results are sent to Delivery Filtering System.

In the further step a survey about the task is given to the worker. The survey is created by CSP collector and one of its goals is to evaluate the task. The evaluation is fed into CSP database, to keep records of the tasks and also it is give as a feed back to task validator modifier, whose job is to train the requester for creating more descriptive and clear tasks. In this way the use of task validators improves over time and the system guarantees well trained requesters. After doing the survey, the result of the survey can be imported to CSP database and update the profile for the requester. At any point after the completion of the survey, the worker can receive a quick feedback. The worker can ask questions about the feedback on communities in Micro-Forum and the Micro Forum can reflect the problems to the Validator Module so that the requester knows what has been the problem. The quick feedback is not the complete feedback and the worker should wait for the complete results to come in.

The Delivery system filters the results and send them to preview generator module and now the requester can preview the results. If the requester approves the results which are partially validated automatically by the system and guaranteed to be acceptable, he/she then prepares a payment and a reward to the worker as well as the approval letter. The worker can receive the final feedback report generated by Result Feedback Generator as well as the payment. The requester can now apply the task results to his/her field or purpose and rewards the worker. The worker at this phase is waiting to the get results and feedbacks and in case of approval is provided with money, approval and reward. If the task is rejected, the feedback generator prepares a rejection letter. In either of these scenarios the results are reflected to CSP database and update the profile builder module and the lifetime of the task is ended.