Over the past months, I have spoken to a few different people about the friction that can exist when groups of new contributors engage with OpenStreetMap in areas where there is already existing and active community. Whilst the prompt for writing this diary entry has been recent issues in Panama (between a local YouthMappers chapter and a small group of active local mappers), the content isn’t specific only to that situation and has been informed by multiple people across multiple continents (as well as my own experience).
The issue in itself is also not at all new - I remember if from 2014 when we started the Missing Maps project. What is new is that I now work in HOT’s community team and it’s actually my job to try and work out how to grow the OSM community in a way that respects the past and the future of the project and the community.
You may wonder what the situation in Panama has to do with HOT and I think there are two answers to this.
Firstly, we run the HOT instance of the tasking manager (TM). We see the TM as a community asset and, whilst we don’t originate every project on there (for example, in 2020, HOT originated 17% of all published projects), we do develop and maintain the technology as well as providing the workflows and onboarding for people that want to create and manage specific projects. For example, a majority of YM chapters contribute by mapping through the TM (including the Panama chapter who organised local projects to be set up in collaboration with the global YM team).
Secondly, it is HOT’s mission to radically increase quality local map contributions and contributors from across 94 countries in Africa, Asia and Latin America / Caribbean over the next five years as part of the Audacious project. We need to be good at making sure that new mappers build on what already exists in collaboration with people and communities already actively engaged in the OSM project and that they are welcomed into those same communities.
So, this diary is about identifying some specific ways in which HOT could improve tasking manager workflows (something firmly within our sphere of influence) to help improve the way we bring new contributors into OSM (and especially those, for whom, the TM is one of their first experiences of OSM) and the way we interact and collaborate with them as experienced contributors and communities.
The below aren’t solutions, but rather a list of issues that, if addressed, could maybe contribute to solving some of the issues raised. Please feel free to add additional ideas in the comments (and ask questions / constructively criticise)!
It is clear that there are misunderstandings around what the TM is and what the mapping process through it looks like. Multiple misconceptions exist around the origin and ownership of projects, who the tool serves and how accessible it is. There is also a lack of understanding around (or buy in to) the two-stage mapping -> validation process as frustrations arise around new mapper edits (including data being deleted / changesets reverted) before a validation process has had time to take place. This can not only discourage new mappers, but also can stop an important learning process taking place.
When the tasking manager was completely open for anyone to build projects in, there was a serious problem with data quality as some projects were poorly described and / or lacked proper instructions and guidance for mappers. HOT adjusted TM policy so that organisations and groups had to register and complete ‘onboarding’ in order to become a project creator (ie. be able to post a new project). Now, through the tasking manager, anyone can find a project’s creator and message them. One issue with the Panama situation was that one staff member from the YM global team is managing all YM’s tasks (currently serving >200 chapters). This makes transparency through the TM difficult as OSM contributors only know who technically implemented the project, not who requested it or is managing it locally.
The main focus of onboarding for project creators / managers is technical project implementation - essentially trying to make sure that standards are met and that mappers are able to do what is asked of them in an effective way. Onboarding does cover expectations and skills around; engaging local communities and contributors, responding to questions and info requests, closing out projects, ensuring documentation on the wiki (in the case of organised editing), etc, but it is clear that this aspect of the onboarding could be developed and strenghthened.
One issue that arose through the Panama situation was that an urban environment was categorised as a beginner project. Current onboarding and guidance for project creators doesn’t support them to make sure that the environment to be mapped is commensurate with the experience of the group of mappers, espercially when there are likely to be many beginners.
Regardless of the quality of the project documentation on the OSM wiki (a convention established in the organised editing guidelines), the TM project template / onboarding process does not emphasise the importance of documentation or link to it if it is available.
Inactive (or barely active) projects can ‘hang around’ on the TM for a long time, meaning data in OSM can be incomplete across the area of interest. This can also cause issues if other editing work is starting in the same / overlapping areas. Also, the longer a project is open, the harder it becomes to find the people who were involved in requesting / creating it.
There is currently no way of knowing or efficiently checking whether other projects in the HOT TM or in other instances of the tasking manager overlap an area of interest. This means that it is theoretically possible (and occassionally occurs) that multiple projects draw different groups of mappers to contribute data for the same area (basically saying to mappers, “this area needs mapping” when it potentially is being / has already been mapped).
Whilst this is possible, it is not easy or intuitive (and this applies to feedback / questions directed to the project creator / manager or to HOT itself).
Currently, there is significant tacit knowledge needed to be able to be able to find local contributors and interact with them. Whilst this is a more generic issue that we would like to dive deeper into in the near future (there are, of course, multiple tools and methods available to do this), there is little space given to this within the TM itself. We know that for some mappers, the TM is one of their first experiences of OSM, so helping them to integrate into / collaborate with existing contributors / communities within the platform could potentially be of benefit.
Please feel free to add anything I have missed and correct anything I have wrong. Once we have done a bit more consultation on this topic, we (at HOT) can look at if / how we might go about addressing the above and what the priorities should be.
BTW, a big thanks to everyone who spoke to me about this and helped me to identify and articulate the above, but especially Rory and Mario for helping me understand the specific issues from the Panama situation. Your time was much appreciated.
Comment from russdeffner on 31 December 2020 at 10:27
Thank you for this Pete! As one of the people at HOT that has tried to steward the Tasking Manager from version to version, I can say that another thing that is well within our sphere of influence is to have a longer testing and documentation period for major releases and new features. For both version 3 and version 4 it really felt like we had a grossly inadequate amount of time to test and many issues that we could have potentially caught were not anticipated and the versions released only to have to back-track and clean up after the fact. Of course there are always budget and deadline constraints but as our partners in Missing Maps, among others, can recall - we were literally creating their organizations and trying to teach them about the new Organization and Teams structure in version 4 just weeks before the release. Only to still have today many users who don’t know that we have moved away from the role structure to teams. Anyway, mostly all good progress being made, but as you outline, a significant amount of issues to keep working on, especially in regards to that mapper, community, organization collaboration.
Comment from mariotomo on 31 December 2020 at 16:33
Hi Pete, thank you warmly for this diary entry!
I think you included all issues we mentioned in our chat, and added a couple more relevant points. this makes this page very complete, but also difficult to comment to it, for you may expect up to 9 separate threads flowing from here.
assuming you want to consider these issues as related to your HOT Tasking Manager, they could be hosted in the issues manager for that software project, even if not all are strictly software issues, but relate to the use we make of your software and online service.
about the “project creators” issue, I think you HOT should put a hard limit to the amount of projects that can be associated to a single project creator. 200 becomes a full time job! a different option is for the TM to include an extra role, something like a local contact or local organization, behind the project and backing the project creator. I do not know what requirements you would set for them, and to my personal opinion is that I would rather have a local project creator, not a centralized one: my impression is that this YM practice defeats your HOT correction to the original situation »When the tasking manager was completely open for anyone to build projects in«. so my advise is that HOT poses a hard limit to the amount of simultaneously open projects associated to the same project creator. this would also help avoiding dangling projects.
about the “projects can overlap” issue, there are cases where this is reasonable, and well implemented, a good example is in Costa Rica: 2353 vs. 2354/5/6. unfortunately bgirardot is yet another example of non-local project creator and this group of projects is yet another example of dangling projects.
Comment from rab on 31 December 2020 at 18:34
TM projects don’t always get closed out - this is highly problematic! Especially when a single mapper takes over an entire project that is no longer monitored. See #hotosm-project-5842 (who is responsible when the project manager cannot be reached) or #hotosm-project-1497. #hotosm-project-1045-loreto is also a project that has produced very interesting results over the years
Comment from Rory Nealon on 31 December 2020 at 22:35
I concur with Russ, thanks for this thoughtful post! It’s nice to see that folks at HOT are not only focused on the software they are developing, but are looking at the impact and interplay it has with the OSM and humanitarian/development communities.
From where I sit, supporting the YouthMappers (YM) program at USAID, I have seen and see that YM and HOT share a lot of common interests and goals. We have worked well together in the past and I believe we will continue to do so in the future.
It is important to remember that both HOT and YM have been wildly successful at helping grow and enrich the OSM community. These efforts have included helping map vulnerable and undermapped areas, expanding and diversifying the community of contributors to OSM, helping train these contributors on a wide range of topics, strengthening local OSM communities, and helping to make connections across communities.
Regardless of the context in which they were prompted, the issues identified highlight tangible areas for improvement that can be addressed by both HOT and the organizations they partner with. At its inception, HOT was purely a disaster response organization. In recent years, HOT has taken on a more diverse set of projects, including longer term initiatives in support of international development and disaster preparedness programs. This expansion into new domains has not always resulted in a corresponding evolution of documentation and processes guideance. Also, establishing where different responsibilities lie between organizations that use the TM and HOT would be helpful in clarifying some of these issues. Similarly, even as a HOT voting member, I have found that HOT’s various roles and services can be a bit confusing since HOT as an organization wears multiple hats, such as being a software service provider, data validation service, community organizer, etc… On any one project it could be playing one or many of these roles and this may be confusing to OSM community members who are not familiar with HOT. As an organization that uses HOT’s TM we would love to explore ways to collaborate and help resolve these issues.
One point that should be clarified is YM’s task creation workflow. While there are five administrators for the YM organization on the TM who are able to create tasks, the tasks are designed and written by local YM chapters. So while it may appear on the TM that there are only five YouthMappers Administrators creating tasks, there is a larger network at play to design, manage, and analyze them.
Your proposal to have links to the OSM wiki makes a lot of sense. This will help tasks in the TM be better aligned with the OEG, provide local contact information, and improve the task’s overall transparency. On the other hand, this opens a new can of worms. The OEG is optional and implemented differently by different organizations and communities. Further, this would link to a system that HOT does not have the authority to enforce and with the plethora of different standards and communications tools used by different OSM communities, might not be standard practice for the organizations that use the TM or in the area being mapped.
Thanks again for the thoughtful diary post and would be happy to discuss and explore solutions to these issues.
Comment from bopercival on 1 January 2021 at 10:22
I’m going to take this opportunity to also bump previous posts about more user engagement in hot_tech’s design sprints. It’s much easier to solve problems before the software is built and the more input we get in the early days, the more problems we can try and solve early on.
Great run down Pete, looking forward to max engagement with those who gave you feedback over the next few months :)
Comment from bopercival on 1 January 2021 at 10:29
Ooop, sorry forgot one thing, for the OEGs point.
For the point on documentation. People may be interested in learning more or contributing to the OEG Reporter Project, that was undertaken this year by Joao, one of hot_tech’s GSoC interns. There was a SOTM session on it this year too.
Comment from Heather Leson on 1 January 2021 at 11:53
HI Pete, thanks for these reflections. I have long opined that the soft skills will help OSM - negotiation, change management, communication styles, systems/complexity, and community engagement. These, of course, underpin your items, but perhaps we need to name them too.
all the best,
Comment from pedrito1414 on 2 January 2021 at 16:05
Hi all, thanks for the comments. Really useful. We’ll have a look at the various options and discuss how to take them forward and document what we are doing… As Russ points out, it’s a false economy to rush these things. And, Heather, yes exactly… I think a lot of this (and much beyond the issues and opportunities raised here) has to do with those soft skills. Interestingly, I was listening to an interview with NASA’s chief flight director, Holly Ridings, and she said NASA have stopped calling them ‘soft skills’ and now just call them skills, which makes sense to me!
Comment from flohoff on 10 January 2021 at 15:47
I am still setting up TM2 whenever i need one because its documentation, requirements and simplicity is great. You can set it up by strictly following the Readme within 5 minutes and off you mapping goes.
I am sysadmin by profession and i failed to even understand or setup a TM3. So i think of fixing some TM2 annoyances instead of looking at TM progress.