Taskable volunteers 01
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:
- Havlik, D. (2015). Taskable Volunteers 01 NetLogo model. http://modelingcommons.org/browse/one_model/4237
- Wilensky, U. (1999). NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL.
COPYRIGHT AND LICENSE
Copyright 2015 Denis Havlik
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
;;;;;;;;;;;;;;;;;;;;;;;;;;; ; 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.
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.
Denis Havlik
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