Apologies for a second email in succession but Jo reminded me of my
original thoughts when I read Sev's first email.
Firstly, I agree that a hugely committed mapper or 3 / 4 regular mappers
are preferable to 10 one-time mappers, but I think that's probably slightly
naive. From what I remember of Martin Dittus' research (and apologies if I
have misremembered, Martin) you need to engage with many more than ten new
mappers to find even one regular one (and this is in a regular mapathon
setting where there is training and community). Also, some of the most
committed humanitarian mappers were, once upon a time, newbies. How do you
find those hard core HOT mappers of the future without looking?
Secondly, I think new mappers are a great thing. We need them. MSF
certainly needs them. The appetite for the kind of speed, quality and
coverage you guys provide so well is growing fast. In terms of tasking, I
have a backlog of more than ten projects that I haven't even put into the
tasking manager yet. None of them are mapping for crises that make the
news. And I know that we can't, as a community, handle these extra requests
without growing significantly. That means inviting new people.
Lastly, I have seen rooms full of new mappers provide operational data for
field teams on urgent request. Mapping for the MSF measles vaccination on
the island of Idjwi in DRC is a good case in point. Experienced HOT mappers
were instrumental in checking the quality of the data, but new mappers in
Glasgow and all over Belgium turned a likely failure into an astonishing
success by doing the initial mapping at speed and with enthusiasm. This
should be celebrated.
If we curb the number of new mappers coming into this space, we will have
to say no to a lot more requests from serious NGOs doing serious work.
Better, I would think, to work out how their time is most effectively
spent however long they stay for... and to work out how to encourage them
to stay for a while. My feeling is that criticising them en masse for
spoiling data on the mailing list might be counter productive to this.
On 13 Oct 2016 08:02, "Jo" <winfi...@gmail.com> wrote:
> Unfortunately there will constantly be new crises. So we'll always be 'in
> the middle of a crisis'.
> 2016-10-13 8:29 GMT+02:00 Robert Banick <rban...@gmail.com>:
>> Hi all,
>> HOT is clearly one of, if not the, most successful crowdsourcing projects
>> for humanitarian response in the world. Success means not just contributors
>> but also use of the data by actual humanitarians. It’s unsurprising we’re
>> encountering some limits to the approach and need to evolve it.
>> I like Phil and John’s automated approach to these things. I think the
>> Tasking Manager has proven that the best way to manage these interactions
>> is through an automated platform. My only concern is making what’s
>> currently straightforward overly complex and intimidating for new users.
>> But that’s a call for good design and introductory materials, not dumbing
>> down our approach.
>> However, it’s the middle of a disaster and clearly not the time for
>> wholesale changes. I suggest we flag these thoughts for the forthcoming
>> Tasking Manager redesign and embrace makeshift systems in the meantime.
>> On Thu, Oct 13, 2016 at 8:31 AM Phil (The Geek) Wyatt <
>> p...@wyatt-family.com> wrote:
>>> Hi Folks,
>>> I am a retired long time map user, occasional mapper (in QGIS, Mapinfo)
>>> and supporter of the OSM mapping project. It seems to me that the issue of
>>> poor mapping, especially for HOT projects, is coming up on such a regular
>>> basis that it's time to consider some mandatory training for users before
>>> they get to map under the HOT task manager. I don't think this would be too
>>> difficult for most volunteers and it could ensure that at least a certain
>>> level of competency is attained before being exposed to complex tasks. If
>>> people know that in the first place then they can make a choice as to
>>> whether they commence or continue to map.
>>> I have no idea how this could be accomplished as I know little of the
>>> linkages between OSM and the HOT Task Manager, but restricting HOT tasks to
>>> those with some defined training could improve the results.
>>> Let's say as a minimum you train folks on roads and residential area
>>> polygons - that might be level 1 (ID Editor)
>>> Level 2 could be after training for buildings, tracks, paths (ID or JOSM)
>>> Level 3 for validation (JOSM)
>>> In this way HOT tasks simply get assigned at each level and you know you
>>> have the right people doing the tasks at hand. The task manager could also
>>> only highlight jobs at their assigned level until they do the next level
>>> You might even consider, as part of validation, dropping people from a
>>> higher level to a lower level if they continually fail to produce results
>>> at the desired consistency.
>>> Just my thoughts as a casual mapper.
>>> Cheers - Phil
>>> Thin Green Line Supporter <http://www.thingreenline.org.au/>, Volunteer
>>> Mapper (GISMO) - Red Cross
>>> *From:* Severin Menard [mailto:severin.men...@gmail.com]
>>> *Sent:* Thursday, October 13, 2016 4:34 AM
>>> *To:* firstname.lastname@example.org
>>> *Subject:* [HOT] OSM humanitarian mapping and its learning curve
>>> The edits on hotosm.org job #2228 <http://tasks.hotosm.org/project/2228>
>>> have started and now happens what I feared. There is no mention of what are
>>> the necessary skills and newbies are coming with a lot of enthusiasm but
>>> with almost no OSM experience. A quick analysis of the first 29
>>> contributors shows that 20 of them have created their OSM account less than
>>> one month ago. Some did it yesterday or today. Wow.
>>> The result of that : obviously, crappy edits are coming, spoiling what
>>> we have been doing over the last few days : now we have building as nodes
>>> where shapes are totally visible, un-squared bad shaped buildings and the
>>> main landuse area is self-cutting in various places (see there
>>> Nothing new under the sun : it was already the case for Haiti EarthQuake
>>> 2010. Quite a pity that six years after, despite the OSM tools have
>>> improved a lot, it remains the same. It is though quite simple to fix the
>>> most part of it: do-not-invite-newcomers-to-map
>>> I guess some will argue that the OSM newcomers are people of good will
>>> and that they just want to help and that they my feel offended/discouraged.
>>> Of course their intentions are high and yes they may feel a bit hurt. But
>>> this is really a classic in humanitarian response: people with the best
>>> intentions in the world may not fit for it, just because they are not
>>> experienced yet.
>>> Mapping in OSM in crisis response is not an exciting one-shot hobby : it
>>> does have its learning curve and it is key to learn how to map correctly
>>> before being dropped over complex humanitarian contexts. This is why I
>>> mentioned three sets of necessary skills for the jobs I created these last
>>> days on http://taches.francophonelibre.org. And the beginner mappers
>>> who joined the job that fitted for beginners are people that already have a
>>> few months of OSM experience, not newcomers. Newcomers should be driven
>>> over non urgent fields.
>>> If someone is not interested to learn first in not a mass media covered
>>> crisis context : this is not a problem, it is actually a good way to see
>>> real motivations. I personally prefer to get one mapper that will become a
>>> huge, excellent contributor, 3-4 more occasional but still producing neat
>>> data, than to lose 10 that would create crappy objects and just leave
>>> forever afterwards anyway.
>>> I guess the resulting need of duplicating the number of necessary edits
>>> (crappy ones then corrections) to get a clean data is a rather a good way
>>> to grow the number of total contributors and the number of total edits
>>> created through the # of the HOT TM instance that seems to be so important
>>> for the board of HOT US Inc (two current directors have contacted me for
>>> this purpose) to make communication and raise funds from the figures. But
>>> what is at stake here is to provide good baseline data for humanitarian
>>> response, not distorted metrics.
>>> HOT mailing list
>> HOT mailing list
> HOT mailing list
HOT mailing list