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
