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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
