> I see that the problem in iD is really easy to solve (much easier than in Potlach).
Please never say this. Estimating that someone else's task, in their domain of experience, is simple, is almost always incorrect, and usually overstepping. "This painting looks pretty easy to paint: can you finish it in an afternoon." If something is easy to do, please try doing it yourself and seeing whether it is. Otherwise, don't tell other people that things should be easy for them to do, so they should do what you want. People have been saying for quite a while that it would be pretty easy for us to improve the software that manages and edit OpenStreetMap, but none of them have decided to do it in an afternoon, much less own the responsibility of maintaining and defending the changes. iD has, to date, consumed thousands of hours of developer time, communications, documentation authoring, and design. The same goes for Potlatch and JOSM and the website. Developing these projects is even more time-consuming because every change needs to be discussed to death, everyone must be consulted, and then after release, we have to catch up with all of the people who want to be consulted but don't read the mailing list. In short, if you believe this is easy, do it. Otherwise, don't underestimate other people's tasks. On Sun, Jun 28, 2015 at 2:34 PM, Fernando Trebien < fernando.treb...@gmail.com> wrote: > On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst <rich...@systemed.net> > wrote: > > What is unacceptable is the relentless, harrying, dismissive, abusive > manner > > in which you and others advance the former view over the latter. That is > why > > we cannot retain developers. > > We really need to be careful to target the philosophical standpoint, > not the people. As I said (now countless times), iD is awesome. I > don't think I've been criticizing developer talent or code quality. I > wouldn't have provided most of its translations into my language if I > thought differently. Anyway, should this conversation be about iD? In > a way yes, but not only. Other editors (except JOSM) seem to have the > same aversion of relations. Relations are valuable and are not going > away, several of them (the most critical being "route") have been > approved long ago by the community (by consensus, by public voting), > so I believe fighting them only make things worse. Fighting them is > fighting the community. Others, such as boundary, are de facto > standards. They have to be properly tamed. One way is to hide them so > that only "clever" people can deal with them. Another is to teach > everybody in the simplest possible manner so that they become widely > accessible. > > Cliché quote: "Make things as simple as possible, but not simpler," > some attribute to Einstein. > > When people are deleting and combining ways, they are editing > invisible data - tags and parent relations. In a world without > relations, combining different tags would still be an issue. For > instance, the "sidewalk" tag is not visible. It should be visible. If > it ever becomes visible, there is still a huge repository of approved > tags that won't be. The current approach - concatenation - is > essentially invisible in many situations (the user must pay a lot of > attention at the result). I would like to see a scenario where a > casual mapper (the target audience of all editors besides JOSM) would > prefer not to be notified about a potential mistake. I do mapping > sprints very often, I'm knowledgeable, and even so I prefer to get > interrupted in my mapping whenever I do something potentially > damaging. Without that, even with my experience, I would have broken > data multiple times. How is that casual mappers would prefer not to > have that? It is a contradiction to design the application for casual > mappers and still place fastest mapping at utmost priority. A casual > mapper is not aware of the data model, and should not be expected to > be so. > > Back to the problem that motivated me into this discussion: I see that > the problem in iD is really easy to solve (much easier than in > Potlach). If there is an objection to an interaction-blocking modal > window, other non-blocking visual cues can be used, such as a > distinctive alert bar at the bottom, an alert icon at the action > button, and an alert log on top after an action breaks something. > Anything that informs the user is fine. It is not done only due to a > philosophical opinion, which I think is negative to OSM as a whole. > The opinion is negative, not the people that hold it. Maybe people are > also being idealistic: instead of implementing a little workaround, > they'd rather wait and see if a cleverer, less intrusive solution > emerges. It is clearly not happening, after two years of waiting and > wondering by the most involved minds in the project. Getting a simple > alert when deleting relation members was a huge struggle. Since > "combining" implies "deleting" I don't think the current issue should > need to be so widely discussed. The only reason I don't set out and > try writing my own editor (which is a pretty big undertaking) is that > my country's map still needs lots of data, and my country's community > still needs lots of support. Potlatch, iD and JOSM have solved that, > mostly. All I ask for is a minor refinement, which I believe is good > not only here but in the whole world. > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "Nullius in verba." > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
