Contents 1 Bugtracker Proposal 1.1 Rationale 1.2 Current State 1.3 Required Additional Features 1.4 Use-Cases 1.5 Procedures 1.5.1 Map-Errors 1.5.2 To-Do-Items 1.6 Components of a Bug Report 1.7 User-Interfaces 1.7.1 Web-based Interface 1.7.1.1 Adding a New Bug 1.7.1.2 Viewing Bugs and Updating Them

Bugtracker Proposal

This is a proposal for a possible successor of openstreetbugs after merging it into the osm infrastructure.

Rationale

With more and more places being "finished" the mapping work changes from adding new areas to correcting and updating existing places. This makes it neccessary to be able to mark errors on the map or to mark locations that require updates. Finding errors or requesting updates does not require any special mapping skills and no equipment. So, every user of osm can easily contribute to it. However, this makes it neccessary that the software to do these tasks is web-based and very easy to use.

There is also a need amongst mappers to put some form of todo-items in the database. At the moment mappers use nodes or ways in special spatial arangements or with note-tags attached to keep track of things like continuing streets which needs mapping or areas that need work. No consensus or documentation exists which clarifies the meaning of these markers.

Current State

Since april 2009 there is a modified version of OpenStreetBugs, more information can be found at User:Emka/new OSB.

A tool called Openstreetbugs made the beginning. It allows users to place error markers with short descriptions on the map. It is possible to add comments to an error and to mark an error as fixed. Fixed errors are deleted after a week. Openstreetbugs does not request any email addresses from bug reporters nor does it have some user management.

Openstreetbugs can be used directly from JOSM with an Openstreetbugs plugin. This plugin offers basically the same functionality as the website but integrated into JOSM. The plugin parses the javascripts returned from the openstreetbugs web application.

Openstreetbugs proved very useful for both applications but over the time it became clear that an integration on the main osm website is desirable and that some more features are needed.

Beginnings of an attempt to integrate OpenStreetBugs into the main page are available on the dev server. It is still in the planning stage and the features it will support in its first version haven't been finalized. It will probably be very similar to the current OSB though.

Required Additional Features

• The ability to contact the reporter of a bug report
• User handling
• Closed bugs should be kept for reference. Especially if the bug report was wrong and no changes were made in response to it
• Handling of duplicate bug reports
• Assigning bugs to mappers
• Adding additional information like files, images and links to a bug report
• E-Mail notifications if a bug changes.
• Current state of a bug
• Search, Filters
• Internationalisation, it should be possible to translate every string in the ui with gettext framework
• Statistics, charts, and reports
• Combination with an entry-level map editor (Richard's email)

Use-Cases

Here are some use cases to demonstrate the application of a bugtracker:

1. Paul finds an error while browsing the map to plan a cycle trip. He likes the error to disappear but he is not a mapper and appart from this he is busy planning his cycle trip.
2. Carla has been out to map her neighbourhood and is now back at the computer to enter the data. Since she wants to continue mapping next week she took notes whereever a street branched off her route and she did not follow it. She now likes to enter these notes with the map so that she and other people know that there are things missing which will be added soon.
3. Mark lives in an area which is already completely mapped. However, he has some time at hand and want to contribute to the map. Since he has no gps receiver he can only do limited mapping. He wants to have map with locations of open bugs where he can go to and check names and add POIs.
4. When Mark comes home he adds his corrections to the database and wants to mark the bugs as closed.
5. Mark also noted that one of the bugs was not actually a bug and everything was fine.

Procedures

Map-Errors

1. The error is noticed and an osb is created.
2. Notifications for a new bug in the area are sent to people interested in this area
3. Someone decides to fix the bug.
4. 1. The bug can either be dealt with straight away (go to step 6)
   2. or some more information needs to be collected
5. 1. The data has been collected (go to step 6)
   2. There is no bug => the bug is wrong and will not be fixed.
   3. There is indeed a bug but it is not fixable at the moment.
6. The database is updated. The bug is fixed
7. Optional: a user is not happy with the resolution and reopens the bug

To-Do-Items

1. Create a to-do item and explain what needs to be done and who is doing it
2. Collect the information
3. Enter the data
4. Close the item as completed

Components of a Bug Report

• Location: Location of the bug on the map. Especially for todo-items (like party-cakes) areas might be handy
• Object type: (optional) to allow assigning a bug to a database object, provide the kind of object (node/way/relation) the error is found. This information can easily be obtained from automated checking routines and shouldn't be lost
• Object ID: (optional) node_id, way_id or relation_id

• State: The state describes in which state of processing the bug report currently is in:
  • NEW: The bug has been created and nothing had happened so far
  • REOPENED: Someone was not satisfied with the resolution of the bug
  • FIXED: The error is fixed and bug report has been closed
  • NOTABUG: There is no error to be fixed
  • NOT YET FIXABLE: There is something to be done but it cannot be done now.
  • DUPLICATE: There is already another bug for the same issue (link to this bug)
  • MORE INFO NEEDED: Someone had a look at the bug report and decided that more information is needed to handle it. A comment should describe what is needed.
  • DATA ADDITION PENDING: All information has been collected. The data just needs to be entered.

• Classification: The classification is used to group bugs together based on what is wrong. The application of the classification is two-fold: First, it can be used to judge the importance of a bug report because it depends on what the map is used for. Second, it can be used to select certain types of errors. E.g. if someone only wants to deal with missing POIs in an area. Suggested values could include: MISSPELLED NAME; Streets: FOOTPATH, CYCLEWAY, STREET, MAIN STREET, MOTORWAY, POI; Railway: RAILWAY, RAILWAY STATION; PUBLIC TRANSPORT POI; WATERWAY; POWERLINE, ... For future extensions a hierarchy of classifications should be possible. A tree view of error classes would be nice on the user interface

• Assigned: People can assign themself to a bug to indicate that they will solve it. This is not a neccessary step but it might be wise to do in cases where data collection is required and you planned to do so.

• Description: A very short description of the bug

• Annotations: Adds a note, file, image, or link to a bug. This field uses a wiki-style mark-up

• Reported-by: Either a osm-username or an email address
• Reported-on: Date and time when the bug was added
• Last time visited: Date and time when the bug was checked last (date of database dump)

The bug-tracker keeps a history of every bug. So, whenever a value is changed or an annotation is made a new revision of the bug is created.

User-Interfaces

The bug-reports database should be kept separate from the user interface and only provide an api to add, change and search bugs.

Web-based Interface

Next to the view tab on the openstreetmap-page is an "Report Errors" tab. Clicking on this tab shows the same map area as the view tab. Above the map is a small text explaining how to add a bug and button to unfold a filter-dialog.

Adding a New Bug

Click on the + button and then somewhere on the map to create a bug at this position. I dialog pops up, asking for:

• a short description
• an email address if the user is not logged in (automatically register this email address in the list of people to notify in case of a change in the bug report or through a checkbox)
• a classification
• if the user is logged in he or she can optionally assign the bug to someone
• a link offers the possibility to annotate the bug further with images, more comments, or files.

If the user chooses to annotate the bug the dialog changes into one with a text window that allows wiki style mark-up and an file upload form.

After pressing okay the bug is placed on the map.

Viewing Bugs and Updating Them

Existing bugs are displayed on the maps. Their appearance could different depending on classification and state. To only view specific bugs the user can click on filter to open a dialog which allows to speficy bug reports by:

• state
• classification
• assigned to
• age
• bug-id
• reporter
• contents of description and annotations

After configuring the filter the display is updated.

To view details of a bug the user can click on a bug in the map and a dialog pops up that displays the details of the bug. If the user is logged-in he/she can update and the bug report. There is also a link to add an annotation which can be used by everyone.