Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Christoph : I do not want to spend time writing a bug tracker that is then rejected because of the way it stores the bug reports. If you propose a tag/value storage, there is no reason someone would reject it. Xav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Thu, Dec 4, 2008 at 12:10 AM, Christoph Böhme [EMAIL PROTECTED] wrote: At the moment I am trying to figure out if bug reports reports can be stored directly in the osm database using standard nodes and tags. Please, please don't take or advocate this approach. The OSM core tables should, ideally, contain geo-data. We already anticipate much of the meta-data (e.g. created_by tags, usernames) to be applied to changesets (which are in themselves natively metadata). There's been a long and steady agreement that future bug tracking systems won't just slap nodes into the midst of our geotables. However, this is another subject that needs more doing and less talking :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Andy Allan [EMAIL PROTECTED] schrieb: On Thu, Dec 4, 2008 at 12:10 AM, Christoph Böhme [EMAIL PROTECTED] wrote: At the moment I am trying to figure out if bug reports reports can be stored directly in the osm database using standard nodes and tags. Please, please don't take or advocate this approach. The OSM core tables should, ideally, contain geo-data. We already anticipate much of the meta-data (e.g. created_by tags, usernames) to be applied to changesets (which are in themselves natively metadata). There's been a long and steady agreement that future bug tracking systems won't just slap nodes into the midst of our geotables. I was not aware of this agreement. When I first started thinking about a bug tracker I intended to keep the bug reports in data structures separate from the osm database. But in the following discussions I got the feeling that a bug tracker which allowed free-form tagging would be very welcomed. But implementing this means basically replicating the node-objects (and the way-objects too if you want to mark buggy areas). So, I concluded it would be the easiest to just introduce a new set of tags and manage them differently in the clients. However, I can see why this is not a very clean solution and I am happy to implement in a different dataset. However, this is another subject that needs more doing and less talking :-) I am really eager to start programming something but at the moment I am still trying to figure out what exactly. I do not want to spend time writing a bug tracker that is then rejected because of the way it stores the bug reports. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Richard Fairhurst wrote: Even when we do use something that wasn't invented here, the best fits are those which were at least partially developed with OSM in mind - from Mapnik to the ODbL. TBH I wouldn't have even considered this application as a bug-tracker had the comparison not been made on the mailing list. Inventing your own stuff makes perfect sense in the area of your core competency. So OSM rolling its own mapping software is entirely reasonable. However, OSM doesn't have a core competency in wikis (so we use MediaWiki), source code management (so we use SVN) or bug trackers (so we use Trac). 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. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
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: - assigned to the community by default, not to the default person/group responsible for that feature - the bugtracker will not be the core client for managing the bug, the usual OSM clients will (Potlatch/JOSM/Merkaartor) - _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) - greater need to manage bugs in aggregate than with a traditional bugtracker 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. cheers Richard -- View this message in context: http://www.nabble.com/Unification-of-OpenStreetBugs-an-Trac-tp20704897p20819118.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
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
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
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
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
David Earl [EMAIL PROTECTED] writes: On 03/12/2008 18:47, Richard Fairhurst wrote: - 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. I could imagine the workflow for people fixing map bugs to be something like starting their favorite editor, download all bugs for the area they care about, download the map data around the bugs they want to work on, fix it, upload the result and close the bug report. Or, attach a comment to the bug report or send a message to the reporter. For all but the last two operations it is probably most efficient if it can be done directly in the editor. For the last two the editor might fire up your email client to send the message. - 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. Yes, but bugs are related to each other by the area they are in. So you might want to highlight all the bugs in the area you have just worked on to close them all, or so. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Hi! Donald Allwright [EMAIL PROTECTED] schrieb: 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. You are probably right about the lifecycle. When I wrote the proposal for an improved bugtracker I noticed that the steps to deal with a map bug might be called differently but are in fact similar to dealing with normal bugs. I also think that a different user front end is definitely necessary. I only started using osb once I found the plugin for josm. I want to mark bugs while entering my data or marking them as fixed imediately after fixing them. If I fix several small bugs (and most bugs are just small things) I do not want to go on a separate website and locate the bugs only to mark them as fixed. I might even accidentally fix bugs without noticing that they exist if I do not see them in the editor. Changing the user interfac of a bug tracker sounds like a logical solution but what I still haven't found out is what will be left from the original bugtracker once I changed the user interface. I have the feeling that there would not be left much more than a database with a couple of methods to query bug reports, add or update them, and request notifications on changes. Since osm does not usually have restrictive read/write access policies there is not even authorization code needed. All the logic of how to handle bug reports is implemented in the different front ends. Depending on the application this logic might be quite different. So, I do not really see a reason why to build upon an existing bug tracker and thereby possibly restraining future applications of the map bug tracker by relying on a certain database format. At the moment I am trying to figure out if bug reports reports can be stored directly in the osm database using standard nodes and tags. The only problem I see with that are comments and attachments on bug reports which probably need to be managed in an extra data struture. I think such an approach would be much more flexible and osm like. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Marc Schütz wrote: Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. Modern Bugzillas have an XML-RPC interface, and also entirely customisable templates. Having OSB automatically create Bugzilla tickets is a simple matter of programming :-) Gerv (Bugzilla hacker, willing to help) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Richard Fairhurst wrote: I'm not sure why the need to reuse existing software at all. Bugtracking is the sort of thing you expect to find in 'Rails For Dummies' as My First Rails App - if you’ve got a decent framework it’s pretty elementary. As someone who's spent the last nine years working on one, and seen several putative competitors arrive and fade (Scarab, anyone?), I'd dispute that. You can do simple things simply, yes, but you always find you have more requirements than you think. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On 30/11/2008 13:06, Gervase Markham wrote: Richard Fairhurst wrote: I'm not sure why the need to reuse existing software at all. Bugtracking is the sort of thing you expect to find in 'Rails For Dummies' as My First Rails App - if you’ve got a decent framework it’s pretty elementary. As someone who's spent the last nine years working on one, and seen several putative competitors arrive and fade (Scarab, anyone?), I'd dispute that. You can do simple things simply, yes, but you always find you have more requirements than you think. Absolutely David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Mikel wrote: I'd suggest bypassing Trac and looking into RedMine http://www.redmine.org/ I'm not sure why the need to reuse existing software at all. Bugtracking is the sort of thing you expect to find in 'Rails For Dummies' as My First Rails App - if you’ve got a decent framework it’s pretty elementary. (I'm doing it right now for our work CMS. It’s not exactly taxing.) It would take more time to integrate an existing set-up, let alone make it usable for n00bs - which is, after all, the point of all this - than to write something new. But really, we have the chance to do something much better. Right now we have three mainstream editors. On a scale of 0-10 where 0 is approachable and 10 is super-powerful, Potlatch is probably 5, Merkaartor 8, JOSM 10. We don’t actually have an entry-level editor. Of course there are things one can do to improve usability, and I'm hoping to make Potlatch a 3 or 4 eventually, but to turn it into something really approachable (like Google Map Maker) would basically mean we go from having no entry-level editor to having no intermediate editor. Which isn't helpful. So let's kill two birds with one stone. OSB + entry-level editing = OSM is suddenly editable by the great unwashed. If you're not logged in, you could: - report bugs (OSB-style) If you are logged in, you could: - report bugs (OSB-style) - place and tag POIs - change way names/refs - some other limited tagging (road type? oneway? access?) No need to have geometry drawing, which is the hard bit to code. If you want to draw ways, you need to make a sufficient commitment to the project to learn an editor, just as thousands have already done. And if you’ve progressed through this entry-level editor, you’re a lot less likely to foul up when you do. Some of this could be built on OpenLayers as per the data browser (though Chris Schmidt has expressed reservations about JS performance with many ways loaded in IE and FF2, and he knows much more about this sort of thing than I do). Tom Carden’s very interesting-looking ActionScript 3 renderer (http://www.tom-carden.co.uk/2008/10/01/openstreetmap-vectors-flash-yahoo-maps/) would be a fantastic foundation, unless there are already code gnomes somewhere working on turning it into a Potlatch killer ;) . cheers Richard -- View this message in context: http://www.nabble.com/Unification-of-OpenStreetBugs-an-Trac-tp20704897p20717111.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Richard Fairhurst wrote: No need to have geometry drawing, which is the hard bit to code. If you want to draw ways, you need to make a sufficient commitment to the project to learn an editor, just as thousands have already done. And if you’ve progressed through this entry-level editor, you’re a lot less likely to foul up when you do. Some of this could be built on OpenLayers as per the data browser (though Chris Schmidt has expressed reservations about JS performance with many ways loaded in IE and FF2, and he knows much more about this sort of thing than I do). Tom Carden’s very interesting-looking ActionScript 3 renderer (http://www.tom-carden.co.uk/2008/10/01/openstreetmap-vectors-flash-yahoo-maps/) would be a fantastic foundation, unless there are already code gnomes somewhere working on turning it into a Potlatch killer ;) . In my experience, most browsers start complaining about lengthy JS runtime when more then (say) 200 OL vectors features are loaded and responsiveness becomes poor. 200 way segments (or even 1k) is not much in any built-up area, so only the highest zoomlevels are usable when all features on the map are expressed in OL vectors. On the other hand, OL/browers are fine with 10k segments in a single vector (see yournavigation.org and generate a long route). So maybe it's just OL that needs optimizing to be able to draw many features on a map. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
2008/11/27 Lambertus [EMAIL PROTECTED]: Richard Fairhurst wrote: No need to have geometry drawing, which is the hard bit to code. If you want to draw ways, you need to make a sufficient commitment to the project to learn an editor, just as thousands have already done. And if you've progressed through this entry-level editor, you're a lot less likely to foul up when you do. Some of this could be built on OpenLayers as per the data browser (though Chris Schmidt has expressed reservations about JS performance with many ways loaded in IE and FF2, and he knows much more about this sort of thing than I do). Tom Carden's very interesting-looking ActionScript 3 renderer (http://www.tom-carden.co.uk/2008/10/01/openstreetmap-vectors-flash-yahoo-maps/) would be a fantastic foundation, unless there are already code gnomes somewhere working on turning it into a Potlatch killer ;) . In my experience, most browsers start complaining about lengthy JS runtime when more then (say) 200 OL vectors features are loaded and responsiveness becomes poor. 200 way segments (or even 1k) is not much in any built-up area, so only the highest zoomlevels are usable when all features on the map are expressed in OL vectors. The current data browser handles this issue by limiting to 100 features, and asking if the user is *really sure* they want to load more. Otherwise, it tells them to zoom in to view the detail. If we're considering an OL editor for small edits, we'd want to require a fairly high zoom level anyway. -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On 26/11/2008 16:56, Steffen Vogel wrote: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. I've already put a installation of Bugzilla to my Server (http://bugs.griesm.de) and I've done some testing around. Bugzilla is coded in perl. I've some basic perl skills. But I'm afraid thats not enough. Perhaps we can some more expierenced perl codes here in the community? A migration of the other bug trackers (http://trac.openstreetmap.org) to Bugzilla would ensure that we have projectwide unique Bug IDs. Small an new projects without a bug tracker could use this installation. I think this would lead us to a faster developement cyclus... It's just imagination.. What do you think about it? This is a very interesting insight. The ability to record, track status and so on of map problems in the same way as tried and tested bug systems seems like an excellent one IMO. I think the key thing is to retain the ease of use (no registration, point at map etc) to report problems, but the consumers of those reports can easily cope with a proper change control system. So I wonder whether the easy way to do this would be for OSB or a similar front end to submit a report to a tracking system behind the scenes. Most such systems allow for custom fields, so we could also have lat/lon and the front end could query the tracking system to display live data. Just a thought - there isn't already a change tracking system for geographical data out there is there, or an add on or plugin for an existing system? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Wed, Nov 26, 2008 at 11:20 AM, David Earl [EMAIL PROTECTED]wrote: Just a thought - there isn't already a change tracking system for geographical data out there is there, or an add on or plugin for an existing system? No, I don't think there's ever been a use case for what we're talking about before. I would think it would relatively trivial to add a Location value to any of the open source bug tracking systems. The hard part might be adapting the bug tracking system to allow anyone to use it with the same (low) amount of work needed to contribute with the current OSB set up. Showing the user a signup page for the bug tracking system is impractical. Only the people who care about fixing the bugs should see those bits of the interface. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Am Mittwoch 26 November 2008 17:56:15 schrieb Steffen Vogel: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. IMO the most important advantage of OSB is its ease of use: there's no login required, you don't need to categorize your bug report etc. I think these features are important to keep in any new bug tracker we are going to use. I've already put a installation of Bugzilla to my Server (http://bugs.griesm.de) and I've done some testing around. Bugzilla is coded in perl. I've some basic perl skills. But I'm afraid thats not enough. Perhaps we can some more expierenced perl codes here in the community? A migration of the other bug trackers (http://trac.openstreetmap.org) to Bugzilla would ensure that we have projectwide unique Bug IDs. Here I disagree: OSB is specifically targeted at users and mappers, not at developers. I think it's quite okay that we have separate bug trackers for these. Small an new projects without a bug tracker could use this installation. I think this would lead us to a faster developement cyclus... That's already possible with our Trac as it is, right? Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On 26/11/2008 17:27, Ian Dees wrote: On Wed, Nov 26, 2008 at 11:20 AM, David Earl [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Just a thought - there isn't already a change tracking system for geographical data out there is there, or an add on or plugin for an existing system? No, I don't think there's ever been a use case for what we're talking about before. I would think it would relatively trivial to add a Location value to any of the open source bug tracking systems. The hard part might be adapting the bug tracking system to allow anyone to use it with the same (low) amount of work needed to contribute with the current OSB set up. Showing the user a signup page for the bug tracking system is impractical. Only the people who care about fixing the bugs should see those bits of the interface. Well the map could be a front end, which behaves as a registered user, so it just submits the same form that it would had it been typed in directly to submit a new issue. Marking the map with exsiting issues would be the bigger problem I think - especially if the number of reports gets large. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Marc Schütz schrieb: Am Mittwoch 26 November 2008 17:56:15 schrieb Steffen Vogel: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. IMO the most important advantage of OSB is its ease of use: there's no login required, you don't need to categorize your bug report etc. I think these features are important to keep in any new bug tracker we are going to use. +1 I've already put a installation of Bugzilla to my Server (http://bugs.griesm.de) and I've done some testing around. Bugzilla is coded in perl. I've some basic perl skills. But I'm afraid thats not enough. Perhaps we can some more expierenced perl codes here in the community? A migration of the other bug trackers (http://trac.openstreetmap.org) to Bugzilla would ensure that we have projectwide unique Bug IDs. Here I disagree: OSB is specifically targeted at users and mappers, not at developers. I think it's quite okay that we have separate bug trackers for these. +1 Small an new projects without a bug tracker could use this installation. I think this would lead us to a faster developement cyclus... That's already possible with our Trac as it is, right? I agree here too. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Wed, Nov 26, 2008 at 9:38 AM, John07 [EMAIL PROTECTED] wrote: Marc Schütz schrieb: Am Mittwoch 26 November 2008 17:56:15 schrieb Steffen Vogel: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. IMO the most important advantage of OSB is its ease of use: there's no login required, you don't need to categorize your bug report etc. I think these features are important to keep in any new bug tracker we are going to use. +1 If it's tying in to a proper bug management system, classification could be a powerful addition. This classification could be done by bug wranglers based on the description typed by the reporter. So, I agree, the ease of use should be kept, but if desired, there could be an alternate Advanced form where the reporter could add the classification or other details (maybe a spot to optionally add their email address to track the bug status?). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Karl Newman schrieb: On Wed, Nov 26, 2008 at 9:38 AM, John07 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Marc Schütz schrieb: Am Mittwoch 26 November 2008 17:56:15 schrieb Steffen Vogel: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. Bugzilla as a backend would certainly be nice, but as a frontend it is obviously inappropriate. I don't know whether Bugzilla supports alternate frontends; if so, it could be worthwhile building one that fits our needs. IMO the most important advantage of OSB is its ease of use: there's no login required, you don't need to categorize your bug report etc. I think these features are important to keep in any new bug tracker we are going to use. +1 If it's tying in to a proper bug management system, classification could be a powerful addition. This classification could be done by bug wranglers based on the description typed by the reporter. So, I agree, the ease of use should be kept, but if desired, there could be an alternate Advanced form where the reporter could add the classification or other details (maybe a spot to optionally add their email address to track the bug status?). +1 :-) Easy to use for the normal people and an advanced button for the osm-people. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
I'd suggest bypassing Trac and looking into RedMine http://www.redmine.org/ Trac is wonderful, but convoluted. RedMine is built in Rails and quite easy to modify. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Hi! Steffen Vogel [EMAIL PROTECTED] schrieb: As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts statistics etc. I never thought about most of these features but they would be very handy, indeed. I am hoping to have things like a basic classification (POI bug, street-bug, power-line bug, etc) and the ability to close a bug without removing it. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? My experiences as a bug reporter with Bugzilla were not very positive so far. In my view the user interface is very confusing and does not seem to be well thought-out from a user's perspective. Based on these experiences I personally would not use Bugzilla as a bugtracker for any project. However, I like your idea of reusing some existing software but we also should make sure that we are reusing some software that is actually suited for what we want to do. What I mean is: The main user interface for map bugtracker is probably very different from a software bugtracker. Also, while having much in common, I think, a map bug is usually much simpler than a software bug and might also require a slightly different way of handling it. At the moment I am not sure if this can be represented naturally with a software bugtracker without ending up with a software that is neither fish nor fowl and difficult to maintain. A migration of the other bug trackers (http://trac.openstreetmap.org) to Bugzilla would ensure that we have projectwide unique Bug IDs. Having unique bug ids would be nice to have but I do not think it is very important. I am not even sure if it would be possible with Bugzilla at all because a map bug description will probably contain a different set of fields than a software bug (e.g. a map bug would not contain operating system fields). And I also have to admit that I prefer the trac bug tracker over bugzilla (again from a bug reporter perspective). Cheers, Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Mikel Maron wrote: I'd suggest bypassing Trac and looking into RedMine http://www.redmine.org/ Trac is wonderful, but convoluted. RedMine is built in Rails and quite easy to modify. Trac has the massive advantage that we're already using it however... Being built on rails is no particular reason to favour something at all really - quite the opposite in many ways. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
Hi, Tom Hughes wrote: Being built on rails is no particular reason to favour something at all really - quite the opposite in many ways. Come on, how can you be critical of a project that single-handedly implements an issue tracker, a wiki, and even forums! It's probably just a few more lines of rails code and it also has a geo database, then we'll just drop everything we have and move over... Oh wait. It doesn't implement its own version of E-Mail. Too bad ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unification of OpenStreetBugs an Trac
On Thu, Nov 27, 2008 at 01:23:59AM +0100, Frederik Ramm wrote: Come on, how can you be critical of a project that single-handedly implements an issue tracker, a wiki, and even forums! It's probably just a few more lines of rails code and it also has a geo database, then we'll just drop everything we have and move over... Oh wait. It doesn't implement its own version of E-Mail. Too bad ;-) It could be the Emacs of the OSM world. :) Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
