Talk:Bugtracker proposal

I don't think it's remotely sensible to consider a bugtracker in isolation from an entry-level editor:

http://lists.openstreetmap.org/pipermail/talk/2008-November/031778.html

--Richard (speaking as Potlatch author)

The way I understand your email is that a bugtracker would be a tool within an entry-level editor. This tool could then even be used without the editor-components if a user is not logged in. I think this makes the bugtracker relatively separated from the rest of the editor. Also, my original motivation for writing this proposal was to find out how a bug report for a map error should look like and what special requirements map-bug processing has. I supposed there will be more than user interface to manage bugs and an entry-level editor will be only one of them.

However, I added the combination of the entry-level editor and the bugtracker to the required features list. Perhaps you can merge your ideas for a combination into the description of the web-based interface?

-- Xoff 17:25, 27 November 2008 (UTC)

I'm still fairly new to OSMing but have been editing Wikipedia articles for a longer time, and one thing that strikes me as the big difference between the two is the ease of fixing damage. In OSM, it is very easy to cause serious damage to the map, by mistake or by deliberate vandalism, and as far as I know there is no easy way for mappers to notice when changes have been made, or to roll back bad changes. In Wikipedia, it is very easy to see when changes have been made, and it takes less effort to revert a change than it does to make one, which is why Wikipedia can withstand millions of anonymous childish vandals. If OSM were easy to edit, those childish vandals would be deleting villages and re-routing highways, and they would overwhelm our capacity to see and fix their damage. (The other thing that helps protect OSM is that changes don't appear until tiles are rendered, hours or days later, and vandals are all about instant gratification.) So I think a well-integrated bug-tracker is good, but I am nervous about an entry-level editor. Until it is easier to undo damage than to do damage, the barrier to entry should remain high. TouringTest 13:29, 17 January 2009 (UTC)

JOSM

I would actually like to see this in JOSM, that way I could put in a "bug" as a reminder where I know more work needs to be done (like branch roads), or areas where I see that here are clear errors. Hopefully this can be fully integrated in JOSM, but a plugin would be the best way to begin with. --Skippern 10:39, 28 November 2008 (UTC)

Have you had a look at the Openstreetbug plugin for JOSM? I am already using it for exactly this type of things. While using it I realised that I like to have some more functionality. And that's why I started this proposal page. --Xoff 23:41, 28 November 2008 (UTC)

I have had a look at Openstreetbug (the site not the plugin) and some how didn't like that. I fully support this proposal as it seems to me a better bug tracking system for maps than the existing OSB. To be able to set a range of statuses on a bug, and to keep bug notes in the system even long after they have been corrected is a vital part of having this system work. To have it fully integrated in JOSM might allow us to check bug reports in areas we work, assigned to us, filtered by status, and so on. For instance, I would like to be notified if somebody puts a bug report in the area I usually work, so that I can investigate it. The best time to get this notice is when I update that area, i.e. downloads the area to see what changes others have done. --Skippern 13:05, 29 November 2008 (UTC)

XMPP OSM Bug Interface

All Bugs are handled by a bot with a jabber id (xmpp:bugbot@openstreetmap.org) The bugbot is connected to a xmpp server all the time. Users can login to all existing xmppserver (like jabber.org, gtalk,...)

Subscription

Normal subscrition

<iq from="someone@jabber.org" type="set" id="push" to="bugbot@openstreetmag.org" >
<query xmlns="jabber:iq:roster">
<item ask="subscribe" subscription="none" jid="bugbot@openstreetmap.org" />
</query>
</iq>

bugbot sends an automatic "subscribed".

---

Presence:

<presence from="someone@jabber.org" to="bugbot@openstreetmap.org" >
<priority>5</priority>
<geo xmlns="noideawhichnamespace">
  <area latmin="-2" latmax="2" lonmin="34" lonmax="36"/>
</geo>
</presence>

Publish a bug

<iq type='set'
   from='someone@jabber.org'
   to='bugbot@openstreetmap.org'
   id='publish1'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
   <publish node='12.32773,45.23332'> 
     <item>
         <bug xmlns="anamespace">
         <text>One Way wrong direction!!!</text>
         <allthedateforabug>
                 ...
         </allthedataforabug>
         </bug>
     </item>
   </publish>
 </pubsub>
</iq>

Subscribe to a bug

<iq type='set'
   from='someone@jabber.org'
   to='bugbot@openstreetmap.org'
   id='publish2'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
   <subscribe
       node='12.32773,45.23332'
       jid='bugbot@openstreetmap.org'/>
 </pubsub>
</iq>

...

More details see pubsub xep-0060.

--Robotnic 01:43, 2 December 2008 (UTC)

Use-cases as APIs?

I would suggest that use-cases might look something like:

• developer for mobile devices wants to upload bug-reports entered in the device.
• website developer wants an HTML form to report errors in the current view
• as above, but using javascript or flash instead of static HTML
• someone with geoRSS or kml-reading code wants to display bugs
• routing device wants to upload a bug whenever the car speeds past something which is a dead-end in the map

when you look at it that way, (rather than "user of openstreetbugs.org wants to do x...") it brings-out feature requests like:

• bug-reports that specify an area or bounding-box rather than just lat/lon
• specifying which zoom level and which renderer the error is on
• groups/tags for classifying the reports (rendering, map, routing, missing things, changed things, closed roads, construction work, future building plans)
• methods for accessing the database (get request, post request, bulk upload, REST api, SMS, DNS)
• reporting errors in the upload (http response codes, text in the response, easy to download the reports you added)