It would be great if batches could be edited after they are uploaded and running.
For instance, adding more images to the batch or removing images that are sufficiently annotated in terms of this particular task.

Please add a wiki item on the Ct:webhook call (DrDetective - app - commands - CTWebhook)

When creating a new user:

Division by zero (View: /var/www/BioCrowd/app/views/sidebar.blade.php) (View: /var/www/BioCrowd/app/views/sidebar.blade.php)

Line number 35

Requirements:

• Clicking and getting a dot instead of a square
• Drag to create a bounding box
• Avoid 'Save' dialog after drawing a bounding box

If annotorious won't do it, consider using these libraries:

• http://zurb.com/playground/javascript-annotation-plugin
• http://flipbit.co.uk/jquery-image-annotation.html
• https://code.google.com/p/paintweb/

Or even just doing our own based on HTML5 canvas:

• http://vombat.tumblr.com/post/255461929/draw-rectangles-with-canvas-tag-in-html5
• http://atomicrobotdesign.com/blog/javascript/draw-a-rectangle-using-the-mouse-on-the-canvas-in-less-than-40-lines-of-javascript/

Provide an option to pause uncompleted tasks and resume them later.

This is useful to send the users e-mails to remind them to finish and to see how many people are not finishing tasks. Being able to interrupt a task or recover from browser crash are other possible advantages.

This feature might be a lot of effort for very little benefit and needs to be discussed.

Campaigns feature needs to be implemented.

Loosely defined, a campaign is a chain of tasks to be completed one after the next. A more structured definition of campaigns is required.

Creation of VerificationTask on completion of AnnotationTask.

Jquery.js file on public is blank and should be removed.

But removing it causes a bug on firefox. Fix the bug then remove it.

Currently, the INVITE_CODE is hard coded on LoginController. Ideally this should come from database (with a configuration option on the admin interface).

Maybe we can use something like this: https://github.com/patkruk/Laravel-Cached-Settings

Or use a Settings model of our own.

Scoring system needs to be defined and implemented. The following considerations need to be taken into account:

• When and how many points are given to each user for each task?
• Are level, task type (or perhaps even specific task!) factors which affect the number of points given?
• When, why and how many points are substracted from a user?
• When and in which format are scores displayed?
  • As a total score on the user mini-profile (next to name and level)
  • On the leader board?
  • On the 'last 5 days' trend graph (number of points per day) ?
  • On a summary page (+X points for task A, +Y points for task B, -Z points for task C).

At the moment, code base is still quite small, but we need to keep documentation up to date as much as possible. It might be easier if we have good documentation since the beginning and we add to it as the code base grows, rather than waiting until the code base is larger and the documentation effort will be huge.

app/lang/en/gamelabels.php contains a hardcoded URL for the game location on crowdtruth.org. This breaks some links when running it somewhere else.

When we are ready to make a first 'stable' release, we should:

• Remove DevelopDBSeeder for final release
• Set $adminUser and $adminPassword to some 'reasonable' initial value (and document it somewhere!)

Right now, a next campaign is selected based on the amount of judgements a user has for this campaign for each game in the campaign.
The game in the campaign that has the least amount of judgements is then chosen as the next game.
This system is good in theory, but it requires each judgement in the judgements table to have a campaign_id and a game_id to be added to it, and if a user finishes a game that is in 2 campaigns, we want both campaigns to be updated.
This means that two judgements need to be made: one for campaign A and one for campaign B.
Two judgements are made, but only one judgement is really done: the user only makes one judgement for one image by clicking the submit button once.
This is ugly and should be done in a better way.
Maybe make a seperate table with user_id, judgement_id, game_id and campaign_id, and then having the same judgement_id appear twice in this table if it was for two different campaigns.

Remove locks when user can play the level of games.

To be defined:

• Whether a player an or cannot play games of a higher level
• When players 'Level up' and what it implies

VesExGameType and CellExGameType could (should? must?) have more intuitive / generic names and descriptions.

Currently these GameTypes are (according with their descriptions) used for:

• Extracting cells from microscopic images
• Extracting vesicles from microscopic images

However, the could have a more generic description, for example "Adding box annotation to images".