DesignGoals.md

MapRoulette 4 Design Goals

draft

Why does MapRoulette exist?

OpenStreetMap, being a crowdsourced map project, requires constant maintenance: map data becomes out of date, mappers make mistakes, mapping conventions are refined over time. While there are tools that allow anyone to inspect the quality of the map data through a variety of lenses, the mapping community also needs a tool that exposes mapping defects as actionable tasks for the crowd to resolve in a organized, systemic manner.

Because no such tool existed at the time, I created MapRoulette in 2012. (Mailing list announcement.)

Even though other tools with similar purpose exist today, MapRoulette remains unique in its purpose, which is:

To give volunteer OSM mappers of all countries, abilities and interests, individual or as a community, small but meaningful mapping tasks that are created by their peers

Before we dive into design goals for the next stage of MapRoulette, it is important to set a strict baseline: what defines MapRoulette at its core? What is the minimal needed feature set to support its purpose as defined above? We will measure any design and architectural decisions against this baseline.

The MapRoulette Core Feature Set

Discovery

MapRoulette wants to cater to mappers of all countries, abilities and interests, and the diversity and volume of tasks represents this. It is imperative that a mapper can quickly discover tasks that meets their interests and skill level.

Solving tasks

The beating heart of the MapRoulette application is the task page. This is where mappers get all the information and tools they need to complete a task:

• Clear, concise task instructions
• Editing tools relevant to the task at hand
• A way to tell MapRoulette what action was taken
• A way to get in touch with the creator of the task

Creating Tasks

MapRoulette wants to be a plat

Platform

Collaboration

MapRoulette wants to support individual mappers as well as communities. Communities can consist of local mapping groups, school classes, groups supporting a cause, to give a few examples. We want to be cognizant of existing tools and channels through which mappers can communicate and form groups. We will aim not to duplicate functionality that exists elsewhere.

Localization

Help

Non-functional

MapRoulette is maintained and developed by a small team. Sometimes there will be paid help, other times there won't. It is imperative that we design the MapRoulette architecture in such a way that we can manage the application with these constraints. That means:

• Choose widely adopted and well documented components and frameworks
• Ensure that new contributors can get up to speed quickly

Out of Scope

A number of features currently available in MapRoulette would not meet the criteria for inclusion:

• Leaderboards
• Peer Review
• Messaging
• Metrics / Achievements
• Teams

MapRoulette As A Platform

Since its inception, MapRoulette has been a self-contained application with a mission to bring meaningful mapping tasks to the OpenStreetMap volunteer mapping community. We will not stray from this mission, but we will expand on it to meet the needs of a much richer ecosystem of interconnected OSM tools.

We will define MapRoulette as a platform rather than (just) an application.

What this means

• Enabling and encouraging two-way integrations between the MapRoulette API and other systems in the OpenStreetMap ecosystem, including the core OpenStreetMap infrastructure, will be central to the MapRoulette platform.
• MapRoulette will strive to be a central repository for QA signals in all of OSM, to be used across applications

What this does not mean

• The MapRoulette Application will not disappear or fundamentally change.

An example

A Trusted Project

We aim to be a reliable and trusted participant in the OpenStreetMap community.

What this means

• A commitment to openness that goes beyond publishing source code
• We will put the needs of the volunteer community first

What this does not mean

• "Design by committee"