Re: [OSM-talk] this has to stop: iD user mistakes all over the place
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 has only 35 rows. 2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com: There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. Example: track was translated to Polish . Good translation is very important for the beginners. and _now_ not so easy to check the quality of the iD translations. I would like to inform you, that I am working on a new *iD Editor translation QA tool * for helping translators detecting translator bugs ... I have created an experimental, manually formatted QA metadata reports for Polish language :) https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 Maybe you can use. ( 4 Sheets : - meta_pl : meta data ... - iDups,- duplicated/same translations - iPresets,- presets ( 2028 ) [ translations from transifex + presets.json https://github.com/openstreetmap/iD/blob/master/data/presets/presets.json ] - iFields -fields (261 ) [translations from transifex + fields.json https://github.com/openstreetmap/iD/blob/master/data/presets/fields.json ] ) Freshly generated raw reports exists for every other iD languages ( de,pl,es,ru, cz,pt, ... ) ( but not formated ) see : https://github.com/ImreSamu/ideditor_translation_test_reports find your xlsx - ./qadata/ (LangCode)/id_presets_translation_(LangCode).xlsx for example: ./qadata/af/id_presets_translation_af.xlsx ./qadata/ar/id_presets_translation_ar.xlsx ./qadata/ar-AA/id_presets_translation_ar-AA.xlsx ./qadata/ast/id_presets_translation_ast.xlsx ./qadata/bg-BG/id_presets_translation_bg-BG.xlsx ./qadata/bn/id_presets_translation_bn.xlsx ./qadata/bs/id_presets_translation_bs.xlsx ./qadata/ca/id_presets_translation_ca.xlsx ./qadata/cs/id_presets_translation_cs.xlsx ./qadata/da/id_presets_translation_da.xlsx ./qadata/de/id_presets_translation_de.xlsx ... My favorite problems type is the same/duplicated translations ( https://github.com/openstreetmap/iD/issues/2448 ) Now the status by languages -here : id_langDups_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langDups_all.md For example German language. But be careful, Experimental report! Not every line is problematic - please check the other columns like - geometry metadata ( area,point,line,vertex,relation ) - searchable ( id_presets_translation_duplicates_de.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/de/id_presets_translation_duplicates_de.md ) nameTransl nameEn presetKey Administrative Grenze Administrative Boundary type/boundary/administrative Administrative Grenze Administrative Boundary boundary/administrative Bahnsteig Platform public_transport/platform Bahnsteig Railway Platform railway/platform Boutique Boutique shop/boutique Boutique Fabric Store shop/fabric Campingplatz Camp Site tourism/camp_site Campingplatz RV Park tourism/caravan_site Drogerie Chemist shop/chemist Drogerie Cosmetics Store shop/cosmetics Eisenbahn Rail railway/rail Eisenbahn Railway railway Fährenroute Ferry Route route/ferry Fährenroute Ferry Route type/route/ferry Friedhof Graveyard amenity/grave_yard Friedhof Cemetery landuse/cemetery Garagen Garages building/garages Garagen Garages landuse/garages Gemischtwarenhandel Convenience Store shop/convenience Gemischtwarenhandel Variety Store shop/variety_store Graben Ditch barrier/ditch Graben Ditch waterway/ditch Hütte Hut building/hut Hütte Cabin building/cabin Kehrtwendeverbot No Turns type/restriction/only_straight_on Kehrtwendeverbot No U-turn type/restriction/no_u_turn Kirche Church amenity/place_of_worship/christian Kirche Church building/church Radweg Cycle Path highway/cycleway Radweg Cycle Route type/route/bicycle Seilbahn Cable Car aerialway/cable_car Seilbahn Aerialway aerialway Uhrmacher Clockmaker craft/clockmaker Uhrmacher Watchmaker craft/watchmaker Wald Wood natural/wood Wald Forest landuse/forest Zebrastreifen Crosswalk footway/crosswalk Zebrastreifen Crosswalk highway/crosswalk And the Translation status by languages : id_langData_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langData_all.md Imre ( from the Hungarian OSM community ) 2015-02-13 3:43 GMT+01:00 Michał Brzozowski www.ha...@gmail.com: Whoops. Good to know. Though it's still rudimentary ;) Not long ago I tried to do intentionally do stupid things in iD demo in order to see if it would stop me - it didn't. There's one more face to iD and mistakes
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
has only 35 rows. 17 word pair + 1 header record There are other worksheets , you can switch/change at the bottom of the page: Direct links: *meta_pl : meta data ...* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=2147407685 *iDups,- duplicated/same translations ( 34 rows )* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 *iPresets,- presets ( 2028 rows )* https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1125791958 *iFields -fields (261 rows ) * https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=661789118 Imre 2015-02-13 11:54 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 has only 35 rows. 2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com: There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. Example: track was translated to Polish . Good translation is very important for the beginners. and _now_ not so easy to check the quality of the iD translations. I would like to inform you, that I am working on a new *iD Editor translation QA tool * for helping translators detecting translator bugs ... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Since two years ago, iD has an range of validations it runs on every potential changeset, as well as an interface to review correct potential errors before saving them. https://github.com/openstreetmap/iD/blob/master/js/id/validate.js#L1 We welcome contributions to expand these, and have a few proposed additions which would be good places to start if you want to help: https://github.com/openstreetmap/iD/issues?q=is%3Aopen+is%3Aissue+label%3Avalidation On Thu, Feb 12, 2015 at 8:44 PM, Michał Brzozowski www.ha...@gmail.com wrote: I was wondering, what do you think (interpret this only as a question) about introducing validation in iD in the future? Using MAGIC integrated circuit design tool, that does DRC (Design Rule Check) in real time and highlights errors inspired me that OSM editors could also incorporate this. It makes sense to me. First, users will not be overwhelmed by a sh**load of errors at once and second, they could learn what they actually do wrong. But this poses challenges, because sometimes when you're editing, there will be a temporary error state, to disappear just when you finish a sequence (e.g. you don't enter all tags at once so there will be a transient place of worship without religion error.) That type of error message should not happen, because spamming irrelevant errors only makes users ignore them. Still, there are checks that can be safely made in real time, like all sorts of geometrical tests (self-intersections, building crossing another building and so on.). Maybe good-enough heuristics could be applied for when the user stopped editing a feature and moved on to another, to address the temporary error issue. Anyway, thanks in advance to anyone who makes iD more iDiot-proof. It really matters a lot, for example there was press coverage (Polish News Agency) back in 2014-08-18 that generated 500 or more new users who obviously contributed a fair share of mistakes. There was simply no manpower available to check edits of all the users, let alone message them on what they did wrong. Having no severe errors is quite a point of honor to me, as I think we must try to be free of all these that cursed satnav told me to do this situations. Steve Jobs once told something along the lines of We don't ship junk. We make products that we could recommend to our family and friends and surely anyone tech-savvy can relate to that feeling of embarrassment when a cool gadget/software you show to your family happens to betray you. Have your navigation lead you off-road (see: wrong road tagging), people will tell that OSM is shit even though other map products are not ideal as well. Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
I was wondering, what do you think (interpret this only as a question) about introducing validation in iD in the future? Using MAGIC integrated circuit design tool, that does DRC (Design Rule Check) in real time and highlights errors inspired me that OSM editors could also incorporate this. It makes sense to me. First, users will not be overwhelmed by a sh**load of errors at once and second, they could learn what they actually do wrong. But this poses challenges, because sometimes when you're editing, there will be a temporary error state, to disappear just when you finish a sequence (e.g. you don't enter all tags at once so there will be a transient place of worship without religion error.) That type of error message should not happen, because spamming irrelevant errors only makes users ignore them. Still, there are checks that can be safely made in real time, like all sorts of geometrical tests (self-intersections, building crossing another building and so on.). Maybe good-enough heuristics could be applied for when the user stopped editing a feature and moved on to another, to address the temporary error issue. Anyway, thanks in advance to anyone who makes iD more iDiot-proof. It really matters a lot, for example there was press coverage (Polish News Agency) back in 2014-08-18 that generated 500 or more new users who obviously contributed a fair share of mistakes. There was simply no manpower available to check edits of all the users, let alone message them on what they did wrong. Having no severe errors is quite a point of honor to me, as I think we must try to be free of all these that cursed satnav told me to do this situations. Steve Jobs once told something along the lines of We don't ship junk. We make products that we could recommend to our family and friends and surely anyone tech-savvy can relate to that feeling of embarrassment when a cool gadget/software you show to your family happens to betray you. Have your navigation lead you off-road (see: wrong road tagging), people will tell that OSM is shit even though other map products are not ideal as well. Michał ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Whoops. Good to know. Though it's still rudimentary ;) Not long ago I tried to do intentionally do stupid things in iD demo in order to see if it would stop me - it didn't. There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. English terms don't always translate 1:1 so I think it is beneficial for a translator to deviate a little when needed. Example: track was translated to Polish as droga gruntowa (grunt is ground so translated back to English it's unpaved road). Which of course is a bad idea, as people will tag every single unpaved road as highway=track. I took a little liberty and changed that to Droga polna lub leśna (Field or forest road) which I think captures the essence more faithfully. Michał On Fri, Feb 13, 2015 at 3:00 AM, Tom MacWright t...@macwright.org wrote: Since two years ago, iD has an range of validations it runs on every potential changeset, as well as an interface to review correct potential errors before saving them. https://github.com/openstreetmap/iD/blob/master/js/id/validate.js#L1 We welcome contributions to expand these, and have a few proposed additions which would be good places to start if you want to help: https://github.com/openstreetmap/iD/issues?q=is%3Aopen+is%3Aissue+label%3Avalidation ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. Example: track was translated to Polish . Good translation is very important for the beginners. and _now_ not so easy to check the quality of the iD translations. I would like to inform you, that I am working on a new *iD Editor translation QA tool * for helping translators detecting translator bugs ... I have created an experimental, manually formatted QA metadata reports for Polish language :) https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312 Maybe you can use. ( 4 Sheets : - meta_pl : meta data ... - iDups,- duplicated/same translations - iPresets,- presets ( 2028 ) [ translations from transifex + presets.json https://github.com/openstreetmap/iD/blob/master/data/presets/presets.json ] - iFields -fields (261 ) [translations from transifex + fields.json https://github.com/openstreetmap/iD/blob/master/data/presets/fields.json ] ) Freshly generated raw reports exists for every other iD languages ( de,pl,es,ru, cz,pt, ... ) ( but not formated ) see : https://github.com/ImreSamu/ideditor_translation_test_reports find your xlsx - ./qadata/ (LangCode)/id_presets_translation_(LangCode).xlsx for example: ./qadata/af/id_presets_translation_af.xlsx ./qadata/ar/id_presets_translation_ar.xlsx ./qadata/ar-AA/id_presets_translation_ar-AA.xlsx ./qadata/ast/id_presets_translation_ast.xlsx ./qadata/bg-BG/id_presets_translation_bg-BG.xlsx ./qadata/bn/id_presets_translation_bn.xlsx ./qadata/bs/id_presets_translation_bs.xlsx ./qadata/ca/id_presets_translation_ca.xlsx ./qadata/cs/id_presets_translation_cs.xlsx ./qadata/da/id_presets_translation_da.xlsx ./qadata/de/id_presets_translation_de.xlsx ... My favorite problems type is the same/duplicated translations ( https://github.com/openstreetmap/iD/issues/2448 ) Now the status by languages -here : id_langDups_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langDups_all.md For example German language. But be careful, Experimental report! Not every line is problematic - please check the other columns like - geometry metadata ( area,point,line,vertex,relation ) - searchable ( id_presets_translation_duplicates_de.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/de/id_presets_translation_duplicates_de.md ) nameTransl nameEn presetKey Administrative Grenze Administrative Boundary type/boundary/administrative Administrative Grenze Administrative Boundary boundary/administrative Bahnsteig Platform public_transport/platform Bahnsteig Railway Platform railway/platform Boutique Boutique shop/boutique Boutique Fabric Store shop/fabric Campingplatz Camp Site tourism/camp_site Campingplatz RV Park tourism/caravan_site Drogerie Chemist shop/chemist Drogerie Cosmetics Store shop/cosmetics Eisenbahn Rail railway/rail Eisenbahn Railway railway Fährenroute Ferry Route route/ferry Fährenroute Ferry Route type/route/ferry Friedhof Graveyard amenity/grave_yard Friedhof Cemetery landuse/cemetery Garagen Garages building/garages Garagen Garages landuse/garages Gemischtwarenhandel Convenience Store shop/convenience Gemischtwarenhandel Variety Store shop/variety_store Graben Ditch barrier/ditch Graben Ditch waterway/ditch Hütte Hut building/hut Hütte Cabin building/cabin Kehrtwendeverbot No Turns type/restriction/only_straight_on Kehrtwendeverbot No U-turn type/restriction/no_u_turn Kirche Church amenity/place_of_worship/christian Kirche Church building/church Radweg Cycle Path highway/cycleway Radweg Cycle Route type/route/bicycle Seilbahn Cable Car aerialway/cable_car Seilbahn Aerialway aerialway Uhrmacher Clockmaker craft/clockmaker Uhrmacher Watchmaker craft/watchmaker Wald Wood natural/wood Wald Forest landuse/forest Zebrastreifen Crosswalk footway/crosswalk Zebrastreifen Crosswalk highway/crosswalk And the Translation status by languages : id_langData_all.md https://github.com/ImreSamu/ideditor_translation_test_reports/blob/master/qadata/id_langData_all.md Imre ( from the Hungarian OSM community ) 2015-02-13 3:43 GMT+01:00 Michał Brzozowski www.ha...@gmail.com: Whoops. Good to know. Though it's still rudimentary ;) Not long ago I tried to do intentionally do stupid things in iD demo in order to see if it would stop me - it didn't. There's one more face to iD and mistakes users make: translations. Bad translations cause bad tagging. English terms don't always translate 1:1 so I think it is beneficial for a translator to deviate a little when needed. Example: track was translated to Polish as droga gruntowa (grunt is ground so translated
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, 11 Feb 2015 16:08:37 -0500, Tom MacWright wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. Regarding this statement it is interesting that iD went live with no graphic hints about the existence of relations. (I hope I remember this point correct.) Thomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Thank you for dismissing all our arguments in one fell swoop. The difference with reported bugs, is that said bugs did get addressed. If we are anti-anything it's anti-having-to-cleanup-with-no-possibility-to-shut-close-the-source-of-the-cause-of-precious-time-wasters. If people were consciously breaking the data, this would most certainly be called vandalism. If you manage to burn out the regular contributors is OSM, you will have done the whole community a major disservice. Then there is the suggestion: it must not be a problem, as nobody bothered to create a pull request. We are mappers, not JS programmers and how hard can it really be to create dialogs to interact with your users? No need for external contributions to accomplish that, all that's needed is the willingness to stop annoying the rest of the community. 2015-02-12 0:40 GMT+01:00 Tom MacWright t...@macwright.org: We also aimed to have no bugs and like every software project before us, have failed to achieve that goal. The uproar about iD is the same as the uproar about the map style, website, user groups, code of conduct, Steve Coast, the board, imports, license change, attribution, and practically everything else about OpenStreetMap. It's not anti-iD bias, of course. It's anti-everything bias. On Wed, Feb 11, 2015 at 6:33 PM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 1:08 PM, Tom MacWright t...@macwright.org wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. This goal does not appear to have been carried out. The iD project comes off as tone deaf to breaking data concerns: Look at the uproar over issues of breaking data. Look at the core team response, which is mostly defensive posturing, not oriented to solutions. Why has iD taken such a beating on the mailing list breaking data issues? I don't think it's just anti-iD bias. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Am 12.02.2015 um 14:27 schrieb malenki: On Wed, 11 Feb 2015 16:08:37 -0500, Tom MacWright wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. Regarding this statement it is interesting that iD went live with no graphic hints about the existence of relations. (I hope I remember this point correct.) +1 Well, methinks thou dost protest too much. I did mention all my points longer time ago and there exists open issues about them. Still do not see the point why some actions should not be denied until they proper work especially as there seems to be not much interest in fixing them. I just was ask by an user of iD how to check the consistency of common relations like multipolygon, boundary and route in iD. Does anyone have an answer ? Where do I find a wiki or help system about iD explaining me the software ? Only found one page which does not even mention relations. I have no problems with newbie mistakes but users with over 2000 commits are no newbies anymore but still miss the common understanding of relations and are not aware of all tags of an object. What do you say about changesets with comment hopefully did not break any relation this time or sorry about breaking relations ? I would say, nice the user is at least adding changeset comments but as an developer alarm bells should start ringing in my head. For sure, I use PM and directly discuss on changesets but so far my advice is at least do not use combine ways or merging nodes at all, plus always discuss in advance of deleting or even better use a better editor software. Cheers colliar 0xE8F56581.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
ICYMI, Richard Fairhurst contributed a patch to fix this problem that we're currently reviewing for inclusion: https://github.com/openstreetmap/iD/pull/2526 On Thu, Feb 12, 2015 at 10:01 AM, Jo winfi...@gmail.com wrote: Thank you for dismissing all our arguments in one fell swoop. The difference with reported bugs, is that said bugs did get addressed. If we are anti-anything it's anti-having-to-cleanup-with-no-possibility-to-shut-close-the-source-of-the-cause-of-precious-time-wasters. If people were consciously breaking the data, this would most certainly be called vandalism. If you manage to burn out the regular contributors is OSM, you will have done the whole community a major disservice. Then there is the suggestion: it must not be a problem, as nobody bothered to create a pull request. We are mappers, not JS programmers and how hard can it really be to create dialogs to interact with your users? No need for external contributions to accomplish that, all that's needed is the willingness to stop annoying the rest of the community. 2015-02-12 0:40 GMT+01:00 Tom MacWright t...@macwright.org: We also aimed to have no bugs and like every software project before us, have failed to achieve that goal. The uproar about iD is the same as the uproar about the map style, website, user groups, code of conduct, Steve Coast, the board, imports, license change, attribution, and practically everything else about OpenStreetMap. It's not anti-iD bias, of course. It's anti-everything bias. On Wed, Feb 11, 2015 at 6:33 PM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 1:08 PM, Tom MacWright t...@macwright.org wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. This goal does not appear to have been carried out. The iD project comes off as tone deaf to breaking data concerns: Look at the uproar over issues of breaking data. Look at the core team response, which is mostly defensive posturing, not oriented to solutions. Why has iD taken such a beating on the mailing list breaking data issues? I don't think it's just anti-iD bias. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
How is an open source project that was open source on day one, was publicly communicated from day one, heavily explained in time-consuming technical blog posts, has 77 contributors, and has accepted hundreds of pull requests tightly held. On Wed, Feb 11, 2015 at 11:39 AM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright t...@macwright.org wrote: Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. Help with development or give productive feedback on the issue tracker. Productive feedback on the iD issue tracker follows a similar trajectory to that on the talk list. It's not really working there either. There seem to be fairly deep seated differences in the philosophy of on-boarding new mappers, and those reflect themselves in iD's user interface. Since iD was awarded prime spot on osm, and since it's development is tightly held, everyone else is left with no outlet other than to complain. OSM is a very open project in general, but iD's development is very tightly held and opinionated. FUD around editors has been discussed to death and it's clear that writing more emails won't do anything. Fear uncertainty and doubt implies the criticism is invalid. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 11:39 AM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright t...@macwright.org wrote: Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. Help with development or give productive feedback on the issue tracker. Productive feedback on the iD issue tracker follows a similar trajectory to that on the talk list. It's not really working there either. There seem to be fairly deep seated differences in the philosophy of on-boarding new mappers, and those reflect themselves in iD's user interface. Since iD was awarded prime spot on osm, and since it's development is tightly held, everyone else is left with no outlet other than to complain. OSM is a very open project in general, but iD's development is very tightly held and opinionated. That is very far from the truth. 77 people have contributed to iD [0]. The code is pretty darn easy to understand and is constructed in a pretty approachable way. It's well-documented and specific questions are answered quickly. If you have something valuable to contribute, iD is one of the best places to put your time in the OSM world. [0] https://github.com/openstreetmap/iD/graphs/contributors ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. This. Help with development or give productive feedback on the issue tracker. FUD around editors has been discussed to death and it's clear that writing more emails won't do anything. On Wed, Feb 11, 2015 at 11:13 AM, Bryce Nesbitt bry...@obviously.com wrote: I agree 100% that iD is making editing mistakes easier, out of proportion to the degree to which it makes editing by new users easier. The delete user interface is particularly fragile, encouraging the most pernicious form of damage: silent deletes. That goes for both the main map, and associated relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright t...@macwright.org wrote: Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. Help with development or give productive feedback on the issue tracker. Productive feedback on the iD issue tracker follows a similar trajectory to that on the talk list. It's not really working there either. There seem to be fairly deep seated differences in the philosophy of on-boarding new mappers, and those reflect themselves in iD's user interface. Since iD was awarded prime spot on osm, and since it's development is tightly held, everyone else is left with no outlet other than to complain. OSM is a very open project in general, but iD's development is very tightly held and opinionated. FUD around editors has been discussed to death and it's clear that writing more emails won't do anything. Fear uncertainty and doubt implies the criticism is invalid. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
I agree 100% that iD is making editing mistakes easier, out of proportion to the degree to which it makes editing by new users easier. The delete user interface is particularly fragile, encouraging the most pernicious form of damage: silent deletes. That goes for both the main map, and associated relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Jo Walsh wrote: On the one hand I'm sorry to hear that communicating and fixing is a distraction from mapping for you, I understand how he feels: When I happen to correct a lot of stupid errors sometimes I feel like there are a lot of stupid mappers. :) on the other you're starting to sound like a candidate member of the DWG ;) Maybe consider it, validating an activity you're pursuing anyway... +1 (but not for me, thank you all the same (: ) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Folks, This post doesn't represent the DWG in any way, but as someone who does DWG work, and closely monitors his local area, I think I have a bit of expertise in this area. In my experience, iD users do not make any more mistakes than any other editor in relative terms. In other words- if 80% of edits are done in iD- then we should see 80% of mistakes by iD users. In my experience, the kinds of editor errors that are being discussed (deletion of objects, etc.) are not happening in a greater relative quantity by iD users than any other editor- and for the kinds of issues that the DWG gets involved in, eg edit wars and problematic imports, JOSM users are by far the biggest problems. The fact is that the amount of data issues we have with OSM users is decreasing, not increasing. iD's tagging support makes things generally better for the beginner and intermediate user. We do have problems the things like addresses, splitting of features and especially relations- but I'd argue that these are not the editor's problems. Addresses in OSM are confusing because we have so many different ways to represent addresses (as attributes of a node, as attributes of a building, as a raw node inside a building, as a relation, as an associatedStreet, etc.), and relations are very complicated. Multipolygon could be replaced with something like area as proposed by Jochen, but until that happens, we're stuck with a very complex data representation that's a pain to understand and an even bigger pain to work with. This is fundamental to the data model itself, and not the editor. I'm not an iD user myself, and I do think that the developer/community communication could be improved, but it's been a large net positive for our project. - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Hi, Am 2015-02-11 um 17:25 schrieb Tom MacWright: Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. This. Help with development or give productive feedback on the issue tracker. FUD around editors has been discussed to death and it's clear that writing more emails won't do anything. The relation issue has been reported almost two years ago. https://github.com/openstreetmap/iD/issues/1461 This fact makes me to suggest everyone, every newbie, not to use iD. https://lists.openstreetmap.de/pipermail/stuttgart/2015-February/000526.html (in German) From my point of view, there is huge difference in opinion between iD developers and the mappers who clean up after an iD mapper has damaged something. There are some cases where the Don't confuse the user by popup warnings (it seems that this is the development goal of iD) does not work. Relations are an example. https://github.com/openstreetmap/iD/blob/master/README.md says: It lets you do the most basic tasks while not breaking other people's data. I can just laugh out loudly. Best regards Michael signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
That ticket doesn't have a difference of opinion: it has a core developer of iD offering to buy a cake for whoever contributes a fix. Nobody has contributed a fix: one would be accepted if it was contributed. Plus, we'd give that person a cake. That isn't a difference of opinion: there's no opposition. There's encouragement and an offer of reward for help. There's limited time the core developers have to work on iD, and they accept snark and hatred when they do. So no, that isn't a difference of opinion. It's a place where we need help and aren't getting it. Threads like this don't help. On Wed, Feb 11, 2015 at 12:45 PM, Michael Reichert naka...@gmx.net wrote: Hi, Am 2015-02-11 um 17:25 schrieb Tom MacWright: Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. This. Help with development or give productive feedback on the issue tracker. FUD around editors has been discussed to death and it's clear that writing more emails won't do anything. The relation issue has been reported almost two years ago. https://github.com/openstreetmap/iD/issues/1461 This fact makes me to suggest everyone, every newbie, not to use iD. https://lists.openstreetmap.de/pipermail/stuttgart/2015-February/000526.html (in German) From my point of view, there is huge difference in opinion between iD developers and the mappers who clean up after an iD mapper has damaged something. There are some cases where the Don't confuse the user by popup warnings (it seems that this is the development goal of iD) does not work. Relations are an example. https://github.com/openstreetmap/iD/blob/master/README.md says: It lets you do the most basic tasks while not breaking other people's data. I can just laugh out loudly. Best regards Michael ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
We have been saying this from the very beginning, so it should have been taken into account right from the very start of development of iD. Don't break other contributor's data should have been among the initial design goals. Don't bother the user with dialogs when they're about to break something should not be a design goal at all. Odd that such an important item would have to be added in retrospect. Worse, it's absurd. Polyglot 2015-02-11 21:15 GMT+01:00 Mike N nice...@att.net: On 2/11/2015 2:49 PM, Bryce Nesbitt wrote: Read through the issue tracker: It's clear that issues reported are pushed back on by the core iD developers. It's very tightly held. I disagree (not a developer here). The interesting thing that came out of this discussion is the realization that none of the key problems that people are seeing have an outstanding pull request. If the pull request is rejected, then you have a point. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On 2/11/2015 2:49 PM, Bryce Nesbitt wrote: Read through the issue tracker: It's clear that issues reported are pushed back on by the core iD developers. It's very tightly held. I disagree (not a developer here). The interesting thing that came out of this discussion is the realization that none of the key problems that people are seeing have an outstanding pull request. If the pull request is rejected, then you have a point. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 8:47 AM, Tom MacWright t...@macwright.org wrote: How is an open source project that was open source on day one, was publicly communicated from day one, heavily explained in time-consuming technical blog posts, has 77 contributors, and has accepted hundreds of pull requests tightly held. Read through the issue tracker: It's clear that issues reported are pushed back on by the core iD developers. It's very tightly held. In terms of design ideas, it's particularly tightly held compared to comparable projects. *Saying it's not tight just does not match the record.* Beyond the tight control, iD is opinionated software. *That's more of an observation than a judgement by the way. * There's a particular focus on fulfillment of iD's funding mission to be an entry level editor, pulling new mappers into OSM. That results in a particular aversion to introducing any sort of complexity, even when the underlying editing is complex. I think that's not really working: iD instead leads new users down roads and into editing jobs they can't correctly complete. iD could, but does not, help users identify interesting and fulfilling editing at the level of the user. iD is helping to breed and support a class of mapper who is not integrated with, or in contact with, other similarly situated contributors. It's really a missed opportunity. A number of specific issues illustrate this point: among them the delete issue, and the relation deletion issue. But it's deeper than those marquee subjects. There's clearly some pretty deep differences in focus between iD developers focusing on maximizing raw input into the system, and cleanup style editors who are on the receiving end of those changes. -- In short: pushing patches to the iD tracker won't help. Making time consuming technical blog posts won't help if goals are out of alignment. Cleanup-oriented editors have been unhappy with iD for a long time: and don't seem to feel respected by the iD core developers. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 9:59 AM, Tom MacWright t...@macwright.org wrote: That ticket doesn't have a difference of opinion: it has a core developer of iD offering to buy a cake for whoever contributes a fix. Nobody has contributed a fix: one would be accepted if it was contributed. Plus, we'd give that person a cake. There are certain tasks where challenging people to supply a patch is almost like saying no softly. This one feels like a core developer task, not a good candidate for a first timer patch yummy cake not withstanding. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
There's no magic to working on iD: 77 people of varying skill levels have done it. It takes time. If this is important to you, I'd suggest you invest that time rather than ordering other people to. On Wed, Feb 11, 2015 at 2:53 PM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 9:59 AM, Tom MacWright t...@macwright.org wrote: That ticket doesn't have a difference of opinion: it has a core developer of iD offering to buy a cake for whoever contributes a fix. Nobody has contributed a fix: one would be accepted if it was contributed. Plus, we'd give that person a cake. There are certain tasks where challenging people to supply a patch is almost like saying no softly. This one feels like a core developer task, not a good candidate for a first timer patch yummy cake not withstanding. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. https://github.com/openstreetmap/iD/commit/22fab3eb1d259fe73d3e1498df1ca0e07c613f87 On Wed, Feb 11, 2015 at 4:00 PM, Jo winfi...@gmail.com wrote: We have been saying this from the very beginning, so it should have been taken into account right from the very start of development of iD. Don't break other contributor's data should have been among the initial design goals. Don't bother the user with dialogs when they're about to break something should not be a design goal at all. Odd that such an important item would have to be added in retrospect. Worse, it's absurd. Polyglot 2015-02-11 21:15 GMT+01:00 Mike N nice...@att.net: On 2/11/2015 2:49 PM, Bryce Nesbitt wrote: Read through the issue tracker: It's clear that issues reported are pushed back on by the core iD developers. It's very tightly held. I disagree (not a developer here). The interesting thing that came out of this discussion is the realization that none of the key problems that people are seeing have an outstanding pull request. If the pull request is rejected, then you have a point. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
We also aimed to have no bugs and like every software project before us, have failed to achieve that goal. The uproar about iD is the same as the uproar about the map style, website, user groups, code of conduct, Steve Coast, the board, imports, license change, attribution, and practically everything else about OpenStreetMap. It's not anti-iD bias, of course. It's anti-everything bias. On Wed, Feb 11, 2015 at 6:33 PM, Bryce Nesbitt bry...@obviously.com wrote: On Wed, Feb 11, 2015 at 1:08 PM, Tom MacWright t...@macwright.org wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. This goal does not appear to have been carried out. The iD project comes off as tone deaf to breaking data concerns: Look at the uproar over issues of breaking data. Look at the core team response, which is mostly defensive posturing, not oriented to solutions. Why has iD taken such a beating on the mailing list breaking data issues? I don't think it's just anti-iD bias. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 1:08 PM, Tom MacWright t...@macwright.org wrote: Ever since 2012, in the second commit ever, Not breaking other people's data has been one of the three clearly stated public design goals of iD. This goal does not appear to have been carried out. The iD project comes off as tone deaf to breaking data concerns: Look at the uproar over issues of breaking data. Look at the core team response, which is mostly defensive posturing, not oriented to solutions. Why has iD taken such a beating on the mailing list breaking data issues? I don't think it's just anti-iD bias. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
Maybe this is an obvious one, but why not just write the user who made the error a nice note? One of my first edits was an error, and somebody (Jaakko Helleranta from HOT, it turns out) wrote me a nice note, something like hey, thanks for editing, I notice you did X but probably should have done Y, and here's why with links and whatnot. I appreciated it. I've done that since a few times when I noticed a person making repeated errors and always got nice responses back. It might take a minute but it's well worth it, both to build community and to save time in the long run with better data and fewer errors that need fixing. People who want to edit a map are generally nice people. Andrew On Tuesday, February 10, 2015, colliar colliar4e...@aol.com wrote: Hey Maybe, it is me only to slow in reverting and solving these mistakes or even the bugs I incounter in JOSM while working but I am definitely feed up with talking about the same things over and over again and I am probably not even polite enough to do the job of communicating. So what to do ? Silently reverting is not an option. Always getting DWG involved neither. I am fed up with: * iD making it way to easy to delete objects but not offering an option to undelete them (is there any history information at all ?) * simply combining ways and merge nodes without any validation or warning about conflicts in tags or problems with relations * not telling the user about the importance of all tags, even unknown to the software and allowing user to communicate with user of the last change of the object Any plans of supporting lanes-tagging-system ? Otherwise there will be even more complains in the future. Is there anyone taking care of mistake made by iD users and documenting the most common ones to either better explain how to avoid them and/or fix the software ? As iD is supposed to be the newbie editor all mistakes will rather turn them down than encourage them. So far, I try to keep calm and rather save my changes and upload them later after solving conflicts instead of starting an edit war by reverting or uploading older versions but I spend more time with communication and investigating problems than actually mapping and resolving notes and I still have quite some gpx tracks and photos from over a year ago to map. How about simply denying some changes with iD like combining ways ? Cheers colliar -- 600,000 DC residents don't have a vote in Congress -- http://www.dcvote.org/ http://www.dcvote.org/about/index.cfm ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On Wed, Feb 11, 2015 at 4:41 PM, Andrew Wiseman awise...@gmail.com wrote: People who want to edit a map are generally nice people. +1 -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
On 10/02/2015 23:38, colliar wrote: ... I am fed up with ... ... at this point it's probably worth mentioning that we've been here before: https://lists.openstreetmap.org/pipermail/talk/2013-August/thread.html#67854 Unfortunately, experience suggests that there's relatively little that a discussion on on the talk mailing list is going to be able to do here. There are essentially two sides to the argument - at one extreme new mappers should never be able to break data (and if they can't edit at all because they can't understand what they need to do, tough) and at the other new mappers must have everything complicated hidden from them (and if some complicated OSM structure breaks, tough). Obviously you're not at one extreme and the iD developers aren't at the other, but there _is_ a difference of opinion here that it's not easy to reconcile. If you want new mappers, you have to actually allow them to map. If you've got specific examples of things that new users get wrong consistently (and even better if you can understand what they've done wrong and why) then I suspect that it would really help would be to raise an issue on Github about it, or add to an existing one if one already exists. * iD making it way to easy to delete objects but not offering an option to undelete them (is there any history information at all ?) Whilst I'm in no way a fan of the iD user interface, even I had no problems finding the undo button. I don't think that new mappers tend not to find it either, since an answer to the common question what do I do if I get a conflict is undo back past the problem, and new mappers haven't said (on the help site or on IRC) how do I undo? * simply combining ways and merge nodes without any validation or warning about conflicts in tags or problems with relations What might help here is to get details from the new mapper concerned of how they felt that they needed to merge nodes or ways. The merge operation is fairly visually obvious when it happens; what's not so obvious is that the resulting merged node with semicolon-separated tag values isn't particularly useful in OSM. There are a couple of merge Github issues; it may be that they already describe the problem that you are referring to here. * not telling the user about the importance of all tags, even unknown to the software and allowing user to communicate with user of the last change of the object I suspect that this comes down to the two sides to the argument mentioned above - the idea is that new mappers shouldn't have to worry about all tags (or indeed, where possible, tags at all). Any plans of supporting lanes-tagging-system ? Otherwise there will be even more complains in the future. This sounds like https://github.com/openstreetmap/iD/issues/387 to me. That's probably the best place to explain what you'd want the end result of a new mapper knowing about turn lanes would be. Is there anyone taking care of mistake made by iD users and documenting the most common ones to either better explain how to avoid them and/or fix the software ? Back in 2013 I did have a look, and came up with this: https://lists.openstreetmap.org/pipermail/talk/2013-August/068018.html Since then the Thing X changed to thing Y problem has been much diminished by the fix for iD issue 542. POI added without a main tag is still pretty common, and unexpected deletions are rarer than the were (perhaps also because of the iD 542 fix). The initial who made what sort of error analysis was in https://lists.openstreetmap.org/pipermail/talk/2013-August/067936.html , and note that in there iD new users made statistically fewer serious errors than P2 ones (or, on a very low sample size, JOSM users). I don't have the numbers, but based on a gut feel since 2013 I'd say that currently the editor for which the highest proportion of new users are going to cause _widespread_ problems is probably JOSM. ... So far, I try to keep calm and rather save my changes and upload them later after solving conflicts instead of starting an edit war by reverting or uploading older versions but I spend more time with communication and investigating problems than actually mapping and resolving notes and I still have quite some gpx tracks and photos from over a year ago to map. Supportive communication with new users is really important, so thanks for taking the time to do this. I don't believe that OSM has an iD users problem; it has a new mappers one - or more accurately, a data far more complicated than it needs to be problem which means even experienced mappers can have problems. For example, have a look at this help question and the ones that it links to: https://help.openstreetmap.org/questions/40792/editing-large-multipolygons-in-josm Those were asked by an experienced OSM mapper who usually edits in JOSM - how's someone without an in-depth knowledge of how OSM data is organised or any of
Re: [OSM-talk] this has to stop: iD user mistakes all over the place
What might help here is to get details from the new mapper concerned of how they felt that they needed to merge nodes or ways. I use changeset discussions a fair bit, partly because they end up right in the new mapper's inbox, and that provides a link to an outside view of the new mapper's changes. I always wish it was more obvious how to explore the history of the related nodes and ways and see the editors of related changesets from the changeset landing page, but at least it's all there in the links, at least in theory. Ideally a calm discussion leads to someone engaging a bit more and fixing the problem themselves, though more often it's a polite prelude to a future reversion :/ * not telling the user about the importance of all tags, even unknown to the software and allowing user to communicate with user of the last change of the object ... So far, I try to keep calm and rather save my changes and upload them later after solving conflicts instead of starting an edit war by reverting or uploading older versions but I spend more time with communication and investigating problems than actually mapping On the one hand I'm sorry to hear that communicating and fixing is a distraction from mapping for you, on the other you're starting to sound like a candidate member of the DWG ;) Maybe consider it, validating an activity you're pursuing anyway... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] this has to stop: iD user mistakes all over the place
Hey Maybe, it is me only to slow in reverting and solving these mistakes or even the bugs I incounter in JOSM while working but I am definitely feed up with talking about the same things over and over again and I am probably not even polite enough to do the job of communicating. So what to do ? Silently reverting is not an option. Always getting DWG involved neither. I am fed up with: * iD making it way to easy to delete objects but not offering an option to undelete them (is there any history information at all ?) * simply combining ways and merge nodes without any validation or warning about conflicts in tags or problems with relations * not telling the user about the importance of all tags, even unknown to the software and allowing user to communicate with user of the last change of the object Any plans of supporting lanes-tagging-system ? Otherwise there will be even more complains in the future. Is there anyone taking care of mistake made by iD users and documenting the most common ones to either better explain how to avoid them and/or fix the software ? As iD is supposed to be the newbie editor all mistakes will rather turn them down than encourage them. So far, I try to keep calm and rather save my changes and upload them later after solving conflicts instead of starting an edit war by reverting or uploading older versions but I spend more time with communication and investigating problems than actually mapping and resolving notes and I still have quite some gpx tracks and photos from over a year ago to map. How about simply denying some changes with iD like combining ways ? Cheers colliar 0xE8F56581.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
