Humanitarian OpenStreetMap Team (HOT) is seeking proposals for the design and implementation of the next generation of its OSM Tasking Manager2 (TM2) software.
HOT’s OSM Tasking Manager 3.0 Tech Challenge
Humanitarian OpenStreetMap Team (HOT) is seeking proposals for the design and implementation of the next generation of its OSM Tasking Manager2 (TM2) software. The selected winner will develop and implement their proposed plan for making significant improvements to TM2 UI/UX and functionality organized around the 5 key goals for the project for a period of 4 months. The total awardable amount for this challenge is $55,000 - 70,000 USD. The full overall project Terms of Reference are available here: https://docs.google.com/document/d/1rUiDk4jMiWZ2gXPJPyAM0td4VGCNwhCBo_E-rsBnc1M
About the OSM Tasking Manager 2.0 Software
HOT coordinates large mapping projects both online through the “OSM Tasking Manager 2” software package and on the ground with local communities through all phases of the Disaster and Crisis Management Cycle. Data is contributed directly to the OpenStreetMap (OSM) database where it is made available under an open license. Humanitarian organizations use the data created by HOT volunteers to support disaster response and recovery activities. It is important for users and the volunteers creating map data to understand the context of an overall mapping project, how OpenStreetMap works and know where to get feedback to be able to map well and confidently.
Through generous support from the USAID GeoCenter, a world leader in the use of geospatial tools and analysis, and the Australia Department of Foreign Affairs and Trade, experts in finding new ways to solve problems through their Disaster Management Innovation (DMInnovation) Indonesia program, HOT has been given the opportunity to develop its third generation of HOT’s OSM Tasking Manager software, OSM Taskinig Manager 3.0 (TM3). The TM3 software will be made available as an online code, along with an open API, allowing for integration with existing and future OSM ecosystem tools.
Existing OSM Tasking Manager 2.0 Description
HOT’s current OSM Tasking Manager 2.0 software is designed to coordinate many people mapping in OpenStreetMap (OSM) over a large area of interest (AoI) simultaneously. The concept and process of managing individual, local and remote, contributions to OSM to cover a large area has shown to be both effective and produce good quality geospatial data. HOT’s OSM Tasking Manager 2.0 software has been used by many organizations and 10's of thousands of people to map 100’s of thousands of square kilometers in OSM.
The core workflow of the Tasking Manager 2.0 software is:
- “Project Managers” create “Projects” either by importing or drawing a polygon, then the Tasking Manager software divides that area into a uniform grid of smaller “Task” squares and allows the Project Manager to attach instructions for how and what features to map in each small Task square.
- The software provides a mechanism for “Mappers” to log in (via OSM OAuth) and checkout a Task square to prevent fellow users of the Tasking Manager from mapping in the same small area.
- The Tasking Manager then hands the Mapper off to one of the standard OSM editing tools, typically the iD Web Editor or the Java OpenStreetMap editor (JOSM). The Mapper then does standard OSM mapping for the features the Project Manager has requested be mapped.
- After the Mapper is done in the OSM editor, they return to the Tasking Manager software and “Unlock” their task square. They have the option of also marking the Task square “Done” which indicates it is completely and properly mapped according to the Project Manager’s instructions.
- Another Mapper can then checkout that Task square, review the mapping using one of the standard OSM editors, return to the Tasking Manager and when unlocking the Task square, mark it “Validated” if they agree all the features asked for by the Project instructions have been well mapped or “Invalid” if the Task square needs more or improved mapping.
- When all of the Task squares in a Project are marked Done and Validated, the Project is considered finished.
Coordination of this workflow forms the core functionality of the Tasking Manager 2.0 software and its success. Its user base has expanded a great deal since the 2.0 release of the software and those individuals are finding innovative and creative ways to accomplish all sorts of incredible OSM mapping projects around the world with it. But these new uses coupled with the large influx of new Mappers, have led to several specific areas being targeted for UI enhancements and additional functionality. The Tasking Manager 3.0 software package will be the end product of the winning proposal(s)’s innovative and community informed approach to addressing the development goals.
OSM Tasking Manager 3.0 Goals
- Increased and improved Mapper Engagement - know who the user is, their experience level, and have some idea of which is the best project for them to spend time on. Mappers need more feedback and engagement at important times in their process of becoming experienced OSM contributors. This means more frequent and better targeted communications with Mappers.
- Improved Validation - This is what the OSM Tasking Manager 2.0 treats as a “second set of eyes” or a “second pass”.n If two Mappers agree a Task square is completed well according to instructions, it is marked “Validated.” OSM Tasking Manager 3.0 (TM3) will need to support the option for a more managed approach to validation probably centered around a “Validator Role” attached to Mappers. Validation also happens outside of the TM2 software, and the TM3 product will need an easy way to record external Validation using other tools and make external validation via 3rd party OSM tools easier.
- A significantly improved UI/UX - This impacts every part of the TM3 and every user. The TM2 software coordinates between two websites for creating a user (OSM) and authentication (TM2 & OSM), then coordinates between the TM2 and several 3rd party OSM editors to get mapping accomplished. It also has to support multiple Project Managers creating projects over large areas simultaneously. Project Managers are also tracking progress on existing projects and need to make use of other HOT OSM tools in decision making, like OSM Analytics (OSMA) or OpenAerialMap (OAM). Mappers and Validators need to have more insights and guidance on Projects or Task squares to work on. Improvements to any part of TM2 should include a usability tested UI, and integrate the UX with the overall goal of moving the “I never mapped” to “happy and experienced” OSM contributors.
- Better Project Creation and Management Tools - Project Managers need better tools and interfaces to see existing projects near or intersecting their Aarea of Interest, incorporate data from other HOT OSM Tools like OAM and OSMA, as well as third party layers. Support for grouping projects is needed to add functionality for managing projects as a group. Better user management and engagement features are needed as well.
- API - All existing and new functionality must be exposed via documented API calls. This needs to support authentication so project management and other admin or validation type actions can be completed via API.
The existing Tasking Manager 2 codebase is written in Python based on this technology stack:
- Pyramid https://trypyramid.com/
- Mako Templates http://www.makotemplates.org/
- SQLAlchemy http://www.sqlalchemy.org/
- PostgrSQL https://www.postgresql.org/
- PostGIS http://www.postgis.net/
- GDAL http://www.gdal.org/
The complete code repository can be found here:
Please review all the sections of the repository, code, issues, wiki.
Make Shiny or Make New?
Redevelop from the ground up with a new software stack, add to or change the existing technology stack, or build on the existing codebase as is? You tell us. We have reviewed the code and the issues and have not come to a consensus on the best approach. This is an opportunity for quick iteration, innovation, creativity and modern, tested UI design work regardless of which options you propose for the technology stack. Meaningfully improving the OSM Tasking Manager 2.0 user experience and increasing data quality in a community sustainable way will have an impact on humanitarian mapping work for years to come. Please tell us why any proposed software stack is the best choice for this project.
Scope of Work
Companies, teams, individuals and consortia are all encouraged to apply. The scope of work (SoW) for this tech challenge is to either build on the existing TM2 codebase and frameworks, or design, develop and implement a new codebase, to deliver the next generation of the OSM Tasking Manager 2.0. Development is roughly divided into UI/Engagement improvements for Mappers and Project Managers, new functionality for project creation and management, both UI and new functionality to manage validation, and completing the API. The architecture should be open and extensible to allow for growth into a common framework and be able to work with existing and future HOT mapping project management tools.
Upon awarding of the contract the successful applicant(s) will have to deliver the following:
- Close collaboration with existing HOT Community software development volunteers as primary stakeholders throughout the process.
- A finalized list of features for implementation. The final feature set will be subject to approval by community engagement processes.
- Develop and deploy the OSM Tasking Manager 3.0 software that includes significant contributions to the following:
- Improvements to UI/UX for Mappers to better engage them and develop their OSM skills.
- Additional validation tools to generate higher OSM data quality and allow Validators to make better use of their time.
- Improved project management and creation tools.
- Complete API with authenticated access.
- No loss of functionality from OSM Tasking Manager 2.0.
- Developer and user documentation.
- Tests to cover load testing, integration tests and unit tests for any new code.
- Results of usability testing with key stakeholder groups.
How to Participate
Applications in PDF format should be submitted to firstname.lastname@example.org with “TM3 Tech Challenge Application” as the subject of the email and must be received by Saturday, December 31st, 2016.
Proposal submissions should include the following:
- Identify if this is an individual, team, group, or company proposal.
- A timeline overview of the expected major activities and milestones over the 4 month period.
- Where you fit in the scope of work. The scope of work entails a complete working software product. If you are not applying to produce the entire software product yourself, explain what roles you see your contributions playing. This is meant to encourage individuals and small community based teams to apply. UI/Python experts are as valuable as PostgreSQL/GIS developers. We want to find as many opportunities for skilled OSM community members to be a part of the development process as possible without them having to be experts in everything.
- Ideas for working with interested community members and stakeholders to better understand usage, needs and solicit feedback throughout the development process.
- Proposed technology stack and why it is the best choice for an iterative development project of this type.
- At least one specific feature addition you propose in your part of the full scope of work that would have the largest impact on any or all of the 5 areas identified as needing improvements.
- A plan addressing the testing of your contributions in the context of your proposed full software stack. As applicable for your contributions, code based tests may need to be written for integration testing, unit testing and load testing. Please explain how your contributions will either fit into a testing strategy that covers those areas, or will handle testing all of those areas. Be specific about when and where the testing will take place in your planned workflow and what code you will write if any to make that testing possible. Additionally, UI testing will need to be done on user facing contributions, please propose a community based method of gathering information about UI feedback.
- Resume or company qualifications with references to contributions to OSM or open source software projects.
Questions? HOT’s Slack Team ( https://hotosm-slack.herokuapp.com/ ) should be an open, direct connection between interested developers, HOT staff, HOT and OSM Community members and representatives of additional key stakeholder groups. Questions about the Tech Challenge can be directed there and it should serve as a main collaborative channel for the duration of the project.
Evaluation of Proposals
By participating in this tech challenge, all candidates agree to make their proposals public (resumes will always be kept private) under a license of their choice, for community review as needed. Criteria that will be considered in proposal and resume evaluation will include:
- Experience with agile development methods, rapid prototyping, and user interaction.
- Efforts to reuse code and integrate with existing open source projects, including other HOT OSS projects.
- Familiarity or contribution to other OSM related tools or libraries anywhere in the full OSM stack and OSGeo ecosystem or research.
- Proposed design and technology stack choices that provide scalability and sustainability.
- Clear examples of how proposed functionality will support HOT mapping projects, both mappers and project managers.
- Community and stakeholder engagement strategy.
All code will be released with an Open Source Initiative approved license to be defined at the beginning of the contract. All intellectual property ownership shall be transferred to HOT.
One important objective of this tech challenge is to create a final product that is well documented and coded according to best practices and standards. We prefer technology and software that have large developer pools in the open source community. We invite participants to review current HOT projects on GitHub and become familiar with technology already used, in order to maximize support by the community and make it easier for other members to contribute.
Direct engagement of the existing HOT Community software development leaders will be critical to the ongoing success of the community supported model HOT relies upon after this project is completed. Every effort must be made to involve those individuals with every important meeting, step or iteration in the development cycle. Other key stakeholders should be identified and also included in the process as much as comfortable and in whatever way is most convenient for them.