>> 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 agree with this as far as it goes, but.....
I think we should keep a separation between OSM as in the tools used to run the
project (what's currently in trac) and the geographical data that we manage.
This would be possible by defining them as separate 'projects' within a single
bug tracker - most bug trackers I've used support this. The two projects have
very different (but overlapping) groups of people working on them - bugs in the
system will only be managed by a relatively small number of people, whereas
bugs in the data we manage will be of interest to any mapper in the area - who
may or may not come from a software development background. I can think of a
number of situations where people would want to filter out one or other type of
bug, and such separation would make this trivial. There are also issues like
'closing' a bug - I suspect most people reporting bugs in OSB won't bother to
go back to mark it as closed, as the target market is for the non-technical
mapper or map user. This won't
be the case with bugs in the software.
Apart from this, the lifecycle of a bug is essentially the same in each case so
the same tool could be used, but with a different front end.
Donald
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
