[OSM-talk] Unification of OpenStreetBugs an Trac
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
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
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
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.
More information about the talk