BluePrint for Human Intelligence Task processing (a.k.a. "Job Jar")

Motivation

During a disaster, people on the scene may report via social media or text messages. Emergency managers might find useful information there, but it's buried in large quantities of incomplete pieces, possibly not in a language known to the EM personnel. Much of this work is not easily automated, e.g. determining whether a message is a request for aid (and specifically what and how much and where). In order to clean up this crowdsourced information, we need...another crowd, but one that's trained, or at least learns as they go, and whose work is cross-checked for accuracy. A similar need holds for data gathering done by volunteers.

These are called "human intelligence tasks" (HITs), and what we want to produce is a system for managing them. Examples of HIT platforms are Amazon's Mechanical Turk and Crowdflower. We want a system tailored to the needs of emergency managers, and to working with crowdsourced data during emergencies.

See also: ​http://www.playsourcing.org/ (only s/Ushahidi/Sahana Eden/ ;-) And in June, see article on Playsourcing in: ​http://www.crcpress.com/product/isbn/9781439853498

We're suggesting this for GSoC, but the whole thing would be too big for one GSoC project -- one or more subsets can be split out into GSoC projects.

Overview

We would like to manage human-intelligence tasks, e.g. data entry, cleaning crowdsourced data. This involves:

• Figure out how to specify a task, and provide a UI for defining tasks.
• Allow reading data for tasks from specified sources.
• Assign tasks to workers based on skills and / or measured performance, or let workers select tasks.
• Provide tasks to users in a web form.
• Compare results of multiple workers on the same task.
• Decide when a task is sufficiently complete.
• Insert tasks with known results as tests.
• Evaluate worker performance.
• Administer training and testing for new workers.

Project breakdown

These are some suggested ways to split the project into somewhat independent pieces.

Task definition

Each overall job to accomplish one purpose will have its own specific set of input data, its own instructions to workers, its own way for workers to enter results, and its own needs for how much verification is needed. Rather than hard-wire a few sorts of task types, we'd like to let the people who need the work done specify these things. To permit this, we might need to...

Figure out what information is needed to specify a task. This might include:

• Specify the task input data source(s).
  • Note: The actual connection to the data source, and the process of reading from it, should be isolated. This is not specific to this project -- reading from a remote feed can be used for many purposes. Here, we could assume that the data is being placed in one or more database tables, or in files on the server.
  • Most commonly each task will operate on one item of data -- can assume this to start.
• Provide instructions for workers.
• Specify what worker skills are needed.
• Specify how many workers should receive each task, and how many need to agree on the result for it to be accepted.
• Specify the web form tools that the worker will need to enter results, e.g.:
  • Text input.
  • Radio buttons or exclusive select from a list.
  • Multi-select boxes or list.
  • Combo-box, i.e. either exclusive or multi-select, but also allow adding a new option.
  • Selection of locations on a map.
• Specify constraints on the results, especially ones that can be checked in the form, such as:
  • Data types for text fields (date, number with range, ...)
  • Multiple selections that make sense together.
• Specify how to compare results from different workers -- when do the results match?
• Assign experts who can handle difficult cases and verify a sampling of results.

Decide how the task setup should be stored, that is:

• What database schema is appropriate?
• For a general task, with arbitrary data sources and arbitrary form fields and layout, we may need a data structure beyond just fixed fields in a single table. This might be implemented in various ways -- options include:
  • An XML specification.
  • A database schema using multiple tables.
  • A form template.
• How does it fit in with other Eden components? What other pieces can we use directly or crib from?

To start, tasks could be defined by editing a setup file. Later, we can provide a web form or wizard that allows the administrator to enter the task setup information. This isn't just for the administrator's convenience -- we can also better guarantee correctness of the setup. E.g. if the user specifies connection info for a data source, we could test the connection on the spot.

To assist people in setting up tasks, we can provide some sample task definitions. We could mimic crowdsourcing activities that occurred in actual emergencies.

Managing the task queue

The task queue is the core workflow for processing tasks. It gets data items from input sources and moves them through the various processing stages to completion.

The overall flow would be:

• Identify new items of data that have not been processed.
• Pick one or more appropriate workers for each.
• Present the tasks to the workers.
• Allow workers to refuse tasks.
• Receive their results.
• Do any automated checking -- push back obviously invalid results.
• Store results.
• Record completion of tasks when there is enough consensus on the results.
• Record task failure if there's not enough agreement.
• Dispatch failed tasks and a sample of successful tasks to experts.

The task queue will be driven by the input data. Actually reading the data from a remote source is "beyond the scope" of this project -- that would be a common process needed by other Eden components as well. If we don't have a component for reading from a particular source that we'd like to support, we can mock reading from it (e.g. by downloading a batch of data or generating fake data and having a cron job add it to appropriate source data tables).

Assigning tasks to users

There are several conditions for assigning tasks to workers.

• They should be signed up to work on tasks, and maybe on specific kinds of tasks. That is, there will be other people registered as users, so we need to identify those who are HIT workers.
• We should let HIT workers say when they're available to work -- that might not be the instant they log in, and they'll want to take breaks.
• An inactivity timer might be needed to detect whether the user has dropped offline or is stuck on something.
• Workers will have different skills, and different levels of ability and training on those skills. For production work (not training), we'd want to assign tasks that are appropriate for each worker's skills and skill level. The requirements for skills will come from the task definition.
• If the task definition calls for it, we'll need to dispatch each task to multiple workers.
• We need to track who has worked on what task, even if they declined it, so that we don't assign a task to a worker more than once.

Sometimes the assignment might be adjusted (these are beyond the basics):

• When we're training new workers, we might want to give them tasks to practice on even if their level of ability isn't high. We might not even count their results toward completion of a task, but just compare them against the other assigned workers.
• Experienced workers with higher performance ratings on a task might need fewer other workers assigned to the same task. Eventually a worker might be promoted to "expert", and become a reviewer for other workers.
• If the task instructions change, we could inject a notification. Could also use this to prompt the worker to take breaks or deliver performance "rewards".

There is a volunteer management component in Eden that is currently under revision. It has simple support for specifying worker skills, and can also serve to identify HIT workers. So that work on this project is not affected by changes, we can fork the volunteer component and modify it as needed. Any useful or necessary mods can be fed back in to the new version later.

Presenting tasks to workers

The task will need a form that displays the data to the worker and accepts their answer.

• The form should be assembled based on what's specified in the task definition.
  • Appropriate means of displaying the data.
  • Widget that implements the required input method.
  • A way to make instructions and help info available without distracting an experienced worker.
• The worker should be allowed to decline a task in case they don't think they can do it.
• Letting them annotate the task with comments or concerns could be helpful in diagnosing problems with the input data, or with the HIT system.
• Customizing the layout or look-and-feel might improve usability.
• A means of contacting the user via the form could help in determining if they're still online and active.

Collating, comparing, verifying results

Evaluating worker performance

Registration and training of workers

Basic registration is already available, and there is support for volunteer signup that we can customize. Administrators can list skills they're interested in and volunteers can say what skills they have. We'll need to add whatever fields we want for performance tracking.

There are two parts to training:

• Using the HIT system. This will be "our" part of the training.
• Performing the specific task. This will be the responsibility of whoever defines the task. But we can assist by providing sample training procedures to go with our sample tasks.

Providing feedback

Some suggested subsets for GSoC

This are several pieces that can probably be done independently:

• Implement the task queue. This is the "backbone" of the project.
• Task definition seems like it could be paired naturally not just with the UI for for setting up tasks, but also with generating the task presentation forms, since they're based on the task definition.
• Performance evaluation and feedback might be paired with training, especially if we use actual tasks as part of training.

---

BluePrints