wiki:BossaReference

Version 7 (modified by davea, 16 years ago) (diff)

--

Bossa reference manual

Abstractions

  • A Bossa project has one or more applications.
  • A application has a dynamic set of jobs.
  • An application has a dynamic set of batches, which are used to group jobs.
  • Each job has a set of job instances, in progress or completed.
  • A user is a person who volunteers to perform jobs.

Each of these is represented by a table in a MySQL database.

Jobs may be marked as calibration jobs. These are jobs for which the answer is known in advance; their purpose is to estimate the accuracy of each user. Each application has a calibration job fraction; this is the probability with which calibration jobs are assigned.

Each job has a state, one of:

BOSSA_JOB_EMBARGOED: the job is not yet eligible to be issued.

BOSSA_JOB_IN_PROGRESS: the job is eligible to be issued.

BOSSA_JOB_DONE: the job has been finished successfully.

BOSSA_JOB_INCONCLUSIVE: the job has finished unsuccessfully (typically because a consensus was not reached).

Each job has a floating-point priority. Jobs are assigned to users in order of decreasing priority.

Each job, job instance, and user has an associated app data - a PHP structure whose contents are determined by the project, not by Bossa. These structures are stored in the database.

For jobs, the app data typically contains the information needed to display the job to a user - e.g., the name of an image file. For calibration jobs, it would also contain the correct answer.

For instances, the app data typically contains the user's response to the job.

For users, the app data typically contains a representation of the user's "skill", possibly including:

  • their score on a training course
  • their performance on calibration tasks
  • their performance based on validation

If a project has multiple applications, it should keep separate data for each applications.

User categories