<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:14pt"><br><div style="font-family: times new roman,new york,times,serif; font-size: 14pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">>> I agree that where the bug tracker starts being used for mapping-<br>>> related things, then the boundaries start to blur. But I'd still suggest <br>>> that the only difference between an OSB "ticket" and a "software <br>>> bug" ticket is the method of submission. After that, it's triaged <br>>> and managed in the same sort of way.<br><br>I agree with this as far as it goes, but.....<br><br>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.<br><br>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.<br><br>Donald<br></div></div></div><br>
</body></html>