Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
On 01/12/08 22:42, Christoph Böhme wrote: Frederik Rammfrede...@remote.org schrieb: Christoph Böhme wrote: Before you get all cranked up writing something new, be sure to check out the notes API branch in SVN, where something OSB-like has been attempted in rails already. I don't know by whom and what the status is but I'm sure you will find out. Thanks, I will have a look at it. I did a bit to much mapping at the weekend and only managed to install the rails port. However, at the moment I am a bit confused anyway and not sure what I am going to implement. Don't look at it too hard - the person that was working on it kind of shot off on a tangent from the original idea. It's also pretty old now so way out of sync with the main code. I should delete it really. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi! Tom Hughes [EMAIL PROTECTED] schrieb: The problem with the notesapi branch is not that it's the same database but just that it takes the wrong approach to doing things within that database. For the record my preference would very much be for this to be a rails based system within the current database. I am definitely in favour of a rails based system, too. When you said within the current database did you mean implementing it using nodes and ways or just placing some more tables within the current database? Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi! Bernhard Zwischenbrugger [EMAIL PROTECTED] schrieb: What about defining the API first? Yes, at least before starting some serious programming. My basic idea for the api was to allow to add, search/filter, and modify bug reports through a RESTful controller. The search/filter output should be able to provide rss feeds to enable watching an area for changes and new bugs. I haven't really thought about email or jabber notifications. At the moment I am just thinking of hooking some notification classes into the main api. These can then send out what ever type of notification is requested (text messages on your mobile depending on your current location?). And before defining the API we need the use cases. I tried to put some use cases on the proposal page already. Feel free to add more (http://wiki.openstreetmap.org/wiki/Bugtracker_proposal). An other thing I would like to see are bug reports in XMPP (Jabber) Network. Think about a map that shows you a new report without polling. People could discuss immediately in a small chat window about this bug. Scalability shouldn't be a problem with XMPP. Such a system might be an interesting job to set up. It could probably be implemented as a transport for jabber that impersonates each bug report with a new user. Everyone who has added one of these users to their roster gets all messages other people send to this user. Another option would be some multi-user chat but I cannot really image how to do this. Cheers, Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Frederik Ramm [EMAIL PROTECTED] schrieb: Christoph Böhme wrote: That sounds good. I will see at the weekend if it really is a piece of cake. Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? Before you get all cranked up writing something new, be sure to check out the notes API branch in SVN, where something OSB-like has been attempted in rails already. I don't know by whom and what the status is but I'm sure you will find out. Thanks, I will have a look at it. I did a bit to much mapping at the weekend and only managed to install the rails port. However, at the moment I am a bit confused anyway and not sure what I am going to implement. Especially it would not help anyone if bug reports contain different information depending which user interface was used to add them to the database. Just imagine the situation where a user adds a bug through the web interface and a mapper requests the bugs with JOSM. Both pieces of software need to use the same model of information in the report and the same concept of how to process the bug report. This is very short-sighted - coming from someone who has worked with OSM! Who are you to know in advance what cool ideas the writers of bug tracking software might have? Just because you cannot think of anything beyond severity, class and comment doesn't mean nobody else can. Let the writers of software decide, do not constrain them by your limited imagination. If someone comes up with a cool new tag the makes reporting and handling bugs much easier, then let him do that and write his own cool interface for it. If it works well then others will copy the idea. By postulating that everyone will have to work with the smallest common denominator, you are killing off creativity. It's ok to have a few suggested standard attributes like severity and so on, but never close the door to enhancements. I should have excepted this reply ;-) and I have to admit I was quite focused on developing just a bugtracker and nothing more. Though, I did not assume I could write the ultimate bug tracking application that would never need to be extended or accompanied by other tools. My argument was basically that changes will not happen as often in a bug tracker as they do for mapping. So, I assumed it would be sufficient to be able to change the table definitions in the database if new ideas pop up. But after thinking about this for a while now I can actually see no advantage of structured bug reports compared to tagged ones. So, let's go for the tagging approach! There is only one (technical) question remaining: If we use the same tagging scheme we could as well store the bug reports directly in the main database instead of setting up additional tables. The only problems I can see with this are: - Notifications when new bugs are added - How to handle file attachments (through an additional api?) - Changesets in api 0.6 (I do not like the idea of creating a new changeset for every single bug) Perhaps this questions should better be asked on dev? Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Xav [EMAIL PROTECTED] schrieb: Christoph Böhme a écrit : Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? If it is a moral question : of course. If it is a technical question : 50% of the code has to be rewriten. Fine, it would at the very least give us something to start with. But when I proposed the use of tags, I thought about the clients-developper : - I want the simplier interface with only lat/lon/date, two bug states, and a text. I do not want a crapy interface with 30 text areas and 60 combo-boxes - Someone will desire to add a zoom level for each bug, the email of the authors, and three bug states - Someone else will want a reference to the OSM data, the diameter of the area that the bug describes, the age of the mother of the author, etc. The tag=value schema does all this. And, as the OSM end-user clients (like Mapnik, [EMAIL PROTECTED], routing softwares), there are only small pieces of the data that are rendered depending of the choice of the rendered. As I wrote earlier, I made my mind up about the tagging scheme and I think it is probably the best solution. I do not think that it would be the best idea to put images in the database besides it is technically possible with a classical database ; I do not know about OSM database. An URL to a solid file seems to me much more efficient. True. It only means that there need to be an additional api for uploading files which works smoothly together with the main api. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Frederik Ramm [EMAIL PROTECTED] schrieb: Christoph Böhme wrote: That sounds good. I will see at the weekend if it really is a piece of cake. Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? Before you get all cranked up writing something new, be sure to check out the notes API branch in SVN, where something OSB-like has been attempted in rails already. I don't know by whom and what the status is but I'm sure you will find out. Thanks, I will have a look at it. I did a bit to much mapping at the weekend and only managed to install the rails port. However, at the moment I am a bit confused anyway and not sure what I am going to implement. Especially it would not help anyone if bug reports contain different information depending which user interface was used to add them to the database. Just imagine the situation where a user adds a bug through the web interface and a mapper requests the bugs with JOSM. Both pieces of software need to use the same model of information in the report and the same concept of how to process the bug report. This is very short-sighted - coming from someone who has worked with OSM! Who are you to know in advance what cool ideas the writers of bug tracking software might have? Just because you cannot think of anything beyond severity, class and comment doesn't mean nobody else can. Let the writers of software decide, do not constrain them by your limited imagination. If someone comes up with a cool new tag the makes reporting and handling bugs much easier, then let him do that and write his own cool interface for it. If it works well then others will copy the idea. By postulating that everyone will have to work with the smallest common denominator, you are killing off creativity. It's ok to have a few suggested standard attributes like severity and so on, but never close the door to enhancements. I should have excepted this reply ;-) and I have to admit I was quite focused on developing just a bugtracker and nothing more. Though, I did not assume I could write the ultimate bug tracking application that would never need to be extended or accompanied by other tools. My argument was basically that changes will not happen as often in a bug tracker as they do for mapping. So, I assumed it would be sufficient to be able to change the table definitions in the database if new ideas pop up. But after thinking about this for a while now I can actually see no advantage of structured bug reports compared to tagged ones. So, let's go for the tagging approach! There is only one (technical) question remaining: If we use the same tagging scheme we could as well store the bug reports directly in the main database instead of setting up additional tables. The only problems I can see with this are: - Notifications when new bugs are added - How to handle file attachments (through an additional api?) - Changesets in api 0.6 (I do not like the idea of creating a new changeset for every single bug) Perhaps this questions should better be asked on dev? Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Christoph Böhme a écrit : Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? If it is a moral question : of course. If it is a technical question : 50% of the code has to be rewriten. So, I do not think bug reporters will ever feel the desire add tags to their bug reports. You're right. No bug reporter will feel the desire to add new tags. But when I proposed the use of tags, I thought about the clients-developper : - I want the simplier interface with only lat/lon/date, two bug states, and a text. I do not want a crapy interface with 30 text areas and 60 combo-boxes - Someone will desire to add a zoom level for each bug, the email of the authors, and three bug states - Someone else will want a reference to the OSM data, the diameter of the area that the bug describes, the age of the mother of the author, etc. The tag=value schema does all this. And, as the OSM end-user clients (like Mapnik, [EMAIL PROTECTED], routing softwares), there are only small pieces of the data that are rendered depending of the choice of the rendered. The server side already exists : it's basically OSM database without ways, with a guest account, and accepting long string values (the text users could add). That is really attractive. The only problems I can see here (apart from that we still should try to define a bug report format) are that annotations to a bug report like comments, images and attachments cannot be stored in the osm database (as far as I know). I do not think that it would be the best idea to put images in the database besides it is technically possible with a classical database ; I do not know about OSM database. An URL to a solid file seems to me much more efficient. and we'd lose out on all the fun of documenting / defining the tags on the wiki :-P And maybe, with all this complexity, we will have a new service to trac the inconsistencies in OpenStreetBugs' bugs. Welcome OpenStreetBugsBugs. Xav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
On Fri, Nov 28, 2008 at 02:10:28PM +0100, Patrick Kilian wrote: I really dislike bugzilla and that I was really glad when I found out that OSM uses trac for its bugtracking. Unless we find a REALLY compelling reason to switch I'd stay with trac. I’m not a fan of Bugzilla either: The code base or the interface. For data, I think OpenStreetBugs works well. You don’t have to work out anything, you just click and type. Maybe an additional field to that to track the status in more detail is in order, but get much more complicated and you destroy the simplicity of reporting bugs. That’s regardless of what back‐end it actually uses to keep track of bugs. Possibly the next best thing after code‐reuse of using an existing bug‐tracker as the backend is that you can easily provide an alternative (the ones the bug‐tracker lets you use). If possible to integrate with Trac, for example, you get http://trac.openstreetmap.org/report, any number of customisable ways to display tickets. Trac also has the option to change the workflow since 0.11, which would be useful for keeping it simple for OpenStreetBugs: http://trac.edgewall.org/wiki/TracWorkflow 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
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Matt Amos wrote: On Sat, Nov 29, 2008 at 12:45 AM, Frederik Ramm [EMAIL PROTECTED] wrote: (I believe the notes API may suffer - my interpretation - from the idea of putting comments directly into the OSM database rather than into a separate data set where they - my opinion - belong but it's worth checking anyway.) i totally agree - OSB has managed just fine as a separate database. The problem with the notesapi branch is not that it's the same database but just that it takes the wrong approach to doing things within that database. For the record my preference would very much be for this to be a rails based system within the current database. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi What about defining the API first? And before defining the API we need the use cases. An other thing I would like to see are bug reports in XMPP (Jabber) Network. Think about a map that shows you a new report without polling. People could discuss immediately in a small chat window about this bug. Scalability shouldn't be a problem with XMPP. Bernhard Tom Hughes wrote: Matt Amos wrote: On Sat, Nov 29, 2008 at 12:45 AM, Frederik Ramm [EMAIL PROTECTED] wrote: (I believe the notes API may suffer - my interpretation - from the idea of putting comments directly into the OSM database rather than into a separate data set where they - my opinion - belong but it's worth checking anyway.) i totally agree - OSB has managed just fine as a separate database. The problem with the notesapi branch is not that it's the same database but just that it takes the wrong approach to doing things within that database. For the record my preference would very much be for this to be a rails based system within the current database. Tom begin:vcard fn:Bernhard Zwischenbrugger n:Zwischenbrugger;Bernhard email;internet:[EMAIL PROTECTED] note;quoted-printable:liebe Gr=C3=BC=C3=9Fe=0D=0A= =0D=0A= Bernhard Zwischenbrugger=0D=0A= =0D=0A= http://datenkueche.com=0D=0A= Multi language online dictionary.=0D=0A= Add new words as easy as in an Excel Table. x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
On Sat, Nov 29, 2008 at 09:49:41AM +0100, Xav wrote: - I want the simplier interface with only lat/lon/date, two bug states, and a text. I do not want a crapy interface with 30 text areas and 60 combo-boxes I don’t suggest there should be a crappy interface with lots of inputs, but it would be possible to have a different interface for people tracking bugs to the one for filing them, where more informations could be added. Even if the interface was the same, there could be an “advanced” mode giving more options. 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
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Just a follow up to my last message: I did a bit of research on the osm software stack yesterday evening and I think implementing a genuine map bugtracker isn't more work than adapting bugzilla. This is basically because the most important part of the map bugtracker is the user interface. And that has to be rewritten in both cases. The rest consists only of some database tables and a RESTful controller to add, edit, and query bugs in the database and return them in different formats (e.g. XML, JSON, RSS). I recently started to work with Pylons which is claims to be very similar to Rails. From this experience I expect the job of writing a bugtracker-controller to be not very difficult. I will try to install the rails-port on my computer at the weekend and have a look at it. For the user interface side it might be possible to user the current osb code as a starting point. It would be nice if we could decide on one solution instead of implementing two competing ones. So, it would be good to have a look at the advantages and disadvantages of a bugzilla and a rails-port solution and decide then which one fits best. Perhaps which should also ask the software developers how they feel about moving from trac to bugzilla. This seemed to be one of your main points for using bugzilla. Christoph Christoph Böhme [EMAIL PROTECTED] schrieb: Hi! Steffen Vogel [EMAIL PROTECTED] schrieb: Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! Thanks! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I am more into python ... I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... This sounds quite handy and like a clean interface. However, Richard's comment about the complexity of writing a new bugtracker compared to adapting one for mapping still makes me think. At the moment it looks like as if we have to replace the current user interface of bugzilla with a completely new one that is suitable for mapping. The original user interface won't be of much use for a map bugtracker (I personally would always want to see where the bugs are). I am wondering how much code there is in a bugtracker which is independent from the user interface. Basically it boils down to the question if we write a new interface how many parts of bugzilla will we actually use? And will these parts fit well into a map bugtracker? Bugzilla has an incredible amount of features but to me they seem to be made very much for software developer teams where only a relatively small number of people is actually fixing bugs. This is quite different to the osm community where several thousand people can possibly solve bugs. I thinks this makes many of bugzillas features unneccessary or even counterproductive if they were used in the osm community. I really do not want to put you off from adapting bugzilla to openstreetmap but at the moment I cannot see what advantages we would get from using bugzilla compared to creating something specific for osm. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
can i plug http://www.redmine.org/ ? its a very nice bit of software and we may be able to steal the bug-tracking bit of it. cheers, matt On Fri, Nov 28, 2008 at 12:53 PM, Christoph Böhme [EMAIL PROTECTED] wrote: Just a follow up to my last message: I did a bit of research on the osm software stack yesterday evening and I think implementing a genuine map bugtracker isn't more work than adapting bugzilla. This is basically because the most important part of the map bugtracker is the user interface. And that has to be rewritten in both cases. The rest consists only of some database tables and a RESTful controller to add, edit, and query bugs in the database and return them in different formats (e.g. XML, JSON, RSS). I recently started to work with Pylons which is claims to be very similar to Rails. From this experience I expect the job of writing a bugtracker-controller to be not very difficult. I will try to install the rails-port on my computer at the weekend and have a look at it. For the user interface side it might be possible to user the current osb code as a starting point. It would be nice if we could decide on one solution instead of implementing two competing ones. So, it would be good to have a look at the advantages and disadvantages of a bugzilla and a rails-port solution and decide then which one fits best. Perhaps which should also ask the software developers how they feel about moving from trac to bugzilla. This seemed to be one of your main points for using bugzilla. Christoph Christoph Böhme [EMAIL PROTECTED] schrieb: Hi! Steffen Vogel [EMAIL PROTECTED] schrieb: Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! Thanks! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I am more into python ... I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... This sounds quite handy and like a clean interface. However, Richard's comment about the complexity of writing a new bugtracker compared to adapting one for mapping still makes me think. At the moment it looks like as if we have to replace the current user interface of bugzilla with a completely new one that is suitable for mapping. The original user interface won't be of much use for a map bugtracker (I personally would always want to see where the bugs are). I am wondering how much code there is in a bugtracker which is independent from the user interface. Basically it boils down to the question if we write a new interface how many parts of bugzilla will we actually use? And will these parts fit well into a map bugtracker? Bugzilla has an incredible amount of features but to me they seem to be made very much for software developer teams where only a relatively small number of people is actually fixing bugs. This is quite different to the osm community where several thousand people can possibly solve bugs. I thinks this makes many of bugzillas features unneccessary or even counterproductive if they were used in the osm community. I really do not want to put you off from adapting bugzilla to openstreetmap but at the moment I cannot see what advantages we would get from using bugzilla compared to creating something specific for osm. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi, It would be nice if we could decide on one solution instead of implementing two competing ones. So, it would be good to have a look at the advantages and disadvantages of a bugzilla and a rails-port solution and decide then which one fits best. Perhaps which should also ask the software developers how they feel about moving from trac to bugzilla. This seemed to be one of your main points for using bugzilla. I'm not a big developer, but I do try to improve the OSM software stack (mostly [EMAIL PROTECTED] client and maplint) and I get to own all the osmarender bugs in trac. From that perspective I have to say that I really dislike bugzilla and that I was really glad when I found out that OSM uses trac for its bugtracking. Unless we find a REALLY compelling reason to switch I'd stay with trac. I'd rather have a seperated bugzilla for tracking bugs in the data and a trac for tracking bugs in the software. At that point I should probably add that it would be a good thing if we could migrate all the user databases to one single location and do authentication against that. Patrick Petschge Kilian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi, With my experience in developing OSB, I would say that Christoph just resumed it quite right : the server side software is a piece of cake and should propose a simple API to insert/edit/delete and view the data (JSON, RSS, GPX). Because everybody has its own idea of what should be specified in the data (bug status, email, classification, age of john's mother), why not to copy OSM : tags. Think of it... The server side already exists : it's basically OSM database without ways, with a guest account, and accepting long string values (the text users could add). A lot of clients already exists : JOSM, Potlatch, Mapnik, trillions of scripts, etc. Xav Christoph Böhme a écrit : Just a follow up to my last message: I did a bit of research on the osm software stack yesterday evening and I think implementing a genuine map bugtracker isn't more work than adapting bugzilla. This is basically because the most important part of the map bugtracker is the user interface. And that has to be rewritten in both cases. The rest consists only of some database tables and a RESTful controller to add, edit, and query bugs in the database and return them in different formats (e.g. XML, JSON, RSS). I recently started to work with Pylons which is claims to be very similar to Rails. From this experience I expect the job of writing a bugtracker-controller to be not very difficult. I will try to install the rails-port on my computer at the weekend and have a look at it. For the user interface side it might be possible to user the current osb code as a starting point. It would be nice if we could decide on one solution instead of implementing two competing ones. So, it would be good to have a look at the advantages and disadvantages of a bugzilla and a rails-port solution and decide then which one fits best. Perhaps which should also ask the software developers how they feel about moving from trac to bugzilla. This seemed to be one of your main points for using bugzilla. Christoph Christoph Böhme [EMAIL PROTECTED] schrieb: Hi! Steffen Vogel [EMAIL PROTECTED] schrieb: Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! Thanks! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I am more into python ... I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... This sounds quite handy and like a clean interface. However, Richard's comment about the complexity of writing a new bugtracker compared to adapting one for mapping still makes me think. At the moment it looks like as if we have to replace the current user interface of bugzilla with a completely new one that is suitable for mapping. The original user interface won't be of much use for a map bugtracker (I personally would always want to see where the bugs are). I am wondering how much code there is in a bugtracker which is independent from the user interface. Basically it boils down to the question if we write a new interface how many parts of bugzilla will we actually use? And will these parts fit well into a map bugtracker? Bugzilla has an incredible amount of features but to me they seem to be made very much for software developer teams where only a relatively small number of people is actually fixing bugs. This is quite different to the osm community where several thousand people can possibly solve bugs. I thinks this makes many of bugzillas features unneccessary or even counterproductive if they were used in the osm community. I really do not want to put you off from adapting bugzilla to openstreetmap but at the moment I cannot see what advantages we would get from using bugzilla compared to creating something specific for osm. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
On 27/11/08 18:18, Steven Le Roux wrote: Maybe, waiting on a solution to be done on the main slippy map, we could put a link on the front www.openstreetmap.org like this : A bug ? please report it here and like to OSB. It's a quick solution... Yeah I like it in theory but can we please not refer to it as a bug? That's a way to technical term. How about Report a problem with this map (once they are zoomed in enough), or something similar. Rory signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
2008/11/28 Rory McCann [EMAIL PROTECTED] On 27/11/08 18:18, Steven Le Roux wrote: Maybe, waiting on a solution to be done on the main slippy map, we could put a link on the front www.openstreetmap.org like this : A bug ? please report it here and like to OSB. It's a quick solution... Yeah I like it in theory but can we please not refer to it as a bug? That's a way to technical term. How about Report a problem with this map (once they are zoomed in enough), or something similar. May be it is my technical leaning but I would interpret Report a problem with this map to be a technical problem. How about Report an inaccuracy with this map, or some thing along the lines that makes it fairly clear that we are concerned about mapping accuracy. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Douglas Furlong [EMAIL PROTECTED] schrieb: 2008/11/28 Rory McCann [EMAIL PROTECTED] On 27/11/08 18:18, Steven Le Roux wrote: Yeah I like it in theory but can we please not refer to it as a bug? That's a way to technical term. How about Report a problem with this map (once they are zoomed in enough), or something similar. May be it is my technical leaning but I would interpret Report a problem with this map to be a technical problem. How about Report an inaccuracy with this map, or some thing along the lines that makes it fairly clear that we are concerned about mapping accuracy. I add Something wrong on this map? -- Report it! and the short and simple Report error to the pool of sentences to choose from. Cheers, Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Matt Amos [EMAIL PROTECTED] schrieb: can i plug http://www.redmine.org/ ? its a very nice bit of software and we may be able to steal the bug-tracking bit of it. It looks indeed very neat and since it is written on Rails it might be easier to include in osm than another bugtracker. But the server side part of the map bugtracker is probably the smallest part and the client side has to be rewritten anyway. So, it might be easier to write some server side code that really works for a map bugtracker instead of trying to fix something. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Douglas Furlong [EMAIL PROTECTED] schrieb: I think the level to which Fedora went is far beyond what we would need, but setting up an LDAP directory to store authentication credentials would be fairly straight forward. I'd be willing to spend time to look at implementing some thing like this, if their is a desire from the community. +1 Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi, Xav [EMAIL PROTECTED] schrieb: With my experience in developing OSB, I would say that Christoph just resumed it quite right : the server side software is a piece of cake and should propose a simple API to insert/edit/delete and view the data (JSON, RSS, GPX). That sounds good. I will see at the weekend if it really is a piece of cake. Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? Because everybody has its own idea of what should be specified in the data (bug status, email, classification, age of john's mother), why not to copy OSM : tags. Think of it... I thought about using a general tag scheme too, but I think its not a good solution for a bugtracker. Bug reports are mostly free-form text already and contain only structured information to remind people to supply certain bits of information and to handle processing of the bug reports. So, I do not think bug reporters will ever feel the desire add tags to their bug reports. In fact, it would probably confuse most people. Developers of user interfaces for the bug tracker might however want to have more structured information. But this is probably only a small group of people who can decide which information a bug report should contain. Especially it would not help anyone if bug reports contain different information depending which user interface was used to add them to the database. Just imagine the situation where a user adds a bug through the web interface and a mapper requests the bugs with JOSM. Both pieces of software need to use the same model of information in the report and the same concept of how to process the bug report. Additionally, I think defining a bug report format is not like defining a database structure to describe the whole world but more like finding one for describing a residential street. Implementing a general tag scheme just postpones the decision of what to put in a bug report in my opinion. The server side already exists : it's basically OSM database without ways, with a guest account, and accepting long string values (the text users could add). That is really attractive. The only problems I can see here (apart from that we still should try to define a bug report format) are that annotations to a bug report like comments, images and attachments cannot be stored in the osm database (as far as I know). Another question is how the introduction of changesets in the api 0.6 affects very small edits. Creating a changeset for every bug which is added to the database might turn out to be very inefficient memorywise. A lot of clients already exists : JOSM, Potlatch, Mapnik, trillions of scripts, etc. But they still need interfaces to handle the bug reports in a user friendly way. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi, Christoph Böhme wrote: That sounds good. I will see at the weekend if it really is a piece of cake. Would it be possible to reuse and extend the client-side code from osb for a web-based client-side interface? Before you get all cranked up writing something new, be sure to check out the notes API branch in SVN, where something OSB-like has been attempted in rails already. I don't know by whom and what the status is but I'm sure you will find out. (I believe the notes API may suffer - my interpretation - from the idea of putting comments directly into the OSM database rather than into a separate data set where they - my opinion - belong but it's worth checking anyway.) Especially it would not help anyone if bug reports contain different information depending which user interface was used to add them to the database. Just imagine the situation where a user adds a bug through the web interface and a mapper requests the bugs with JOSM. Both pieces of software need to use the same model of information in the report and the same concept of how to process the bug report. This is very short-sighted - coming from someone who has worked with OSM! Who are you to know in advance what cool ideas the writers of bug tracking software might have? Just because you cannot think of anything beyond severity, class and comment doesn't mean nobody else can. Let the writers of software decide, do not constrain them by your limited imagination. If someone comes up with a cool new tag the makes reporting and handling bugs much easier, then let him do that and write his own cool interface for it. If it works well then others will copy the idea. By postulating that everyone will have to work with the smallest common denominator, you are killing off creativity. It's ok to have a few suggested standard attributes like severity and so on, but never close the door to enhancements. 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] Proposal for a map-bug tracker (Openstreetbugs)
On Sat, Nov 29, 2008 at 12:45 AM, Frederik Ramm [EMAIL PROTECTED] wrote: (I believe the notes API may suffer - my interpretation - from the idea of putting comments directly into the OSM database rather than into a separate data set where they - my opinion - belong but it's worth checking anyway.) i totally agree - OSB has managed just fine as a separate database. It's ok to have a few suggested standard attributes like severity and so on, but never close the door to enhancements. and we'd lose out on all the fun of documenting / defining the tags on the wiki :-P cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi, after the two latest discussions on the list I sat down and put together a little proposal for an improved map-bug tracker: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal This is *not* meant to be a decision to write a new bugtracker from scratch instead of improving openstreetbugs or using some bugzilla based solution. The proposal shall only support us to figure out what we except from a bug tracker for maps and how a good user interface should look like. Once we know how the bug tracker should look like, we can see how it is best implemented. I did not find a place in the wiki were to put this type of proposals. Map features does not seem to be the right place. So, I only linked it from my user page. Perhaps someone with more knowledge about the wiki structure can find a nice place for it. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
maybe we could provide two version of OSB... ? Xav keep www.openstreebugs.org for his simplicity and non-mapper contributors. and another version like : advance.openstreebugs.org, which provide an advanced mapbugtracker... the principal page could invite for users to visite the advanced app for better tracking... and improve their tracking skills... my 2cts On Thu, Nov 27, 2008 at 4:16 PM, Christoph Böhme [EMAIL PROTECTED] wrote: Hi, after the two latest discussions on the list I sat down and put together a little proposal for an improved map-bug tracker: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal This is *not* meant to be a decision to write a new bugtracker from scratch instead of improving openstreetbugs or using some bugzilla based solution. The proposal shall only support us to figure out what we except from a bug tracker for maps and how a good user interface should look like. Once we know how the bug tracker should look like, we can see how it is best implemented. I did not find a place in the wiki were to put this type of proposals. Map features does not seem to be the right place. So, I only linked it from my user page. Perhaps someone with more knowledge about the wiki structure can find a nice place for it. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: Hi, after the two latest discussions on the list I sat down and put together a little proposal for an improved map-bug tracker: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... greetings Steffen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
On Thu, Nov 27, 2008 at 6:45 PM, Steffen Vogel [EMAIL PROTECTED] wrote: Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: Hi, after the two latest discussions on the list I sat down and put together a little proposal for an improved map-bug tracker: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... greetings Steffen Maybe, waiting on a solution to be done on the main slippy map, we could put a link on the front www.openstreetmap.org like this : A bug ? please report it here and like to OSB. It's a quick solution... -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi! Florian Lohoff [EMAIL PROTECTED] schrieb: I'd vote for making the OSB as simple as possible - as soon as you require a login or filling in some drop downs we'll loose Aunt Tilly with her good local knowledge. I am completely with you here. However, while Aunt Tilly wants a no-frills interface mappers who are dealing with bugs need a bit more functionality. There might be also people willing and able to provide more detailed bug reports. They should have the option to do so. IMO, the problem is to put these three things together. I think, it is quite clear that we need an Aunt Tilly-interface to the bugtracker with the following features: - no registration required - only a single text field to describe the error - optional email address if the reporter wishes to be contacted So, basically what openstreetbugs is now. Though, I see no point why things behind this interface could be a bit more advanced. Since only mappers will use them. I also see no reason why the Aunt Tilly-interface should not contain a link saying advanced which shows some more options (like classification and so on). Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Am Donnerstag, den 27.11.2008, 18:30 + schrieb Christoph Böhme: Hi! Florian Lohoff [EMAIL PROTECTED] schrieb: I'd vote for making the OSB as simple as possible - as soon as you require a login or filling in some drop downs we'll loose Aunt Tilly with her good local knowledge. I am completely with you here. However, while Aunt Tilly wants a no-frills interface mappers who are dealing with bugs need a bit more functionality. There might be also people willing and able to provide more detailed bug reports. They should have the option to do so. IMO, the problem is to put these three things together. I think, it is quite clear that we need an Aunt Tilly-interface to the bugtracker with the following features: - no registration required Unfortunatly Bugzilla don't provides this feature. But I already found a solution: I've created a guest user. Any bug reports thru the slippy map will be added as reports from the guest user. - only a single text field to describe the error No problem. Default values for other fields will be set. - optional email address if the reporter wishes to be contacted There is a way to add people to the CC header of a mail. I have to prove that this is also possible for nonregistred persons. So, basically what openstreetbugs is now. Though, I see no point why things behind this interface could be a bit more advanced. Since only mappers will use them. I also see no reason why the Aunt Tilly-interface should not contain a link saying advanced which shows some more options (like classification and so on). Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Hi! Steffen Vogel [EMAIL PROTECTED] schrieb: Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: http://wiki.openstreetmap.org/wiki/Bugtracker_proposal Hey great work! Thanks! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I am more into python ... I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... This sounds quite handy and like a clean interface. However, Richard's comment about the complexity of writing a new bugtracker compared to adapting one for mapping still makes me think. At the moment it looks like as if we have to replace the current user interface of bugzilla with a completely new one that is suitable for mapping. The original user interface won't be of much use for a map bugtracker (I personally would always want to see where the bugs are). I am wondering how much code there is in a bugtracker which is independent from the user interface. Basically it boils down to the question if we write a new interface how many parts of bugzilla will we actually use? And will these parts fit well into a map bugtracker? Bugzilla has an incredible amount of features but to me they seem to be made very much for software developer teams where only a relatively small number of people is actually fixing bugs. This is quite different to the osm community where several thousand people can possibly solve bugs. I thinks this makes many of bugzillas features unneccessary or even counterproductive if they were used in the osm community. I really do not want to put you off from adapting bugzilla to openstreetmap but at the moment I cannot see what advantages we would get from using bugzilla compared to creating something specific for osm. Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk