[OSM-dev] Death prediction of notes on osm.org as it seams to be planned
sly (sylvain letuffe)
liste at letuffe.org
Sat Nov 24 16:25:34 GMT 2012
First sorry for the FUD starting title, but I found it cool to copy
journalists some times ;-)
This discussion first took place on  and I'm sad it wasn't made more
public, but that might just be that developers/admins don't want my POV after
all, no problem, you can quit reading right now, that is just a Message in a
Bottle sent into the ocean as I'm not going to get involve in development of
> Kai Krueger kakrueger at gmail.com Tue Nov 13 :
> Hello everyone,
> I presume you are all familiar with OpenStreetBugs and I suspect you
> also have heard that there are efforts underway to bring a similar
> concept to the front page of osm.org to increase the exposure of map
> bugs and notes to a wider audience of mappers and problem reporters.
> The current efforts can be seen at
I've read all of the thread + summary of talk-de pro-anonymous comments, and a
general statement that OSB is quite good, let's copy it more or less and even
import bugs reports from it.
Let's put it strait : "Going this path will lead to the death of the notes
project in medium (1y) to long term (3y)"
That's my prediction.
Allow me to expand my thoughts on a few things :
= OSB is good =
No it isn't, it "was" good. If you don't agree, then you might just not be
using it at all or you are still in a niche place where it is still usefull.
There were those phases : the raise, stagnation, decline, and, my prediction :
frustration and death.
== raise (2008->2010) ==
OSB filled a need and OSM mappeurs discovered it first and started to use it
to add notes on a map for real errors they couldn't correct themself by lack
of knowledge knowing exactly what needs to be provided to help resolve the
reporters and fixers were on equal numbers, reporters were following their bug
reports and even fixing it themself "a form of note to self"
Ratio (R) signal/noise was high, OSB was usefull
== stagnation (?2011) ==
By advertising it more and more, by integration in JOSM, OSMOSE, mobile apps,
etc. mappers thought of an easy way to get help from local knowlege anonymous
bypassers. Reports started to increase in number and the frustration of
useless bug reports was acceptable as R kept high.
== decline (2012+) ==
The number of reports kept on raising even more (coming from many different
new bad sources: see down there ), and alas, R dropped significantly IMHO,
I stopped using OSB early this year because of that. I never was a reporter
but a fixer.
I've allways been in addition a reporter/fixer on fixme=* tagged objects but
now, I'm only using that and QA tools.
OSB dust starts to accumulate in my region, bugs aren't fixed, nor closed,
they linger here, leading to reporters frustration. Its only future is death.
(well, in my region it is agonising as the last 2 OSB fixers have quit)
= My analysis =
If you are still here reading me, maybe you have seen that somewhere else,
let's go for my analysis :
fixme tags in the db is working for me, osb isn't anymore, why ?
- visibility, technical advantages, categories ? about the same, I don't thing
it has to do with that
- complexity ? yes.
Sad to say it this way, but it has to be complex for reporters to be usefull.
Why ? because the bottleneck isn't lazy reporters writing in 4s : "please fix"
The bottleneck is us, the fixers ! We need to spare that ressource.
=My proposed solutions=
*  Never ever allow mass mechanical bugs reporting. The OSB API for
uploading bugs was it's last terrible error accelerating it's downfall
(That is also true for fixme=* tags, I'm banging my head in the wall every
time someone thinks he is smart by adding a fixme=* tag all over the planet :
http://www.openstreetmap.org/browse/node/308819536/history : 200k tags)
* Make it complex to report bugs, no matter how
Sure, you could ask the reporter to find and write the 100th Pi decimals and
that will lower the number of report, but I'm sure there are better things to
ask him, some have been listed on the  thread.
What we should try to avoid is lazy reporters
- mandatory email
- 5 to 8 mandatory fields
--are you ? : providing a name, shop closed, bad shape, routing error
--your source of information is : (free mandatory field of ~10chars min)
--zoom level <16 reporting not allowed
* Allow and encourage bug closing
let fixers be bold and close "not clear" reports. Better a false close, than a
bug lingering in there.
Automatic closing could also be though of (+90d = invalid = auto-close )
ps: obviouly far too long, but when reading answers on  I guess my opinion
if far from the gaggle and I though I needed to explain
sly (sylvain letuffe)
More information about the dev