-
-
Notifications
You must be signed in to change notification settings - Fork 39
DesignGoals.md
draft
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.
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. This implies the MapRoulette website must have
- Relevant, fast, additive task filters to narrow down the task list by topic or geography
- Free text search
- Persistent search / filter results
- A friendly & effective onboarding funnel
Small, Meaningful tasks are the beating heart of MapRoulette. Mappers have solved millions of them in the past
- 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
MapRoulette is a democratic platform; everyone can help make OSM better by solving tasks but also by creating tasks for the community to solve. This is what sets MapRoulette apart from other task-oriented tools, but with the power to create tasks comes great responsibility. Poorly designed tasks can confuse mappers. lead to bad edits and erode trust in MapRoulette. It is imperative that MapRoulette creates the conditions for mappers to create high quality tasks. We need to provide:
- Great onboarding for new task creators
- Technical safety barriers
- Active feedback for creators
- Opportunity for mappers to give feedback
- A Staging environment to test and dry-run task ideas
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. We will only build features for the MapRoulette website that directly support communities collaborating on tasks:
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:
- We choose Boring Technology, key quote: "consider how you would solve your immediate problem without adding anything new"
- We create an inviting developer experience through architectural choices and human connection
- We create the conditions to be able to outlive any current contributors
- We avoid platform / systems vendor lock-in
A number of features currently available in MapRoulette would not meet the criteria for inclusion:
- Leaderboards
- Peer Review
- Messaging
- Metrics / Achievements
- Teams
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.
- 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
- The MapRoulette Application will not disappear or fundamentally change.
We aim to be a reliable and trusted participant in the OpenStreetMap community.
- A commitment to openness that goes beyond publishing source code
- We will put the needs of the volunteer community first
- "Design by committee"