Re: [OSM-talk] Unification of OpenStreetBugs an Trac

[David Earl]

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

[Ian Dees]

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

[Marc Schütz]

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

[David Earl]

On 26/11/2008 17:27, Ian Dees wrote:
> 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.

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

[John07]

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

[Karl Newman]

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

[John07]

Karl Newman schrieb:
> 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?).
+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

[Mikel Maron]

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

[Christoph Böhme]

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

[Tom Hughes]

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

[Frederik Ramm]

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

[Simon Ward]

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

Re: [OSM-talk] Unification of OpenStreetBugs an Trac

[Richard Fairhurst]

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

[Lambertus]

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

[Thomas Wood]

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

[Gervase Markham]

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

[Gervase Markham]

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

[David Earl]

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

[Richard Fairhurst]

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.

Sure, but the question - here as in anywhere - is whether you have the same
"more requirements" as the people who wrote the bugtracker.

_Generally_ OSM has found that, for the external-facing stuff, we rarely do
have the same "more requirements". (Clearly our internal-facing stuff like
trac is fairly par for the course; we have a svn repository like any other
open source project.) Famously, OSM rejected the entire classical GIS stack,
and now everyone thinks it's obvious but three years ago they were telling
us we were mad.

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.

Good ol' Joel Spolsky again: "A lot of software developers are seduced by
the old '80/20' rule. It seems to make a lot of sense: 80% of the people
use 20% of the features... Unfortunately, it's never the same 20%. Everybody
uses a different set of features."

Anyway, none of this is getting any code written. :)

cheers
Richard
-- 
View this message in context: 
http://www.nabble.com/Unification-of-OpenStreetBugs-an-Trac-tp20704897p20768510.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

[Gervase Markham]

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

[Richard Fairhurst]

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

[David Earl]

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

[Donald Allwright]

>> 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

[Matthias Julius]

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

[Christoph Böhme]

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

[Andy Allan]

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

[Christoph Böhme]

"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

[Xav]

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