Taskable volunteers 01

Taskable volunteers 01 preview image

1 collaborator

Denis_havlik Denis Havlik (Author)

Tags

crowdsourcing 

"This model shows the difference between crowdsourcing and crowdtasking"

Tagged by Denis Havlik over 10 years ago

crowdtasking 

"This model shows the difference between crowdsourcing and crowdtasking"

Tagged by Denis Havlik over 10 years ago

volunteers 

Tagged by Denis Havlik over 10 years ago

Model group Volunteers | Visible to everyone | Changeable by the author
Model was written in NetLogo 5.1.0 • Viewed 574 times • Downloaded 75 times • Run 0 times
Download the 'Taskable volunteers 01' modelDownload this modelEmbed this model

Do you have questions or comments about this model? Ask them here! (You'll first need to log in.)


WHAT IS IT?

This model shows how some anomalies or artefacts are spotted and reported by volunteers. It concentrates on the difference in observing efficiency between taskable and non-taskable volunteers.

The aim of the model is to illustrate the importance of crowdtasking in volunteer management.

HOW IT WORKS

Volunteers walk randomly around and report whenever they see an anomaly. Depending on the value of "Nr-confirmations", one or more reports are required until the anomaly is considered "resolved".

  • Taskable volunteers will be directed towards nearby already discovered anomalies
  • If "error-perc" > 0, some of the reports will be false.
  • If "Nr-consensus" > 1, the anomaly finding has to be confirmed (reported more than once, by different volunteers.

Every time a volunteer reports a new observation, it will "grow". Or, to put it differently: "the volunteers grow with the resolved tasks".

HOW TO USE IT

Model offers various buttons and sliders:

  • Reset, Run and Step 1 buttons have the usual meanings.
  • Nr-issues determines the number of issues which need to be discovered.
  • No-confirmations determines the number of required report confirmations
  • error-perc determines the probability that a single report will be wrong

  • Size-world determines the size of the world in patches (both x and y dimension)

  • R-discover determines the distance from which the issues can be spotted by volunteers.

  • R-task is the initial geo-fencing radius for taskable volunteers. Volunteers will only be sent to confirm findings within this radius.

  • Adjust-tasking-radius? switch enables or disables the automated R-task adjusting function.

Two more sliders are on the right-hand side:

  • Nr. Reporters allows adjusting the number of non-taskable volunteers.
  • Nr. Taskable allows adjusting the number of taskable volunteers.
    • with-base? switch regulates weather idle volunteers will try to return to their initial position or not.

THINGS TO NOTICE

In most cases, the taskable volunteers are far more efficient at resolving already known issues then the non-taskable ones. As a result, they will exhibit higher ration of reports per volunteer.

Tasking the volunteers with far-away issues is ineffective. On the other hand, not tasking them at all is bad too. The model tries to adjust the tasking radius accordingly if the Adjust-tasking-radius? switch is enabled.

COLOR CODING

The model uses shapes and color coding to visualize the situation:

  • All Volunteers are shaped as people.
    • Non-taskable volunteers (reporters) are blue.
    • Taskable (but not tasked) volunteers are violet.
    • Currently tasked volunteers are orange.

Volunteers grow every time they report a new observation.

  • Issues are shaped as targets.
    • Undiscovered issues are red.
    • Discovered issues are orange and a bit larger (size = 1.5).
    • Correctly resolved issues are green and size = 2.
    • Incorrectly resolved issues are black and size = 2.

Even more information can be shown by enabling the three switches at the bottom-left of the user interface.

  • The first one (debug?) enables writing of debug messages.
  • The second one (show-observations?) makes the observation links between reporter and the issue visible.
  • The last one (show-tasks) does the same for the task links.

THINGS TO TRY

  • What is the relation between the tasking radius and the time needed to resolve the issues?
  • How does model behave with no, few and many taskable volunteers?
  • How does the model behave in very crowded (small) and relatively empty (large) worlds?
  • Odd numbers of confirmations lead to more errors than even ones. Why?

EXTENDING THE MODEL

This model is very simple. Here are some things that could be improved:

MOTIVATION

In the real world, volunteers’ motivation changes with the time. Every new discovery is a motivation boost. Other motivation boosts include e.g.:

  • Getting tasked
  • hearing that own observations were confirmed

Long and unfruitful searches are boring. Hearing that own report was found incorrect could diminish motivation as well.

Motivation can also be understood as "energy". Volunteers with no energy stop working...

LEARNING BY DOING

All volunteers make mistakes. However, hearing the report on own reports (confirmed/not confirmed) leads to a learning effect. Consequently the future reports are more accurate.

To make things more fun, the consensus could also be wrong, in which case the learning effect is negative and the probability of error is larger in the next step.

TRUST

In real world, the volunteer management organizations try to differ between more or less trusted volunteers. At the lowest end are the non-taskable volunteers, then the pre-registered (taskable) volunteers who haven't confirmed their identity, followed by

MORE TASK TYPES

The only task implemented by this model is "confirm observation". Other interesting tasks are for instance:

  • Patrol area: ask volunteer to scan an area (square is fine). Ideally, the volunteer should scan this area in some more efficient way than random walk.
  • Group scan: a group of volunteers quickly scans an area by walking in a line.
  • TBD: other???

NETLOGO FEATURES

  • Uses "breeds" to differ between various types of agents.
  • Uses links to model the tasks and observations.
  • Custom shapes, sizes and colors of various turtle breeds.

RELATED MODELS

See other "Volunteers" models by the same author.

HOW TO CITE

If you mention this model in a publication, we ask that you include these citations for the model itself and for the NetLogo software:

COPYRIGHT AND LICENSE

Copyright 2015 Denis Havlik

CC BY-NC-SA 3.0

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

To inquire about commercial licenses, please contact Denis Havlik at denis@havlik.org.

CREDITS AND REFERENCES

This model is an indirect consequence of my work in ENVIROFI and DRIVER EU projects. In these projects we have developed some mobile applications for crowdsourcing and crowdtasking, which got me interested in the factors which govern the behavior of the volunteers.

Comments and Questions

Ready to go for a test ride :-)

I have invested some more work in making the model more interesting and improving the user interface and documentation today. In my opinion the model is "as good as it gets" now, and I intend to leave it "as is" unless I receive some requests and suggestions for improvements. Enjoy. Note: the "info" is shown correctly now, but unfortunately the Java applet still does not work. Apparently the java applets aren't supported anymore - you will have to download the model and test offline.

Posted over 10 years ago

Click to Run Model

;;;;;;;;;;;;;;;;;;;;;;;;;;;
; globals and definitions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

breed [reporters reporter]

breed [volunteers volunteer]
breed [issues issue]

; report is reserved word, so we'll use observation.
directed-link-breed [ observations observation ]
directed-link-breed [ v_tasks v_task ]

; two types of volunteers. One can be asigned a task, other can't
; the taskable ones also have a "base" and prefer to stay in its vicinity.
; In the future we could replace this with possibility to task them to search a certain area.
;
; *motivation* is percentage - at motivation >= 100%:
;   - taskable volunteer can be tasked to confirm observations.
;   - both types will report nearby issues 
;
; the chance of taking the task/reporting findings depends on motivation (TODO!)

volunteers-own [ v_motivation xhome yhome ]
reporters-own  [ v_motivation ]

; i_resolved? is set to true when we have enough reports.
issues-own [ i_resolved? i_generated i_discovered i_resolved i_consensus]

; not sure what we need in this link...
observations-own [v_breed timestamp correct?]
;v_tasks-own []

;;;;;;;;;;;;;;;;;;;; 
; setup procedures ;
;;;;;;;;;;;;;;;;;;;;

to setup
  clear-all
  setup-world
  setup-reporters
  setup-volunteers
  setup-issues
  reset-ticks
end 


; initially all patches are just grey = unknown.

to setup-world
  resize-world 0 Size-world 0 Size-world
  set-patch-size 1000 / Size-world
  ask patches [
      set pcolor grey
  ]
end 


; randomly add some spontaneous volunteers to the world

to setup-reporters
  set-default-shape reporters "person"
  ; can't happen with a slider
  ;  if not is-number? Nr-reporters [ set Nr-reporters 100 ]
  create-reporters Nr-reporters [ 
    setxy random-xcor random-ycor
    set v_motivation init-motivation
    set color blue
    set size 1
  ]
end 

; randomly add some taskable volunteers to the world

to setup-volunteers
  set-default-shape volunteers "person"
  ;  if not is-number? Nr-taskable [ set Nr-taskable 10 ]
  create-volunteers Nr-taskable [ 
    setxy random-xcor random-ycor
    ; volunteers will try to stay near their home coordinates
    ; This could be considered kind of a task too.
    set xhome xcor
    set yhome ycor 
    set v_motivation init-motivation
    set color violet
    set size 1
  ]
end 


; randomly add some issues to the world
;
; issues have a generation time & later also a discovery time

to setup-issues
  set-default-shape issues "target"
  create-issues Nr-issues [ 
    setxy random-xcor random-ycor
    set i_generated 0
    set i_consensus 0
    set i_resolved? false
    set color red
    set size 1
  ]
end 


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Procedures governing the world development ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

to go 
  assign-tasks
  move-reporters
  move-volunteers
  report-issues
  manage-issues
  if count issues with [ i_resolved? = true ] = Nr-issues [ stop ]
  tick
end 

; some volunters can be tasked, e.g. to quality-assure the reports

to assign-tasks
  ; nothing to do. Actually we should only call this function if there is something to do..
  ; Note: if I need 0 confirmation, this means one observation. 1 confirmations = 2 observations etc.
  ; So open issues are the ones with with less than Nconfirmations + 1 links. Which is the same as "<= Nconfirmations" links.
  let open_issues issues with [i_discovered > 0 and (count in-link-neighbors) <= Nr-confirmations]
  if count open_issues = 0 [stop]

  let free_volunteers volunteers with [not any? out-v_task-neighbors]
  ask free_volunteers [
    let nearest_issue min-one-of (issues with [ 
      i_discovered > 0 
      and not in-observation-neighbor? myself
      and (count in-link-neighbors) <= Nr-confirmations
      and distance myself <= R-task ])  [distance myself ]
    if is-issue? nearest_issue [
      create-v_task-to nearest_issue [
        if show-tasks? [ 
          set color orange 
        ]
      ]
      if debug? [
        write "created task"
        show self
      ]
      set color orange
      ;set size size + 1
    ]
  ]
  if Adjust-tasking-radius? [
    ; let's play with tasking radius
    let tasking-need count issues with [ i_discovered > 0 and (count in-link-neighbors) <= Nr-confirmations]
    let tasked-volunteers count v_tasks
    let tasking-offer Nr-taskable - tasked-volunteers

    ifelse  tasking-need < tasking-offer
      [ if tasking-need > 0 and R-task < max-pxcor [set R-task  R-task + 1 ] ]
      [ if tasking-offer = 0 and R-task > R-discover [set R-task  R-task - 1 ] ]
;      [ if tasking-offer > Nr-taskable / 10 + 1 and R-task < max-pxcor [set R-task  R-task + 1 ] ]
;      [ if tasking-need > 0 and R-task > R-discover [set R-task  R-task - 1 ] ]

  ]
end 

; reporters just move at random.
; motivation always goes down, unless an issue is discovered

to move-reporters
  ask reporters [
    right random 360 
    forward 1
    if v_motivation > 0 [
      set v_motivation v_motivation - 1
    ]
  ]
end 

; tasked volunteers move towards their task or at random if no task defined.

to move-volunteers
  ask volunteers [
    ; current target?
    ; normally there should be only one, so "one-of" is the same as
    ; min-one-of (out-v_task-neighbors)  [distance myself ]

    ; If we have a task, let's go for it!
    ifelse any? out-v_task-neighbors [
;      print "heading towards"
;      print one-of out-v_task-neighbors
      face one-of out-v_task-neighbors   
    ]
    ; else we'll stroll arround
    [
      ; if "with base" meander back towards vicinity of the initial position      
      if with-base? 
      [ 
        if distancexy xhome yhome > r-task / 4 [ facexy xhome yhome ]
      ]
      ; let him also menader a bit.
      right random 60 - 30 
    ] 
    forward 1
    ; motivation always goes down, unless an issue is discovered
    ; TODO: this is not implemented yet
    if v_motivation > 0 [
      set v_motivation v_motivation - 1
    ]
  ]
end 

; report observations on nearby issues

to report-issues
  ask turtles with [is-reporter? self or is-volunteer? self ] [
    ; "myself" refers to a volunteer which initiated the loop, not to issue!
    ; issue would be reffered to as "self" in own context.
    let this_reporter self

    ; which issues are in vicinity?
    ask issues in-radius R-discover [
      ; report only those issues we haven't reported already!
      if in-observation-neighbor? myself [ stop ]       

      ; delete the task from a caling turtle to this issue
      ask my-in-v_tasks with [ other-end = this_reporter ] [ 
        ask this_reporter [ 
          set color violet
          ]
        if debug? [
          write "deleting obsolete task (1):"
          print self
        ]
        die 
      ]
      ; don't report if already enough reports. 
      ; This is kind-or optional, results might even improve if we don't do this.
      ; Note: 0 confirmation means 1 observations etc. 
      if (count in-observation-neighbors) > Nr-confirmations [stop]
      ; good reporters grow. :-)
      ask this_reporter [ 
        set size size + 1 
      ]

      ; is our observation correct or not?
      let obs_correct? (error-perc < random 100)
      
      ; if issue is already discovered, confirm 
      ifelse i_discovered > 0 
      [
        create-observation-from myself [
          if show-observations? [ 
            ; actually i should set it to black if the observation is wrong...
            ifelse obs_correct? [set color green] [set color black]
          ] 
          set v_breed [breed] of this_reporter 
          set timestamp ticks
          set correct? obs_correct?
          if debug? [print self]
        ]
      ]
      ; else report new discoveries
      [
        set i_discovered ticks
        create-observation-from myself [ 
          if show-observations? [ 
            ifelse obs_correct? [set color red] [set color magenta]
          ] 
          set v_breed [breed] of this_reporter 
          set timestamp ticks
          set correct? obs_correct?
          if debug? [print self]
        ]
        set color orange
        set size 1.5
      ]
    ]
  ]
end 

to manage-issues 
  ; issues are considered resolved if we get enough reports on it.
  ; thus we can have "false positives" here too.

  ask issues with [ not i_resolved? and (count in-observation-neighbors) > Nr-confirmations ] [ 
    if debug? [
      write "No. neigbours:"
      print count in-observation-neighbors
    ]

    set i_resolved? true
    set i_resolved ticks
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    set i_consensus (count my-in-observations with [correct?] - count my-in-observations with [ not correct? ])

    ; if needed, tell the volunteers that their help isn't needed anymore!
    ask my-in-v_tasks [
      if debug? [
        write "deleting obsolete tasks (2):"
        print self
      ]
      if is-volunteer? other-end [ 
        ask other-end [ 
          set color violet 
          ;set size 1.5
        ]
      ] 
      die
    ]
    ifelse i_consensus > 0 
    [ set color turquoise ]
    [ set color black ]
    set size 2
  ]
end 

There are 6 versions of this model.

Uploaded by When Description Download
Denis Havlik over 10 years ago Spell-check on Info Download this version
Denis Havlik over 10 years ago Corrected the "how to cite" section Download this version
Denis Havlik over 10 years ago Improved documentation Download this version
Denis Havlik over 10 years ago Volunteers grow with their results :-) Download this version
Denis Havlik over 10 years ago Why don't I see the "info"? Download this version
Denis Havlik over 10 years ago Initial upload Download this version

Attached files

File Type Description Last updated
Taskable volunteers 01.png preview Preview for 'Taskable volunteers 01' over 10 years ago, by Denis Havlik Download

This model does not have any ancestors.

This model does not have any descendants.