[OSM-talk] Unification of OpenStreetBugs an Trac

David Earl david at frankieandshadow.com
Wed Dec 3 19:40:32 GMT 2008


On 03/12/2008 18:47, Richard Fairhurst wrote:
> Gervase Markham wrote:
>> Inventing your own stuff makes perfect sense in the area of your 
>> core competency.
> 
> Agreed absolutely.
> 
>> [...]
>> I agree that where the bug tracker starts being used for mapping-
>> related things, then the boundaries start to blur. But I'd still suggest 
>> that the only difference between an OSB "ticket" and a "software 
>> bug" ticket is the method of submission. After that, it's triaged 
>> and managed in the same sort of way.
> 
> I wouldn't have thought so. Some big differences:

I'm with Gerv here. The process seems very similar to me. You are 
possibly thinking only in terms of how Trac works if you don't have much 
experience of bug trackers in general - I found Trac rather strange 
having used other bug trackers - they're not all alike...

> - assigned to the community by default, not to the default person/group
> responsible for that "feature"

So it starts off unassigned and someone takes responsibility for it. 
That's not an untypical use of bug tracking systems.

> - the bugtracker will not be the core client for managing the "bug", the
> usual OSM clients will (Potlatch/JOSM/Merkaartor)

I don't think so, with one exception: you'd like to be able to view the 
map from the bug report, but that can be handled by embedding a link in 
the original report.

When you're fixing a software bug, the tools you use to fix it and the 
tools for tracking it are usually independent. (Though in one system I 
wrote, checking in a file caused it to update the bug tracking system 
*and* the comments at the top of the source files with the check in reason.

> - _generally_ no desire for e-mail communication (if I post a report about
> "missing street name here", I don't want to be spammed when someone fixes
> it, I'm just being helpful)

So you don't disclose your identity, or we let you choose when 
submitting. Again sending email isn't a fundamental necessity in a bug 
trackers.

Having said that, I would really like an efficient way to communicate 
with the original reporter if it isn't clear what they meant, or I think 
they are wrong. It might be sufficient if certain fields were 
redisplayed in the reporter interface instead so if they revisit they 
can see why their suggestion was rejected or whatever.

> - greater need to manage bugs in aggregate than with a traditional
> bugtracker

I don't think so. People's comments are generally "this or that feature 
is wrong", which is an individual "bug".

> But I guess it depends where you come from. If you're primarily an
> open-source programmer you probably do naturally think of it in terms of
> bug-tracking.

The process seems a perfect fit to me, but the vocabulary is different, 
so something which lets you customise field names and so on would help.

David





More information about the talk mailing list